DOSSIER INFORMATIQUE TECHNOLOGIE APPLIQUÉE Claude PINET 1 Validation et qualité des systèmes de traitement de l information dédiés aux laboratoires RÉSUMÉ Quel que soit son domaine d application, un système de traitement de l information doit de façon évidente être de «bonne qualité». Le terme «bonne» est subjectif et ce qu il implique doit être mesuré pour être démontré. Pour cela, des preuves tangibles doivent confirmer que le niveau d exigences fixé est atteint avec satisfaction. Ces vérifications et validations doivent s effectuer sur les processus et sur les livrables. Ce document présente les méthodes et outils pour y parvenir. MOTS-CLÉS Qualité, évaluation, validation, conformité, cycle de vie, critères qualité (caractéristiques), attribut, capacité, maturité, modèle de référence. Validation and quality for laboratories information technology systems SUMMARY An information technology system must be of a good quality level. As this is something subjective, it must be measured. Its meeting the requirement level set in a satisfactory manner must be demonstrated with physical proves. Controls and validations must be applied on the processes and on the deliveries. The present document explains the methodology and tools to achieve that. KEYWORDS Quality, assessment, validation, conformity, life circle, quality criteria (characteristic), attribute, capability, maturity, referential model. Qualité I - Introduction Un système d information se compose de données (éléments d information, en anglais data) et de traitements. Ces derniers constituent des successions d opérations élémentaires qui se déroulent dans un ordre précis, lorsque les traitements sont structurés on parlera de processus. Les parties du système d information qui sont automatisés constituent le système informatique qui est implanté sur un, ou plusieurs, ordinateur(s). Les traitements automatisés sont stockés sur support (magnétique ou optique) ; ils constituent le logiciel qui a pour principale caractéristique le fait d être immatériel. Toutefois, son utilisation requiert un environnement matériel et réseau pour pouvoir fonctionner. Il est évident que le système d information d un laboratoire doit être conforme aux exigences exprimées pour son fonctionnement, c est le gage de son niveau de qualité. En revanche, pour les systèmes logiciels la problématique de leur validation est de plus en plus complexe. En effet, leurs architectures intègrent souvent des progiciels plus ou moins paramétrés comme des LIMS dans le domaine du laboratoire, des modules personnalisés et des logiciels développés pour des besoins spécifiques. Lors des livraisons (initiale ou des versions successives) il est difficile de vérifier que tous les livrables (logiciels, documentations et services) mis à disposition par le fournisseur correspondent exactement à ce qui a été commandé et aux besoins exprimés par les utilisateurs du système. 1 CPI Conseil 6, rue de la Corniche 91120 Palaiseau Tél./Fax : 01 60 10 63 59 E-Mail : cpi.conseil@online.fr http://cpi.conseil.free.fr/ 30 SPECTRA ANALYSE n 253 Décembre 2006
Technologie appliquée Validation et qualité des systèmes de traitement de l information dédiés aux laboratoires II - Définitions Avant d aborder les méthodes et les outils de la validation de la qualité des systèmes d information dédiés au laboratoire, il apparaît utile de revenir sur quelques définitions. La qualité : c est la satisfaction des exigences exprimées par un client. Logiciel : «Ensemble des programmes, des procédures et de la documentation et des données éventuellement associées.» (Source : ISO/CEI 12207 : 1995). Qualité du logiciel : «Ensemble des traits et des caractéristiques d un produit logiciel portant sur son aptitude à satisfaire des besoins exprimés ou implicites.» (Source : ISO/CEI 9126 : 1991) Validation : c est la vérification de la conformité aux exigences spécifiées. (Source : ISO 9000 : 2005) La validation d un système logiciel : c est la vérification que les livrables (logiciel, documentation, procédures, formation, services annexes) délivrés par un fournisseur sont conformes à ce qui a été commandé ; en terme de fonctionnalité et de performances. «Confirmation par examen et apport de preuves tangibles que les exigences particulières pour un usage spécifique prévu sont satisfaisantes.» (Source : ISO/CEI 12207 : 1995) La validation d un service de traitement de l information : c est la vérification au moyens d indicateurs prédéfinis, qu un service de traitement de l information est délivré conformément aux spécifications définies. Vérification : «Confirmation par examen et apport de preuves tangibles que les exigences spécifiées ont été satisfaites.» (Source : ISO/CEI 12207 : 1995). III - Méthode d évaluation / validation Le contexte La validation n est qu une étape qui s inscrit dans un processus plus vaste (figure 1) de progrès et de gestion du changement. Nous allons nous limiter à la partie évaluation et à ses outils qui permettent de valider le niveau de qualité d un système de traitement de l information. Le domaine d application Tout d abord, il ne faut pas confondre une mission d audit qualité qui vise généralement l obtention d une certification avec une mission d évaluation qualité dont l objectif est la recherche et la mise en place d améliorations. Pour apprécier le niveau de qualité d un objet, matériel ou immatériel, nous avons à notre disposition deux catégories d évaluations : l évaluation de la qualité des processus de conception, de fabrication et de livraison ; l évaluation de la qualité du/des produit(s) et service(s) livré(s). Ces évaluations sont complémentaires et peuvent être menées en parallèle. Le processus d évaluation Une évaluation qu elle concerne des processus ou des produits services se déroule selon une démarche systématique. Les étapes de la démarche d évaluation sont : 1 ) le choix d un référentiel : Pour les processus logiciels ; Pour les produits logiciels. 2 ) la planification des actions à entreprendre : Contrôles sur les processus (calage sur les étapes) ; Contrôles sur les livrables (produits / services). 3 ) le déroulement des actions planifiées, Sur les processus ; Sur les livrables (produits / services). 4 ) la formalisation des observations de l évaluateur dans un rapport : Définition de la structure du rapport ; Alimentation du contenu du rapport ; Approbation du rapport. Figure 1 Processus de progrès et de gestion du changement. SPECTRA ANALYSE n 253 Décembre 2006 31
DOSSIER INFORMATIQUE TECHNOLOGIE APPLIQUÉE La démarche de validation proposée garantit un processus de vérification systématique maîtrisé qui apporte des preuves tangibles du niveau de qualité atteint. IV - La validation des processus logiciels 1. Le référentiel pour les processus logiciels Nous disposons d un référentiel normatif international qui décrit le modèle type d un projet d implantation d un nouveau système de traitement de l information. Ce modèle appartient à la norme ISO/CEI 12207 : 1995 (voir les sites Web de l organisation internationale de normalisation www. iso.org et celui de la commission électrotechnique internationale www.iec.ch). Selon ce modèle, les processus d un système de traitement de l information se répartissent dans les trois catégories de processus suivantes (figure 2) : Les processus de base ; Les processus de support ; Les processus organisationnels. La famille des processus de base contient toutes les activités relatives à la vie d un système de traitement de l information. On les appelle processus du «cycle de vie» par analogie avec le déroulement de l existence qui va de la naissance à la mort. A chacune des étapes (acquisition, fourniture, développement ) correspond des objectifs qui sont définis, une finalité à respecter, des tâches à réaliser, des livrables à fournir. La famille des processus de support contient toutes les activités connexes aux processus de base mais néanmoins indispensables à leur maîtrise ; donc à l atteinte du niveau de qualité. La famille des processus organisationnels couvre les activités de gestion qui garantissent la réussite «managériale» du projet. Chaque processus est répertorié et géré. Il existe une description détaillée de chaque processus sous la forme de fiches dont un exemple est présenté en Figure 3. Cette description est éventuellement complétée par une représentation graphique (logigramme) de l enchaînement des activités constitutives du processus. Les processus identifiés dans le modèle de référence sont génériques. Lors de l évaluation il convient de prendre en compte la complexité du contexte du laboratoire et d y adjoindre tous les processus spécifiques. 2. L évaluation des processus Figure 2 Le modèle de processus d après ISO/CEI 12207. L évaluation doit s appuyer sur des critères bien définis. La stabilité dans le temps des critères permettra des comparaisons entre les résultats de plusieurs évaluations successives. Les écarts constatés d une évaluation à l autre matérialisent les progrès (ou les régressions) et guident le choix pour des actions d amélioration. L évaluation s effectue par rapport au modèle d évaluation décrit dans l ISO/ CEI 15504 (Spice). 2.1- Le concept de dimension de processus L évaluation de processus est conduite selon deux dimensions (figure 4) : Figure 3 Fiche de description de processus. 32 SPECTRA ANALYSE n 253 Décembre 2006
Technologie appliquée Validation et qualité des systèmes de traitement de l information dédiés aux laboratoires Figure 4 Les dimensions de l évaluation de processus d après ISO/CEI 15504. La dimension processus qui va permettre de ranger le processus dans l une des trois catégories : base (primary), support (supporting) ou organisationnel (organizational) ; La dimension de capacité qui va permettre de ranger le processus dans l un des six niveaux de l échelle de maturité. 2.2- Le concept d attribut de processus Evaluer c est mesurer les processus. Pour cela il faut définir des caractéristiques (Il s agit là d un trait distinctif. La caractéristique qualité : caractéristique intrinsèque d un produit, d un processus ou d un système relative à une exigence (d après ISO 9000 : 2005)) mesurables. Ce sont les attributs (définition de l attribut de processus : caractéristique mesurable de l aptitude de processus applicable à tout processus (d après ISO 15504-9 : 1998)) du management du processus (process attributes). La norme en a retenu neuf qui sont listés dans le Tableau I. 2.3-Le concept de niveau d aptitude Les mesures étant définies, il faut une échelle graduée afin de positionner les résultats des mesures. Pour déterminer l aptitude (l aptitude de processus est la faculté d un processus à atteindre un but exigé (d après ISO 15504-9 : 1998)) des processus à mesurer, la norme a retenu six niveaux qui sont listés dans le Tableau II. Le niveau zéro correspond à un état naturel où rien n est fait. Plus on monte dans les niveaux du modèle, plus le processus a acquis de la maturité. 2.4- La cotation de processus La cotation d attribut de processus se définit comme le jugement du niveau d atteinte de l aptitude définie de l attribut de processus pour le processus évalué (d après ISO 15504-9 : 1998). Pour chacun des neuf attributs du modèle d évaluation l évaluateur va faire des observations et des mesures. C est la cotation. Il existe deux types de cotations : La cotation de la finalité de processus ; La cotation du management de processus. 2.5- La cotation de la finalité de processus Pendant le déroulement de la cotation, la finalité du processus est jaugée (figure 5, voir page suivante) sur les critères de l attribut PA 1.1 (attribut N 1). Cet attribut permet d apprécier la réalisation du processus. L objectif étant de juger si le processus satisfait à sa finalité définie. CODE PA 1.1 PA 2.1 PA 2.2 PA 3.1 PA 3.2 PA 4.1 PA 4.2 PA 5.1 PA 5.2 LIBELLE Attribut de réalisation de processus Attribut de gestion de la réalisation Attribut de gestion des produits du travail (work product) Attribut de définition de processus Attribut de ressource de processus Attribut de mesurage du processus Attribut de maîtrise du processus Attribut de changement de processus Attribut d amélioration continue Tableau I Table des attributs de processus (Process Attributes : PA) SPECTRA ANALYSE n 253 Décembre 2006 33
DOSSIER INFORMATIQUE TECHNOLOGIE APPLIQUÉE NIVEAU TITRE DESCRIPTION NIVEAU 0 Le processus n est pas réalisé NIVEAU 1 Le processus est réalisé Le processus a qualifié ses objectifs NIVEAU 2 Le processus est géré Toutes les activités planifiées sont faites et que toutes les exigences des produits issus du processus sont identifiées NIVEAU 3 Le processus est établi La mise en œuvre du processus s appuie sur des pratiques standardisées NIVEAU 4 NIVEAU 5 Le processus est prévisible Le processus est en optimisation Les variations d un processus sont mesurées et comprises. Les mesures collectées sont utilisées pour piloter et contrôler le déroulement du processus L organisation est capable d améliorer ses processus et de les adapter de façon proactive afin de s adapter à l évolution des exigences Tableau II Niveaux de maturité Figure 5 Le processus de cotation de la finalité de processus Figure 6 Le processus de cotation de management de processus 2.6 - La cotation de management de processus Pendant le déroulement de la cotation, la finalité est jaugée (figure 6) au moyen des critères de chacun des attributs PA 2.1 (attribut N 2) à PA 5.2 (attribut N 9). Notamment l évaluation estimera si : les pratiques sont-elles adéquates pour gérer le processus ; les résultats des pratiques existent ; ces résultats sont appropriés. Le résultat de la mesure sur chaque attribut de processus de chaque processus s apprécie dans les termes suivants : - soit l attribut n a pas été évalué (not rated), - soit les exigences ne sont pas atteintes (not achieved), - soit les exigences sont partiellement atteintes (partially achieved), - soit les exigences sont largement atteintes (largely achieved), - soit les exigences sont complètement atteintes (fully achieved). 2.7 - La détermination du profil de processus Ensuite, les attributs de processus sont groupés dans les niveaux d aptitudes. En fonction du résultat de la mesure obtenue sur chacun des attributs de processus le niveau de maturité est déterminé : niveau de maturité atteint. Le résultat de la cotation obtenue est comparé à la grille standard (tableau III). L évaluateur en déduit le positionnement du processus évalué sur l échelle de maturité. En final on obtient le profil processus par processus. Le processus de cotation ainsi conduit met en évidence les forces et faiblesses de chaque processus. Par exemple le niveau 3 est attribué si les PA 1.1, PA 2.1 et PA 2.2 sont jugés pleinement réalisés et si les PA 3.1 et PA 3.2 sont jugés au moins largement réalisés. 2.8 - Le rapport d évaluation de processus Le processus d évaluation doit produire un livrable formalisé (exemple de tableau de synthèse d évaluation voir tableau IV). 34 SPECTRA ANALYSE n 253 Décembre 2006
Technologie appliquée Validation et qualité des systèmes de traitement de l information dédiés aux laboratoires Niveau Echelle de maturité N PA Attribut de processus Cotation de référence 0 Incomplet 1 Réalisé PA1.1 Réalisation de processus Largement ou pleinement PA1.1 Réalisation de processus Pleinement 2 Géré PA2.1 Gestion de la réalisation Largement ou pleinement PA2.3 Gestion des produits du travail Largement ou pleinement PA1.1 Réalisation de processus Pleinement PA2.1 Gestion de la réalisation Pleinement 3 Etabli PA2.3 Gestion des produits du travail Pleinement PA3.1 Définition de processus Largement ou pleinement PA3.2 Ressource de processus Largement ou pleinement PA1.1 Réalisation de processus Pleinement PA2.1 Gestion de la réalisation Pleinement PA2.3 Gestion des produits du travail Pleinement 4 Prévisible PA3.1 Définition de processus Pleinement PA3.2 Ressource de processus Pleinement PA4.1 Mesurage du processus Largement ou pleinement PA4.2 Maîtrise du processus Largement ou pleinement PA1.1 Réalisation de processus Pleinement PA2.1 Gestion de la réalisation Pleinement PA2.3 Gestion des produits du travail Pleinement PA3.1 Définition de processus Pleinement 5 En optimisation PA3.2 Ressource de processus Pleinement PA4.1 Mesurage du processus Pleinement PA4.2 Maîtrise du processus Pleinement PA5.1 Changement de processus Largement ou pleinement PA5.2 Amélioration continue Largement ou pleinement Tableau III Grille standard d atteinte des niveaux après cotation Tableau IV Exemple de résultat d évaluation pour un ensemble de processus. (couleur de fond, blanc : non coté (not rated) ; vert : non réalisé (not achieved) ; bleu : partiellement réalisé (partially achieved ) ; orange : Largement réalisé (largely achieved) ; rouge : complétement réalisé (fully achieved). Le rapport doit décrire : Le rôle et les responsabilités ; Les outils et techniques utilisés ; Les ressources requises ; La séquence des activités : - Planification (description de l ensemble des informations requises. Approbation du plan) ; - Collecte des données(systématique et ordonnée. Modalités) ; - Validation des données (s assurer de la couverture du champ d évaluation) ; - Cotation des processus (pour chaque attribut, validation des cotations. Enregistrement des cotations) ; - Compte rendu (restitution des modalités, format des données d entrée, conservation des enregistrements de sortie). SPECTRA ANALYSE n 253 Décembre 2006 35
DOSSIER INFORMATIQUE TECHNOLOGIE APPLIQUÉE Tableau V Les caractéristiques qualité d un logiciel d après ISO/CEI 9126 : 2001. Capacité fonctionnelle (Functionality) Fiabilité (Reliability) Facilité d utilisation (Usability) Rendement (Efficiency) Maintenabilité (Maintainability) Portabilité (Portability) CARACTERISTIQUES SOUS CARACTERISTIQUES Aptitude (Accuracy) Exactitude (Suitability) Interopérabilité (Interoperability) Sécurité (Security) Conformité à l aptitude fonctionnelle (Functionality compliance) Maturité (Maturity) Tolérance aux fautes (Fault tolerance) Possibilité de récupération (Recoverability) Conformité relative à la fiabilité (Reliability compliance) Facilité de compréhension (Undertandability) Facilité d apprentissage (Learnability) Facilité d exploitation (Opérability) Pouvoir d attraction (Attractability) Comportement vis à vis du temps (Time behaviour) Utilisation des ressources (Resource behaviour) Conformité relative au rendement (Efficiency compliance) Facilité d analyse (Analysability) Facilité de modification (Changeability) Stabilité (Stability) Facilité de tests (Testability) Conformité relative à la maintenabilité (Maintenability compliance) Facilité d adaptation (Adaptability) Facilité à l installation (Installability) Facilité à co-exister (Co-existence) Interchangeabilité (Replaceability) Conformité aux règles de portabilité (Portability compliance) V - La validation des produits/services logiciels 1. Le modèle de référence des produits logiciels Nous disposons d un référentiel normatif international qui décrit 6 caractéristiques et 26 sous caractéristiques qualité (tableau V). Ce modèle appartient à la norme ISO/CEI 9126 : 2001 partie 1. Chacune des caractéristiques/sous caractéristiques comporte une définition détaillée normée. 1.1 - Trois niveaux d exigences de qualité, trois niveaux de validation Les exigences de qualité internes Elles permettent de spécifier les propriétés d un produit logiciel pendant son développement. Leur validation s effectuera au regard de métriques internes définies quantitativement en fonction des stratégies de développement. Les revues de code et les tests techniques permettent de détecter des non conformités et d entreprendre des améliorations. Toutefois, la qualité interne est intimement liée à la qualité de la conception du logiciel. Les exigences de qualité externes Elles permettent de spécifier les propriétés d un produit logiciel prévues pour le moment de sa livraison au client. Leur validation s effectuera au regard de métriques externes définies pour répondre aux besoins exprimés par l utilisateur. Le déroulement des tests dans un environnement simulé, avec des données simulées, contribue à la validation des métriques externes. Toutefois, certains défauts peuvent demeurer après ces tests fonctionnels. Les exigences de qualité en utilisation Elles permettent de spécifier les exigences qu un produit logiciel doit satisfaire au niveau du poste de travail opérationnel de l utilisateur. Leur validation s effectuera au regard de métriques de fonctionnement définies souvent de manière interactive. La qualité de fonctionnement s apprécie en environnement réel. Son évaluation contribue à vérifier si les attributs du logiciel (placé dans son environnement définitif : exploitation et réseau) permettent à l utilisateur final de satisfaire aux objectifs des activités de son métier. Les attributs (un attribut constitue une propriété physique ou abstraite mesurable. Les attributs peuvent être internes ou externes (d après ISO/ CEI 9126 : 2001)) de la qualité de fonctionnement portent essentiellement sur : l efficacité, la productivité, la sécurité et la satisfaction. 1.2 - Trois catégories de métriques pour trois niveaux d exigences L ISO/CEI 9126 dans sa partie 1 donne l ensemble des attributs qui caractérisent la qualité d un logiciel. Toutefois, compte tenu des trois niveaux d exigences, des métriques spécialisées sont positionnées pour chacun des niveaux. L ISO/CEI 9126 dans sa partie 2 décrit les métriques internes pour les exigences internes. L ISO/CEI 9126 dans sa partie 3 décrit les métriques 36 SPECTRA ANALYSE n 253 Décembre 2006
Technologie appliquée Validation et qualité des systèmes de traitement de l information dédiés aux laboratoires Critère (caractéristique) Indicateur Métrique Evaluation Interprétation Facilité de test Couverture fonctionnelle Matrice d exigences Existe-t-il une matrice d exigences? Exécution des tests de validation Résultats des tests de validation Journal d exécution des tests de validation Problèmes bloquants Problèmes majeurs Scénarios de tests de validation Tous les tests de validation on-t-ils été effectués? Quel est le pourcentage des tests de validation interrompus à cause d un problème bloquant? Quel est le pourcentage des tests de validation interrompus à cause d un problème majeur? Quel est le pourcentage des scénarios de validation abandonnés? - Oui - Non - Oui - Non - 0 % accepté - autre rejeté - 5 % accepté - autre rejeté - <10 % accepté - autre rejeté externes pour les exigences externes. L ISO/CEI 9126 dans sa partie 4 décrit les métriques d utilisation pour les exigences en utilisation. 1.3 - Le choix des indicateurs Un indicateur constitue une mesure pouvant permettre d évaluer ou de prévoir une autre mesure externe. La valeur prévue peut être issue de la même caractéristique de qualité ou d une caractéristique différente. Les indicateurs peuvent être utilisés à la fois pour évaluer des attributs de produit logiciel et pour évaluer des attributs de processus (d après ISO/CEI 9126 : 2001). Le choix des indicateurs sera fonction des objectifs assignés à l évaluation. Le commanditaire (sponsor) de l évaluation peut souhaiter vérifier d une manière plus approfondie tel attribut particulier. Le modèle d évaluation sera adapté en conséquence. Quelques exemples d indicateurs : Pour la conformité fonctionnelle : la traçabilité de la couverture fonctionnelle ; Pour la facilité d exploitation : le manuel d exploitation, le service help desk ; Pour la facilité d installation : le manuel d installation, les tests d installation. 1.4 - Les métriques Une métrique est une méthode de mesurage (affectation d une valeur, nombre ou catégorie, par rapport à une échelle) définie et qui utilise une échelle de mesurage. Les métriques peuvent être internes ou externes. Elles comprennent des méthodes de catégorisation des données qualitatives (d après ISO/CEI 9126 : 2001). Le nombre et le type de métriques sera positionné afin de répondre au plus près des exigences (de même les seuils de conformité et d acceptabilité). Le modèle de référence est nécessairement générique et ne décrit pas comment il faut faire. C est pourquoi pour chaque sous caractéristique il importe de définir des indicateurs et des métriques. Le choix des métriques doit être pertinent au regard des objectifs d évaluation, notamment : Pour être en adéquation avec les attributs à mesurer ; Pour le positionnement des capteurs d information ; Pour le degré de précision attendu. Un exemple de choix d indicateurs et de métriques est donné dans le Tableau VI. 1.5 - Les mesures Certains indicateurs seront mesurés «manuellement». Dans ce cas ils sont conditionnés par une appréciation humaine, donc une part plus ou moins importante de subjectivité. Par exemple : L appréciation de la couverture fonctionnelle implique une compétence métier ; L appréciation de la lisibilité et de la complétude de la documentation sera fonction de la perception du lecteur. D autres indicateurs seront le résultat de comptages automatiques réalisés par des sondes ou des outils. Leur précision dépendra de la finesse de leur calibrage et de leur étalonnage. Par exemple : Le taux de commentaires des composants. Le nombre cyclomatique Le taux de couverture des cas de tests. On remarque que les valeurs de conformité fixées comme valeurs normales attendues pour une mesure pourront être différentes en fonction du langage de programmation utilisé. Ainsi, pour un même systèmes informatique, la valeur standard du nombre cyclomatique (voir note 1) peut varier. A titre d exemple, Pour des composants logiciels écrits en langage C, la valeur standard de conformité de V(G) est généralement fixée à 10 alors qu elle est le plus souvent de 8 pour des composants logiciels écrits en langage Java. 1.6 - L interprétation des résultats Les résultats bruts des mesures effectuées lors d une évaluation ne sont pas toujours significatifs. Souvent ils ont besoins d être interprétés afin de donner du sens à leur lecture. L interprétation tient compte du contexte, mais aussi du degré de précision de la mesure, et d une certaine marge d erreur (effet de seuil). Ainsi, pour un indicateur donné fixant une exigence, une valeur cible à atteindre est définie. Cette Tableau VI Exemple de métriques. NOTE 1 Le nombre cyclomatique permet de mesurer le nombre de décisions qui existent dans la structure d un composant logiciel. Sa valeur représente le nombre de chemins possibles qui traversent un composant logiciel donné. Il s exprime sous la forme de l expression suivante : V(G) = au nombre de décisions du composant+1 SPECTRA ANALYSE n 253 Décembre 2006 37
DOSSIER INFORMATIQUE TECHNOLOGIE APPLIQUÉE Figure 7 Les niveaux d interprétation des mesures. valeur objectif constitue le seuil de conformité. Le relevé de la mesure de cet indicateur donne une certaine valeur. Cette mesure est comparée au seuil de conformité (la cible) (figure 7). Si l égalité est obtenue l exigence est satisfaite. Généralement, l égalité parfaite n est pas obtenue. Ainsi, il peut être judicieux de fixer une plage de tolérance (en plus ou en moins de la valeur de conformité suivant le cas) et de choisir un seuil d acceptabilité. Toute mesure relevée comprise dans cette plage de tolérance sera acceptée et l exigence sera considérée comme satisfaite. 2. Le modèle d évaluation des produits logiciels Nous disposons d un référentiel normatif international qui décrit le modèle type d une évaluation de produit logiciel. Ce modèle appartient à la norme ISO/CEI 14598 et à l ensemble des normes de la série ISO/CEI 25000 Software product Quality Requirements and Evaluation (SQUARE) (figure 8). 2.1 - Les étapes du processus d évaluation Un processus standard d évaluation comprend les étapes suivantes (ISO/CEI 14598 partie 1) : Etablir les exigences de l évaluation - Etablir le périmètre de l évaluation - Identifier les types de produits logiciel concernés - Spécifier le modèle qualité (caractéristiques qualité) Spécifier l évaluation - Sélectionner les métriques (internes, externes, en utilisation) - Etablir les niveaux de cotation des métriques - Etablir les critères d évaluation Concevoir l évaluation (dresser le plan de l évaluation) Exécuter l évaluation - Mesurer les caractéristiques qualité - Comparer les mesures avec les critères - Evaluer les résultats 2.2 - Environnement et ressources Pour réussir une évaluation de produit logiciel il faut : Un planning et du management (ISO/CEI 14598 partie 2). Des modules d évaluation qui définissent la structure et le contenu de la documentation utilisée (ISO/CEI 14598 partie 6). 2.3 Catégories de destinataires de l évaluation Il existe trois catégories de destinataires d une évaluation de produit logiciel : 1 ) Les développeurs, soit d un nouveau produit, soit d une extension d un produit existant. Généralement cette évaluation est réalisée par le propre personnel technique de l entreprise. Le choix des indicateurs internes de mesure concerne des composants intermédiaires développés pendant le cycle de vie du projet. La comparaison par rapport à des exigences établies préalablement donne des indications d améliorations pour les étapes suivantes du projet. Cette évaluation, décrite dans l ISO/ CEI 14598 partie 3 peut aussi être utilisée en complément d une évaluation d acquisition. 2 ) Les acquéreurs, lorsqu une organisation achète ou réutilise un produit logiciel développé préalablement, soit d un nouveau produit, soit d une extension d un produit existant. Cette évaluation sert à déterminer le niveau d acceptation de ce produit ou sa comparaison avec d autres produits alternatifs. C est le cas notamment pour les produits dits «sur étagères» (ou selon l expression anglo-saxonne, Components off the shelf (Cots)). Cette évaluation est décrite dans l ISO/CEI 14598 partie 4. 3 ) Les évaluateurs, lorsqu une organisation décide de faire procéder à une évaluation en externe réalisée par un évaluateur indépendant (tierce partie). Cette évaluation résulte d une demande d un organisme développeur ou acquéreur. Elle est décrite dans l ISO/CEI 14598 partie 5 qui Figure 8 Le modèle qualité produit logiciel d après ISO/CEI 25000. 38 SPECTRA ANALYSE n 253 Décembre 2006
Technologie appliquée Validation et qualité des systèmes de traitement de l information dédiés aux laboratoires Figure 9 Exemple de résultat de l évaluation de produit logiciel (graphe radar selon les caractéristiques). définit les conditions contractuelles de l opération, les responsabilité de chacun des intervenants et les livrables. Ce processus standard garanti des caractéristiques d évaluation qui sont reproductibles, impartiales et objectives. 2.4 - Exemple de résultat d évaluation de produit logiciel Les résultats d une évaluation de produit logiciel pourront être présentés sous la forme d un graphe «en radar». Un exemple de ce type de restitution est présenté en figure 9. Les valeurs mesurées pour chaque caractéristique qualité sont positionnées sur un axe. Ainsi, dans l exemple présenté, on remarquera que les scores obtenus pour les sous caractéristiques RELIABILITY et EFFICIENCY sont respectivement de 90 et 100 % sur les métriques choisies. Par contre, le score obtenu pour le critère USABILITY n est que de 50 %. Au vu d un tel résultat un plan d action d amélioration devra être mis en place pour atteindre un/des objectif(s) d amélioration. La campagne suivante de mesure et d évaluation permettra d en vérifier les effets. D une façon analogue, les évaluations sur chacune des sous caractéristiques pourront donner une présentation graphique similaire des résultats des mesures. VI - Conclusion Les processus de validation d un logiciel garantissent le niveau de qualité d un système de traitement de l information quel qu il soit. Toutefois cette validation est encore plus importante pour des systèmes qui gèrent des informations stratégiques faisant appel à des technologies complexes dans des environnements à risque qui doivent être maîtrisés. La qualité d un tel système, perçue par chacun des acteurs qui contribuent à son utilisation, va s exprimer sous la forme de la satisfaction qu ils en retirent. Pour atteindre le niveau de satisfaction requis, nous avons utilisé deux leviers à notre disposition : l évaluation des processus et l évaluation des livrables. Pour y parvenir les référentiels normatifs internationaux mettent à notre disposition des méthodes et des outils permettant la mise en œuvre de mesures objectives. Il nous appartient de les déployer efficacement pour engager et développer une démarche d amélioration continue. SPECTRA ANALYSE n 253 Décembre 2006 39