Qualité des logiciels industriels

par Élisabeth WALTI

Consultant en qualité des logiciels
Responsable de secteur à la Société Qualience

1. Processus de base .................................................................................... R 8 080 - 2

1.1 Processus d’acquisition ............................................................................... — 2
1.2 Processus de fourniture ............................................................................... — 3
1.3 Processus de développement ..................................................................... — 4
1.4 Processus d’exploitation.............................................................................. — 4
1.5 Processus de maintenance .......................................................................... — 4
2. Processus de support .............................................................................. — 5
2.1 Processus de documentation ...................................................................... — 5
2.2 Processus de gestion de configuration ...................................................... — 6
2.3 Processus d’assurance de la qualité ........................................................... — 6
2.4 Processus de vérification ............................................................................. — 6
2.5 Processus de validation ............................................................................... — 7
2.6 Processus de revues..................................................................................... — 7
2.7 Processus d’audits........................................................................................ — 7
2.8 Processus de résolution de problème ........................................................ — 7
3. Processus organisationnels ................................................................... — 7
3.1 Processus de management ......................................................................... — 7
3.2 Processus d’infrastructure ........................................................................... — 9
3.3 Processus d’amélioration ............................................................................ — 9
3.4 Processus de formation ............................................................................... — 9
4. Conclusion .................................................................................................. — 9
5. Annexe A. Les tests du logiciel ............................................................ — 10
5.1 Étapes de test................................................................................................ — 10
5.2 Familles de tests ........................................................................................... — 10
5.3 Techniques de tests ...................................................................................... — 10
6. Annexe B. Les normes, les standards, les référentiels .................. — 13
6.1 DO-178B/ED-12B ........................................................................................... — 13
6.2 DoD-STD-2167 .............................................................................................. — 13
7. Annexe C. La qualimétrie ....................................................................... — 13
Pour en savoir plus ........................................................................................... Doc. R 8 080

P arler de qualité est le plus souvent trop abstrait. Il semble plus facile d’abor-
der la question de la qualité par la non-qualité. Chacun a pu voir dans la vie
de tous les jours ou dans le milieu professionnel, les effets de la non-qualité. Les
conséquences sont aussi bien au niveau des coûts, des délais que des personnes
et des biens.
Comme exemple grand public, le logiciel Socrate de la SNCF, dont la mise en
œuvre a été laborieuse, a beaucoup compliqué la vie des utilisateurs et des usa-
gers, et a profondément nui à l’image de l’entreprise. L’exemple du premier tir
d’Ariane 5 vient également à l’esprit. Ces deux faits sont connus de tous, en rai-
son de leur importante couverture médiatique, mais de nombreux autres exem-
ples se rencontrent tous les jours et par tout un chacun.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Mesures et Contrôle R 8 080 − 1
QUALITÉ DES LOGICIELS INDUSTRIELS _____________________________________________________________________________________________________

Un état d’esprit encore assez répandu dans le domaine du logiciel laisse enten-
dre que la qualité coûte trop cher, retarde le développement, ... et la décision de
réaliser en premier le produit (exécutable) et ensuite le reste (documentation,
tests, etc.) en fonction du temps restant est encore très souvent d’actualité.
En fait, la qualité n’est pas une entité précise et délimitée à un instant du déve-
loppement mais doit faire partie intégrante de la manière d’être, et se faire tout
au long du cycle de vie d’un produit.
Il semble intéressant de préciser que des secteurs industriels, développant des
logiciels sécuritaires comme l’aéronautique par exemple, ont depuis longtemps
mis en place des méthodes répondant à des besoins de rigueur et donc de qua-
lité. L’apparition de standards a permis de quantifier les besoins et les attentes
de chacun et servent de référence au moment des phases d’acceptation.
Depuis quelques années, le concept de qualité totale est apparu sur le marché.
Les entreprises voulant rattraper leur retard se sont lancées dans des recherches
d’amélioration à travers l’ISO 9000, CMM, SPICE, etc. Ces démarches sont loin
d’être négatives, les apports sont plus que positifs. Il faut cependant signaler des
échecs cuisants, induits le plus souvent par une non-communication interne à
l’entreprise. Faire avancer à marche forcée tout le personnel, sans explication et
sans tenir compte de leur point de vue, est la garantie d’un échec. La mise en
place d’un système qualité propre à une entreprise, ou à un secteur déterminé,
s’il est bien compris et approprié, ne peut être que positive.
Pour faciliter l’approche, et dans un souci de normalisation, il paraît plus sim-
ple de prendre le cycle de vie du logiciel et de passer en revue tous les processus
le constituant pour en faire ressortir les points qualité. La norme internationale
ISO 12207 « Processus du cycle de vie du logiciel » peut servir de trame dans la
suite de la présentation. Cette norme regroupe les activités qui doivent être
mises en œuvre pendant le cycle de vie, en cinq processus de base, huit proces-
sus de support et quatre processus organisationnels.
L’avantage de cette norme est de ne pas se limiter au développement pur du
logiciel, mais de le mettre dans le contexte de l’entreprise. Un autre avantage, qui
peut être déstabilisant au premier abord, est de ne proposer aucun modèle de
cycle de vie, laissant à l’utilisateur la liberté de choix en fonction de son besoin.

1. Processus de base
1.1 Processus d’acquisition
Sous cette appellation est rassemblé l’ensemble des activités à
réaliser par l’acquéreur. Il faut noter que leur présence comme pro-
cessus à part entière du cycle de vie est relativement récente. Néan-
moins, ces activités existaient au sein de l’entreprise. Ce nouvel
éclairage ne doit que les formaliser davantage.
Ce processus comprend trois grandes phases.
■ La contractualisation
Il s’agit de l’initialisation, l’appel d’offres et le contrat. C’est-à-dire
de toutes les activités menant à la signature du contrat.
Cette phase est très importante dans la mesure où elle est la
pierre angulaire de la réussite du futur projet. La qualité ici intervient
à travers le sérieux des études préalables, les critères de choix du
fournisseur et les décisions prises, la documentation et les comptes
rendus de réunions, l’appel à des experts pour des points nouveaux
ou très particuliers.
Exemple : si le contrat doit être fait avec une entreprise étrangère,
il peut être important de contacter un juriste pour connaître les parti-
cularités à spécifier dans le contrat.
C’est également pendant cette phase que les exigences qualité
(relatives au produit ou à la prestation, au suivi ou à l’acceptation)
envers le fournisseur sont à définir de la façon la plus exhaustive
possible.
Pour les entreprises mettant en place un système qualité
conforme à l’ISO 9000, cette étape doit être complètement décrite
dans une procédure, qui doit ensuite être appliquée.
■ Le suivi
La seconde phase est le suivi du fournisseur. Cette activité qui doit
courir tout au long du développement est parfois laissée en som-
meil, le plus souvent par manque de temps ou par excès de
confiance.
L’intervention de l’acquéreur sous la forme de la participation à
des réunions d’avancement régulières, même espacées dans le
temps peut suffire à éviter un écart final que ce soit au niveau du
produit ou de sa date effective de livraison.
Exemple : la spécification du produit demandait : « la possibilité
d’écrire sur deux écrans de format différent ». Le fournisseur a prévu
deux configurations différentes, et l’acquéreur de son côté pensait
« en simultané ». La reprise finale est très importante, puisqu’elle
demande au minimum une reprise profonde de l’interface utilisateur.
Cette incompréhension aurait rapidement été détectée au cours d’une
réunion d’avancement ou lors de la relecture des documents techni-
ques.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
R 8 080 − 2 © Techniques de l’Ingénieur, traité Mesures et Contrôle
_____________________________________________________________________________________________________ QUALITÉ DES LOGICIELS INDUSTRIELS
Pour éviter tout litige, la demande de l’acquéreur d’avoir une vue
sur le développement doit être spécifiée dans le contrat.
■ La réception
La dernière phase comprend l’acceptation et l’achèvement du
processus. Si l’acceptation est assez classique et régulièrement réa-
lisée car liée le plus souvent à une clé de paiement, l’achèvement
pour sa part est plus rare. Il doit être vu comme la conclusion du pro-
jet. Cette étape doit permettre de tirer les enseignements du projet
qui se termine. Il y a quelques années de nombreuses entreprises
ont cherché des outils capables de les aider dans les démarrages de
nouvelles affaires pour diminuer les risques. Ces outils fonctionnent
tous à partir d’une base de connaissance. Le principal point blo-
quant fut le manque d’informations pour l’enrichir. D’autre part, ces
outils demandent le réglage de nombreux paramètres avant de four-
nir un résultat fiable.
Le côté positif de ces essais est la prise de conscience du risque
inhérent au démarrage de tout projet et de l’importance de garder la
trace de l’antécédent.
Exemple : sans aller si loin, l’idée la plus simple est la mise à jour
de la liste des fournisseurs. C’est également la décision de ne plus
sous-traiter, ou alors dans des conditions très particulières, certains
types de projets.
Quels qu’ils soient, ces enseignements sont toujours enrichis-
sants pour le futur et la pérennité de l’entreprise.
1.2 Processus de fourniture
Ce processus est le pendant exact du processus d’acquisition. Il
regroupe les activités du fournisseur.
Il peut également être découpé en trois phases.
■ La première doit contenir l’initialisation, la réponse à l’appel
d’offres et se poursuivre jusqu’à la signature du contrat. Cette étape
est vitale pour la suite du projet et même dans certains cas pour la
survie de l’entreprise. Le premier point est la décision de répondre,
qui ne doit jamais se faire à la légère. Comme contre-exemple par-
fait, il est facile d’imaginer un ordre qui arrive de la direction et qui
balaie toutes les contradictions. Autre cas de figure, pour la survie
de l’entreprise, il faut prendre ce contrat et le mener à son terme
contre vents et marées, si nécessaire. Il est important de signaler
que même dans ces cas extrêmes, les études doivent être menées
avec le plus grand soin. Comme dans le cas de l’acquéreur, la signa-
ture du contrat portant des clauses particulières ou avec des clients
nouveaux peut demander l’aide d’experts.
Exemple : 1. Il est important de signaler que la propriété des con-
naissances et du savoir-faire n’est pas régie de façon identique dans
tous les pays.
2. Au moment de la réponse à l’appel d’offres, il arrive souvent que
la demande ressemble beaucoup à une autre affaire terminée ou en
cours de réalisation. Il suffit alors de présenter la même proposition.
Il convient quand même de se méfier de plusieurs points :
— l’ensemble des petits détails formant le delta entre les deux affai-
res crée des différences importantes ;
— le contrat initial de la précédente affaire a pu être renégocié pour
rendre le projet réalisable (solution technique non viable, ...) ;
— les dépassements de budget sont importants.
Ces points n’étant pas toujours présentés sous leur vrai jour, une
attention particulière est de mise lors de la reprise de travaux antérieurs.
La réutilisabilité, très à la mode actuellement avec le développe-
ment des méthodes à objets, est à prendre en considération dans ce
processus. La décision de faire un logiciel, une bibliothèque ou
même un composant réutilisable n’est pas neutre. Il est admis que
les coûts du premier développement sont plus élevés. Il convient
d’en tenir compte au moment du choix.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Mesures et Contrôle
■ La seconde phase, qui suit le développement du projet, commence
par l’élaboration des plans du projet, que ce soit au niveau des
méthodes de développement (choix du cycle de vie, méthode de tra-
vail structurée ou à objets), au niveau de la gestion (avec la gestion de
projet ou de configuration...), ou au niveau qualité, avec la descrip-
tion des directives à respecter pour assurer la qualité du projet. Tous
ces plans sont vitaux, ils doivent être relus et validés avant le démar-
rage du développement et suivant les clauses du contrat, ils peuvent
être soumis pour approbation au client ou à un service officiel.
Exemple : pour les projets aéronautiques, le standard DO-178B est
imposé et la fourniture des plans en début de projet, en vue d’une cer-
tification des équipements, est demandée.
Il est très important de réaliser un planning précis de l’affaire.
L’expérience préconise de signaler que la montée de charge sur un
projet n’est jamais à coût nul. La prise en compte de ce phénomène,
ainsi que les vacances, les réunions extérieures et les formations
envisageables permettront la construction d’un planning réaliste. Le
raisonnement voulant qu’une personne soit productive sur un projet
huit heures par jour, cinq jours par semaine, cinquante-deux semai-
nes par an, peut entraîner des dérives importantes par rapport au
planning initial. Pour ce processus, le niveau de granularité des
tâches reste encore assez faible, le but recherché étant l’évaluation
des différentes enveloppes. Les activités doivent toutes être listées
et placées dans le temps. Un affinage est à mener par le processus
de management.
Cette phase couvre l’exécution et la maîtrise des activités du four-
nisseur. Le point le plus important est la notion de maîtrise. Le four-
nisseur ne doit jamais se laisser porter par l’avancement du projet,
mais à partir du planning initial, des revues et des évaluations
menées régulièrement, produire un nouveau planning, mais surtout
comprendre et, si possible, corriger les dérives.
Exemple : les retards sont dus à :
— une épidémie de grippe (30 % des effectifs atteints pendant
15 jours) (c’est une cause non prévisible) ;
— un produit non disponible dans les temps (c’est une cause exté-
rieure prévisible) ;
— un manque de rigueur dans les développements (c’est une cause
intérieure).
Quelle que soit la cause, il est important de la déterminer et de la
corriger et même si possible de l’éviter.
Exemple : la livraison est prévue le 15 mars. Le 15 février, il reste
« si tout se passe bien » 40 jours de travail non parallélisables. Les
miracles étant fort rares dans une entreprise, il convient peut-être de
songer à prévenir le futur acquéreur ou, tout au moins, de décider la
politique à suivre.
Pour des raisons politiques ou financières (une clé de paiement), il
peut être décidé de ne pas immédiatement prévenir l’acquéreur du
retard. C’est une arme à double tranchant dont il faut savoir se servir.
■ La dernière phase de ce processus, est la livraison du produit, la
fourniture. Il est très important de s’assurer que tout est conforme et
complet avant de le livrer. Dans le cas contraire, le flou peut être vu
par l’acquéreur comme un manque de savoir-faire et donc comme
une non-qualité.
Exemple : il faut éviter de livrer au client, un produit comprenant
plusieurs logiciels dans des versions incompatibles ou avec une do-
cumentation périmée.
Le fait qu’à la mise sous tension du système, rien ne se passe, est
du plus mauvais effet et correspond à une absence de contrôle de
sortie et toujours à de la non-qualité.
Exemple : à la mise sous tension d’un oscilloscope électronique,
l’écran reste muet. Le dévissage de la face arrière met en évidence
l’absence de circuit de traitement des signaux. L’acquéreur vient
d’acheter à prix d’or une boîte vide. La suite est facilement envisagea-
ble et surtout compréhensible.
R 8 080 − 3
QUALITÉ DES LOGICIELS INDUSTRIELS _____________________________________________________________________________________________________
1.3 Processus de développement
Cette activité est la plus connue, puisqu’elle sert de cœur au cycle
de vie, il convient toutefois d’en rappeler brièvement les étapes
(figure 1).
Ce processus de développement couvre les activités suivantes :
— analyser les exigences du système ;
— définir les exigences du logiciel et des interfaces (spécification
logicielle) ;
— définir l’architecture du logiciel (conception générale) ;
— définir les traitements élémentaires et les entrées/sorties de
chaque élément (conception détaillée) ;
— transcrire les traitements en code exécutable (codage) ;
— tester chaque élément du logiciel (test unitaire) ;
— assembler les éléments et tester les parties (test d’intégration).
La validation ne fait pas partie de ce processus.
Les tâches décrites ci-dessus ne sont pas nouvelles, et toute per-
sonne ayant déjà participé à un développement de logiciel a dû les
réaliser. Vrai dans l’absolu, il est encore courant de rencontrer des
projets où les différentes tâches sont faites en parallèle.
Exemple : dans le même temps, une personne écrit la conception,
pendant qu’une autre met une touche finale aux jeux de test de valida-
tion, ou même prépare le résumé des travaux avant la livraison offi-
cielle. L’exécutable est terminé depuis longtemps au moment de la
réalisation du dossier.
Chaque étape ou phase du développement doit être faite confor-
mément aux plans, en fonction du cycle de vie, des contraintes spé-
cifiques (niveau de criticité de la DO-178B, paragraphe 5, par
exemple), de la méthode, du langage, etc.
Pour travailler, chaque membre de l’équipe devra pouvoir trouver
dans les plans toutes les informations qui lui seront nécessaires :
— plan-type des documents avec une description sommaire des
contenus attendus ;
— contraintes de conception ;
— contraintes de codage ;
— description de l’environnement de travail ;
— option de compilation ;
— règles de nommage (dénomination) des composants, des
variables, etc. ;
— niveau de test imposé ;
— taux de couverture de test ;
— techniques de test ;
— règles d’utilisation des « bouchons » ou « composants muets »
en test, etc.
Un point important, est le passage d’une phase à la suivante. La
suffisance des fournitures doit être évaluée. La traçabilité avec la
phase précédente est réalisée pour prouver qu’il n’y a pas eu de
perte dans la transmission des informations.
La traçabilité peut être faite à deux niveaux :
— d’une phase vers sa phase amont (entre la conception et la
spécification ) ;
— des tests vers les exigences (de la validation vers la spécifica-
tion).
Dans le cas du cycle de vie dit en « V », ces traçabilités sont dites
descendantes et transversales.
Il existe d’autres types de cycle de vie qui permettent un chevau-
chement des phases. Quel que soit le type de cycle choisi, il est fon-
damental qu’il soit en corrélation complète avec la méthode de
travail décrite dans les plans.
L’important pendant le développement est d’écrire ce que l’on
va faire et de faire ce que l’on a écrit.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
R 8 080 − 4 © Techniques de l’Ingénieur, traité Mesures et Contrôle
Exigences Système
Valider
du système
Logiciel
Spécifier
Intégrer
et concevoir
Coder
et tester
Figure 1 – Étapes du processus de développement
1.4 Processus d’exploitation
Mettre l’exploitation dans les activités couvertes par le cycle de
vie, est une façon relativement récente d’envisager cette activité.
L’idée fondamentale du processus d’exploitation, est l’assistance
à l’utilisateur qui commence par s’assurer que le produit fourni fonc-
tionne dans l’environnement opérationnel de l’utilisateur et qui doit
se poursuivre par un soutien en cours d’utilisation si nécessaire.
Cette assistance peut comprendre le développement de fonctions
spécifiques à l’exploitant.
Exemple : il est encore assez courant d’utiliser un produit dont la
documentation, très succincte, laisse planer de nombreux doutes, et
de devoir par l’apprentissage trouver une manière satisfaisante de l’uti-
liser. L’impression de recevoir en cadeau une pochette surprise et
d’être seul au monde face à l’adversité en découle.
Le point fondamental de ce processus est la réalisation méti-
culeuse de la définition détaillée des attentes de l’utilisateur.
L’importance de ce processus va beaucoup dépendre du type de
produit et de l’ampleur de son interface utilisateur. Il convient de
mettre en place une activité en adéquation avec le besoin.
Exemple : éviter de mettre en place un service « Hot line » avec
des débutants. C’est du plus mauvais effet, quand l’utilisateur paniqué
téléphone, de le mettre en relation avec une personne connaissant
moins bien le produit que lui. Il est également recommandé d’éviter le
turn-over dans les équipes support.
Ce phénomène se rencontre assez fréquemment. De nombreuses
SSII (Sociétés de Service en Informatique Industrielle) sont revendeu-
ses de produits logiciels et constituent le gros des troupes de leur ser-
vice support avec les personnes en inter-contrat.
L’inverse est également vrai. Du personnel qui attend un hypothéti-
que coup de téléphone est ruineux pour une entreprise et pas très
motivant pour les personnes affectées.
Une étude précise est donc nécessaire. Le credo actuel de tous les
responsables est la satisfaction du client.
Pour ce processus, la qualité est directement liée à l’image de
marque, et à moins d’avoir une position de monopole international,
il convient de faire réellement quelque chose.
1.5 Processus de maintenance
Ce processus est vu le plus souvent comme une phase de déve-
loppement au rabais. Cette activité demande d’être approfondie. En
effet, la première partie, correspondant à l’analyse des problèmes et
à la réalisation des modifications, est généralement bien faite et suit,
comme prévue, le même processus d’évolution, ou peu s’en faut,
_____________________________________________________________________________________________________ QUALITÉ DES LOGICIELS INDUSTRIELS
que celui du développement. Il semble quand même intéressant de
rappeler que la mise à jour de la documentation et la mise en place
de tests de non-régression font partie intégrante de cette activité.
Le reste de l’activité, plus spécifique à cette étape, est le plus sou-
vent négligée. Il couvre les migrations possibles et le retrait des logi-
ciels.
Une gestion rigoureuse est nécessaire pour maîtriser ces deux
activités. Cette maîtrise passe par la connaissance de tout ce qui a
été fourni à un client, avec la version, la quantité, les conditions de
maintenance... Pour de nombreux logiciels, il arrive très souvent de
livrer des versions en BetaTest, ou même des versions intermédiai-
res « par avance » pour débloquer un utilisateur. Toutes ces infor-
mations doivent être connues et suivies.
Il est du plus mauvais effet que la version officielle et estampillée
ne contiennent pas les fonctionnalités des « patchs » fournis par
avance au client. Mais il est tout à fait concevable de lui livrer la ver-
sion officielle avec un nouveau « patch » spécifique à son problème,
il pourra de ce fait profiter des nouveautés sans subir de régression.
Traiter les livraisons au client de cette façon, démontre une parfaite
maîtrise de son processus de maintenance.
La migration peut être une demande de l’utilisateur, ou une
contrainte du fournisseur.
Exemple : la maintenance n’est assurée que pour les versions
supérieures à n – 2 du produit. Soit l’utilisateur migre (« upgrade »),
soit il rompt son contrat de maintenance. Les grandes sociétés de
matériels informatiques imposent souvent ce genre de chose pour
rationaliser la gestion du parc.
Un point souvent négligé est la sauvegarde du contexte toujours
plus ou moins particulier de l’utilisateur avant la nouvelle installa-
tion, pour permettre un retour en arrière le plus rapide possible, en
cas de problème.
Exemple : problème de gestion du disque lors de la création d’un
nombre très important de petits fichiers. Le disque n’est pas plein,
mais la table de vecteur est en débordement. Ce problème survenu à
la nouvelle version d’un OS créait des pannes aléatoires et des incohé-
rences majeures dans les bases de données. Avant de faire la moindre
analyse pour trouver la cause, le retour à la version précédente s’impo-
sait.
Pour l’exemple ci-dessus, le souvenir du peu de compréhension
du fournisseur et même de son agressivité face à la mise en cause
de son produit est encore vivace. C’est l’utilisateur qui a prouvé la
défaillance.
Le retrait, pour le domaine du logiciel, est vu comme un arrêt de
la maintenance. Avant toute action, une procédure doit être mise en
place et toujours respecter les besoins de l’utilisateur.
2. Processus de support
2.1 Processus de documentation
Il peut sembler inutile de préciser l’importance de la documenta-
tion sur un projet, ne serait-ce que pour perpétuer le savoir-faire.
Malheureusement, à l’heure actuelle, l’idée de faire le logiciel, et de
voir après si il reste du temps pour la réalisation de la documenta-
tion, est encore très répandue.
La théorie la plus simpliste voudrait que l’on ne commence un
document qu’en possession de tous les documents amont nécessai-
res figés et complets. Cette vision ne correspond que très rarement
à une réalité économique. Une façon plus réaliste est de travailler
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Mesures et Contrôle
dans le même état d’esprit, mais par grandes fonctionnalités du
projet.
Exemple : le document de spécification est en attente de précision
du client sur des points particuliers d’un des sous-systèmes du projet.
Si d’autres sous-systèmes ont une spécification complète, relue et
validée, rien ne doit s’opposer au lancement de la conception de ces
sous-systèmes.
Cette façon de travailler permet une montée en charge progres-
sive des équipes et un lissage de la charge à chaque phase de réali-
sation. Quelle qu’elle soit, la méthode de travail doit être décrite
dans les plans.
Pour faciliter le travail des équipes et également dans un souci
d’homogénéité, il convient de définir au préalable, un certain nom-
bre de contraintes :
— lister les documents et la personne qui en sera responsable ;
— pour chaque document, décrire son contenu et, si possible,
fournir un plan type ;
— donner des règles et des recommandations de présentation
(saut de page, taille et police,...) et d’écriture (emploi de mots,
d’expressions,...).
Il n’est pas nécessaire de réinventer le monde. Il existe des nor-
mes et des standards définissant déjà les documents et parfois leur
plan type. Il est toujours possible de les prendre comme référence
ou de les utiliser comme base d’inspiration. Il faut noter que certai-
nes entreprises ont résolu le problème en se créant un référentiel de
travail contenant, entre autre, toutes les informations nécessaires à
la rédaction des documents.
À partir des directives, ou de leur absence, la documentation doit
être produite, puis vérifiée. Il convient de rappeler qu’une vérifica-
tion n’est possible que si des exigences prédéfinies dans les plans
existent au préalable. Dans le cas contraire, elle ne peut être que
subjective et donc sujette à caution.
La suite des activités à réaliser dans le cadre du processus de
documentation est le plus souvent oubliée. Il s’agit de la mainte-
nance et par là même de la gestion des évolutions. Pendant la vie du
produit, le document satisfaisant à l’origine devient de plus en plus
périmé.
Exemple : après une première livraison du produit et de sa do-
cumentation associée, le fournisseur accepte successivement de réali-
ser une suite de petites modifications ayant des impacts mineurs sur la
documentation. Il est vrai que ces évolutions prises séparément n’im-
posent pas une remise à niveau immédiate de la documentation, mais
l’ensemble donne un document largement périmé.
Il convient également de gérer les diffusions, les archivages et
surtout les désarchivages, quand prendre la décision de détruire un
document ?
Pour les diffusions, le problème est la suppression des périmés
« dans la nature ». Le fait de considérer que les personnes présentes
sur la liste de diffusion aient reçu un avis, ou une nouvelle version,
est notoirement insuffisant. Les photocopies libres rendent ce pro-
cédé caduque.
Il y a plusieurs moyens de contourner le problème, ils dépendent
surtout de la taille du projet et des méthodes de travail. Il est possi-
ble de considérer que seules des versions diffusées en couleur origi-
nale aux personnes citées dans la liste de diffusion sont valides, les
autres copies étant par définition, périmées. Dans ce cas, ces per-
sonnes détiennent les « bonnes » versions et sont sensées les gérer.
Il est également possible de considérer que seule la version élec-
tronique fait foi. Tout papier est forcément périmé. Cette option
paraît plus simple, mais impose que chaque utilisateur potentiel ait
accès à l’information. Les coûts non nuls de l’opération font encore
reculer beaucoup d’entreprises.
Il existe d’autres moyens ni plus ni moins bons que les autres, leur
mise en œuvre et leur réussite dépend surtout de la structure de
l’entreprise et des habitudes de travail.
R 8 080 − 5
QUALITÉ DES LOGICIELS INDUSTRIELS _____________________________________________________________________________________________________
Il convient surtout de définir les responsabilités au niveau de la
gestion de la documentation.
En ce qui concerne le désarchivage, le problème n’est pas trivial.
Il peut être décidé de tout garder. Sur un petit projet, dans une entre-
prise ayant de l’espace, cette solution est viable. Dans le cas
contraire, la définition de règles est très importante, en particulier
vis-à-vis de l’acquéreur.
Exemple : il arrive à un fournisseur de signer un contrat avec archi-
vage des documents de développement pendant 30 ans... Quand le
prix du mètre cube chez LocArchive est intégré aux coûts de dévelop-
pement brut, la facture peut faire frémir.
La solution de considérer qu’il suffit de garder les versions n – 1
ou n – 2 est le plus souvent un peu simpliste. Il faut réfléchir au
besoin réel de l’acquéreur et du fournisseur lui-même.
Il est vrai que lorsque l’on évoque l’archivage, il vient surtout à
l’esprit la notion de papier, de boîtes rangées sur des étagères. Il faut
également penser à l’archivage électronique. Les supports magnéti-
ques ont une durée de vie limitée, et même s’ils sont toujours vali-
des, a-t-on conservé l’outil qui permet de les relire ?
2.2 Processus de gestion de configuration
L’écriture d’un plan de gestion de configuration doit permettre,
d’une part, de savoir ce qui doit être géré en configuration et, d’autre
part, de savoir comment le faire.
Une configuration est composée d’un ensemble d’articles de
configuration. Un article doit être identifiable et pouvoir évoluer de
façon maîtrisée. Un article peut être une partie de code, de do-
cumentation, un outil, un compilateur, mais également un local, une
personne (au sens de la compétence plutôt que de l’individu).
Cette gestion doit permettre à tout moment de fournir un état de
configuration, de connaître les évolutions entre deux états d’une
même configuration.
Exemple : cet état de configuration doit permettre de recréer une
ancienne version pour pouvoir démarrer un développement en parallèle.
La configuration sert lors de la mise en place des référentiels aux
étapes clés du projet. La vérification du respect des directives du
plan de gestion de configuration se fait par l’intermédiaire d’audits
de configuration.
Le piège, lors de la mise en place de ce processus, est de se créer
une machinerie beaucoup trop lourde en comparaison de l’impor-
tance du projet. Ce phénomène induit tôt ou tard de la non-qualité,
des actions étant mal faites, ou carrément abandonnées, par man-
que de temps au fur et à mesure de l’avancement du projet.
Il existe dans le commerce des outils d’aide à la gestion de confi-
guration. Ces outils très en vogue, il y a quelques années, ont subi
de plein fouet la crise du début des années 1990. À l’heure actuelle,
ils font leur retour de façon plus discrète, mais sont toujours pré-
sents puisque le besoin existe.
Au moment de choisir un outil pour mettre en œuvre la méthode de
gestion préconisée, il est très important de trouver l’adéquation entre
l’outil et la méthode, qui peut être légèrement modifiée si nécessaire.
Exemple : l’outil ne sait gérer que les agrégats de composants,
alors que la méthode demande une gestion par composant. Il revient à
dire que la partie fine de la gestion devra être manuelle et que l’outil
n’apporte pas vraiment une aide efficace.
2.3 Processus d’assurance de la qualité
Ce processus vise à garantir que les processus et le logiciel asso-
ciés au cycle de vie du projet sont conformes aux exigences requi-
ses et respectent les plans préétablis.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
R 8 080 − 6 © Techniques de l’Ingénieur, traité Mesures et Contrôle
Il convient de tout mettre en œuvre pour réaliser :
— l’assurance du produit ;
— l’assurance du processus ;
— l’assurance des systèmes qualité (action ISO 9001).
Pendant longtemps, l’activité qualité sur un projet est restée au
niveau du produit. C’est ce qui est couramment appelé le contrôle
qualité.
Cette activité revient à évaluer le produit c’est-à-dire :
— le logiciel ;
— sa documentation ;
— mais également les logiciels non développés mais livrables ;
— les logiciels non livrables ;
— la fourniture autre que le logiciel.
Depuis quelques années, l’évaluation des processus du cycle de
vie prend une place de plus en plus importante. Si le développement
a été effectué comme prévu dans les plans, cela permet d’assurer
que le produit fonctionne, et qu’il continuera à fonctionner et de
prouver ce fait.
Ces activités sont menées par le biais d’inspection (§ 2.4), de
revues (§ 2.6) et d’audits (§ 2.7). Comme pour les autres processus,
un plan doit les décrire.
Pour suivre l’avancement de ce processus, il convient de faire
régulièrement un bilan qualité contenant :
— les généralités sur le projet, avec en particulier les exigences
qualité requises ;
— les actions déjà réalisées, avec leurs conclusions ;
— les actions à venir, avec leur planification et les responsabilités
associées.
Au niveau des systèmes qualité, l’assurance consiste à vérifier la
définition et la mise en œuvre des dispositions applicables au
moyen de revues et d’audits, et de prévenir les non-conformités.
2.4 Processus de vérification
Ce processus peut paraître très lourd dans la mesure où, en pre-
mière lecture, il peut sembler que tout doit être vérifié.
La méthode de vérification est l’inspection ou la relecture d’un
document, d’un code, d’un test à l’aide d’une check-list fournissant
des critères d’évaluation. Il est rappelé qu’une vérification n’est pos-
sible que dans la mesure où les règles préalables ont été définies.
Pour un document, les critères les plus courants sont :
— la cohérence interne ;
— la compréhensibilité ;
— la traçabilité avec le document amont ;
— l’adéquation des techniques mises en œuvre ;
— l’adéquation des ressources employées.
Il est possible d’aller beaucoup plus loin avec des critères
comme :
— l’adéquation des facteurs qualité ;
— la testabilité des exigences (au niveau de la spécification) ;
— la conformité à un plan-type, etc.
Pour le code, il est possible de travailler à partir du même type de
critères, mais il est également possible d’utiliser la qualimétrie (§ 6).
La norme ISO 9126 présente de façon détaillée la démarche à suivre
pour la mettre en œuvre.
Cette norme fournit les caractéristiques intéressantes à évaluer
sur un logiciel, mais ne donne pas le « comment », c’est-à-dire les
métriques permettant le mesurage qualimétrie (§ 6). Il existe une
importante littérature autour des travaux de MacCall, Halstead,
MacCabe, Mohanty, etc., qui propose des métriques. Il existe
aujourd’hui des outils utilisant ces théories et fournissant des résul-
tats de mesure. La difficulté est toujours là : il faut évaluer ce résul-
tat. L’outil donne un nombre, c’est à l’utilisateur de savoir à partir de
cette information, si son logiciel est satisfaisant ou non.
_____________________________________________________________________________________________________ QUALITÉ DES LOGICIELS INDUSTRIELS
2.5 Processus de validation
Suivant les méthodes de travail, ce processus peut comprendre
les tests de plus haut niveau ou alors être considéré comme une
recette à jouer à la livraison pour prouver la conformité aux exigen-
ces de l’acquéreur. La seconde partie étant le plus souvent un extrait
de la première.
Quel que soit son but, la validation doit être menée avec les
mêmes méthodes de travail que le développement lui-même. Écri-
ture d’un plan de validation, réalisation des tests et vérification du
bon déroulement du processus et des résultats sont les activités
classiques à réaliser (§ 4).
2.6 Processus de revues
Les revues ont pour objectifs de vérifier que les actions requises
ont été effectuées, que les remarques ont été traitées, que les solu-
tions proposées sont satisfaisantes.
Elles peuvent être de deux types :
— les revues documentaires : elles servent à lever les points blo-
quants suite à la relecture d’un document. Elles ont une grande
importance lors de la rédaction des plans ou des documents de haut
niveau (spécification) ;
— les revues de fin de phase : elles doivent s’assurer que les four-
nitures de la phase sont suffisantes pour passer à la phase suivante
et que l’environnement nécessaire à la réalisation de la phase sui-
vante est en place.
Une revue est une procédure formelle dont le déroulement est le
suivant :
— la planification, qui comprend la convocation à la réunion, la
diffusion des documents nécessaires ;
— la préparation, qui correspond à l’étude de ces documents ;
— la réunion, avec la prise de décision sur les points bloquants et
les conclusions (accepté, accepté avec réserve, refusé) ;
— la rédaction du rapport ;
— le suivi de la revue, c’est-à-dire suivi de la prise en compte des
actions.
2.7 Processus d’audits
Un audit permet de vérifier l’état du projet à un instant donné. Les
audits se font en général aux étapes clés, comme par exemple à la
fin des développements, au moment de la mise en production pour
s’assurer que toutes les activités ont bien été réalisées et que le pro-
duit est conforme à son attente.
Il est également possible de réaliser des audits à la demande de
l’acquéreur ou de la direction pour trouver les causes d’un pro-
blème. Le plus souvent pour un retard inexpliqué dans le planning,
un nombre de retour client en constante augmentation...
Comme pour les revues, il convient de planifier cette activité et les
entretiens avec les personnes impliquées, de prévenir les person-
nes, de conduire les entretiens, de faire un compte rendu et de sui-
vre les actions fournies par les conclusions.
Un audit peut être réalisé par des personnes internes ou externes
au projet et même à l’entreprise.
Avec la mise en place des systèmes qualité de type ISO 9000 dans
les entreprises, il existe également des audits permettant d’évaluer,
par la mise en œuvre systématique des dispositions préétablies, la
pénétration du système qualité et de ses procédures associées au
sein de l’entreprise.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Mesures et Contrôle
2.8 Processus de résolution de problème
Très souvent couplé à la gestion de configuration, ce processus
doit être basé sur une procédure décrivant les activités à réaliser
quel que soit le type de problème rencontré. Le plus souvent cette
procédure se limite à expliquer la gestion des évolutions et des
modifications lors du développement initial. Cette procédure doit
couvrir tous les processus du cycle de vie.
Exemple : Prise en compte d’une nouvelle version de compilateur.
Ajout d’un test de robustesse sur la variable SPEED2 en cas de divi-
sion par zéro.
La gestion de configuration doit pouvoir fournir tous les articles
qui ont évolué depuis un état précédent, ce processus doit être capa-
ble de dire pourquoi ils ont évolué.
Il peut paraître relativement simple de mettre en œuvre un suivi
de modification. Il convient cependant de noter que ce suivi doit être
en adéquation avec l’environnement de développement.
La procédure de suivi peut être écrite, ou récupérée du référentiel
(sans aucun souci du « comment »). Cette procédure doit définir
sous quelle forme se présente une demande d’évolution ou une
demande de modification.
Les points importants sont de savoir :
— comment est-elle gérée ?
— qui doit la rédiger ? la valider ? y répondre ?
— qui doit la suivre ? la diffuser ? effectuer une relance si
nécessaire ?
— qui doit la prendre en compte et enfin la clore ?
Il convient de souligner que suivant son niveau d’applicabilité (sur
la spécification, sur le code, ...), les personnes concernées sont diffé-
rentes. Le passage de l’information d’une personne à une autre est
également à préciser.
Ces demandes se présentent le plus souvent sous la forme de for-
mulaires qui seront complétés à chaque étape par la personne
concernée. Pour une gestion souple mais maîtrisée, il convient qu’il
y ait une responsabilité unique, mais des accès multiples.
De nombreuses entreprises se sont développé un outil de gestion
des problèmes autour d’une base de données du commerce. Pour
un petit projet, un classeur avec des feuilles papier et une numéro-
tation manuelle n’est pas systématiquement à rejeter. Il est rappelé
de toujours chercher l’adéquation entre l’environnement de travail
et le besoin réel.
Indépendamment du moyen de gestion choisi, le processus
doit :
— identifier les problèmes ;
— identifier les causes des problèmes ;
— identifier l’impact ;
— tracer les décisions (rejet, dérogation, niveau de priorité de
résolution).
3. Processus organisationnels
3.1 Processus de management
Ce processus est lié au processus de fourniture. Il est possible de
le considérer comme un raffinement de ses activités. Le processus
de fourniture peut être vu comme le niveau de la direction et le
management comme celui du responsable programme ou projet.
R 8 080 − 7
QUALITÉ DES LOGICIELS INDUSTRIELS _____________________________________________________________________________________________________

À partir de tout ce qui a été défini au niveau des exigences, des
plans, il convient en début de ce processus de définir complètement
le domaine du projet, son environnement de travail, et de planifier
toutes les activités, de construire un calendrier, de détailler les char-
ges, les risques et les ressources nécessaires. Cette mise en place
semble une évidence, mais la pression des réalités réduit trop sou-
vent ces activités. Le calendrier est vague, la qualité viendra après, les
ressources ne sont pas détaillées, l’étude des risques est inexistante.
Exemple : la phrase suivante est édifiante de la part d’un chef de
projet, mais cependant véridique : « Pourquoi parler des risques, pour
l’instant il n’y a pas de problème. »
Il faut signaler qu’un risque est l’éventuelle apparition d’un pro-
blème pouvant entraîner un échec.
Le suivi du management peut se faire par la fourniture régulière
d’un bilan décrivant les points remarquables de la vie du projet, son
avancement actuel, avec la mise en évidence des dérives ou de pro-
blèmes connus, et les prévisions. Le bilan qualité, directement
rattaché à l’avancement des activités induites par le processus
d’assurance de la qualité, peut être un document spécifique réfé-
rencé dans le bilan produit par le management, ou être directement
inclus dans le même document.
Exemple : le banc de tests prend du retard en fabrication, le projet
n’est pas encore dans cette phase donc pas encore directement
concerné. Il convient cependant de le signaler.
Ce document sert de base de travail au responsable du manage-
ment. Il est également utile à la direction pour évaluer l’avancement
effectif du projet.
Ce document peut être très complet et faire appel à des indica-
teurs (tableau 1). Il est cependant rappelé que la charge de cette acti-
vité doit rester en proportion avec la taille du projet.
Au premier abord, ce bilan semble vraiment lourd à mettre en
œuvre. Il faut souligner que le bilan présenté en encadré est un
exemple, et que ce document n’étant pas écrit en fin de projet mais
enrichi au fur et à mesure du développement, la charge de travail est
plus progressive. D’autre part, les informations ne sont pas forcé-
ment à dupliquer dans ce bilan. Si elles existent déjà de façon claire
dans un document projet, une référence documentaire précise peut
être suffisante.

Tableau 1 – Exemple de bilan de projet Tableau 1 – Exemple de bilan de projet (suite)

1. Organisation en place Présentation générale 5.1.3. Indicateurs — Maîtrise des délais :
• description des tâches et leur
Montage industriel ordonnancement,
• planning,
Organigrammes et Rôles • temps passé,
Sites • avancement des tâches, les glisse-
ments, ...
Modifications de structure — Maîtrise des performances
(effectuées, en cours, prévues) techniques :
• spécifications,
2. Ressources humaines Compétences, Formation • matrices de traçabilité,
• revues,
Turn-over • dérogations, ...
Charges (prévues, réalisées, possibles) — Maîtrise des ressources :
• plans,
Sous-traitances • devis,
• plans de charges,
3. Moyens Disponibilité • charges consommées,
• temps CPU (central proceeding
Consommations unit),
Adéquation • lots sous-traités, ...
— Maîtrise des coûts :
Qualification • budget,
(effectuées, en cours, prévues) • comptes,
• coûts de production réels,
4. Aspects contractuels Délais • prévisions de dépenses, ...
et financiers
Coûts 5.2 Présentation — identification des risques ;
et gestion des risques — évaluation du risque et de son
Livraison (en particulier, ceux niveau de gravité ;
inhérents aux points — jalons clé du risque ;
Respect des spécifications du tableau de bord) :
et des performances — critères de suppression du risque ;
— solution alternative et critères de
Actions qualité décision ;
(effectuées, en cours, prévues) — réduction du risque ;
— conséquence d’un échec éventuel.
5. Aspects industriels
5.3 Actions correctives
5.1 Tableau de bord (effectuées, en cours,
prévues)
5.1.1. Rappel de la 5.4 Réutilisation
fourniture et réutilisabilité
5.1.2. Principaux 5.5 Conseils issus
événements intervenus de l’expérience

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
R 8 080 − 8 © Techniques de l’Ingénieur, traité Mesures et Contrôle
_____________________________________________________________________________________________________ QUALITÉ DES LOGICIELS INDUSTRIELS
Pour jouer pleinement son rôle, le bilan doit vivre et être rensei-
gné avec précision, objectivité, ... Il est rappelé que ce bilan peut être
limité à un usage interne. Il est toujours possible de présenter à
l’extérieur une version expurgée.
Comme pour les autres processus, il existe dans le commerce des
outils permettant la gestion de projet. Comme dans les autres cas, il
convient de correctement définir son besoin qui peut se limiter à un
tableur si nécessaire.
3.2 Processus d’infrastructure
Ce processus permet d’établir et de maintenir l’environnement
nécessaire à la vie du projet. Il comprend aussi bien le matériel, que
les outils, mais également les normes, les méthodes nécessaires à la
mise en œuvre des autres processus.
Le choix doit être fait au moment du démarrage du projet. Il n’est
pas nécessaire de rappeler qu’il est un des points essentiels pour la
réussite du projet.
Il convient de respecter quelques règles avant de choisir son
environnement :
— faire un état des lieux de l’existant, l’entreprise a déjà un envi-
ronnement, pourquoi ne pas le reprendre ?
— puis exprimer son besoin et expliquer son désir de change-
ment. Les points positifs sont toujours nombreux et les différents
revendeurs aident à les trouver. Il faut donc essayer de voir l’autre
côté des choses ;
— étudier les produits proposés, en particulier la pérennité, le
support, etc. ;
— consulter les personnes qui vont être directement concernées
par ce changement ;
— prévoir dans le planning des temps de formation, de mise en
œuvre et d’adaptation.
Dans le cas de la DO-178B, il est demandé pour certains outils de
fournir un dossier permettant la qualification de l’outil en même
temps que celle du produit. Ces exigences peuvent être lourdes à
mettre en œuvre, il convient d’en tenir compte.
Une approche possible est la constitution d’une check-list, avec
tous les points que l’on souhaite voir couverts par l’outil. Pour facili-
ter cette activité, l’écriture d’une spécification de l’outil dans le mode
textuel peut être un point d’entrée, avant d’en extraire les points
remarquables.
Cette liste doit être la plus complète possible, et validée par diffé-
rents types d’intervenants (utilisateurs, administrateurs, responsa-
bles techniques et financiers, supports internes...), pour aborder
tous les points de vue.
Cette check-list va être remplie pour chaque outil avec le plus
grand soin. Il est important de rappeler que les outils faisant déjà
partie de l’existant doivent être inclus dans l’étude et ceci avec un
maximum d’objectivité.
Cette étude doit être réalisée aussi bien théoriquement que prati-
quement, avec des essais en grandeur réelle. Il ne suffit pas de se
reposer sur les exemples proposés par les constructeurs, qui peu-
vent être très différents de ses besoins spécifiques.
L’analyse des résultats doit être menée avec soin. En effet, il est
très rare de trouver un outil remplissant tous les critères. Les points
positifs ou négatifs doivent donc être pondérés pour permettre un
choix.
Les conclusions sont alors remises à la direction pour la décision
finale.
Il est important de conserver ce dossier pour faciliter les recher-
ches ultérieures, pour lever les litiges sur les choix, pour améliorer
le processus de définition des environnements.
Il existe le document ISO 14102 qui offre des points de réflexion.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Mesures et Contrôle
3.3 Processus d’amélioration
Ce processus couvre la directive principale de l’ISO 9000. Un sys-
tème qualité doit être vivant.
La remise en cause des choix, des directives doit être faite réguliè-
rement. Mais attention de ne pas confondre évolution et instabilité.
Le temps de réactivité des personnes n’est jamais nul.
De façon périodique, il s’agit de se demander si les dispositions
établies sont efficaces (permettent d’atteindre les objectifs définis)
et d’identifier des gisements de progrès (amélioration de la produc-
tivité, amélioration de la qualité par réduction des risques, ...) ou des
axes de capitalisation (éléments positifs à généraliser).
Exemple : redéfinition de la stratégie de test afin de limiter les
« bugs » en maintenance.
La réalisation de ce processus nécessite la définition des actions à
mener et les responsabilités associées, puis la vérification de l’effi-
cacité de ces actions.
Ce processus d’amélioration peut être mené au niveau d’un pro-
duit particulier ou, de façon plus globale, au niveau d’un processus
ou d’un système qualité.
3.4 Processus de formation
Ce processus ne semble pas directement lié au logiciel. En effet, la
théorie voudrait que les personnes intervenant sur un projet soient
toutes parfaitement formées et aptes à accomplir leur tâche. Il est pré-
férable de se mettre face à la réalité et de considérer que tout au long
du cycle de vie du projet, des personnes seront à former (surtout si la
durée du développement est importante, ce qui renforce le risque de
turn-over), et d’en tenir compte dans le coût et les plannings.
Le plus courant, est la mise en place d’un plan de formation.
Il peut être intéressant de profiter de ce paragraphe pour insister
sur le facteur humain. C’est une idée assez nouvelle de prendre en
compte les facteurs humains dans un projet. Certains esprits sarcas-
tiques vont signaler que l’on n’est pas en Suède et que le côté
« assistante sociale » est non productif. Il faut regarder un peu plus
loin. L’analyse d’échec a montré des erreurs de « déploiement ».
Derrière ce terme générique, est souvent caché un écart important
entre les aptitudes des personnes et l’environnement de travail mis
a leur disposition. S’il est vrai que ce seul problème ne fait pas péri-
cliter l’ensemble, il est généralement révélateur d’un manque de
maturité générale.
4. Conclusion
Ce document a cherché à montrer que la qualité est présente dans
chaque processus du cycle de vie d’un produit, même si très sou-
vent le mot « qualité » n’est pas cité explicitement. Tout intervenant
d’un projet met en œuvre des actions qualité, éventuellement de
façon inconsciente, à l’instar de M. Jourdain.
La qualité n’est pas une activité autonome et intemporelle, qui
apparaît de temps à autre sur un projet. Ce n’est pas non plus un
doigt accusateur mettant en péril l’équilibre précaire du déroule-
ment du projet. La qualité consiste à ce que chacun soit pleinement
conscient de ses actions, de l’impact de ses décisions sur la qualité
du produit final.
La qualité est l’affaire de tous et de tous les instants.
R 8 080 − 9
QUALITÉ DES LOGICIELS INDUSTRIELS _____________________________________________________________________________________________________
5. Annexe A.
Les tests du logiciel
5.1 Étapes de test
Suivant le choix du cycle de vie, ces étapes peuvent légèrement
varier dans leur contenu et leur chronologie, leur principe restant
identique. Ces étapes sont les suivantes.
■ Les tests de validation
Ces tests vérifient les fonctionnalités, les interfaces, les perfor-
mances et le bon fonctionnement du logiciel. Ils doivent contrôler
que le logiciel répond bien aux besoins exprimés, qu’il s’insère cor-
rectement dans son environnement.
Le test de validation ne s’intéresse pas à la structure interne du
logiciel.
■ Les tests d’intégration du logiciel
Ces tests vérifient l’architecture du logiciel. Ils doivent contrôler
que les composants du logiciel communiquent correctement entre
eux.
Cette activité se fait en agrégeant progressivement les compo-
sants selon une stratégie définie au préalable, et en testant l’agrégat
ainsi constitué.
■ Les tests unitaires
Ces tests vérifient le codage. Ils contrôlent que le code du compo-
sant est conforme à l’algorithme sur les domaines de définition des
données d’entrée et de sortie.
Ces tests sont réalisés dans un environnement simulé. Ils sont le
plus souvent réalisés en isolant le composant et en remplaçant les
fonctions appelées par des fonctions dites « bouchons ».
5.2 Familles de tests
5.2.1 Tests fonctionnels
Comme leur nom l’indique, ces tests permettent de vérifier les
fonctionnalités du logiciel (au niveau d’un composant, d’un agrégat
ou d’un produit final).
Ils peuvent également comprendre les étapes suivantes.
■ Les tests de robustesse
Ces tests permettent de s’assurer que dans des conditions anor-
males non spécifiées, le composant ou l’agrégat ou le produit testé
remplit ses fonctions.
Exemple : la division par zéro, la non-réinitialisation des compteurs.
■ Les tests de performance
Ces tests servent à vérifier que le composant ou l’agrégat ou le
produit testé respecte les contraintes de temps, de charge, d’espace
mémoire, etc., qui lui sont imposées.
■ Les tests d’interface
Ces tests permettent de vérifier la cohérence entre les interfaces
des différents composants du logiciel.
Ces tests, surtout employés en phase d’intégration, permettent de
vérifier l’appel des composants en cours de test. Le contrôle porte
sur les liens entre les composants, sur les passages des paramètres
et leurs types.
5.2.2 Tests structurels
Le composant est considéré comme une boîte blanche. On s’inté-
resse à la structure interne du composant.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
R 8 080 − 10 © Techniques de l’Ingénieur, traité Mesures et Contrôle
On va essayer de montrer que l’on a couvert une partie de cette
structure, en utilisant la notion de taux de couverture :
taux de couverture =
nombre d′un type d′objets de structure couverts
------------------------------------------------------------------------------------------------------------------------------------------
nombre total de ce type d′objets
5.3 Techniques de tests
5.3.1 Découpage en classe d’équivalence
Cette technique ne s’intéresse qu’aux données d’entrée. Elle
consiste à découper l’espace des entrées en classes d’équivalence et
repose sur les hypothèses suivantes :
— le test sur une valeur représentative d’une classe est équiva-
lent à celui effectué sur n’importe quelle autre valeur représentative
de cette classe ;
— si un test dans une classe permet de trouver une erreur, tous
les tests effectués dans cette classe donneront la même erreur ;
— inversement, si un jeu d’essais ne met pas en évidence
d’erreur, il en sera de même pour tous les jeux d’essai que l’on
pourra élaborer pour cette classe.
L’élaboration des jeux d’essais se fait en deux étapes
● On commence par identifier les classes d’équivalence en consi-
dérant chaque condition d’entrée et en découpant le domaine
d’entrée en classes. On identifie ainsi des classes valides et invali-
des. Cette identification peut se faire suivant les principes généraux
suivants :
— si une entrée est représentée par un intervalle, on distingue
trois classes : une classe valide et deux classes invalides ;
— si une entrée est représentée par un type énuméré, on distin-
gue trois classes : une classe valide et deux classes invalides ;
— si une entrée est représentée par un domaine discontinu
induisant un comportement différent du logiciel testé, on distingue
une classe valide et une classe invalide pour chaque élément du
domaine.
● On crée ensuite les jeux d’essais en assurant la couverture de
toutes les classes d’équivalence valide.
Exemple : soit la fonction :
G(X) = –5 pour X < –5, G(X) = X pour –5 < X < 5, G(X) = 5 pour X > 5
On aura trois classes d’équivalence valides :
X = –200, X = 1, X = 10
Il faut remarquer que pour l’intervalle [–5, 5] :
— la classe valide est :
–5 < X < 5 ;
— que les deux classes invalides sont :
X < –5 et X > 5.
5.3.2 Analyse aux valeurs limites
Cette technique s’apparente à la technique précédente, cependant
elle diffère sur deux points :
— avec la technique précédente, tous les éléments d’une classe
d’équivalence sont représentatifs de la classe. Avec cette technique,
les valeurs extrêmes de la classe doivent également faire l’objet
d’un test ;
— cette technique s’intéresse à la fois aux données d’entrée et
aux données de sortie.
Cette technique consiste à déterminer les valeurs frontières des
variables d’entrée et de sortie des composants. On choisit les jeux
de tests de façon à ce que chaque variable prenne successivement
_____________________________________________________________________________________________________ QUALITÉ DES LOGICIELS INDUSTRIELS

des valeurs égales, juste inférieures, puis juste supérieures aux
valeurs limites.
Avec cette technique, on attache autant d’importance à l’espace
des valeurs de sortie qu’à celui des valeurs d’entrée.
L’expérience montre que l’analyse des valeurs limites est la plu-
part du temps intéressante. Ces points particuliers étant les lieux
des défauts les plus probables.
Exemple : si on reprend l’exemple précédent ; les limites sont –5
et 5. Il convient de tester des valeurs comme 5.1, 4.9, etc.
5.3.3 Graphe de causes à effets
On remarquera que la dernière phrase de l’exemple n’implique
pas que cette technique soit à rejeter de prime abord. Il convient de
parfaitement définir son besoin avant de se lancer dans une coû-
teuse campagne de tests.
5.3.6 Couverture de décision
Cette technique consiste à construire des jeux d’essais permettant
de passer au moins une fois par chaque point d’entrée et de sortie
du logiciel, et chaque décision du logiciel doit avoir pris toutes les
valeurs possibles au moins une fois.

Cette technique apporte une aide pour le choix de combinaison de Exemple :

données d’entrée choisies dans les classes d’équivalence. Elle per- if CondA and CondB then
met d’obtenir un grand nombre de jeux de tests et de détecter des traitement
oublis éventuels ou des ambiguïtés dans le document d’architecture. endif
Le graphe de cause à effets est un langage formel qui représente Si On teste :
à l’aide de notations simplifiées la logique des traitements spécifiés. CondA = Vrai et CondB = Vrai,
La démarche est la suivante :
CondA = Faux et CondB = Vrai
— décomposer le document de référence (spécification ou
conception globale), en entité appréhendable pour éviter une trop le taux de couverture de décision est de 100 %, mais CondB n’est pas
grande complexité des graphes ; testée.
— identifier les causes et les effets par une lecture approfondie :
• une cause est une condition d’entrée,
• un effet est une condition de sortie ou une transformation du 5.3.7 Couverture de condition
système due à une répercussion en sortie d’une condition
d’entrée ; Cette technique consiste à construire des jeux d’essais permettant
— construire le graphe de causes à effets en reliant les causes et à chaque condition d’avoir pris toutes les valeurs possibles au
les effets à partir du contenu sémantique ; moins une fois.
— compléter le graphe avec les contraintes éventuelles sur les
combinaisons des causes à effets ; Exemple :
— convertir le graphe en une table de décision. Chaque colonne if CondA and CondB then
de la table de décision correspond à un jeu d’essais : traitement
• mettre successivement un à un tous les effets à l’état vrai, endif
• à partir du graphe, rechercher toutes les combinaisons possi-
Si On teste :
bles des causes permettant d’obtenir chaque effet,
CondA = Vrai et CondB = Faux,
• créer une colonne pour chaque combinaison des causes,
• pour chaque combinaison, rechercher l’état de tous les effets CondA = Faux et CondB = Vrai
et les placer dans la table ;
le taux de couverture de condition est de 100 %, mais le traitement
— élaborer les jeux d’essais à partir de la table de décision.
n’est pas testé.
Il convient de souligner que cette technique, basée sur l’utilisation
des tables de vérité, devient rapidement inexploitable si elle est mal
appréhendée. 5.3.8 Couverture de condition/décision

5.3.4 Recherche intuitive d’erreurs Cette technique consiste à construire des jeux d’essais permettant
à chaque condition et à chaque décision d’avoir pris toutes les
Cette technique repose entièrement sur l’intuition de la personne valeurs possibles au moins une fois.
construisant les jeux d’essais. Cette personne doit « sentir » les
problèmes potentiels. Exemple :
Cette technique, bien que non scientifique et ne permettant if CondA then
d’apporter aucune preuve de bon fonctionnement, se révèle le plus if CondB then
souvent efficace lors d’un premier contact avec le composant à tester. traitement
endif
5.3.5 Couverture d’instruction endif
Si On teste :
Cette technique consiste à construire des jeux d’essais permettant CondA = Vrai et CondB = Vrai,
de passer au moins une fois par chaque instruction du logiciel.
CondA = Faux et CondB = Faux
Exemple :
if CondA and CondB then le taux de couverture de condition/décision est de 100 %, mais
« else » de « if CondB » n’est pas testée.
traitement
endif
Si On teste : 5.3.9 Couverture de condition/décision modifiée
CondA = Vrai et CondB = Vrai,
le taux de couverture d’instruction est de 100 %, mais la partie « else » Cette technique consiste à construire des jeux d’essais permettant
n’est pas testée. de passer au moins une fois par chaque point d’entrée et de sortie

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Mesures et Contrôle R 8 080 − 11
QUALITÉ DES LOGICIELS INDUSTRIELS _____________________________________________________________________________________________________

du logiciel, et à chaque condition et à chaque décision d’avoir pris V, F ⇒ V

toutes les valeurs possibles au moins une fois. F, V ⇒ V
Exemple : F, F ⇒ F
if CondA then Cas 3 :
if CondB then if A and B and C then..
traitement Jeux de tests pour A, B, C
endif V, V, V ⇒ V
endif
F, V, V ⇒ F
Si On teste :
V, F, V ⇒ F
CondA = Vrai et CondB = Vrai, V, V, F ⇒ F
CondA = Faux et CondB = Vrai, Cas 4 :
CondA = Vrai et CondB = Faux if A or B or C then..
le taux de couverture de condition/décision est de 100 %, l’identifica- Jeux de tests pour A, B, C
tion des jeux est délicate pour un cas un peu complexe. (Valeur A, Valeur B ⇒ Valeur de la condition)
F, F, V ⇒ V
5.3.10Couverture de condition/décision multiple F, V, F ⇒ V
V, F, F ⇒ V
Cette technique consiste à construire des jeux d’essais permettant F, F, F ⇒ F
de dire que :
Cas 5 :
— chaque combinaison de condition dans chaque décision doit
avoir pris toutes les valeurs possibles au moins une fois ; if (A or B) and C then..
— chaque condition dans une décision doit avoir été démontrée Jeux de tests pour A, B, C
comme affectant de façon indépendante la valeur de la décision. V, F, V ⇒ V
Exemple : F, V, V ⇒ V
if CondA then F, F, V ⇒ F
if CondB then V, F, F ⇒ F
traitement F, V, F ⇒ F
endif L’analyse de l’indépendance montre que seulement un des deux
endif derniers cas est nécessaire. Dans la pratique, il arrive souvent de
Si On teste : prendre les 5 jeux et non pas de chercher à supprimer le cas redon-
dant.
CondA = Vrai et CondB = Vrai,
Cas 6 :
CondA = Faux et CondB = Vrai,
if A or (B and C) then..
CondA = Vrai et CondB = Faux Jeux de tests pour A, B, C
CondA = Faux et CondB = Faux V, F, V ⇒ V
le taux de couverture de condition/décision est de 100 %. V, V, F ⇒ V
F, V, V ⇒ V
Lorsque la condition est complexe, le nombre de jeux de tests
F, F, V ⇒ F
devient très important (2 puissance N pour N conditions.)
F, V, F ⇒ F
On remarque que certains cas sont redondants et il est admis que
N + 1 jeux de tests peuvent être suffisants. Le paragraphe suivant L’analyse de l’indépendance montre que seulement un des deux
propose une approche pour choisir ces N + 1. premiers cas est nécessaire.
Ce cas sert à montrer l’importance des parenthèses. Si la condi-
tion est « A or B and C », la position des parenthèses est laissée à
5.3.11Choix des N + 1 jeux de tests l’appréciation dans un premier temps du compilateur, puis à celui
du testeur. Nous quittons le monde déterministe nécessaire à la
Cas 1 : construction des preuves.
if A and B then..
Jeux de tests pour A, B
5.3.12Le test de chemin
(Valeur A, Valeur B ⇒ Valeur de la condition)
V (Vrai), V ⇒ V
Un chemin est un ensemble de branches d’un graphe de contrôle
F (Faux), V ⇒ F reliant logiquement le point d’entrée d’un logiciel à son point de sor-
V, F ⇒ F tie.
Cas 2 : Le test de chemin consiste à exécuter un maximum de chemins
du graphe de contrôle. Il faut remarquer que lorsque le graphe est
if A or B then.. complexe, le nombre de chemin peut être trop important pour être
Jeux de tests pour A, B : couvert en totalité.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
R 8 080 − 12 © Techniques de l’Ingénieur, traité Mesures et Contrôle
_____________________________________________________________________________________________________ QUALITÉ DES LOGICIELS INDUSTRIELS

6. Annexe B. —
—
la capacité fonctionnelle ;
la fiabilité ;
Les normes, les standards, —
—
la facilité d’utilisation ;
le rendement (au sens de l’efficience) ;
les référentiels — la maintenabilité ;
— la portabilité.
Ces caractéristiques sont représentatives de la qualité du logiciel.
Il suffit dans un premier temps de choisir la ou les caractéristiques
6.1 DO-178B/ED-12B qui seront représentatives de son logiciel. La charge de travail per-
mettant de prouver que l’on satisfait une caractéristique pouvant
être importante, il est souhaitable de faire un choix judicieux.
Considérations sur le logiciel en vue de la certification des
systèmes et équipements de bord Comme on le voit, ces caractéristiques ne sont pas directement
mesurables. Il convient donc de se définir des métriques représenta-
Édition de décembre 1992. tives de chaque caractéristique.
But : ce document fournit à la communauté aéronautique des Pour aider à cette définition, la norme propose, à titre informatif,
directives pour déterminer, de manière cohérente et avec un degré une liste de sous-caractéristiques permettant une première appro-
acceptable de confiance, si les aspects relatifs aux logiciels des systè- che. Ce ne sont pas des métriques mais des attributs.
mes et équipements de bord satisfont les exigences de navigabilité.
Par exemple pour la fiabilité, ce sera :
Ce document, se basant sur les règlements de l’aviation, définit
— la maturité ;
des catégories de panne :
— la tolérance aux fautes ;
— catastrophique (risque sur la sécurité du vol et de l’atterris- — la possibilité de récupération.
sage) ;
— dangereuse (réduction importante des capacités de l’aéronef) ; Pour la maintenabilité, ce sera :
— majeure (réduction significative des capacités de l’aéronef) ; — la facilité d’analyse ;
— mineure (réduction non significative des capacités de l’aéro- — la facilité de modification ;
nef) ; — la stabilité ;
— sans effet. — la facilité de test.
Le niveau du logiciel est basé sur la faculté de celui-ci à rencontrer À partir de ce découpage, il est plus facile d’appréhender ce qui
certaines catégories de panne. Ce niveau implique l’effort néces- doit être mesuré. D’où la mise en place de métrique.
saire à fournir pour pallier le risque de survenue de ces pannes. Une métrique doit avoir les attributs suivants. Elle doit être :
Il existe 5 niveaux de A à E, correspondant aux 5 catégories. On — simple ;
parle du niveau de criticité du logiciel. Pour chacun de ces niveaux, — caractéristique ;
ce document définit les exigences à respecter. — non contraignante ;
Ce document demande de prouver que l’environnement de déve- — permanente ;
loppement, dans la mesure où il allège le travail, ne peut introduire — suivie ;
des erreurs dans le logiciel. — non contestable ;
— facilement interprétable ;
— ni trop stable, ni trop dynamique ;
— anticipative, si possible.
6.2 DoD-STD-2167
Le présent document ne cherche pas à faire une liste exhaustive
des métriques existants. Pour la théorie, il existe les travaux de
Defence system software development McCall, Halstead, McCabe, Mohanty.
Ce document du Department of Defence américain décrit l’ensem- Dans la pratique, il existe des outils de mesure et d’aide à l’inter-
ble des activités à réaliser pour être conforme à ce standard. prétation. On peut citer par exemple, LOGISCOPE de Vérilog (un
Il est annexé à ce document un ensemble de plans-type très direc- des plus anciens présent sur le marché français), ou Visual Quality
tifs décrivant les documents à fournir pour être conforme. ToolSet de McCabe & Associates suivant les métriques de McCabe.
À l’heure actuelle, ce document est en révision, les plans-type ne Ces outils ne sont pas les seuls, ils sont relativement complets
font plus partie du standard pour permettre de s’adapter plus facile- mais ne couvrent pas l’ensemble des métriques possibles. Il con-
ment aux nouvelles méthodes de travail, comme les méthodes à vient donc de bien réfléchir à son besoin avant d’en choisir un, si
objets par exemple. nécessaire.
Il est quand même intéressant de regarder ces plans-type car ils Il existe des outils du type de XRAY, qui travaillent uniquement sur
sont assez complets et peuvent servir de base de départ lors de la la couverture d’instructions. Si le besoin du projet est couvert, pour-
mise en place d’un nouvel environnement de travail. quoi aller plus loin.

Exemple de métriques :
— le nombre d’opérateurs distincts (n1) ;
— le nombre d’opérandes distincts (n2) ;
7. Annexe C. — le nombre d’occurrences d’opérateurs (N1) ;
— le nombre d’occurrences d’opérandes (N2) ;
La qualimétrie — la longueur du programme (N = N1 + N2) ;
— le volume du programme (V = N × log(n)) ;
— le nombre d’arc (e) ;
La norme ISO 9126 présente les activités nécessaires à la mise en — le nombre de nœud (n) ;
place de la qualimétrie. Elles sont résumées dans le schéma de la — le nombre de composants connectés (p) ;
figure 2. — le nombre cyclomatique (V(G) = e – n + 2p).
Cette norme définit six caractéristiques qui décrivent la qualité du Cette dernière métrique sert à évaluer la complexité du composant
logiciel. Ce sont : et, par la même, la difficulté qu’il y aura à le tester.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Mesures et Contrôle R 8 080 − 13
QUALITÉ DES LOGICIELS INDUSTRIELS _____________________________________________________________________________________________________

Besoins exprimés ou implicites Exigence du maître d'ouvrage

ISO/CEI 9126 et autres informations techniques Définition des exigences

Spécification
Définition d'exigences qualité
d'exigences
qualité

Définition des Définition

Choix des
échelles de des critères
métriques
classement d'évaluation
Préparation

Produits finis
ou en états
intermédiaires
Réalisation
du logiciel

Valeur
mesurée
Mesurage Évaluation

Niveau
de classement
Classement

Résultat
Évaluation (acceptable ou
non acceptable)

Figure 2 – Activités nécessaires à la mise en place de métriques

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
R 8 080 − 14 © Techniques de l’Ingénieur, traité Mesures et Contrôle
 P
O
U
Qualité des logiciels industriels R

E
par Élisabeth WALTI N
Consultant en qualité des logiciels
Responsable de secteur à la Société Qualience

S
Normes et directives
A
FD Z 67900 4-96 Technologies de l’information – Évaluation des
processus du logiciel. Modèle pour le manage-
NF ISO/CEI 12207 11-95 Ingénierie du logiciel, Processus du cycle de vie
du logiciel.
V
FD Z 67901 4-96
ment du processus.

Technologie de l’information – Évaluation des

ISO/CEI 9126
ISO/IEC 14102
1991
1995
Évaluation des produits logiciels.
Guideline for the evaluation and selection of
O
processus de logiciel. Guide pour la conduite
d’une évaluation. RTCA/EUROCAE DO-178B/ED-12B
CASE tools.
12-92 Considérations sur le logiciel en
I
FD Z 67902 4-96 Technologie de l’information – Évaluation des
processus de logiciel. Guide pour mener un
DoD-STD-2167A
vue de la certification des systè-
mes et équipements de bord.
Defense System Software Development.
R
programme d’amélioration de processus.
CMU/SEI-93-TR-24 CMM (Capability Maturity Model for Software) :
NF EN ISO 9001 8-94 Modèle pour l’assurance de la qualité en (basé sur les travaux de Humphrey, Managing
conception, développement, production, instal-
lation et prestations associées.
the Software Process, Addison-Wesley, Rea-
ding, MA) P
Modèles
L
Capability Maturity Model for Software (CMM)
Software Process Improvement and Capability Determination (SPICE)
U
(ISO)
S

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. − © Techniques de l’Ingénieur, traité Mesures et Contrôle Doc. R 8 080 − 1