Normalisation et informatique dans le domaine des transports : 2 exemples de normes

Vérification du logiciel

Objectif(s)

Extrait de la norme, dans la contrainte 6.2.1.1 : "L'objectif de la vérification du logiciel est d'examiner et parvenir à un jugement fondé sur la preuve que les éléments de sortie (processus, documentation, logiciel ou application) d'une phase de développement spécifique satisfont aux exigences et aux plans en ce qui concerne la complétude, l'exactitude et la cohérence."

Documents en entrée

Tous les documents nécessaires sur le système, le matériel et le logiciel. Sous cette formulation un peu générale, on retrouve bien la préoccupation que la vérification va se faire durant tout le processus de développement du produit et donc à toutes les phases, transition de phases se retrouvera une activité de vérification. Voila pourquoi l'intégralité de l'activité de vérification requiert l'intégralité de la documentation.

Documents en sortie

Le document spécifiant les activités de vérifications à mener (le plan de vérification du logiciel), les rapports de vérifications (un rapport pouvant agréger l’ensemble des rapports liés à une phase particulière) et le plan de vérification de l'assurance qualité du logiciel (un point concerne plus spécifiquement cette activité dans la suite).

Contraintes

  1. Exigences liées au plan de vérification du logiciel

    Le plan peut être établi par étape en fonction de l'avancement du projet (pour les projets complexes). Le plan doit énoncer les critères, les techniques et les outils à utiliser pour mener à bien la vérification. Les techniques et mesures utilisées pour la vérification doivent être énoncées ainsi que la justification que leur combinaison permet de conclure. Elles sont à choisir dans les tableaux de l'annexe A de la norme.

    Prenons un exemple de combinaison spécifiée dans l'annexe A (tableau A5) : une combinaison approuvée est la mise en œuvre d'une traçabilité des exigences avec soit une analyse statique, soit une analyse et des tests dynamiques, soit des tests fonctionnels boite noire pour un niveau SIL 1 ou 2. Pour un niveau 3 ou 4, une combinaison approuvée consiste à mettre en œuvre la traçabilité, l'analyse et des tests dynamiques, la couverture de test pour le code, des test fonctionnels boite noire avec en plus au choix, soit une preuve formelle, soit une analyse statique ou soit une analyse des effets des erreurs logiciels. Nous ne détaillons pas ici ces différentes techniques, mais nous voyons bien qu'entre un niveau 1 et un niveau 4 de sécurité logiciel, l'ensemble des techniques à mettre en œuvre est de plus en plus important. D'autres combinaisons sont bien évidemment possibles, il s'agit dans ce cas de justifier de l'acceptabilité de la combinaison.

    Le plan de vérification doit énoncer les vérifications nécessaires pour l'entrée dans chaque phase ainsi que les personnes devant effectuer la vérification. Par exemple, le plan peut exprimer que pour commencer la phase de codage d'un module du logiciel il faut avoir mené une activité de revue du document de spécification détaillée des exigences logicielles de ce module.

  2. Exigences liées aux rapports de vérification du logiciel

    Sous la responsabilité du chargé de vérification, et comme pour tous les rapports, le rapport de vérification doit clairement identifier ce qui est vérifié (référence des documents, du produit logiciel, etc). Le rapport reprend les non conformités relevées ainsi que les résultats de vérification.

  3. Exigences liées au rapport de vérification de l'assurance qualité du logiciel

    Ce rapport doit comporter le résultat de l'analyse du plan de vérification, de sa cohérence vis à vis des contraintes qui lui sont applicables, de sa lisibilité, de sa traçabilité.

PrécédentPrécédentSuivantSuivant
AccueilAccueilImprimerImprimerRéalisé avec Scenari (nouvelle fenêtre)