16 Janvier 2012

Qualité Logiciel - AP-7

Établir les règles pour obtenir un niveau de qualité des logiciels suffisant

A. Objet

Le présent chapitre a pour but de présenter des exigences Qualité Logiciel simplifiées permettant d'obtenir un niveau de Qualité Logiciel minimum pour les logiciels d'application non critique et à petit budget développés pour le CNES, par les industriels fournisseurs, par les laboratoires scientifiques ou en interne au CNES, pour les projets scientifiques. Les exigences qualité telles qu'énoncées dans le document « RNC-ECSS-Q-ST-80 Software product assurance » peuvent être adaptées en relation avec le niveau de risque acceptable.

Il sert :

  • dès la phase A pour définir le cadre de développement aux futurs réalisateurs ;
  • de base aux discussions avec le réalisateur de logiciels dès le début des développements (fin de phase B - début de phase C) afin de finaliser les dispositions pratiques. Ces dispositions seront définies lors de réunions de travail entre le CNES et ses fournisseurs ; elles seront formalisées dans la proposition du fournisseur reportées dans un plan d'application.

 

B. Principes

1. Méthode

Tout développement de logiciel doit être mené selon des règles préétablies, en réponse aux exigences du CNES.

La réponse à ces exigences est reportée dans un plan d'application (dont un plan-type est donné en annexe Plan d'application), qui traduit l'engagement du fournisseur sur la prise en compte de ces exigences. Ce plan est soumis à l'acceptation du client livré avant le début des activités qu'il décrit

Le fournisseur doit préciser l'organisation et les responsabilités de l'équipe en charge du développement, en particulier identifier la personne responsable de l'assurance qualité logiciel, ainsi que les dispositions d'Assurance Produit qu'il met en place (comprenant au minimum la gestion de configuration documentaire et logicielle et la gestion des faits techniques) et la planification des activités correspondantes.

Si des formations sont nécessaire pour combler les manques éventuels des compétences disponibles dans l'équipe de développement, elles doivent être listée dans la plan.

Les sous traitants du fournisseur doivent également se conformer aux principes énoncés dans ce document.

2. Cycle de développement

Une analyse de besoins doit être menée avant tout développement de logiciel.

Après la phase d'analyse des besoins, le cycle de développement du logiciel doit comporter les phases suivantes :

  • spécifications,
  • conception,
  • codage - tests unitaires,
  • validation,
  • recette.

 

Dans le cas d'un logiciel intégré, le logiciel participe en tant que constituant à la phase d'intégration matériel/logiciel et son cycle de développement doit être cohérent avec celui du matériel.

Si le fournisseur souhaite utiliser un cycle de développement itératif ou en spirale, les itérations doivent être décrites dans le plan de développement du logiciel selon les critères suivants :

  • objectifs,
  • activités prévues (qui peuvent reprendre tout ou partie des activités prévues dans les phases classiques du cycle de vie),
  • critères d'achèvement,
  • conditions de réalisation de l'itération.

 

2.1 Phase de Spécification du logiciel

Les spécifications du logiciel permettent :

  • d'identifier les besoins exprimés par le client puis de les traduire en termes de fonctions, d'interfaces avec l'extérieur et entre elles ;
  • de préciser les enchaînements de fonctions ;
  • de préciser les contraintes (performances, priorités, encombrement mémoire) ;
  • d'analyser, en fonction des besoins à couvrir, les logiciels qui pourraient être réutilisés et d'évaluer les impacts de leur réutilisation sur le développement (cf. paragraphe 3 « Logiciels réutilisés »).

 

Ces éléments seront décrits dans le document de spécification du logiciel (dont un plan-type est donné en annexe Document de spécification).

Cette phase a également pour but :

  • de préparer une première version du document de validation ;
  • de définir une première version d'un manuel d'utilisation ;
  • éventuellement d'élaborer une maquette de l'interface homme / machine.

 

Cette phase s'achève par une réunion technique (ou revue) de spécifications du logiciel (RSL) permettant de statuer sur les documents issus de cette phase et sur la réutilisation éventuelle de logiciels. Cette réunion technique doit se dérouler avec la participation des scientifiques et/ou des utilisateurs.

2.2 Phase de Conception

L'activité de conception consiste à :

  • définir le découpage structurel de l'application en constituants logiciels puis à détailler chacun d'eux ;
  • définir le flux de données et les interfaces ;
  • effectuer les estimations de ressources ;
  • préciser les interfaces homme / machine.

 

La conception du logiciel fait apparaître dans des éléments de conception différenciés les fonctions que l'on souhaite réutiliser de façon à pouvoir les valider de manière indépendante.

Le résultat de ces activités est décrit dans le document de conception (dont un plan-type est donné en annexe Document de conception).

2.3 Phase de Codage - Tests unitaires

Les activités à mener au cours de cette phase sont :

  • le codage des constituants,
  • l'exécution des test unitaires des constituants et des tests d'intégration entre constituants.

 

Les règles de codage à utiliser sont décrites dans le chapitre Méthodes, outils et règles.

On s'efforcera :

  • de choisir un langage évolué plutôt qu'un langage assembleur,
  • de réaliser tout le projet avec le même langage évolué.

 

2.4 Phase de Validation

La validation permet de vérifier que le logiciel remplit les fonctions spécifiées.

Les essais de validation doivent couvrir toutes les exigences de la spécification du logiciel.

Pour un logiciel intégré dans un équipement bord, la validation doit comporter des essais sur le modèle d'identification du matériel correspondant.

Ces essais doivent être effectués sur un logiciel stable, dont la version est gérée en configuration. Toute modification de la configuration au cours de la phase de validation doit être tracée.

La validation du logiciel doit être réalisée sur le modèle de laboratoire.

Au cours de cette phase seront finalisés le document de validation (dont un plan-type est donné en annexe Document de validation) complété par les comptes-rendus de tests et le manuel d'utilisation (dont un plan-type est donné en annexe.

Pour bien montrer que toutes les exigences de la spécification sont associées à au moins au test, il est commode d'utiliser une matrice de vérification associant ces éléments.

La phase de validation sera précédée par un bilan technique (BT) (cf. AP-15) et clôturée par une Commission de Revue d'Essai (CRE) (cf. AP-16).

Le bilan technique (BT), en début de phase de validation du logiciel, a pour objectif d'autoriser le démarrage des essais de validation.

Il permettra de :

  • vérifier l'état des actions,
  • vérifier la complétude et la cohérence du plan et des procédures de tests,
  • identifier l'état de la configuration et figer la version du logiciel correspondante.

 

À l'issue du BT, si l'autorisation de démarrage des essais est donnée, l'ensemble des procédures de test sera déroulé.

Durant les essais, les résultats de chaque essai (ou d'analyse) seront consignés dans un journal d'essais, ainsi que les anomalies et les modifications qui seront identifiées.

Dans la mesure du possible, les actions correctives associées aux anomalies et aux modifications identifiées ne seront effectuées qu'à la fin de la phase de validation et donneront lieu à une nouvelle version du logiciel.

Dans le cas contraire, toute évolution de la configuration au cours des essais sera consignée dans le Journal de Bord.

La Commission de Revue d'Essai (CRE), clôturant la phase de validation, permettra d'établir :

  • une synthèse des résultats de tests ;
  • un état des anomalies et des modifications résiduelles ;
  • un état des actions en précisant, pour celles qui sont ouvertes, leur date d'échéance et leur(s) responsable(s) ;
  • l'acceptation ou le refus de la fin de la phase de validation.

 

En cas de refus ou d'acceptation avec réserve(s), les actions à réaliser et leur date limite de réalisation apparaîtront explicitement dans le compte-rendu.

2.5 Recette

Dans le cas où il existe une recette du logiciel, celle-ci suit les activités et les principes définis ci-dessus pour la phase de validation du logiciel. La recette s'appuiera sur le cahier de recette extrait du document de validation du logiciel (dont un plan-type est donné en annexe Cahier de recette)et aura lieu après acceptation de la phase de validation.

Elle est précédée par un BT qui autorisera le démarrage des essais.

Elle se termine par une CRE au cours de laquelle sera prononcée ou non l'acceptation du logiciel développé.

C. Gestion de la configuration logicielle et documentaire, Gestion des modifications

La gestion de la configuration du logiciel correspond à l'ensemble des activités, manuelles ou automatiques, permettant d'identifier, à tout instant, les éléments créés, utilisés ou modifiés par le processus de développement du logiciel, et leurs relations.

Son but principal est de mémoriser chaque version de référence d'un élément, afin de connaître précisément à chaque instant la version utilisée et afin de pouvoir reconstituer, en cas de besoin, toute version antérieure.

1. Principes

La gestion de configuration du logiciel doit identifier, de manière unique selon les règles de nomenclature du projet, chaque élément à gérer.

Un membre de l'équipe projet sera désigné pour assurer la fonction de gestion de la configuration du logiciel.

Il aura pour tâche de :

  • définir les éléments à gérer ;
  • définir la version de référence ;
  • connaître les relations entre éléments d'une configuration donnée (afin, par exemple de pouvoir répondre à la question : « quels sont les tests de validation qui correspondent à cette version du logiciel ? ») ;
  • définir les moments de mise en configuration (d'archivage) d'un élément de la configuration ;
  • définir et appliquer les modalités de livraison du produit
  • produire le document de configuration.

 

Pour chaque version du logiciel, la gestion de configuration doit permettre :

  • d'identifier les documents avec leur référence et édition / révision
  • de sauvegarder sur un support identifié avec une étiquette de marquage non décollable précisant le nom du logiciel d'application et sa version / révision :
    • le produit (sources, données, procédures de génération),
    • les jeux de tests de validation,
    • les éventuels moyens d'essai spécifiques associés (simulateur, données, ...) ;
  • de connaître les références :
    • du support de sauvegarde (n° de bande par exemple) ;
    • des faits techniques (anomalies, corrections, demandes de modification),,
    • des logiciels de base (système d'exploitation, émulateur, moniteur temps réel, bibliothèques, compilateurs, éditeurs de liens, ...) ;
    • des matériels ;
    • des éventuels moyens d'essais ;
  • de restaurer, si nécessaire, un logiciel archivé.

 

1.1 Document descriptif de la configuration

Le fournisseur doit établir pour chaque version un Dossier Descriptif de la Configuration (DDC), inclus dans la livraison de la version du produit.

Celui-ci contient au minimum les fichiers suivants :

  • ddc.txt   identification de l'article
  • fa-couv.txt  liste des FA couvertes
  • dm-couv.txt  liste des DM couvertes
  • etat-fa.txt  liste des FA ouvertes
  • ls-doc.txt  liste des documents (CNES et fournisseur) associés au produit
  • ls-ref.txt  liste des fichiers constituant le produit

 

D. Méthodes, outils et règles

1. Principes

Les méthodes et éventuels outils support adaptés aux différentes phases du cycle de développement du logiciel seront choisis en fonction des compétences de l'équipe projet (plan de formation, expériences antérieures, ...) et de ses moyens financiers. L'utilisation de logiciels libres est fortement préconisée (en respectant les conditions de licence).

Le choix des outils devra être justifié dans le plan d'application ou son équivalent. On utilisera, dans la mesure du possible, des outils standards de manière homogène sur l'ensemble du développement.

Des règles de nomenclature seront définies, en particulier pour les variables d'interface. Ces règles sont cohérentes avec les conventions d'usage pour le langage de codage choisi.

2. Règles de codage

Un standard de codage est choisi par le fournisseur, soumis à l'acceptation du client et appliqué pour tout le codage. Il doit comporter en particulier les règles suivantes :

Les variables d'interface seront décrites sous forme de commentaires dans le code.

Chaque module de code respectera les règles suivantes :

Il comportera une entête commentaire contenant au moins les rubriques suivantes :

  • nom du projet ;
  • nom du module ;
  • version ;
  • auteur ;
  • date ;
  • rôle et but du module ;
  • paramètres en entrée, en sortie, ou en entrée/sortie, avec pour chacun :
    • son nom,
    • sa signification,
    • l'unité utilisée en cas de grandeur physique,
    • son degré de précision,
    • son domaine de valeur,
    • fichiers utilisés,
    • modules appelés,
    • modules appelants,
    • références des modifications ;
  • chaque ordre de saut conditionnel ou de rupture de séquence sera commenté en expliquant l'objet du débranchement ;
  • n'écrire dans le programme principal que le flot de contrôle du logiciel ;
  • un seul point d'entrée, un seul point de sortie pour toute unité compilable ;
  • toute partie de code doit être accessible (pas de code mort).

 

E. Conditions particulières de développement

1. Sûreté de fonctionnement des logiciels critiques

Une analyse fonctionnelle au niveau système doit être utilisée pour identifier les modules logiciels critiques, en tenant compte de l'interaction du logiciel avec son environnement.

Le fournisseur doit s'efforcer de concevoir les composants logiciels critiques aussi simplement que possible afin de faciliter l'analyse de la sûreté de fonctionnement et de la sécurité et les essais du logiciel.

Remarque : Attention si le logiciel est critique le fournisseur doit se conformer aux exigences du document  « RNC-CNES-Q-ST-80 » pour les niveaux A, B ou C et ne pas utiliser le GNS.

2. Logiciels réutilisés

Dans le cas où l'utilisation de logiciels existants (produits du marché, logiciels libres, autres produits) est envisagée, il faudra tenir compte dans le choix de ceux-ci, des éléments suivants :

  • l'évaluation du produit par rapport aux besoins ;
  • les conditions de recette et de garantie (démonstration de bon fonctionnement) ;
  • les conditions d'installation, de mise en oeuvre, de formation et d'utilisation ;
  • l'identification et la prise en compte par la gestion de la configuration ;
  • les conditions de maintenance ;
  • les éventuelles contraintes de propriété industrielle (droit d'utilisation ou de modification).

 

Pour les logiciels à adapter, il sera indispensable préalablement à toute modification de :

  • évaluer le taux de modifications ;
  • vérifier l'état de la documentation des logiciels existants afin de s'assurer de leur cohérence et complétude vis-à-vis du logiciel réutilisé ;
  • mettre en place une gestion de configuration de ces logiciels ;

 

À l'issue de la phase de spécifications, la liste des logiciels que l'on envisage de réutiliser sera donc présentée en précisant leur état et l'effort de développement associé en fonction des éléments justificatifs ci-dessus. Cette liste sera soumis à l'acceptation du client.

L'analyse des modifications à apporter au logiciel réutilisé devra identifier, pour chacune d'elles, la phase du cycle de développement où doit être initialisée l'intervention permettant sa prise en compte.

Par exemple :

  • un ajout de fonctionnalité ou un changement d'interface externe entraîne un retour sur la phase de spécifications du logiciel, suivi d'un " mini " cycle de développement complet afin d'intégrer et de valider cette fonctionnalité ;
  • un changement d'interface interne au logiciel ou un changement d'algorithme entraîne un retour sur la conception.

 

On n'oubliera pas dans l'évaluation des conséquences d'une modification d'inclure la charge induite par la mise à jour de la documentation associée aux phases à reprendre.

Chaque modification nécessite également une analyse permettant d'identifier, selon son impact, les tests nécessaires à sa validation (test unitaire du constituant modifié, test fonctionnel mettant en jeu le constituant modifié, tests de non régression de validation de l'ensemble du logiciel).

La conception du logiciel en cours de développement fera apparaître dans des éléments de conception différents les fonctions que l'on souhaite réutiliser de façon à

pouvoir les valider de manière indépendante.

Afin de faciliter la maintenance du logiciel, toute modification du code devra être réalisée de façon à conserver le squelette du constituant (pas de " verrue "). Si cette règle ne peut être satisfaite, on optera pour une reprogrammation complète du constituant en respectant les principes de la programmation structurée.

3. Interface homme / machine

Pour les logiciels disposant d'une interface homme / machine, une maquette de cette interface doit être établie pendant la phase de spécifications.

Cette maquette doit présenter :

  • le contenu des écrans,
  • la dynamique d'enchaînement des écrans,
  • la mise en oeuvre des différentes commandes,
  • les aides en ligne éventuelles.

 

Les futurs utilisateurs devront participer à la validation de la maquette de l'interface homme / machine, qui doit avoir lieu au cours de la phase de spécifications.

Les utilisateurs doivent participer à la phase de recette du logiciel.

F. La documentation

Le tableau suivant présente les documents à fournir lors des réunions formelles préconisées dans le cas d'un cycle de vie en V classique. Il convient d'adapter les instants de livraison des documents dans le cas d'un cycle de développement différent.

 

 Réunion de démarrageRSLFin conceptionBT Avant validationCRE Après validationRecetteA chaque versionA chaque réunion d'avancement
Plan d'applicationPD      
Document de spécification du logiciel D      
Document de conception  D     
Document de validation P CD   
Rapport de tests    DDD 
Analyse des logiciels réutilisés CJ     
Dossier descriptif de la configuration   CJJJ 
Manuel d'utilisation P  CD  
Cahier de recette  P  D  
PlanningP      J

 

 

Légende :

P  version préliminaire
C  version complète
D  version définitive
J  version mise à jour

Des précisions sur le contenu des documents (y compris les plans type) sont indiquées dans les annexes.

G. Annexe

Plan d'application

Il décrit les dispositions de gestion qui sont appliquées au projet en réponse aux exigences du présent document. Ces dispositions de gestion doivent être définies lors de réunion de travail entre le client et le fournisseur.

Plan-type du plan d'application : Télécharger le document

Document de spécification

Ce document décrit :

  • les fonctionnalités du logiciel,
  • la manière dont le logiciel doit être opéré,
  • les interfaces externes,
  • les données manipulées,
  • le flux de données,
  • les éventuelles conditions d'activation,
  • les éventuels points de reprise ou de sauvegarde de données à prévoir pour les cas dégradés,
  • les contraintes (ressources,...),
  • les conditions de réutilisation de produits tiers (COTS, logiciels libres, .).

 

Cette description doit prendre la forme d'exigences. Chaque exigence de la spécification technique du logiciel doit être :

  • unitaire
  • non ambiguë
  • identifiée (au moyen d'un identificateur unique pour chaque exigence)
  • vérifiable (par test ou analyse).

 

Plan-type du document de spécification : Télécharger le document

Document de conception

Ce document décrit la solution retenue pour répondre aux spécifications du logiciel :

  • l'architecture du logiciel avec la décomposition en constituants (graphes d'appel, flux de données),
  • les éventuelles synchronisations entre constituants,
  • la stratégie de traitement des erreurs et des exceptions.

 

La description de chaque constituant apparaît en commentaires dans le code. Elle comporte :

  • son rôle d'un point de vue fonctionnel,
  • ses principales interfaces (fichiers, paramètres, messages, ...),
  • ses "liens" avec d'autres constituants (liens d'appel, de dépendance, de service, d'héritages, de généricité, ...),
  • ses éventuelles conditions d'activation,
  • son pseudo-code.

 

Plan-type du document de conception : Télécharger le document

Document de validation

En fin de phase de spécifications du logiciel, une première version de ce document décrit :

  • l'organisation, la planification, les enchaînements des tests,
  • les ressources nécessaires, en particulier les moyens d'essais en précisant les limites de leur représentativité par rapport à l'environnement réel :
    1. limites des domaines physiques,
    2. limites de performances,
    3. limites en terme de fonctionnalités,
    4. limites en terme de commandabilité et d'observabilité.
  • le plan de validation (description des éléments de logiciels à tester d'un point de vue fonctionnel, liste des tests en terme d'objectifs et de moyens nécessaires).

 

Avant le début de la phase de validation du logiciel, ce document est complété afin de décrire, pour chaque test de validation, les procédures de test. Ces procédures comportent la description de la mise en oeuvre des tests, des actions à réaliser avant, pendant ou après le test, des moyens à mettre en place, et des résultats attendus.

En fin de phase de validation du logiciel, le document final doit être complété par les comptes-rendus de tests qui décriront les résultats obtenus avec les références des éventuelles anomalies détectées.

Plan-type du document de validation : Télécharger le document

Dossier Descriptif de la Configuration

Exemple de DDC (fichier texte) : Télécharger le document

Manuel d'utilisation

La fourniture de ce document dépend du type de logiciel. Elle est indispensable pour les logiciels disposant d'une interface homme/machine.

Ce document décrit :

  • les différents types d'utilisateurs possibles,
  • les moyens d'interaction (clavier, souris, touches de fonction, ascenseurs, boutons, ...), leur signification et leurs principes d'utilisation,
  • les menus et grilles d'écran : type, signification des différents champs, contrôles effectués et actions associées,
  • les messages émis par le logiciel avec indication de la fonction émettrice et les actions correctives associées,
  • l'enchaînement des écrans,
  • la forme des éditions papier.

 

L'organisation et le contenu de ce document sont à soumettre à l'approbation des futurs utilisateurs.

Ce document est initialisé dès la phase de spécifications du logiciel et est complété au cours du développement afin d'être livré en version complète en fin de validation du logiciel.

Plan-type du manuel d'utilisation : Télécharger le document

Cahier de recette

Les essais de recette décrits dans ce document sont un extrait de la liste des tests du document de validation du logiciel. Le cahier de recette doit être approuvé par le CNES avant le début de la recette.

Plan-type du cahier de recette : Télécharger le document

Spécification Technique de Besoin Logiciel

Télécharger le document

 

Risques

RisquesMéconnaissance des évolutions du logiciel
Validation Logiciel incomplète
 RecommandationsETABLIR DES REGLES "QUALITE LOGICIEL" ADAPTEES
Dispositions Qualité Logiciel

 

Activités / documentation