Assurance qualité du logiciel
Objectif(s)
L'objectif de l'activité assurance qualité du logiciel est de mener des activités permettant de garantir un niveau de qualité suffisant au regard de la norme. L’objectif majeur est d'enregistrer les activités menées afin de garder une trace de celles ci.
Documents en entrée
Tous les documents. En effet, cette activité est comme pour la vérification et la validation transverse et présente à chaque étape.
Documents en sortie
Les documents à fournir sont le plan d'assurance qualité du logiciel ainsi que le rapport correspondant pour la vérification de l'assurance qualité du logiciel. L'activité peut également être l'occasion de fournir le plan de gestion de la configuration du logiciel si celui ci n'a pas été établi au niveau système du projet. Il est à noter que ces plans doivent être établis au commencement du projet et faire l'objet d'évolutions durant le développement du projet. Le plan d'assurance qualité du logiciel est le document central et référence pour toutes les activités qui vont être menées dans le développement du logiciel.
Contraintes
La norme stipule que l'organisation qui mène le projet doit mettre en œuvre un système qualité conforme à la norme ISO 9000. La certification ISO 9001 est hautement recommandée, ce qui signifie que si la structure n'est pas certifiée ISO 9001, une justification doit être apportée.
Contraintes liées au plan de gestion de la qualité du logiciel
Le plan doit lister le modèle du cycle de vie en définissant toutes les activités élémentaires à mener ainsi que les contraintes de passage d'une phase du développement à une autre et les responsables de chacune des phases. Pour chacune des étapes, les activités spécifiques en terme d'assurance qualité doivent également être spécifiées. C'est également dans ce plan que se retrouvent les techniques et méthodes mises en œuvre pour le projet (pour le test par exemple) ainsi que la justification de l'adéquation de ces choix vis à vis de la norme. Le plan doit détailler comment sont suivis les anomalies, les écarts décelés. La localisation physique de tous les éléments peut se retrouver dans des documents divers, mais dans ce cas le plan d'assurance qualité du logiciel doit faire référence à ces documents.
Contraintes liées au rapport de vérification d'assurance qualité du logiciel
Les contraintes qui régissent le rapport de vérification de l'assurance qualité du logiciel sont identiques aux autres activités, à savoir qu'il est nécessaire de vérifier que le plan satisfait bien les exigences de lisibilité et de traçabilité générale, il doit également vérifier que le plan sur lequel il porte (ici le plan d'assurance qualité du logiciel) est bien conforme aux exigences de la norme.
Contraintes liées à la gestion de configuration
La gestion de configuration consiste à garder une trace de toutes les versions de ce qui est produit lors du développement d'un logiciel, à la fois en terme de documentation, de version logiciel, etc. Elle sert également à former une référence cohérente entre les éléments, c'est à dire à lister par exemple que pour le produit logiciel en version 1.0, le document de spécification des exigences du logiciel est en version X, que tel module logiciel est en version Y, que c'est la version Z de telle recommandation ou règle de fonctionnement interne, que telle version d'outil de développement et de compilateur a été utilisée. L'idée de cela est, en plus d'enregistrer l'état et de vérifier de la conformité des éléments constitutifs du tout, d'être capable de se remettre dans l'état pour la production de la version du logiciel 1.0.
Autres contraintes exprimées
Le contrôle des fournisseurs
Certains développements peuvent être menés par des entités externes à l'entreprise qui mène le projet, soit par le fait de la mise en sous traitance d'une partie de l'activité, soit par le fait d'utiliser des outils développés en externe (ce qui peut être le cas d'un compilateur par exemple). Dans le premier cas, il est nécessaire de formaliser les échanges avec le fournisseur externe et de mettre en place une vérification du produit livré afin de vérifier que celui ci est bien conforme à ce qui est attendu (tant en terme de produit que de méthode de développement, etc). En ce qui concerne l'utilisation de produit externe, reprenons l'exemple du compilateur, il est nécessaire d'apporter la preuve que son utilisation est conforme au niveau de sécurité du logiciel en développement. La justification peut prendre différentes formes, allant de la certification de l'outil à une justification de son utilisation dans différents projets ayant une contrainte de sécurité ou non.
la traçabilité
La notion de traçabilité a déjà été évoquée, ce qui est normal car il s'agit du concept de base de la mise en œuvre de la norme, il s'agit de savoir du début à la fin de où viennent les éléments et où ils sont ensuite utilisés. Même si l’exigence de gestion de la traçabilité diffère entre les niveaux de sécurité, à tous les niveaux, il est nécessaire de la mettre en œuvre. La traçabilité doit permettre de vérifier la prise en compte des exigences de sécurité dans le développement logiciel et de suivre le chemin de cette prise en compte dans les divers documents jusqu'au code. Il en va de même pour les exigences non sécuritaires. En cas de défaut dans la traçabilité d'une entité, il faut apporter la preuve que celle ci n'a pas d'impact au niveau de la sécurité du logiciel, cela passe par une analyse des potentielles défaillances pouvant apparaître.
