Outils et langages
Objectif(s)
L'objectif est d'apporter la preuve que les outils utilisés ou les langages ne nuisent pas à la sécurité du logiciel développé.
Documents en entrée
Spécifications des outils ou manuel
Documents en sortie
Le document éventuellement en sortie de cette activité est le rapport de validation des outils. Mais ce rapport n'est à fournir que si cela s'avère nécessaire. La justification peut très bien se trouver au niveau du plan d'assurance qualité du logiciel si les justifications peuvent être facilement énoncées.
Contraintes
Contraintes liées aux outils
La norme recommande l'utilisation d'outils permettant notamment de limiter l'introduction de défauts. Plusieurs exemples de catégorie d'outils sont donnés, comme les outils permettant le passage d'une version abstraite d'une conception à une version plus concrète, les outils de vérification comme les outils d'analyse statique de code, les outils de compilation de code source en code exécutable, les outils de gestion de version, etc
La norme définit trois classes d'outils pouvant intervenir dans le développement :
Classe T1 : il s'agit des outils n'ayant pas d'impact sur le code exécutable du logiciel ou aux données utilisées. Dans cette catégorie d'outils se trouvent les éditeurs de texte par exemple ou des outils de conception si il ne génère pas de code.
Classe T2 : il s'agit des outils permettant le test ou la vérification de la conception ou du code exécutable. Un dysfonctionnement d'un outil de cette catégorie pourra entraîner une non détection d'un défaut, mais en aucun cas l'outil ne créera de défaut dans le logiciel exécutable.
Classe T3 : il s'agit de la catégorie des outils qui contribuent au code exécutable ou aux données utilisées. C'est dans cette catégorie que se retrouveront les compilateurs par exemple.
En fonction de la classe d'outils d'appartenance, il est nécessaire d'apporter des justifications de l'utilisation et cela pour chacune des versions utilisées (sauf pour les outils de classe T1 qui n'ont pas d’impact sur le produit final). Prenons l'exemple de l'utilisation d'un outil de classe T3. Il faudra fournir pour cet outil un manuel ou une spécification du comportement de l'outil. Il est également nécessaire de fournir la liste des défaillances potentiellement introduite par l'utilisation de l'outil ainsi que les mesures prises pour la prise en compte de ce risque. Il faudra également fournir la preuve que la sortie de l'outil est conforme à sa spécification (ou que les défaillances sont détectées afin de prendre les mesures pour y remédier). Cette preuve pouvant être difficile à fournir (reprenons l'exemple du compilateur), il est possible par exemple de se baser sur un historique de l'utilisation de l'outil pour des applications relativement similaires et pour un contexte d'utilisation également relativement similaire. Si la preuve ne peut être donnée, il sera nécessaire de mettre en œuvre des mesures pour la maîtrise des risques associés à l'utilisation de l'outil.
Dans certains cas, comme le développement d'un outil interne, il peut être nécessaire de fournir un rapport de validation de l'outil. Ce rapport indiquera précisément le produit qui est validé ainsi que toutes les informations permettant de connaître précisément le contour de la validation (version de l'outil, de son manuel, fonctions validées, scenarii de test et résultats de leur exécution, etc)
Contraintes liées au langage
Nous parlons ici de langage, mais par langage, il faut comprendre langage de programmation mais également langage de représentation de spécification. La norme parle de représentation du logiciel ou de la conception. Les langages étant accompagnés d'outils, s'inscrivent dans les justificatifs nécessaires énoncés au point 1, d'autant plus que la norme indique qu'il est nécessaire qu'un traducteur existe pour le langage. Ce qui vient en plus des contraintes outils est le fait que le langage choisi doit faciliter la détection d'erreurs de conception ou de programmation et être compatible avec la méthode de conception.
