Universit du Qubec

cole de technologie de linformation Universit du Qubec Montral

Rapport du projet dapplication

Assurance et contrle qualit du logiciel
Rapport prsent pour lobtention du diplme de matrise en Technologie de linformation

tudiant Chawki Hajjem

Directeur du projet Philippe Gabrini Dr Ing., I. P. A. Professeur titulaire Dpartement Informatique Universit du Qubec Montral

Sessions Hiver / t 2003

Remerciements
Je tiens adresser mes profonds remerciements Monsieur Philippe Gabrini professeur au dpartement informatique luniversit du Qubec Montral, qui a bien voulu diriger ce travail avec ses trs grandes comptences reconnues non seulement sur le plan professionnel mais aussi scientifique. Ma profonde gratitude sexprime galement M.Fazil Chouakri conseiller principal au niveau de CGI ainsi qu M.Daniel Thavard responsable qualit et dveloppement au niveau de CGI pour leur participation active et comptente llaboration du projet. Mes remerciements vont galement tous ceux et celles qui mont aid de prs ou de loin la ralisation du projet.

Prsentation du cadre de travail Ltude est ralise dans le cadre de la prparation dune matrise en sciences en technologie de linformation et plus prcisment dans le cadre du projet dapplication qui fait partie du bloc 3, intitul innovation technologique dans lorganisation. Le projet dapplication vise lapprofondissement des connaissances et leur mise en application dans un processus dinnovation ou de recherche et dveloppement. Le projet prsente deux dimensions : technologique et organisationnelle. Il est compos des activits suivantes : recherche bibliographique, dfinition dune problmatique, laboration dune mthodologie, tude thorique approfondie du thme de recherche, ralisations des activits, et rdaction du rapport final. Les diverses activits du projet se droulent sous la direction du directeur du projet.

Rsum Le projet mis en uvre est intitul lassurance et le contrle de la qualit du logiciel ; il tudie lassurance de la qualit du logiciel selon deux perspectives : thorique et pratique. Ltude thorique identifie les normes officielles (ISO 9000) et professionnelles (IEEE) ainsi que le modle thorique (CMM) encadrant lassurance et le contrle de la qualit du logiciel. Elle prsente aussi les exigences respecter pour assurer llaboration de logiciels de qualit, de mme que les activits lies lassurance et au contrle de la qualit du logiciel. Ltude pratique a t ralise au niveau de la CGI et plus prcisment au niveau de lunit de dveloppement M031; elle est centre sur : - Ltude du systme qualit de lentreprise et de ses diverses composantes (documentation, organisation, ressources, processus); - La vrification de la conformit du systme qualit mis en uvre aux exigences identifies par la norme ISO 9001; - lvaluation du systme qualit par rapport au modle CMM. Pour conclure, le travail discute la performance du systme qualit mis en place pour faciliter llaboration du logiciel ayant le niveau de qualit vis, prsente des suggestions pour amliorer lefficacit et la maturit de ce systme qualit tout en tenant compte de la spcificit et des objectifs viss par lentreprise..

Abstract The title of the project is "Software Quality Assurance and Software Quality Control". The project uses two different approaches: theoretical and practical. The theoretical approach identifies the official standard (ISO 9000) and the professional standards (IEEE) as well as the theoretical model (CMM) comprising the software quality assurance and quality control. To that effect, it presents the requirements to follow in order to assure the elaboration of software at the required level of quality, as well as the activities connected to software quality assurance and quality control. The practical study was realized at CGI, more precisely in development unit M031. It focused on: a study of the companys quality system and its different constituents (documentation, organization, resources, process); a verification of the matching between the quality system and the requirements identified in standard ISO 9001; an evaluation of the quality system with the CMM model. In conclusion, the project discusses the performance of the quality system used to facilitate the software development at the required quality level. It then presents suggestions to improve the efficiency and the maturity of the quality system used, taking into account the specificity and the objectives of the company.

Table des matires

Prsentation du cadre de travail ....................................................................................... 3 Rsum ........................................................................................................................... 4 Abstract .......................................................................................................................... 5 Table des matires........................................................................................................... 6 A/ Introduction................................................................................................................ 9 B/ Identification de la problmatique............................................................................... 9 C/ Identification des objectifs du projet ......................................................................... 10 D/ tude thorique ........................................................................................................ 11 1- Les normes et les modles rgissant la qualit du logiciel.......................................... 11 1. Les normes officielles............................................................................................ 11 1.2 Les normes professionnelles ................................................................................ 13 1.3 Le modle CMM (Capability Maturity Model For Software) ............................... 15 1.3.1 Les niveaux de maturit ................................................................................ 15 1.3.2 Les secteurs-cls .......................................................................................... 16 1.3.3 Les caractristiques communes ..................................................................... 18 1.3.4 Les pratiques-cls ......................................................................................... 18 2- Dfinitions ................................................................................................................ 19 2.1 Systme qualit ................................................................................................... 19 2.2 Assurance qualit ................................................................................................ 19 3- Composantes du systme qualit ............................................................................... 20 3.1 Responsabilits et autorits relatives la qualit.................................................. 20 3.2 Structure organisationnelle ...................................................................................... 21 3.3 Procdures........................................................................................................... 21 3.4 Ressources humaines et matrielles ..................................................................... 22 4- Documentation du systme qualit ............................................................................ 22 4.1 Manuel qualit..................................................................................................... 24 4.2 Manuel assurance qualit..................................................................................... 24 4.3 Manuel des procdures ............................................................................................ 25 4.4 Les instructions ................................................................................................... 25 4.5 Les enregistrements................................................................................................. 26 D-5- Exigences en matire systme qualit.................................................................... 27 Engagement de la direction ....................................................................................... 27 Politique qualit .................................................................................................... 27 Identification de lorganisation .............................................................................. 28 Revues de direction ............................................................................................... 28 Identification du systme qualit ............................................................................... 28 Revues de contrats..................................................................................................... 29 Matrise du processus de dveloppement ................................................................... 29 Phase de planification du projet ............................................................................. 29 Phase danalyse des besoins................................................................................... 30 Phase de conception .............................................................................................. 31 Programmation...................................................................................................... 32 gestion de configuration ........................................................................................ 33 Vrification et validation ....................................................................................... 34

Logiciels inclus ......................................................................................................... 35 Matrise de la documentation..................................................................................... 36 Suivi et tude des achats............................................................................................ 37 Identification et traabilit......................................................................................... 38 Mise en place dune procdure de contrle de la qualit du logiciel ........................... 38 Contrle et vrification des quipements de dveloppement et de contrle qualit du logiciel ...................................................................................................................... 39 Identification de ltat de contrle ............................................................................. 40 Matrise de la phase de livraison du logiciel .............................................................. 40 Les audits et les inspections....................................................................................... 40 Documentation relative la qualit............................................................................ 42 Les actions prventives et volutives ......................................................................... 42 Formation.................................................................................................................. 44 Soutien fourni aprs vente ......................................................................................... 45 Matrise des non-conformits ........................................................................................ 45 tude statistique ............................................................................................................ 46 D-6- Lassurance qualit du logiciel.............................................................................. 47 6-1- Objectifs ................................................................................................................ 47 6-2- Activits lies lassurance qualit du logiciel....................................................... 47 6-2-1- Dveloppement de la documentation du dpartement assurance qualit .............. 47 6-2-2- laboration du plan assurance qualit ................................................................. 48 6-2-3- Revue du processus de dveloppement ............................................................... 48 6-2-4- Faire un audit du systme qualit........................................................................ 49 6-2-5- tude statistique de lassurance qualit du logiciel.............................................. 49 D-7- Les spcifications du logiciel ................................................................................ 51 7.1 Capacit fonctionnelle ............................................................................................. 51 7.2 Fiabilit................................................................................................................... 51 7-3 Facilit dutilisation ................................................................................................ 52 7.4 Rendement .............................................................................................................. 52 7.5 Maintenabilit ......................................................................................................... 53 7.6 Portabilit................................................................................................................ 53 D-8- Vrification et contrle de la qualit du logiciel ................................................... 55 Objectifs des contrles .............................................................................................. 55 Dmarche de vrification de la qualit logiciel .............................................................. 55 laboration du plan de vrification et de validation ....................................................... 56 Activits de vrification ................................................................................................ 57 8.4.1 Les tests unitaires ............................................................................................ 57 8.4.1.1 Les tests fonctionnels "Black box testing\.................................................. 57\ 8.4.1.2. Les tests structurels "White box testing\.................................................... 57\ 8.4.2.Profilers............................................................................................................ 57 8.4.3. Les mtriques .................................................................................................. 57 Analyse des rsultats de vrification.............................................................................. 58 E/ tude Pratique .......................................................................................................... 59 1- Prsentation de lentreprise ....................................................................................... 59 1.1. Mission .............................................................................................................. 59 1.2. Objectifs............................................................................................................. 60

2- Prsentation de lunit daffaire ................................................................................ 61 3- tude du systme qualit........................................................................................... 61 3.1 lments du systme qualit ................................................................................ 61 3.1.1 Organisation ................................................................................................. 61 3.1.2 Processus ...................................................................................................... 62 3.1.3 Documentation ............................................................................................. 62 3.1.3.1 Manuel qualit ....................................................................................... 63 3.1.3.2 Manuel des procdures........................................................................... 63 3.1.3.3 Gabarits ................................................................................................. 63 3.1.3.4. Enregistrements .................................................................................... 63 4- tude du processus de dveloppement....................................................................... 63 5- Application du questionnaire de maturit .................................................................. 64 6- Spcifications de logiciels......................................................................................... 65 7- valuation du processus de dveloppement selon le modle CMM ........................... 65 8. Activits mettre en place pour amliorer lefficacit du systme qualit.................. 66 F/ Conclusion................................................................................................................ 69 Bibliographie ................................................................................................................ 72 Annexe 1....................................................................................................................... 74 Annexe 2....................................................................................................................... 76

A/ Introduction
Ltude de la qualit du logiciel soulve toujours un trs grand intrt chez les chercheurs et les professionnels en informatique. En effet, plusieurs normes et modles ont vu le jour. Lobjectif des diverses recherches tait de permettre aux entreprises informatiques qui oprent dans un environnement en changement continu dlaborer des logiciels qui rpondent adquatement aux besoins de leurs clients. Cependant une grande faille persiste encore entre les attentes des clients et les produits et services offerts par les entreprises. La dfaillance stale sur trois volets :le cot, la dure des projets informatiques, et la qualit du logiciel dvelopp. Une tude effectue par le Standish Group International Inc. rvlait que 28% des projets dlaboration de logiciel des entreprises ont t annuls avant terme et que 46% taient en retard ou dpassaient le budget (Whiting, 1998). Ltude de la qualit du logiciel touche trois aspects : Le systme qualit qui touche lensemble de lorganisation, des responsabilits, des processus, des procdures, des moyens et des techniques permettant la gestion de la qualit; Le logiciel qui doit rpondre aux spcifications bien tablies; Le processus de dveloppement du logiciel;

B/ Identification de la problmatique
Les entreprises informatiques ont beaucoup de difficult mettre en place et maintenir un systme qualit qui leur permet le dveloppement de logiciels qui rpondent efficacement aux besoins de leurs clients. Les difficults sont dorigines diverses : lidentification et la mise en place des composantes du systme qualit, lengagement actif des diffrents participants au systme, labsence de mthodologies structures permettant le maintien et lvolution du systme, les complexits des activits de contrle, les changements dans les besoins daffaires, etc. Afin daider les entreprises informatiques russir le dveloppement de logiciels de qualit dans un dlai et un cot permettant de gnrer des profits, le projet prsente une

approche simple et pratique de maintien et dvolution du systme qualit (qui se base sur des normes et modle ainsi que sur les diverses recherches et mme sur lexprience pratique dans une entreprise informatique) permettant aux entreprises informatiques datteindre leurs objectifs. La partie thorique du projet identifie les lments essentiels la mise en place et au maintien du systme qualit efficace, les paramtres et les grandeurs permettant destimer la qualit du logiciel dvelopp (les spcifications du logiciel), les activits dassurance et de contrle de la qualit. La partie pratique du projet consiste comparer le systme qualit propos par rapport un systme qualit implant au niveau de lentreprise objet de ltude (CGI), discuter les diffrences constates, identifier les causes probables des dficiences et leurs impacts sur la qualit des logiciels labors, prsenter des suggestions pour amliorer lefficacit du systme qualit de lentreprise tudie.

C/ Identification des objectifs du projet

Le projet traite deux perspectives : organisationnelle et technologique dont la conjonction permettrait daboutir lobjectif final : prsenter une approche pratique permettant de maintenir et de faire voluer un systme de qualit efficace au niveau des entreprises informatiques. Les buts de la perspective organisationnelle sont : Dfinir et identifier les composantes du systme qualit (documentation, processus, organisation, etc.); Identifier les activits mettre en uvre pour assurer le fonctionnement adquat du systme qualit. Les buts de la perspective technologique : Identifier les normes officielles et professionnelles qui touchent la qualit du logiciel, ainsi que le modle CMM; Identifier les spcifications qui touchent la qualit du logiciel; Identifier les techniques et les moyens permettant de contrler la qualit du logiciel.

10

D/ tude thorique
1- Les normes et les modles rgissant la qualit du logiciel La matrise de la qualit du logiciel a fait lobjet des travaux de recherches de divers organismes de normalisation (ISO, IEEE, AFNOR, CEI, etc.) . Les normes labores sont les rsultats de leffort et de lexpertise des chercheurs et des entreprises; elles touchent toutes les activits de lentreprise : lorganisation, le management, les techniques et outils de production, les techniques de suivi et de contrle, lassurance de la qualit du logiciel, etc. 1.1 Les normes officielles La famille des normes ISO 9000 a t dveloppe afin dassister les organisations grer leurs systmes qualit et dunifier la terminologie et les pratiques travers le monde. Parmi les normes labores (ISO 9001, ISO 9002 et ISO 9003) seul la norme ISO 9001 dfinit des exigences dont la transposition est possible pour les entreprises informatiques. Ceci est d au fait que le dveloppement du logiciel ne comporte que des activits de conception et trs peu dactivits de fabrication. En effet, les activits de planification, danalyse, de conception, et de tests ne peuvent pas tre assimiles des activits de fabrication. La norme ISO 9001 (Systme qualit Modle pour lassurance de la qualit en conception / dveloppement, production installation et soutien aprs la vente) dfinit vingt exigences : 1) Engagement de la direction; 2) Systme qualit; 3) Revue de contrat; 4) Matrise de la conception; 5) Matrise des documents et des donnes; 6) Achats; 7) Matrise du produit fourni par le client; 8) Identification et traabilit du produit; 9) Matrise des processus; 10) Contrles et essais; 11

11) Matrise des quipements de contrle, de mesure et d'essai; 12) tat des contrles et des essais; 13) Matrise du produit non-conforme; 14) Actions correctives et prventives; 15) Manutention, stockage, conditionnement et livraison; 16) Matrise des enregistrements relatifs la qualit; 17) Audits qualit internes; 18) Formation; 19) Soutien aprs la vente; 20) Techniques statistiques. En raison de la gnralit de la norme ISO 9001 et de la spcificit des technologies de linformation, lISO a labor la norme ISO 9000-3 (Normes pour la gestion de la qualit et lassurance de la qualit Partie 3 : Lignes directrices pour lapplication de lISO 9001 au dveloppement, et la mise disposition et la maintenance du logiciel) afin de fournir des conseils supplmentaires pour assurer une application harmonieuse de la norme ISO 9001 dans le domaine des technologies de linformation. La norme ISO 9000-3 est spcifique au dveloppement du logiciel et tient compte des diffrents aspects du processus de dveloppement, en effet, elle prsente les vingt exigences identifies au niveau de la norme ISO 9001 mais dun angle spcifique aux technologies de linformation, elle les tale en vingt-deux exigences tenant compte de cycle de vie du logiciel. Les exigences prsentes par la norme ISO 9000-3 sont : a) Responsabilit de la direction; b) Systme qualit; c) Audits internes du systme qualit; d) Action corrective; e) Revues des contrats; f) Spcifications des besoins de lacheteur; g) Plan qualit; h) Conception et ralisation; i) Tests et validation; j) Rception;

12

k) Reproduction, livraison, et installation; l) Gestion de configuration; m) Matrise des documents; n) Enregistrements relatifs la qualit; o) Mesures; p) Rgles, pratiques et conventions; q) Outils et techniques; r) Achats; s) Logiciels inclus; t) Formation. ( Pour faire la correspondance entre les exigences identifies au niveau de la norme ISO 9001 et celles prsentes dans la norme ISO 9000-3 voir annexe 1 ) 1.2 Les normes professionnelles Les normes labores par lIEEE (Institute of Electrical and Electronics Engineers, Inc) couvrent les activits lies au dveloppement du logiciel. La norme IEEE 730-1980 (Standard for Software Quality Assurance Plans) prsente les exigences lies au plan dassurance qualit du logiciel. Les exigences identifies touchent aux points suivants: Rfrences; La gestion de lassurance qualit : o Lorganisation; o Les activits; o Les responsabilits. Le minimum de documents requis pour un projet de dveloppement du logiciel : o Dossier danalyse; o Dossier de conception; o Plan de vrification et de validation; o Dossier de vrification et de validation; o Manuel dutilisateur; o Plan de configuration;

13

o Dautres documents (plan du projet, Manuel des procdures, Manuel de maintenance, etc.). Les pratiques et les mtriques adoptes; Les revues et les audits : o Revue des spcifications; o Revue prliminaire de conception; o Revue de conception; o Revue du plan de vrification et de validation; o Audit fonctionnel; o Audit du systme; o Audit du processus; o Revue de la direction; o Revue de plan de configuration; o Revue dimplantation; o Autres revues (la revue du manuel dutilisation, etc.). Les tests; Lidentification des anomalies et les actions correctives; Les outils, les techniques et les mthodologies; Les contrles de codes; Les moyens de contrles; Les contrles du fournisseur; La matrise de la documentation; La formation; Ltude du risque. Les diverses phases du cycle de vie du logiciel ont t lobjet des normes labores par lIEEE, Parmi la quarantaine de normes labores, titre de rfrence, on cite les normes suivantes en raison de leur lien avec lobjet de ltude (Assurance et contrle qualit du logiciel) : IEEE 1058 : traite le plan de gestion de dveloppement du logiciel; IEEE 730 : traite le plan dassurance qualit du logiciel;

14

IEEE 830: traite les activits lies la phase didentification des spcifications du logiciel; IEEE 1016 : traite les activits lies la phase de conception; IEEE 1012 : traite les activits de vrification et de validation; IEEE 1008 : traite les tests unitaires; IEEE 1063 : traite le manuel dutilisateur; IEEE 829 : traite la documentation lie aux tests; IEEE 1028 : identifie les diverses revues laborer.; IEEE 1044, 1044.1 : classifient les diffrentes anomalies pouvant affecter la qualit du logiciel.; IEEE 1061 : identifie la mthodologie suivre pour mettre en uvre les mtriques de la qualit du logiciel.

1 . 3 Le modle CMM (Capability Maturity Model For Software) La notion de niveau de maturit permet de dterminer laptitude dune entreprise raliser de manire prvisible un logiciel de qualit. Le modle CMM (ou modle dvaluation et dvolution des capacits de dveloppement de logiciels) dvelopp par le SEI (Software Engineering Institute, Carnegie Mellon University) offre une organisation cherchant amliorer ses comptences en matire de production de logiciel une structure dvaluation de son niveau de maturit, un ensemble de procdures documentes pour amliorer son niveau de maturit et un ensemble de processus de contrles pour valider les tapes de cette progression. 1.3.1 Les niveaux de maturit Le modle CMM classe en cinq niveaux de maturit les activits de mise en uvre du processus dlaboration du logiciel : o Niveau 1 : initial ; Quelques processus sont dfinis. Le succs dpend essentiellement des efforts individuels; o Niveau 2 : rptable ; Il y a un suivi de cot, une planification pour chaque projet et une dfinition des exigences. Un management du projet est mis en place. Il est fond sur la russite de projets antrieurs;

15

o Niveau 3 : dfini ; Les processus de ralisation du logiciel sont institutionnaliss au niveau de lentreprise, cest--dire documents et appliqus au niveau du projet; o Niveau 4 : gr ; Des mtriques ou indicateurs sont mis en place pour contrler le bon droulement des projets et le respect des objectifs qualit; o Niveau 5 : optimis ; Lentreprise a mis en place une action damlioration continue pour optimiser le processus de ralisation dans le but de prvenir les dfauts. 1.3.2 Les secteurs-cls lexception du niveau 1, les niveaux de maturit identifis par le modle CMM sont diviss en plusieurs secteurs-cls. Chaque secteur-cl identifie les proccupations essentielles du niveau concern, en effet, il faut satisfaire ces exigences pour atteindre le niveau de maturit concern. Les secteurs-cls identifis sont : * Secteurs-cls du niveau 2 : Objectifs : tablir les contrles de base de gestion de projets Gestion des exigences (identifier les spcifications du logiciel); Planification des projets (laboration du plan, chancier, etc.); Suivi et supervision des projets (faire le suivi de progression du projet et le comparer aux expriences prcdentes); Gestion de la sous-traitancea(slection des sous-traitants selon leurs performances); Assurance de qualit du logiciel (tablir la visibilit du processus de dveloppement du logiciel travers les procdures, les revues, les audits, et veiller la conformit du logiciel labor avec les spcifications dj tablies); Gestion des configurations du logiciel (identifier les items de la configuration, contrler les modifications, maintenir lintgrit et la visibilit de la configuration). * Secteurs-cls au niveau 3 Objectif: tablir linfrastructure qui permet dassurer la gestion efficace des processus de gestion et dingnierie de tous les projets.

16

Focalisation organisationnelle sur les processus (dfinir les responsabilits dans lorganisation); Dfinition du processus pour lorganisation (structurer les activits de lentreprise sous forme de processus); Programme de formation; Gestion intgre du logiciel (assurer la coordination entre le processus de dveloppement du logiciel et le processus de gestion du projet); Ingnierie de produits logiciels (excuter avec constance et efficacit le processus de dveloppement du logiciel); Coordination entre les groupes (tablir les moyens pour permettre au groupe du gnie logiciel de participer activement avec dautres groupes interdisciplinaires llaboration des exigences du systme);

Revues par les pairs (lobjectif est dliminer efficacement les dfectuosits des produits le plus tt possible dans le cycle de vie).

* Secteurs-cls au niveau 4 Objectif: tablir la comprhension quantitative du processus et des logiciels dvelopps. Gestion quantitative de processus (contrler quantitativement la performance du processus dun projet); Gestion de la qualit du logiciel (tablir une comprhension quantitative de la qualit ). * Secteurs-cls au niveau 5 Objectif: amlioration continue et mesurable du processus Prvention des dfauts (identifier les causes des dfauts et prvenir leurs occurrences par des modifications portes au processus ) ; Gestion des changements technologiques (identifier les nouvelles technologies bnfiques (outils, mthodes, processus) et les transfrer lorganisation de manire ordonne ); Gestion des changements du processus (amliorer continuellement le processus de dveloppement avec comme objectifs : amliorer la qualit des logiciels labors, augmenter la productivit, diminuer la dure de dveloppement du logiciel ).

17

1.3.3 Les caractristiques communes Chaque secteur-cl comprend cinq caractristiques communes. Celles-ci indiquent si la mise en oeuvre d'un secteur-cl est : Engagement de ralisation; Capacit de ralisation; Activits ralises; Mesure et analyse; Vrification de mise en uvre. efficace, reproductible, durable. Les caractristiques communes chaque secteur-cl sont les suivantes :

1.3.4 Les pratiques-cls 5 Niveaux de maturit 2 Secteurs-cls 4 3

Objectifs

Caractristiques communes Pratiques-cls

Figure N1 : Structure du modle CMM [Caputo] (Voir annexe 2 : Correspondance entre les secteurs-cls du modle CMM et les exigences de la norme ISO 9001)

18

Pour atteindre un niveau de maturit, il faut satisfaire aux exigences des secteurs cls correspondants. Or chaque secteur-cl est dcrit par un ensemble de pratiques-cls, qui permettent d'atteindre les objectifs d'amlioration fixs. Ces pratiques-cls dcrivent des activits que si elles sont respectes, contribuent de manire effective l'atteinte des objectifs. Lensemble des pratiques-cls est dfini dans le guide Key Practices of the Capability Model Version 1.1 [Garcia] 2- Dfinitions 2.1 Systme qualit La norme ISO8402 :1986 dfinie le systme qualit comme suit : Un systme qualit est lensemble de la structure organisationnelle, des responsabilits, des procdures, des procds et des ressources pour mettre en uvre la gestion de la qualit En effet, cette dfinition met laccent sur les composantes du systme qualit, et le prsente comme tant un systme complet qui intgre tous les lments de lentreprise, de ce fait, la qualit devient laffaire de toute lentreprise et non seulement des spcialistes de la qualit (service de contrle qualit, service de lassurance qualit) En plus, la qualit nest pas considre comme un attribut particulier dun des systmes composants lentreprise (systme de gestion, systme de production, etc.) mais plutt un systme part entire (bas sur des lments : Organisation, processus, responsabilits, ressources) qui coopre avec les autres systmes de lentreprise. Cela prsente les avantages suivants : La qualit devient une responsabilit de toute lorganisation; La responsabilit des spcialistes de la qualit nest pas de produire la qualit, mais plutt de fournir les moyens pour contrler et assurer la production du logiciel de qualit; La mise en place dun systme de qualit efficace permet de prvenir les anomalies et par consquent de prendre les mesures ncessaires pour les viter, ainsi de rpondre efficacement aux besoins du client. 2.2 Assurance qualit

19

La norme ISO8402 :1986 dfinit lassurance qualit comme suit: Lassurance de la qualit est lensemble des actions prtablies et systmatiques ncessaires pour donner la confiance approprie en ce quun produit ou service satisfera aux exigences donnes relatives la qualit En effet, lassurance de la qualit est la capacit de lentreprise prouver objectivement quelle a mis en place un systme qualit permettant dlaborer des produits (logiciels) qui rpondent adquatement aux attentes de ses clients. Lassurance qualit est base sur le principe crire ce quon va faire, faire ce quon a crit, et vrifier ce quon a fait En effet, lassurance qualit consiste assurer que le logiciel qui sera dvelopp rpondra aux spcifications dj tablies; et par consquent de prvenir les anomalies et rduire les cots et les dlais de production. Ainsi les objectifs de lassurance qualit sont : assurer que les besoins des clients sont satisfaits, que les mthodes et les processus de travail sont documents, et que les cots et les dlais du projet sont matriss ( travers une utilisation efficace de leffectif et des quipements en place) tout ceci, en mettant et entretenant un systme qualit complet et efficace (voir section 6: Les activits lies lassurance qualit) 3- Composantes du systme qualit La mise en place dun systme qualit efficace exige lengagement de la direction; ceci se manifeste dans lexpression de la politique qualit de lentreprise, ses objectifs, la fourniture de linfrastructure ncessaire ltablissement et lentretien du systme qualit. La structure du systme qualit prsente les lments suivants. 3.1 Responsabilits et autorits relatives la qualit Lun des lments fondamentaux dun systme qualit est lidentification des responsabilits et la dlgation de lautorit ncessaire pour laccomplissement des fonctions octroyes. Les actions suivantes devraient tre entreprises : Identifier les responsabilits au moyen des fiches de fonctions; Mise en place des fonctions : responsable dassurance qualit et responsable de contrle qualit;

20

Lautorit dlgue chaque responsabilit devrait tre suffisante pour accomplir les t_ches demandes (les audits, llaboration et la vrification de la documentation, ltablissement et lapplication des mtriques, lapplication des procdures de vrification et de validation, etc.);

Linteraction entre les diverses activits devrait tre clairement dfinie au niveau des procdures.

3.2 Structure organisationnelle Le systme qualit repose sur toute une structure organisationnelle, qui englobe toutes les fonctions lies directement ou indirectement la gestion de la qualit; en effet, elle doit introduire toutes les fonctions qui interviennent durant tout le cycle de vie du logiciel, ceci ds lidentification des besoins du client jusqu limplantation et lentretien du logiciel. Elle est compose de la direction, de lquipe de dveloppement (analystes, concepteurs, programmeurs, testeurs, quipe des utilisateurs) lquipe de lassurance qualit et de contrle qualit. Dautres fonctions peuvent sajouter selon les besoins et la dimension de lentreprise. Cette structure organisationnelle devrait tre bien tablie, les liens hirarchiques bien dfinis, le flux dinformation devrait tre systmatique, structur et continu. Lorganigramme est loutil le plus utilis pour identifier la structure organisationnelle. 3.3 Procdures Les activits au sein de lentreprise sont organises sous forme de processus dont la corrlation aboutit la ralisation du logiciel qui devrait satisfaire aux spcifications et aux besoins du client, tout en ralisant les objectifs de lentreprise (notamment llaboration du produit un cot qui gnre un profit) Les divers processus (processus de dveloppement du logiciel, processus de vrification et de validation, processus de livraison du logiciel, etc. ) devraient tre organiss de telle sorte que toute les activits (identification de besoins, application des tests unitaires, laboration des contrats, etc.) quils incluent, soient parfaitement matriss, et ceci au moyen des procdures (qui identifient les divers processus au niveau de lentreprise) et des instructions (qui dfinissent les t_ches accomplir dans chaque

21

activit) et des enregistrements (donne la preuve de lapplication de toutes les activits concernes) Les diverses documentations doivent mettre laccent sur les actions prventives, sans oublier didentifier les actions correctives appliquer en cas dapparition danomalies. Toutes les procdures crites devraient tre formules en terme simple et du domaine, afin dviter toute ambigut et elles devraient indiquer les techniques appliquer et les spcifications satisfaire. (voir section 4: documentation du systme qualit) 3.4 Ressources humaines et matrielles La direction devrait fournir les ressources ncessaires et suffisantes pour mettre en uvre sa politique qualit et pour assurer le fonctionnement efficace du systme qualit. Ces ressources incluent : Les ressources humaines et les comptences spcialises et qualifies; Les ressources matrielles et logicielles ; Les ressources financires pour assurer le fonctionnement continu de diverses activits. La dotation en personnel devra tre faite selon des procdures bien tablies qui sont centres sur lidentification de besoins de lentreprise, et les comptences recherches. De mme lachat de matriel devra tre ralis selon un plan et un chancier bien tablis. La direction devra offrir la formation ncessaire son personnel selon les t_ches demandes et les comptences recherches, ceci doit tre effectu selon un plan et un chancier. 4- Documentation du systme qualit La documentation est lun des lments essentiels du systme qualit. En effet une documentation approprie est indispensable pour atteindre la qualit requise, valuer le systme qualit, amliorer la qualit et mettre jour les amliorations. Les documents sont tablis dans le cadre de la politique qualit gnrale de lentreprise. On distingue trois niveaux de documentation :

22

- Le premier niveau concerne les lignes directrices de la politique qualit de lentreprise; - Le niveau 2 prcise le niveau qualit dfini au premier niveau en identifiant et dtaillant les procdures gnriques et leurs modalits dapplication dans lentreprise; - Le niveau 3 se rapporte la documentation des projets et des enregistrements relatifs la qualit.

Niveau 1

Manuel qualit, plan assurance qualit

Niveau 2

Procdures Instructions

Niveau 3

Enregistrement (Contrats, plan du projet, dossier danalyse, dossier de conception, plan des tests, dossier dimplantation, dossier de configuration, )

Figure N2: Dcomposition de la documentation du systme qualit. [CAFNOR]

La documentation du logiciel doit tre dveloppe au mme titre que le produit logiciel. Elle doit sinscrire dans la dmarche globale de lentreprise. Il est donc ncessaire de formaliser la charte documentaire qui sera prcise aux niveaux 1 et 2 et daider les personnes sur le terrain, cest--dire au niveau 3, fournir toute la documentation requise pour un projet informatique.

23

4.1 Manuel qualit La norme ISO 10 013 dfinie le manuel qualit comme suit : Le manuel qualit est le document dcrivant les dispositions gnrales prises par l'entreprise pour obtenir la qualit de ses produits ou services En effet, le manuel qualit est le document de rfrence, nonant la politique qualit de lentreprise et dcrivant le systme qualit. Il est tabli par lentreprise essentiellement pour son usage interne, mais il peut tre utilis pour prouver aux clients la matrise du processus de dveloppement du logiciel et par consquent du logiciel labor. Il constitue un support privilgi pour bien faire comprendre les objectifs lis aux lments cls de la qualit, les bnfices pour une telle dmarche pour lentreprise et lintrt pour chacun dy participer. Le contenu du manuel qualit comprend : Sommaire dtaill ; Politique qualit avec approbation de la direction ; Feuille de mise jour ; Diffusion et confidentialit du manuel ; Terminologie et vocabulaire utiliss ; Prsentation gnrale de lentreprise (mission, objectifs, etc.) ; Description sommaire des logiciels labors ; Rfrences des procdures appliques ; Identification des responsabilits des services oprationnels et fonctionnels en matire de qualit. 4.2 Manuel assurance qualit Le manuel assurance qualit identifie les objectifs atteindre en terme de qualit, les activits mises en uvre pour assurer lobtention de la qualit requise; en effet, il identifie les t_ches relies la fonction du responsable assurance qualit. Le manuel assurance qualit devrait tre vrifi et approuv par la direction. Le manuel assurance qualit comprend : Sommaire dtaill ;

24

Approbation la direction ; Feuille de mise jour ; Identification de lobjectif du manuel ; Diffusion et confidentialit du manuel assurance qualit ; Terminologie et vocabulaire utiliss ; Description gnrale des diverses activits relies lassurance qualit ; Rfrences des procdures appliques.

4.3 Manuel des procdures Le manuel qualit et le manuel assurance qualit sont complts par des documents de mise en uvre oprationnels du systme qualit tel que les procdures, les instructions, et les enregistrements. La documentation du niveau procdure consiste spcifier la manire daccomplir un processus. Elle peut porter aussi bien sur lassurance qualit que sur le processus de dveloppement du logiciel. Le contenu du manuel des procdures comprend : Page de garde (identifie le code, le titre, la version, date dapplication, nombre de pages de la procdure); Identification du rdacteur, vrificateur, approbateur; tat de la procdure; Introduction; Objet; Domaine dapplication; Responsabilits; quipements et logiciels utiliser; Documents rfrences; Dfinition et terminologie; Description de la procdure; Squence graphique de la procdure (logigramme); Rfrence des instructions lies.

4.4 Les instructions

25

La documentation du niveau instructions consiste spcifier la manire daccomplir une activit. Comme les procdures, elle peut porter aussi bien sur lassurance qualit que sur le processus dlaboration du logiciel. Les instructions permettent de complter les procdures et de dfinir clairement la mthode dapplication dune activit. La structure dune instruction est similaire une procdure sauf que le contenu diffre par le fait quil traite des sujets plus prcis et de faon dtaille. 4.5 Les enregistrements Les enregistrements sont constitus par tous les documents lis directement aux projets informatiques : Contrats; Plan du projet; Dossier danalyse; Dossier de conception; Code source; Dossier de vrification et de validation; Preuves des tests; Dossier dimplantation; Dossier de configuration; Manuel dutilisation; Manuel de maintenance. Plan assurance qualit; Plans dactions; Rapports des revues et des audits; Documents lis la formation; Enregistrements lis la consultation et lacceptation des procdures; Demandes de mise jour de la documentation.

Aussi, les enregistrements comprennent la documentation lie lassurance qualit :

La mise en place dune telle documentation (manuel qualit, manuel assurance qualit, manuel des procdures, manuel des instructions, enregistrements) permet

26

dassurer la cohrence entre la documentation des projets informatiques et la politique qualit de lentreprise. Cependant, il convient de veiller limiter la documentation celle qui est ncessaire au fonctionnement adquat du systme qualit et lobtention de la qualit dsire, par exemple, si le manuel qualit identifie les divers points signals au niveau du manuel assurance qualit il serait intressant de se limiter au manuel qualit.

1 Manuel qualit, manuel assurance qualit

1 2 3

2 Manuel des procdures 3 Manuel des instructions 4 Enregistrement

4
Figure N3: Documentation du systme qualit [ExpoRevue]

D-5- Exigences en matire systme qualit Pour quun systme qualit soit efficace, il est indispensable de rpondre adquatement aux exigences suivantes : 5.1. Engagement de la direction Sans engagement clair et crit de la direction, se traduisant par des actes concrets, aucun systme qualit ne peut tre efficace, et ne favorise jamais lobtention de logiciel de qualit. Lengagement de la direction se prsente dans les points suivants : a) Politique qualit La direction doit prciser par crit sa politique qualit et ses objectifs en matire de qualit. La dclaration de la politique qualit doit tre crite au niveau du manuel qualit, et elle doit tre diffuse tous les niveaux de lorganisation. 27

b) Identification de lorganisation La direction doit mettre en place une organisation bien dfinie dans le rle : dveloppement du logiciel, lassurance et le contrle de la qualit du logiciel. Les fonctions de chaque membre de lorganisation doivent tre dfinies au moyen dune fiche de fonction. Lorganisation mise en place doit tre dote de lautorit ncessaire pour accomplir ses fonctions et notamment les t_ches suivantes : Dclencher des actions prventives et correctives; Enregistrer toutes non-conformits; Vrifier et contrler lapplication des procdures et des normes de lentreprise. c) Revues de direction Pour maintenir et ventuellement amliorer lefficacit du systme qualit, la direction doit procder priodiquement des inspections. La revue labore constitue un engagement formel de la direction dans la dmarche gnrale vers la qualit. La revue de la direction doit inclure toutes les composantes du systme qualit et aussi doit tenir compte des divers audits qui ont t dj raliss. Remarque : La revue peut tre effectue par un ou des reprsentants de la direction identifis explicitement au niveau du manuel qualit. 5.2 Identification du systme qualit Il est essentiel de mettre en place tous les lments du systme qualit, et plus particulirement la documentation. En effet, lentreprise doit laborer la documentation ncessaire au fonctionnement adquat du systme qualit. Cette documentation doit toucher aux thmes suivants : Gestion du processus de dveloppement; Ingnierie du logiciel.; Assurance qualit du logiciel; Contrle qualit du logiciel.

Il est recommand dlaborer pour chaque projet de dveloppement du logiciel un plan qualit qui identifie les diverses activits qualit (audits, revues, tests, actions correctives et prventives, etc.) et leur rpartition dans lchancier du projet.

28

5.3 Revues de contrats Il est fondamental de clarifier avec prcision les besoins du client, et de vrifier si les spcifications permettent de conduire llaboration du logiciel des conditions conomiques acceptables. Les activits suivantes doivent tre ralises: Lquipe de dveloppement doit vrifier sil est techniquement possible de rpondre aux besoins du client, en effet, il faut vrifier labsence dambigut et de contradiction; Toute spcification prsentant des anomalies doit tre enregistre et vrifie avec lorganisation du client; Dterminer limpact des changements au niveau des spcifications sur le cot et la dure du projet; Vrifier si les changements effectus au niveau des spcifications sont effectivement appliqus. Les revues doivent tre effectues priodiquement jusqu la livraison afin de dtecter les dviations ventuelles. Il est recommand de coordonner les activits de revues de contrats avec lorganisation du client afin daugmenter lefficacit et dinformer continuellement le client propos lvolution du projet. 5.4 Matrise du processus de dveloppement Cette exigence touche tout le processus de dveloppement du logiciel (analyses des besoins, conception, programmation, tests, configuration, implantation) en effet, elle met laccent sur les activits et les consignes mettre en application pour assurer la production de logiciel de qualit. 5.4.1 Phase de planification du projet Dans cette phase laccent est mis sur lenregistrement des estimations du droulement du projet (les activits, les responsabilits, lchancier et le cot du projet) dans un plan du projet qui sert par la suite comme moyen de vrification de lavancement du projet. Ainsi les activits suivantes doivent tre ralises : laboration de procdures identifiant les diverses activits mettre en uvre pour llaboration du plan du projet, comme par exemple, le choix de cycle de vie, les techniques destimation du dlai de projet (le nombre de lignes de codes, de

29

fonctions), les techniques destimation du dur du projet (COCOMO), lvaluation des risques, etc. Le plan du projet labor identifie les points suivant : o Ltat du projet (objet, les objectifs, identification du client, les normes et rglements respecter, les livrables laborer, le cot et lchancier, les risques techniques, temporels, financiers et organisationnels, les ressources matrielles ncessaires, les responsabilits); o Lauteur du plan (chef du projet) , les vrificateurs (les personnes impliques : analystes, concepteurs, etc.) et lapprobateur (reprsentant de la direction); o Les dates prvues pour les revues du plan du projet. La formation ncessaire est donne aux personnes responsables de llaboration, la vrification et lapprobation du plan du projet; Le plan du projet est labor ds le dbut du projet et utilis comme rfrence durant tout le cycle de dveloppement du projet; Pour laborer le plan du projet le chef du projet travaille en troite collaboration avec toutes les personnes affectes au projet tout en suivant les procdures en vigueur (la mise en place dune quipe multidisciplinaire est suggre); Rvision du plan du projet avec le client; Revue priodique du plan du projet par la direction, le responsable assurance qualit et le chef du projet. 5.4.2 Phase danalyse des besoins Lobjectif essentiel est didentifier clairement les besoins du client, et de les utiliser comme base pour la conception du logiciel laborer. Ainsi pour matriser cette phase les activits suivantes doivent tre ralises : o Mettre en place des procdures signalant les activits mettre en uvre pour identifier clairement les besoins du client; o Obtenir les ressources ncessaires (matrielles, financires et humaines ); o laborer pour chaque projet un dossier danalyse qui doit dtailler les points suivants : o Objet et objectifs du dossier;

30

o Identification du rdacteur, du vrificateur, de lapprobateur; o Planification des t_ches mettre en uvre et identification des outils de collecte dinformation utiliser (entrevues, questionnaires, simulation, observation); o Enregistrer les besoins identifis, notamment, les spcifications nontechniques (besoins daffaires, les livrables rendre, etc.) et techniques (les fonctions, les supports techniques par exemple : exigences de performance, r-utilisations des fonctions, langage de programmation, etc.); o Identifier les ''input'' et les ''output'' du systme ainsi que leur forme (forme imprime, enregistrement dans une base de donnes, affichage lcran); o Modliser le systme dinformation existant (diagramme DFD) et ainsi que le processus qui va supporter le logiciel laborer (logigramme); o Identifier les contraintes dont il faut tenir compte lors de la conception (lergonomie de linterface, les classes et les mthodes r-utiliser, etc.). o valuer la phase danalyse (cot et dure) par rapport au plan du projet, et dclencher des actions correctives en cas de dviation selon les procdures en vigueur; o Faire laudit du dossier danalyse par la direction, le chef du projet, lassurance qualit ainsi quun reprsentant du client; o Revoir priodiquement la procdure identifiant les activits mettre en place pour laborer le dossier danalyse. 5.4.3 Phase de conception Lobjectif principal de cette phase est la conception du logiciel selon les spcifications identifies dans la phase prcdente (lanalyse des besoins). Pour matriser cette phase les activits suivantes doivent tre mises en uvre : laboration dune procdure identifiant les activits mettre en uvre pour laborer le dossier de conception; Fourniture des ressources ncessaires (humaines, matrielles et financires); laboration pour chaque projet dun dossier de conception selon les procdures en vigueur (qui doivent insister sur lobligation de respecter les consignes identifies

31

dans le dossier de danalyse et le plan du projet), le dossier de conception doit signaler les points suivants : o Objet et objectifs du dossier; o Identification du rdacteur, du vrificateur, de lapprobateur; o Les responsabilits (identification des t_ches octroyes aux personnes impliques : concepteurs, chef du projet, etc.); o Les rfrences utilises pour laborer le dossier (procdures, instructions, plan du projet, dossier danalyse); o Description du dictionnaire des donnes (identifie les diverses classes, leurs attributs, leurs types, les contraintes); o Les divers scnarios; o Les dpendances fonctionnelles entre les diverses classes; o Les modles (les ''use case'', le diagramme de classes, le diagramme dobjets, le diagramme dactivits, le diagramme de squences, le diagramme dtats de transition, le diagramme de collaboration, le diagramme de dploiement, le diagramme de composantes); o Les maquettes dinterfaces; o Les exigences en matire dinfrastructure technique (capacit de mmoires, rseaux, etc.). Audit du dossier de conception par une quipe multidisciplinaire (un reprsentant de la direction, le chef du projet, le responsable assurance qualit, le programmeur, le testeur, un reprsentant du client); Revue priodique et en cas dvnement particulier des procdures et des instructions permettant llaboration du dossier de conception par la direction, le chef du projet et lassurance qualit; Mise en place des indicateurs permettant de vrifier la performance de cette phase (par exemple comparaison du cot et du dlai rel ceux estims au plan du projet ou par rapport une phase de conception dans un projet prcdent ayant pratiquement les mmes dimensions et contraintes). 1.4.4 Programmation

32

Les principales t_ches dans cette phase sont une traduction des modles conus en code source. Les exigences respecter dans cette phase sont : laboration dune instruction identifiant les t_ches mettre en uvre (le choix de langage de programmation, les outils et techniques utiliser, les consignes respecter, etc.); Fourniture des ressources ncessaires (humaines, financires, matrielles : compilateurs, ateliers de gnie logiciels, etc.); Traduction du modle labor (diagramme de classes, diagrammes de squences, etc.) en code source aprs consultation approfondie du dossier de conception et en respectant les consignes identifies au niveau des instructions applicables (lobligation de mettre des commentaires, la mise en forme, etc.); Enregistrement et duplication du code labor selon les instructions prtablies. Revue du code labor par le chef du projet et le programmeur; Archivage du code labor selon les procdures en vigueur (gestion configuration, protection et confidentialit, procdure de r-utilisation, etc.). 1.4.5 gestion de configuration

Lobjectif de cette exigence est de maintenir lintgrit du logiciel durant tout son cycle de vie. Pour atteindre cet objectif, les activits de configuration devraient tre planifies (plan de configuration), les diffrentes composantes du logiciel sont identifies, les mises jour sont contrles, les personnes responsables sont identifies, la formation et lautorit ncessaires sont octroyes. Les activits suivantes doivent tre ralises : Une procdure traitant la configuration du logiciel est labore, elle identifie les lignes directrices suivre pour llaboration du plan de configuration; Un plan de configuration est labor pour chaque logiciel dvelopp selon les procdures en vigueur; Le plan de configuration identifie : les activits de configuration, llaboration de bibliothques de configuration du logiciel, la rpartition des activits de configuration dans lchancier, les responsabilits, les ressources ncessaires (hardware, software);

33

Le flux de communication entre les divers participants (le responsable du projet, le responsable des oprations de configuration, le responsable contrle qualit) devrait tre structur, systmatis;

Les oprations de configuration devraient tre enregistres au niveau du dossier de configuration; Des audits priodiques sont appliqus au plan de configuration ; Des mtriques sont mises en place afin de vrifier la performance des activits de configuration (par exemple le nombre moyen de changement par composante du logiciel).

1.4.6 Vrification et validation Lobjet de cette exigence est de maintenir un contrle continu durant tout le cycle de vie du logiciel et par consquent de sassurer que le logiciel labor rpond adquatement aux spcifications identifies pendant la phase danalyse des besoins. Pour rpondre adquatement cette exigence les activits suivantes doivent tre mises en uvre : Mettre en place une procdure identifiant les activits appliquer pour contrler la qualit du logiciel laborer ainsi que le processus de dveloppement; Fournir les ressources ncessaires (humaines, financires, matrielles : dbogueur, profilers, etc.); laborer pour chaque projet un plan de vrification et de validation suivant les procdures et les instructions en vigueur; Indiquer au niveau du plan de vrification et de validation les points suivant : o Objet et objectifs de contrles; o Responsabilits (chef de projet, testeurs, responsable contrle qualit); o Activits appliquer : Contrle du logiciel par rapport aux spcifications (besoins du client); Contrle du code source (tests fonctionnels, structurels, tests unitaires, tests dintgration, application profilers, etc.); Contrle de la performance du processus de dveloppement (cot, dlai, flexibilit, apparition danomalies, etc.).

34

o Rpartition des activits dans lchancier du projet; o Caractristiques du logiciel (fiabilit, maintenabilit, portabilit, facilit dutilisation, etc.). Enregistrer les rsultats du contrle au nouveau du dossier de vrification et de validation; Analyser les rsultats du contrle et laborer un plan daction pour corriger toutes dfectuosits; Revoir priodiquement les procdures et les instructions permettant llaboration du plan de vrification et de validation. Les revues doivent tre ralises par la direction, le contrle qualit et lassurance qualit; Mettre en place des mtriques permettant didentifier lefficacit des contrles raliss ( par exemple le nombre de bugs identifis aprs livraison par projet). 1.5 Logiciels inclus Dans le cas o lquipe de dveloppement est amene inclure au niveau du logiciel laborer des composantes dautres logiciels soit fournies par le client, soit dans le cadre des r-utilisation des composantes dj labores (par exemple, dans le cadre de la programmation oriente-objet) la mise en place des procdures identifiant le processus suivre est indispensable. En effet les activits suivantes doivent tre appliques : laboration des procdures et des instructions identifiant les activits suivre : identification, classement, archivage, et configuration des composantes, ainsi que les consignes de protection et de confidentialit et les prcautions prendre; Identification au niveau du plan de projet des composantes qui sont susceptibles dtre incluses ainsi que leur rpartition dans lchancier du projet; laboration dune bibliothque darchivage des composantes selon les instructions en vigueur; laboration dun rapport transmettre au client dans le cas o la composante inclure est inadapte au logiciel laborer.; valuation du cot de r-utilisation des composantes et son impact sur le cot et la dure du projet;

35

Revue priodique et en cas dvnement particulier des procdures, des instructions de traitement des composantes inclure; laboration, application et enregistrements des mtriques identifiant lvolution de lentreprise dans le cadre de r-utilisation des composantes (par exemple le nombre de composantes r-utilises par projet). 1.6 Matrise de la documentation

Le terme document est prendre au sens large, il inclut les documents papier et les documents lectroniques. En gnral, au niveau des entreprises linformation est traite et transfre entre les divers services soit sur papier soit avec les nouveaux moyens de transfert lectronique (EDI) Avant leur diffusion, les documents doivent tre revus et approuvs en ce qui concerne leur adquation par des personnes comptentes. Une des rfrences indiquant la rvision en vigueur des documents doit tre tablie et tre facilement accessible pour empcher lutilisation de documents non valables ou prims. Cette matrise doit assurer que : Les ditions pertinentes des documents appropris sont disponibles tous les endroits o les oprations lies au systme qualit sont effectues; -Les documents prims sont aussitt retirs de tous les points de diffusion et dutilisation et quils ne peuvent pas tre utiliss de faon non intentionnelle; Les documents prims et conservs des fins de traabilit sont convenablement identifis. En effet dans le cadre de dfinition de son systme qualit au niveau du manuel qualit, lentreprise doit signaler les lments lis la matrise de la documentation. Pour assurer la matrise qualit il est ncessaire de prciser : Les fonctions et les responsabilits des personnes intervenant dans le cadre de la gestion de la documentation notamment lauteur, le vrificateur et lapprobateur du document; Les mcanismes didentification des documents pour assurer lefficacit du contrle de la documentation. En effet, il est essentiel de garder une mme forme pour tous les documents, et de prciser le titre du document, le code du

36

document, ltat du document (utilisable ou prim), la date de rdaction, la date de diffusion et dapplication, le numro de version, la confidentialit et la diffusion du document, le nombre de pages, et les rgles darchivage. 1.7 Suivi et tude des achats Afin dassurer la continuit et la performance des activits de dveloppement et de contrle de la qualit du logiciel, les entreprises informatiques doivent non seulement construire une liste de fournisseurs en quipements et en logiciels mais ils aussi doivent la grer efficacement. En effet, lentreprise doit slectionner ses fournisseurs selon ses besoins et les performances de ces derniers, laborer un plan de travail avec ses fournisseurs (identifiant les spcifications techniques ainsi que les exigences conomiques) et maintenir un flux de communication continu. Pour rpondre adquatement cette exigence, les activits suivantes doivent tre ralises : Mise en place des ressources humaines multidisciplinaires (des spcialistes en informatiques ainsi que des gestionnaires) afin de pouvoir slectionner et grer la liste des fournisseurs; Offre de formation ncessaire aux personnes responsables dvaluation de la fourniture; Planification des achats selon un chancier et un plan de travail; Mise en place des procdures dvaluation et de slection des fournisseurs; Mise en place dune procdure de communication avec le fournisseur, o lon insiste sur lidentification de la personne avec laquelle le flux dinformation sera entretenu; Revue priodique des contrats conclus avec les fournisseurs, ainsi que des procdures mises en place; Utilisation de la documentation offerte avec toute fourniture (hardware ou software) non seulement comme outil de configuration mais aussi base dvaluation du logiciel ou dquipement achet; tablissement souhaitable dun lien entre le service dassurance qualit de lentreprise et celui du fournisseur afin dvaluer la capacit du fournisseur dassurer llaboration du produit de qualit;

37

Enregistrement et communication des rsultats dvaluation au fournisseur afin de lui prciser les anomalies ventuelles constates. 1.8 Identification et traabilit

Afin dviter tout risque derreur ou de confusion due une nomination inadquate du logiciel (ou dun composant du logiciel) : version prime, deux composantes ayant le mme nom, il est essentiel de mettre en place un mcanisme didentification dcrit laide dune procdure bien tablie. Cette procdure devra souligner les points suivants : Identifier de faon univoque la version de chaque constituant du logiciel; Identifier ltat du logiciel (en dveloppement, livr, install ); Fournir une coordination pour la mise jour des versions composantes utilises dans des lieux diffrents; Codifier chaque quipement ou outil (software, documentation) utilis pour le dveloppement ou le contrle et lassurance qualit du logiciel; Mentionner au niveau des procdures, instructions, enregistrements le libell et le code de chaque composante du logiciel utilis ainsi que les outils de dveloppement impliques. 1.9 Mise en place dune procdure de contrle de la qualit du logiciel Il est essentiel dviter que le logiciel labor ne soit implant avant quil ne soit contrl et que sa conformit aux spcifications soit prouve. Les contrles devraient tre appliqus et enregistrs selon un plan bien tabli (plan de vrification et de validation) Pour que les contrles soient efficaces et permettent didentifier toute anomalies, les activits suivantes devraient tre mises en uvre : Mise en place dune infrastructure de contrle (ressources humaines : responsable contrle qualit, testeurs; ressources matrielles : test drivers, profilers, dbogueurs, etc.); Offre de la formation adquate ( planification des tests, utilisation des outils de contrles, analyse des rsultats de contrles) aux personnes responsables de la gestion et de lapplication des tests;

38

-Mise en place des procdures de gestion des contrles et des instructions identifiant la manire dappliquer les contrles (test unitaire, test dintgration, test fonctionnel, test structurel );

Mise en place dun plan de vrification et validation identifiant les tests appliquer ainsi que leur rpartition dans lchancier du projet; Application des contrles, et vrification de la concordance entre les rsultats des tests et les spcifications du logiciel; Enregistrement des contrles appliqus au niveau du dossier de vrification et de validation; Mise en place des mesures correctives pour supprimer toute anomalie constate; Revue priodique des procdures, les instructions et le plan de contrle par le responsable du projet, responsable assurance qualit ainsi que le responsable contrle qualit.

1.10 Contrle et vrification des quipements de dveloppement et de contrle qualit du logiciel Afin de sassurer de la validit des rsultats de contrle et de vrifier la performance des outils de dveloppement (hardware, software : compilateurs, ateliers de gnie de logiciel), il est essentiel de les contrler. Pour rpondre adquatement cette exigence les activits suivantes doivent tre ralises : - Mise en place de procdure de contrle et dinspection des outils de dveloppement et de contrle qualit; - Application des instructions de contrle et enregistrement de toute dficience constate; - Revue priodique des procdures et des instructions de contrle par le responsable assurance qualit, le responsable de dveloppement, et le responsable contrle qualit; - Mise en place dune veille technologique afin didentifier les nouvelles technologies offertes sur le march et qui peuvent amliorer le processus de dveloppement et de contrle qualit.

39

1.11 Identification de ltat de contrle Lobjectif de cette exigence est dviter quun logiciel (ou une partie du logiciel : prototype) soit livr avant que les contrles ne soient compltement raliss. En effet, elle exige que ltat de contrle soit clairement indiqu. Il existe trois tats de contrles : 1. En cours de contrle (en quarantaine) les tests sont encore en train dtre appliqus; 2. Conforme : rpond adquatement aux spcifications identifies; 3. Non conforme : les tests ont rvl lexistence de dviations par rapport aux spcifications. Ainsi il est indispensable de mettre en place une instruction identifiant les t_ches effectuer pour identifier clairement ltat des contrles et les personnes responsables de lapplication de cette instruction. 1.12 Matrise de la phase de livraison du logiciel La livraison du logiciel doit tre effectue selon les procdures mises en place, et en respectant les clauses du contrat effectu avec le client. Au niveau du dossier de configuration (qui devrait tre labor en suivant les procdures de lentreprise et les clauses du contrat signer avec le client) il est souhaitable dindiquer : Les modalits de livraison du logiciel (ou de chaque composante du logiciel dans le cas o on procde par prototypage) : les responsables de lopration et les consignes suivre; Les dates de livraison; Les enregistrements effectuer lors de la livraison.

Il faut souligner que la phase de livraison ne peut tre considre termine que lorsque la priode de garantie offerte au client est acheve. 1.13 Les audits et les inspections Dans le but de vrifier lefficacit du systme qualit, il est indispensable de procder des audits de faon priodique en suivant un plan daudits labor conformment aux procdures mises en place.

40

La direction devra fournir les ressources ncessaires la mise en uvre des audits, notamment offrir aux personnes responsables la formation adquate (le recours un auditeur externe est souhait afin dviter tout risque de conflits inter-personnels) Lobjet de laudit peut porter sur toutes les activits ayant une influence directe ou indirecte sur la qualit du logiciel labor. En effet, elle peut porter sur lvaluation des contrats, les plaintes des clients, le processus de dveloppement (analyse, conception, programmation, test, implantation, configuration), le processus de contrle de la qualit du logiciel, lassurance qualit, la documentation du systme qualit, etc. Avant de procder laudit il est ncessaire de procder un bref meeting avec les responsables des services audits leurs rappelant lintrt de laudit pour lentreprise, et une courte description du plan de laudit Le plan de laudit doit indiquer clairement : Lautorisation obtenue pour procder laudit (dclaration de la direction, indication au niveau plan du projet); Lobjet de laudit (audit priodique, audit conformment au plan assurance qualit, suite un vnement particulier); Les personnes impliques (le responsable de laudit, un reprsentant de la direction, le responsable du service audit ainsi que lquipe du service concern, le responsable assurance qualit, lauditeur externe sil existe); La date et le lieu de laudit; Les rfrences (code de la procdure suivie); Les services audits; Les activits auditer; Les documents inspecter; Les critres dvaluation; Les rapports rendre .

Aprs avoir procd laudit (inspection des documents concerns, entrevues avec les personnes impliques, valuation de lapplication des procdures et des instructions mises place, conformits avec les normes et les exigences internes de lentreprise, etc.) lquipe charge de laudit doit effectuer les activits suivantes :

41

Prparer le rapport de laudit qui doit identifier les dviations constates, ainsi que les actions correctives mettre en place; Effectuer un meeting de fermeture de laudit dans lequel on dcrit le droulement de laudit et on souligne les difficults et les anomalies observes; Envoyer le rapport de laudit aux personnes concernes; Analyser le rapport daudit du point de vue statistique, les observations rvles doivent tre enregistres et doivent tre lobjet des audits suivants. 1.14 Documentation relative la qualit

Lentreprise doit tablir et tenir jour des procdures dlaboration, didentification, de classement, darchivage, de mise jour et de destruction de la documentation relative la qualit. Cette documentation comprend : Manuel qualit; Manuel assurance qualit; Plan dassurance qualit; Procdures dlaboration et matrise des documentations relatives la qualit; Plan de vrification et de validation; Dossiers de vrification et de validation (preuves de lapplication des tests); Plan des audits; Rapports des audits; Plan des revues; Rapport des revues; Rapport dvaluation des fournisseurs; Plan de formation; Rapport de formation. 1.15 Les actions prventives et volutives Pour quun systme qualit soit efficace il devrait permettre de prvenir lapparition danomalies durant tout le cycle de dveloppement du logiciel. Aussi il devrait prsenter un mcanisme permettant lvolution permanente du systme pour quil maintienne et

42

amliore ventuellement sa performance. Ainsi les activits suivantes devraient tre mises en uvre : Une procdure devra tre mise en place dont lobjet est lidentification du risque danomalies durant tout le cycle de dveloppement; Au niveau du plan du projet, il faut tudier les risques pour chaque projet et identifier les mesures prventives mettre en place; Les ressources ncessaires pour lidentification et lvaluation du risque sont mises en place (la formation ncessaire est donne aux personnes responsables de la gestion du projet); Lvaluation du risque seffectue sous lautorit de chef du projet mais avec consultation de divers participants au projet; Pour tout anomalie constate une analyse causale est effectue afin didentifier, enregistrer, clarifier les origines de lanomalie et de mettre en applications les mesures ncessaires pour les corriger selon un plan daction labor selon les procdures en vigueur; Le plan daction doit clarifier limpact de tout anomalie constate sur la qualit du logiciel laborer et souligne les dviations par rapport aux spcifications ainsi que les incidences sur lchancier et le cot du projet; Le plan daction doit tre rvis par la direction et approuv avant dtre mis en application; Des indicateurs de performance devraient tre mis en place afin dvaluer la maturit et la performance du systme qualit, parmi les mtriques quon peut mettre en place : le temps mis pour identifier lanomalie, le nombre danomalies par phase de dveloppement, le nombre danomalies par ligne de code, etc. Appliquer des audits priodiques sur toute les composantes du systme selon des plans et des procdures bien tablies; tudier et analyser statistiquement lvolution de la maturit du systme qualit ; Mettre en place une veille technologique afin de vrifier lexistence sur le march de nouveaux moyens technologiques permettant dviter lapparition de nouvelles anomalies ou damliorer lefficacit du systme.

43

1.16 Formation Lentreprise doit mettre en place des procdures permettant didentifier les besoins en formation pour toute personne charge dune activit ayant un impact direct ou indirect sur la qualit logiciel labor ou mme sur le processus de dveloppement. En effet, lobjectif de ces procdures est de permettre une planification de la formation, offrir aux personnels les comptences et les connaissances ncessaires pour accomplir adquatement les activits sous leur responsabilit et damliorer leur rendement et la qualit de service quils offrent lentreprise. Pour rpondre adquatement cette exigence lentreprise doit : Sassurer que la direction va fournir les ressources ncessaires pour mettre en place un plan de formation; Identifier les besoins en formation pour chaque projet de dveloppement de logiciel ; Identifier la faon dobtenir la formation ncessaire (consultation des ouvrages spcialiss, formation lintrieur de lentreprise, la formation dans un tablissement acadmique externe); laborer un plan de formation dont on identifie le type de formation ncessaire, le mode de formation (comment la formation peut tre obtenue) , lchancier, les personnes qui vont profiter de la formation et ceux qui vont ventuellement offrir la formation; Sassurer que la direction vrifie et approuve le plan de formation avant de le mettre en application; Mettre les rapports de formation la disposition des personnes intresses durant tout le cycle de vie du logiciel, et ils doivent tre archivs selon les instructions en vigueur; Mettre en place des mtriques pour vrifier lvolution des besoins en formation (nombre de formations par projet, ou plus prcisment par phase du projet) et limpact de la formation donne sur le rendement et la qualit de service donn par les personnels impliqus;

44

Sassurer que la direction effectue une revue priodique du plan de formation selon les procdures en vigueur (on insiste sur la qualit de la formation donne, le suivi du plan de formation, le classement et larchivage des rapports de formation, etc.). 1.17 Soutien fourni aprs vente

Afin de rpondre adquatement aux besoins des clients, il est indispensable que lentreprise mette en uvre une procdure identifiant les services quelle offre ses clients aprs la vente. La procdure doit souligner limportance didentifier les diverses activits offertes aux clients au niveau du contrat sign avec ce dernier (client) ds le dbut du projet. Les services aprs vente peuvent inclure une priode de garantie dans laquelle lentreprise sengage installer, configurer, et entretenir le logiciel. Le service aprs vente peut tre offert de diffrente manire : laboration de manuel utilisateur; Aide distance; Intervention technique; Sances de formation.

Il est indispensable denregistrer toute anomalie constate, et maintenir un flux de communication continu avec le client. 1.18 Matrise des non-conformits Lentreprise doit mettre en place une procdure expliquant les activits mettre en place en cas de dtection dune non-conformit dans le logiciel labor ou dans un quipement ou logiciel achet. Il est souhaitable de mettre en uvre les activits suivantes : laborer des fiches de non-conformit dtaillant les anomalies constates; En suivant les instructions en vigueur appliquer les actions correctives ncessaires; En cas dun produit achet il faut communiquer avec le fournisseur et appliquer les procdures en vigueur (valuation et slection des fournisseurs);

45

Dans le cas o la livraison du logiciel est indispensable, et si la non-conformit est mineure (les dviations par rapport aux spcifications sont limites) une fiche de drogation peut tre remplie selon les procdures en vigueur et elle peut tre prsente au client. Si cette dernire (fiche de drogation ) est accepte par le client, le logiciel peut tre livr;

Mettre en place des mtriques afin dtudier et danalyser lefficacit du systme mis en place (par exemple le nombre de fiche de drogation labore par nombre de projets). 1.19 tude statistique

Afin dvaluer objectivement lvolution et la maturit du systme qualit de lentreprise, la mise en place des procdures et dinstructions identifiant les mtriques et les indicateurs appliquer et analyser est indispensable. En effet, les objectifs de cette exigence sont : La gestion quantitative du systme qualit est planifie; Les performances du processus de dveloppement, de contrle qualit, et dassurance qualit sont identifies quantitativement; laboration des plans daction sur des bases objectives. Mettre en place une procdure identifiant les diverses mtriques appliquer durant tout le cycle de vie du logiciel; Lentreprise doit mettre en place les ressources ncessaires pour laborer et appliquer les mtriques identifies; Offrir la formation ncessaire aux personnes charges de lapplication et de lanalyse des mtriques; Au niveau du plan du projet on identifie les mtriques appliquer, leur rpartition au niveau de lchancier ainsi que la rfrence des instructions suivre pour les mettre en application; Calculer le cot de lapplication des mtriques et le comparer au cot estim au dbut du projet, ainsi que son impact sur la dure et le cot total du projet; Vrifier si les cots de lapplication des mtriques sont justifis; Ainsi pour atteindre ces objectifs, les activits suivantes doivent tre ralises :

46

Diffuser les rsultats danalyse des mtriques appliques aux personnes concernes selon les procdures en vigueur; Revue priodique des procdures de mise en uvre des mtriques, et dclenchement des actions correctives, prventives, et volutives selon les procdures et les instructions en vigueur.

D-6- Lassurance qualit du logiciel 6-1- Objectifs Ayant conscience que la majorit des anomalies affectant la qualit du logiciel peuvent tre vites condition de mettre en place un mcanisme de prvention, les entreprises informatiques ont mis en uvre des services assurance qualit dont les principaux objectifs sont: viter que les objectifs des divers dpartements (dveloppement, contrle qualit, etc.) soient en contradiction avec les objectifs de lentreprise; viter que les objectifs de lentreprise soient en conflits avec les rglements qui rgissent le domaine; Maintenir, inspecter et faire voluer le systme qualit mis en place.

6-2- Activits lies lassurance qualit du logiciel 6-2-1- Dveloppement de la documentation du dpartement assurance qualit La premire proccupation du responsable assurance qualit est doffrir son service les lments ncessaire (personnels, formation, quipements) pour atteindre les objectifs quil vise. En effet, pour structurer et organiser ses activits, le service dassurance qualit met en place la documentation suivante : Manuel assurance qualit (voir section 4.2); Procdures et instructions identifiant les activits mettre en application, en mettant laccent sur les activits suivantes : o Matrise de la documentation; o laboration du plan assurance qualit; o Mise en uvre et droulement des audits et des revues; o laboration des plans de formation.

47

6-2-2- laboration du plan assurance qualit Pour chaque projet de dveloppement du logiciel, le service assurance qualit doit laborer un plan assurance qualit (selon les procdures en vigueur) dans lequel on signale les points suivants : Objet et objectifs du plan assurance qualit; -Rfrences de la procdure utilise pour laborer le plan assurance qualit; Identification de lauteur, du vrificateur et de lapprobateur; Responsables de lapplication du plan assurance qualit; Rfrences de la documentation du processus de dveloppement du logiciel ( plan du projet, dossier danalyse, dossier de conception, etc.) et de contrle de la qualit du logiciel (plan de vrification et de validation, dossier de vrification et de validation); Normes et instructions respecter; Mtriques mettre en uvre; Revues et audits appliquer; Moyens et quipements utiliser; chancier ; Risques lis lapplication du plan assurance qualit; Formation ncessaire pour lapplication du plan assurance qualit.

6-2-3- Revue du processus de dveloppement Lune des proccupations principales de lassurance qualit est la revue du processus de dveloppement. La revue est centre sur la concordance avec les normes et les procdures de lentreprise et les divers documents labors lors de llaboration du logiciel. En effet, si lassurance qualit a t implique ds le dbut du projet (par le dveloppement du plan assurance qualit) le respect des procdures internes de lentreprise sera bien prsent. La revue du processus de dveloppement comprend les six points suivants :

48

1- Revoir techniquement le logiciel en cours de dveloppement (caractristiques du logiciel, plan du projet, dossier danalyse, dossier de conception, dossier de vrification et de validation, dossier de configuration, dossier dimplantation); 2- Dterminer si le processus de dveloppement permet de rpondre efficacement aux besoins du client, et aux objectifs de lentreprise; 3- Vrifier si le processus de dveloppement suit correctement les procdures, les instructions et le plan du projet; 4- Vrifier si le processus de dveloppement permet une gestion efficace des ressources fournies; 5- Revoir les procdures et les instructions utilises au niveau du service de dveloppement; 6- Dterminer sil est possible dutiliser un nouveau moyen (utilisation de moyen technologique, implication dans le processus de dveloppement, etc.) pour amliorer lefficacit des revues. 6-2-4- Faire un audit du systme qualit Pour valuer la performance du systme qualit (en vitant lapparition danomalies et en facilitant leur identification en cas dexistence ), lassurance qualit doit procder des audits priodiques et en cas dvnement particulier selon les procdures et les instructions en vigueur, sur toutes les composantes du systme qualit (organisation, documentation, processus, ressources matriels). Les exigences suivre lors de lapplication des audits et les points signaler au niveau du rapport de laudit sont identifis au niveau de la section D-5.13. 6-2-5- tude statistique de lassurance qualit du logiciel Ltude statistique de lassurance qualit du logiciel donne lentreprise les moyens ncessaires pour valuer objectivement lamlioration du systme qualit mis en place et se centrer essentiellement sur les principales causes des dfauts observs au niveau des logiciels dvelopps et du fonctionnement du systme qualit. Ltude statistique de lassurance de la qualit du logiciel implique que les activits suivantes sont dj mises en place :

49

Une procdure identifiant les activits suivre pour identifier, classer et enregistrer les dfauts constats; Identification des causes relies chaque dfaut (erreur lors de lanalyse des besoins du client, erreur de conception, non-conformit une procdure, erreur lors de lapplication des tests, erreur lors de lanalyse des mtriques, etc.);

Utilisation du principe de Parto (80% des dfauts sont lis 20% des causes) lors de la classification des dfauts en anomalie majeure, moyenne et mineure.

Il est utile dutiliser la mthode dcrite par Pressman [Pres2001] pour tudier statistiquement lassurance qualit du logiciel, dont le principe est se concentrer sur ltude des causes importantes mais sassurer dabord quelles sont vraiment importantes . Ce principe prsente un guide pour lamlioration de lefficacit du systme qualit. La mthode de Pressman [Pres2001] met laccent sur les paramtres suivants : Ei = nombre de dfauts identifis au niveau de la phase i; Si = nombre derreurs majeures Mi = nombre derreurs moyennes; Ti = nombre derreurs mineures; PS = taille du logiciel ( en nombre de lignes de code); Ws = Facteur de pondration des dfauts majeurs; Wm = Facteur de pondration des dfauts moyens; Wt = Facteur de pondration des dfauts mineurs. Pour chaque phase i du cycle de vie du logiciel on calcule lindice suivant : PIi = Ws (Si/Ei) + Wm (Mi/Ei) + (Ti/Ei) Avec lindice PIi on peut identifier dans quelles phases les dfauts ont t le plus rencontrs et par consquent ont peut se concentrer sur ltude de cette phase et porter par suite les changements ncessaires pour prvenir les causes de ses dfauts. Ensuite, on calcule lindice des erreurs (EI) pour tous le cycle de dveloppement du logiciel : EI = (i _ PIi )/ PS = (PI1 + 2 PI2 +3 PI3 + ... n PIn) / PS

50

Lutilisation dindicateurs PI, EI et le principe de Parto permettent de guider le travail accompli par lquipe de lassurance qualit notamment lors de la planification des audits, des revues et des changements porter au systme qualit. D-7- Les spcifications du logiciel Pour pouvoir valuer la qualit dun logiciel, il est indispensable de disposer dun ensemble de paramtres ou de caractristiques de la qualit. La norme ISO/CEI9126 (technologie de linformation valuation des produits logiciels Caractristiques de qualit et directives dutilisation) identifie six caractristiques lies la qualit du logiciel : la fiabilit, les capacits fonctionnelles, le rendement, la maintenabilit, la portabilit et la facilit dutilisation. 7.1 Capacit fonctionnelle On entend par la capacit fonctionnelle, les fonctions du logiciel qui rpondent des besoins explicites ou implicites des utilisateurs, dclenchs par les vnements daffaires. Cette caractristique est dfinie par cinq sous-caractristiques Aptitude (attributs du logiciel portant sur la prsence et ladquation dune srie de fonctions pour des t_ches donnes); Exactitude (attributs du logiciel portant sur la fourniture de rsultats ou deffets justes ou convenus); Interoprabilit (attributs du logiciel portant sur sa capacit dinteraction avec dautres systmes); Conformit rglementaire (attributs du logiciel selon lesquels il respecte lapplication de normes, des conventions, des rglementations de droit ou des prescriptions similaires); Scurit (attributs du logiciel portant sur son aptitude empcher tout accs non autoris). 7.2 Fiabilit

51

La fiabilit est la capacit du logiciel maintenir son niveau de performance dans des conditions prcises et pendant une priode dtermine. La fiabilit est dfinie par trois sous-caractristiques : Maturit: frquence des dfaillances dues des dfauts du logiciel; Tolrances aux fautes (aptitude du logiciel maintenir son niveau de service en cas de dfauts); Possibilit de rcupration (capacit du logiciel rtablir son niveau de service et de restaurer les informations directement affectes en cas de dfaillance, et sur le temps et leffort ncessaire pour le faire). 7.3 Facilit dutilisation La facilit dutilisation est dfinie par lensemble dattributs portant sur leffort ncessaire pour lutilisation et sur lvaluation individuelle de cette utilisation par un ensemble dutilisateurs. Elle est dfinie par trois sous-caractristiques Facilit de comprhension (attributs du logiciel portant sur leffort que doit faire lutilisateur pour reconnatre la logique de son utilisation); Facilit dexploitation (attributs du logiciel portant sur leffort que doit faire lutilisateur pour lexploiter et contrler son exploitation); Facilit dapprentissage (attributs du logiciel portant sur leffort que doit faire lutilisateur pour apprendre son application). 7.4 Rendement Le rendement est le rapport entre le niveau de service du logiciel et la quantit de ressources utilises, dans des conditions dtermines. Cette caractristique est dfinie par deux sous-caractristiques : Par rapport au temps (attributs du logiciel portant sur le temps de rponse et de traitement ainsi que sur les dbits lors de lexcution des fonctions); Par rapport aux ressources (attributs du logiciel portant sur la quantit de ressources utilises et sur la dure de leur utilisation lors de lexcution des fonctions).

52

7.5 Maintenabilit On entend par la maintenabilit leffort ncessaire pour modifier le logiciel (corrections, amliorations, adaptations). La maintenabilit est dtermine par quatre sous caractristiques : Facilit danalyse (attributs du logiciel portant sur leffort ncessaire pour diagnostiquer les dficiences ou les causes de dfaillance, ou pour identifier les parties modifier); Facilit de modification (attributs du logiciel portant sur leffort ncessaire pour modifier, remdier aux dfauts ou changer denvironnement); Stabilit (attributs du logiciel portant sur le risque des effets inattendus des modifications); Facilit de test (attributs du logiciel portant sur leffort ncessaire pour valider le logiciel modifi). 7.6 Portabilit La portabilit est dfinie par la facilit de transfrer le logiciel dun environnement un autre. Cette caractristique est identifie par quatre sous-caractristiques : Facilit dadaptation (attributs du logiciel portant sur la possibilit de son adaptation diffrents environnements donns sans que lon ait recours dautres actions ou moyens que ceux prvus cet effet pour le logiciel considr); Facilit dinstallation (attributs du logiciel portant sur leffort ncessaire pour installer le logiciel dans un environnement donn); Conformit relative aux rgles de portabilit (attributs du logiciel permettant celui-ci de se conformer aux normes ou conventions ayant trait la portabilit); Interchangeabilit (attributs du logiciel portant sur la possibilit et leffort pour lutiliser la place dun autre logiciel donn dans le mme environnement).

53

Exactitude Aptitude Capacit fonctionnelle Interoprabilit Conformit rglementaire Scurit Maturit Fiabilit Tolrances au fautes Possibilit de rcupration Facilit de comprhension Exigences qualit Facilit dutilisation Facilit dapprentissage Facilit dexploitation Vis--vis du temps Vis--vis des ressources Facilit danalyse Facilit de modification Maintenabilit Facilit des tests Stabilit Facilit dadaptation Facilit linstallation Portabilit Caractristiques Conformit aux rgles de portabilit Interchangeabilit Sous-caractristiques

Rendement

Figure N4 : Les spcifications logiciel [CAFNOR]

54

D-8- Vrification et contrle de la qualit du logiciel 8.1 Objectifs des contrles Les entreprises informatiques mettent en application des procdures de vrification et de validation de la qualit du logiciel afin datteindre les objectifs suivants : Identifier les anomalies le plus tt possible au niveau du processus de dveloppement; Sassurer que les actions correctives sont appliques; Vrifier que le logiciel labor rpond adquatement aux exigences pr-tablies. Fournir les informations ncessaires pour estimer la qualit du logiciel; Amliorer lefficacit des tests; voluer le niveau technique des participants aux projets de dveloppement du logiciel. 8.2 Dmarche de vrification de la qualit logiciel Pour pouvoir estimer la qualit du logiciel il faut suivre une dmarche qui se compose de quatre tapes : laboration du plan de vrification et de validation selon les procdures en vigueur; Identification des exigences de la qualit au moyen des caractristiques et des sous-caractristiques; Prparation de lapprciation : identification et choix des mtriques significatives, mise au point dune chelle de mesure qui permet aprs regroupement par sous-caractristiques et pondration selon le domaine dapplication du logiciel et des besoins de lutilisateur dtablir un classement final; valuation de la qualit du logiciel (application des mesures et jugement suivant lchelle mis en place).

En plus, les vrifications permettent datteindre les objectifs suivants :

55

laboration du plan de vrification Identification des caractristiques

Identification des sous-caractristiques Mise en place des mtriques Application des tests Analyse des rsultats obtenues Dossier de vrification et de validation

Figure N5 : Dmarche de vrification de la qualit du logiciel [CAFNOR]

8.3 laboration du plan de vrification et de validation Pour chaque projet de dveloppement du logiciel, il faut laborer un plan de vrification et de validation en respectant les exigences identifies dans la section D-5-9. Le plan de vrification et de validation doit identifier les points suivants : Objectifs du plan; Documents de rfrences (normes, procdures, etc.); Dfinitions et terminologie; Responsabilits; chancier; Outils, techniques et mthodes; T_ches de vrification et de validation selon le cycle de vie du logiciel; Mthodes et critres dvaluation; Identification des entres (plan du projet, plan assurance qualit) et sorties (dossier de vrification et de validation, preuves de tests, etc.);

56

Risques; Formation ncessaire pour llaboration et lapplication du plan de vrification et de validation.

8.4 Activits de vrification 8.4.1 Les tests unitaires Les tests unitaires sont raliss pendant la phase de dveloppement, sont dissociables, selon le processus de slection des tests utiliss, en deux stratgies : 8.4.1.1 Les tests fonctionnels "Black box testing" Ce sont des tests qui permettent de vrifier l'adquation du logiciel aux contraintes dfinies dans les spcifications. Les tests de fonctionnalits valuent la raction du logiciel par rapport des donnes d'entres reprsentatives. On teste ici ce que le programme est cens faire et non pas ce qu'il fait rellement. 8.4.1.2. Les tests structurels "White box testing" Ce sont des tests qui permettent de valider la structure de chaque module composant le logiciel. Ils permettent d'avoir l'assurance que toutes les parties d'un programme ont t essayes. On teste ici ce que le programme fait et non pas ce qu'il est cens faire. Tests fonctionnels et tests structurels sont complmentaires, dans le sens o ensemble, ils permettent de tester ce que le programme doit faire et ce que le programme fait. 8.4.2.Profilers Le "profiling" d'application permet de dterminer dans quelles portions du code le programme passe la plupart de son temps et partir de quelles fonctions ces parties sont invoques. Ces informations permettent de rvler des problmes d'optimisation. Dans certains cas cela peut galement indiquer un bug si on se rend compte qu'une fonction est appele plus souvent que prvu. 8.4.3. Les mtriques Pour pouvoir estimer objectivement la qualit du logiciel, il est essentiel de se doter de mtriques convenables permettant dvaluer les caractristiques et les souscaractristiques du logiciel

57

En effet, grce aux aspects quantifiables des mtriques, on rduit la place de la subjectivit dans lvaluation du logiciel. Cependant, lintervention humaine sera toujours de la partie l o le bon sens prvaut dans la dtermination des valeurs des pondrations, ou mme dans lanalyse des rsultats. Une mtrique est dfinie par des lments tel que : laboration de la plage de classement : il peut tre une valeur numrique (nombre de lignes de code), dun critre dapprciation (valide, non valide), dune chelle dapprciation (linaire :1 10 , Excellent, bon, moyen, mauvais); Offre de la formation requise aux personnes qui vont appliquer les mtriques ; Identification de linformation collecter (on dcrit les caractristiques mesurer dans le temps et dans lespace); Mise en place des quipements et des outils requis; Identification de lorganisation mettre en place pour assurer lapplication efficace des mtriques; Identification des exigences lies lenregistrement et larchivage des rsultats Mise en place des procdures lies lanalyse des rsultats; Mise en place des exemples types dapplication des mtriques afin dassurer une application efficace des mtriques en question. 8.5 Analyse des rsultats de vrification Lanalyse des rsultats obtenus la suite de lapplication des tests et des mtriques est une tche assez dlicate qui demande la prsence de certains facteurs essentiels notamment : Mettre en uvre des instructions identifiant les exigences respecter pour assurer une analyse efficace des rsultats des vrifications; Tenir en considration le domaine dapplication de logiciel labor (sret, conomie, scurit, environnement, etc.); Dterminer le niveau dexigence (par exemple : A : faible, B : moyen, C : peu lev, D : leve); Se concentrer sur les besoins implicites et explicites du client;

58

Offrir la formation et lexprience aux personnes charges daccomplir cette tche; Enregistrer linterprtation des rsultats danalyse. Cet enregistrement servira non seulement pour des besoins de traabilit mais aussi il pourra tre utilis comme exemple type pour des nouvelles applications. Aussi, il sera trs utile pour prouver aux clients la qualit du logiciel dvelopp et le niveau de maturit du systme qualit de lentreprise.

E/ tude Pratique
1- Prsentation de lentreprise Fonde en 1976, CGI est la premire entreprise indpendante canadienne de services en technologies de l'information et la quatrime en Amrique du Nord compte tenu de son effectif de plus de 21 000 professionnels. partir de son rseau de bureaux au Canada, aux tats-Unis et en Europe, CGI offre une gamme complte de services en technologies de l'information et en gestion des processus daffaires plus de 3 500 clients. En 1994, ses processus de gestion ont t dcrits, consigns et enregistrs conformment aux exigences de la norme ISO 9001; en 1998 CGI a produit son Cadre de gestion des technologies afin dtendre sa certification ISO ses processus de gestion de centres de traitement. Depuis lors, CGI sest empresse dlargir son ventail de services pour saffirmer comme une entreprise de calibre mondial offrant une gamme complte de services en TI 1.1. Mission CGI est une entreprise spcialise en technologie de linformation, elle offre ses clients une gamme complte de services qui comprend : Services-conseils : CGI joue le rle de conseiller auprs de ses clients en leur fournissant une gamme complte des services de consultation en TI et en gestion, y compris la planification stratgique des TI, lingnierie des processus daffaires et larchitecture de systmes; 59

Services dintgration de systmes : CGI offre des services complets de mise en uvre, intgrant les multiples volets de lenvironnement technologique de ses clients, afin de crer des systmes qui rpondent leurs besoins stratgiques. CGI fournit aussi ses clients des services de dveloppement dapplications sur mesure;

Services dimpartition (Gestion de fonctions informatiques et daffaires ) : Les clients dlguent CGI la responsabilit totale ou partielle de leurs fonctions informatiques et daffaires. Les services fournis dans le cadre dun contrat dimpartition peuvent englober un ou plusieurs des aspects suivants : la gestion dinstallations (centres de traitement des donnes, centres dappel, services rseaux et de bureautique); la maintenance dapplications et le soutien; le dveloppement et lintgration de nouveaux projets et de nouvelles applications; la gestion de processus daffaires tels que la gestion documentaire, la gestion financire et comptable ou ladministration des contrats dassurance.
80 70 60 50 40 30 20 10 0 Intgration systmes et servicesconseils Impartition

Figure N6 : Rpartition des services offerts par CGI 1.2. Objectifs Lobjectif permanent de CGI est dtre un leader de classe mondiale du secteur des technologies de linformation et de la gestion des processus daffaire. Pour lanne 2003, CGI a fix comme objectif financier, une croissance de 11% 20% par rapport lanne 2002 en centrant essentiellement sur lexpansion des contrats dimpartition.

60

2- Prsentation de lunit daffaire Lunit daffaire M031 est spcialise dans le dveloppement du logiciel et plus particulirement dans le dveloppement des applications transactionnelles sur le Web. Nomme auparavant Myriap lunit M031 sest jointe la CGI partir du 03 juin 2002, avec environ 60 professionnels travaillant Montral et Toronto. Lorganisation de lunit est de type vertical trois niveaux. Malgr lindpendance dont profite lunit, elle reste bien attache la politique et la vision stratgique du CGI. 3- tude du systme qualit 3.1 lments du systme qualit 3.1.1 Organisation Linfrastructure organisationnelle mise en place au niveau de lunit M031 permet cette dernire de grer son systme de travail. Elle peut tre modlise comme suit :

Section CGI de Montral VP de Montral VP Service dveloppement

Unit M031 Directeur Unit d'affaire M031 Directeurs Processus d'affaire Conseiller principal Conseillers

61

3.1.2 Processus Lidentification de divers processus tablis au niveau de lunit M031 est effectu dans lIntranet de lentreprise; parmi les processus identifis, on cite : Le processus de vrification et de tests; Le processus de validation (revues); Le processus danalyse; Le processus de planification; Le processus destimation des dures et de cots des projets, Le processus didentification de dfauts; 3.1.3 Documentation La documentation utilise au niveau de lunit M031 (procdures, gabarits, enregistrements) est sous forme lectronique. Pour dvelopper cette documentation lunit a suivi la structure suivante :

Processus

Phases

Disciplines

Gabarits

Activits

tapes

Techniques

62

3.1.3.1 Manuel qualit Lunit daffaire M031, na pas dvelopp un manuel qualit spcifique elle, mais elle a adopt celui de la CGI. Le manuel qualit prsente la structure gnrale du systme qualit adopt au niveau de la CGI, il identifie : La politique qualit de la CGI; La structure organisationnelle de la CGI; Le cadre de gestion du partenariat client, membre, actionnaire; Le cadre de gestion des oprations.

3.1.3.2 Manuel des procdures Au niveau de lunit M031, il nexiste pas de manuel intitul manuel des procdures mais les divers processus mis en place sont identifis au niveau de lIntranet. En effet on identifie les diverses activits appliquer pour assurer la mise en uvre du processus en question. 3.1.3.3 Gabarits Llaboration des livrables rendre aux clients ou pour usage interne seffectue en utilisant les gabarits dj dvelopps et mis sur Intranet. 3.1.3.4. Enregistrements Selon le modle adopt par lunit M031, il nexiste pas de document intitul plan du projet, dossier de danalyse, etc. mais les diverses parties identifies au niveau de ces enregistrements sont labores dans des livrables indpendants afin dviter llaboration des dossiers volumineux qui sont difficiles consulter, larchivage et la matrise de ces divers enregistrements sont assurs laide du logiciel CVS1. 4- tude du processus de dveloppement Le processus de dveloppement adopt par M031 est un processus en spirale, il est inspir du modle donn par Rational : RUP (Rational Unified Process), il se base sur 4 phases essentielles : inception, laboration, construction et transition; chaque phase comprend plusieurs disciplines (modlisation daffaires, exigences, analyse et conception, etc.) et chaque discipline comprend plusieurs itrations successives. Le

63

passage dune phase une autre seffectue suite une dcision prise par lquipe de dveloppement (un jalon).1

Phases Disciplines
Modlisation daffaire Exigences Analyse & conception Implantation Test

Inception

laboration Construction Transition

dploiement

Jalon
Configurtion

Processus de dveloppement

5- Application du questionnaire de maturit Dans le but dvaluer le systme qualit mis en oeuvre au niveau de lunit M031, on a appliqu le questionnaire de maturit de CMM [Zubrow] dvelopp par le SEI (Software Engineering Institute). Lapplication du questionnaire a dur deux heures et un conseiller de lunit M031 a rpondu aux diverses questions poses par le questionnaire. Les observations obtenues sont rsumes au niveau de la section 7 (valuation du processus de dveloppement selon le modle CMM).

http://www.cvshome.org/ (consult le 20/06/2003)

64

6- Spcifications de logiciels Afin dvaluer la qualit du logiciel labor, lentreprise utilise les paramtres suivantes : Les capacits fonctionnelles : laptitude du logiciel rpondre adquatement aux besoins du client et plus particulirement aux besoins daffaires; La performance du logiciel; La conformit aux normes rgissant le domaine.

7- valuation du processus de dveloppement selon le modle CMM Le CMM (Capablility Maturity Model) est un cadre qui dcrit les lments clefs d'un processus technique efficace. Le CMM prsente une approche volutionniste d'amlioration des processus indfinis vers des processus disciplins (voir section D-1.3). La mise en application du questionnaire de maturit, nous a permis de mettre en vidence les efforts faits par lentreprise pour amliorer et grer efficacement son systme qualit. En effet, nous remarquons que lentreprise mis en uvre les pratiquescls exiges par des secteurs-cls qui se situent des niveaux diffrents du modle CMM (par exemple : lentreprise rpond adquatement la pratique-cl 2 du secteur-cl gestion des exigences du niveau de maturit 2 et aussi la pratique-cl 1 du secteur-cl 2 gestion de la qualit du niveau de maturit 4). Cependant pour atteindre un niveau de maturit dtermin, il faut rpondre adquatement aux diverses exigences de tous les secteurs-cls quil comprend, par consquent le niveau de maturit du processus de dveloppement de lunit M031 se situe au niveau 1 (vu que le niveau de maturit du processus de dveloppement ne satisfait pas les exigences des secteurs-cl suivants du niveau de maturit 2 : gestion de la sous-traitance et assurance de qualit du logiciel ). Cependant il faut mentionner que le systme qualit mis en place rpond aux exigences identifies par les secteurs-cls du niveau de maturit 2 : Gestion des exigences; Planification des projets; Suivi et supervision des projets; Gestion des configurations du logiciel.

65

L'organisation n'offre galement pas un environnement stable pour le dveloppement et le maintien des TI. Les procdures peuvent tre abandonnes et les projets se transforment en usines de codage et de tests. La russite de tels projets dpend uniquement de la qualit du gestionnaire de projet et de l'quipe de dveloppement. Mme les processus techniques peuvent perdre de leur efficacit en labsence de pratiques de gestion saines. 8. Activits mettre en place pour amliorer lefficacit du systme qualit Suite lvaluation du systme qualit de lunit M031 par rapport au modle CMM et aux exigences identifies au niveau de la section D- 5, et dans lobjectif damliorer lefficacit de son systme qualit, on suggre lentreprise la mise en application des activits suivantes : Identifier de faon formelle les responsabilits des diverses personnes travaillant lunit M031 au moyen des fiches de fonctions; Identifier les relations entre les diverses personnes travaillant lunit M031 au moyen de lorganigramme et mettre ce dernier la disponibilit des personnes impliques; Mettre en place les fonctions : responsable dassurance qualit et responsable de contrle qualit; laborer un manuel qualit spcifique lunit M031 qui identifie la politique qualit de lunit (laquelle doit tre en concordance avec la politique qualit de lentreprise); Mettre lventuel Manuel qualit la disponibilit des personnes travaillant lunit M031; Mettre en place un manuel assurance qualit identifiant les activits lies la fonction du responsable assurance qualit; Adopter un seul formalisme pour les documents qualit au niveau de lunit M031; Identifier au niveau de chaque document les responsabilits des personnes impliques;

66

Former le personnel sur lutilisation et la consultation des diverses informations contenues au niveau de lIntranet; Mettre en application les diverses exigences et activits identifies au niveau des procdures; Identifier au niveau du plan du projet les besoins en formation pour chaque projet; valuer la qualit du logiciel labor selon les caractristiques identifies au niveau de la norme ISO/CEI9126 (technologie de linformation valuation des produits logiciels Caractristiques de qualit et directives dutilisation);

Identifier au niveau des procdures labores les rfrences utilises pour laborer les documents en question Mettre en place une instruction permettant le reprage de divers documents (vu que chaque partie dun enregistrement - par exemple le dossier danalyse est divis en plusieurs livrables : document de vision, document des spcifications, etc. - constitue un livrable en soi) ;

Mettre en place une procdure formelle identifiant les diverses exigences et activits (voir section D 5.8 ) mettre en uvre pour russir lachat de matriels et de logiciels;

Mettre en place une procdure formelle identifiant les diverses exigences et activits (voir section D 5.16 ) mettre en oeuvre pour russir la formation de personnels;

Mettre en place une procdure formelle identifiant les diverses activits et exigences ( voir section D - 5.19) appliquer pour valuer quantitativement la performance des diverses activits au niveau de lunit M031;

Mettre en place des instructions identifiant les diverses mtriques appliquer durant tout le cycle de vie du logiciel; Identifier au niveau du plan du projet les mtriques appliquer, leur rpartition au niveau de lchancier ainsi que les rfrences des instructions suivre pour les mettre en application;

Calculer le cot de lapplication des mtriques et le comparer au cot estim au dbut du projet, ainsi que son impact sur la dure et le cot total du projet;

67

Vrifier si les cots de lapplication des mtriques sont justifis; Mettre en place une procdure identifiant les restrictions lies la confidentialit et la diffusion des documents. Pour atteindre le niveau de maturit 2 : Rptable du modle CMM, il faut mettre en application les activits suivantes : laborer une procdure de slection des sous-traitants; laborer une procdure de gestion des relations avec les sous-traitants; Mettre en place une procdure dterminant les activits mettre en place en cas de changements des exigences donnes au sous-traitant; Maintenir un flux dinformation continue avec les sous-traitants; valuer la performance des activits effectues par les sous-traitants Enregistrer et archiver tous les documents relis aux activits maintenues par les sous-traitants; Offrir la formation ncessaire aux personnes responsables de grer les relations avec les sous-traitants; Mettre en place des mtriques dterminant objectivement les performances des sous-traitants; Revoir priodiquement les activits lies la gestion des relations avec les soustraitants par la direction; Mettre en place des mtriques dterminant objectivement les performances des activits lies lassurance qualit; Mettre en place des mtriques dterminant objectivement les performances des activits lies la gestion de la configuration; laborer une procdure de slection des fournisseurs; laborer une procdure de gestion des relations avec les fournisseurs; Maintenir un flux dinformation continue avec les fournisseurs; valuer laptitude des fournisseurs rpondre adquatement aux exigences et aux standards de lentreprise; Offrir la formation ncessaire aux personnes responsables de grer les relations avec les fournisseurs;

68

Mettre en place des mtriques dterminant objectivement les performances des fournisseurs; Revoir priodiquement les activits lies la gestion des relations avec les fournisseurs par la direction; Mettre en fonctionnement le systme qualit de lentreprise;

F/ Conclusion
Vu les diverses menaces et obstacles (exigences des clients, concurrence, cots du projet, etc.) auxquels font face les entreprises informatiques, la mise en place dun systme qualit efficace devient une ncessit incontournable. En effet, plusieurs approches et mthodologies ont t prsentes dans lobjectif de soutenir ces entreprises dans leur dmarche de qualification. Cependant, il sest rvl que plusieurs expriences se sont soldes par un chec, parmi les causes des checs ont note : Lapproche suivie pour la mise en oeuvre et le maintien du systme qualit nest pas adapte au contexte de lentreprise ce qui entrane une grande rsistance au changement; Le systme mis en place est implant sans porter des modifications afin de ladapter au contexte de lentreprise; Le systme est impos par la direction dans une vision publicitaire sans tre conscient des avantages quil peut apporter; Seulement certains lments du systme qualit sont implants ce qui empche le fonctionnement adquat du systme. En tenant compte des diverses normes, modles, expriences de certains entreprises et des recherches prsentes dans le domaine, le projet prsente une approche pratique de maintien et dvolution du systme qualit qui vise permettre aux entreprises informatiques datteindre leurs objectifs. Lapproche prsente par le projet identifie les lments essentiels mettre en uvre pour maintenir et faire voluer lefficacit du systme qualit mis en place, en 69

effet il traite tous les facteurs ayant un impact direct ( les exigences lies au processus de dveloppement, le processus de vrification et de validation, etc.) ou indirect (lengagement de la direction, les exigences lies la formation, lachat de matriels et de logiciels de dveloppement, etc.) sur la qualit du logiciel dvelopp et se centre plus particulirement sur la documentation du systme qualit en partant du principe ce qui nest pas crit nexiste pas . Aussi, le projet a mis la lumire sur les objectifs de la fonction assurance qualit, et il prsente les activits qui lui sont lies, ainsi que les techniques et mthodes ncessaires pour vrifier la performance de ses activits. De mme le projet dtaille la phase de vrification et de tests en tenant compte de son importance sur ltude de la qualit du logiciel; en effet, les vrifications et les revues sont les fondements de lassurance qualit du logiciel. Pour que ltude soit aussi complte que possible, le projet exige lemploi des mtriques pour vrifier tous les processus daffaires lis au systme qualit; en effet la performance de toute activit doit tre vrifie au moyen de mtriques convenables. De plus le projet souligne limportance de porter des changements continus au systme qualit afin de maintenir et ventuellement de faire voluer ses performances. Cependant, dans un objectif de mise en valeur, il faut bien identifier les limites de ltude; en effet bien que le projet se base sur plusieurs normes (ISO9001, IEEE 7301980, etc.), recherches ( Qualit du logiciel et systme qualit [Martin], Quality assurance for information system [Perry], etc.) et modles (CMM), en raison des moyens disponibles (moyens financiers, disponibilit des entreprises) et de taille du projet (qui se situe dans le cadre dune matrise en technologie de linformation) ltude pratique sest limite lexprience dune seule entreprise (CGI) qui se place parmi les grandes entreprises dont les exigences, les objectifs et les moyens sont diffrentes des petites et moyennes entreprises. La porte reste donc ouverte pour plus dapprofondissement et denrichissement de ltude. Pour conclure, il est essentiel de souligner que lintrt pour ltude de lassurance de la qualit du logiciel ne cesse dvoluer, et que les recherches dans ce domaine sont de plus en plus nombreuses et visent offrir aux entreprises informatiques les moyens

70

ncessaires pour grer efficacement leurs processus de dveloppement et leurs processus daffaires. Elles vont aussi permettre une matrise plus efficace des trois facteurs : qualit du logiciel, cots et dlais des projets informatiques; et par consquent aider laborer continuellement des logiciels qui rpondent aux besoins des clients et qui permettent de gnrer des profits .

71

Bibliographie 1. [Bertini] M-T Bertini. La normalisation du logiciel. Mc Graw Hill 1986. 2. [CAFNOR] CIBA-AFNOR. Management de la qualit du logiciel. Corlet 1996. 3. [Caputo] K Caputo. CMM Implementation Guide. Addison-Wesley , c1998 4. [Dymond] M D Kenneth, Le guide du modle CMM, Cpadus-ditions 1997. 5. [ExpoRevue] ExpoRevue, N 8&9. Imprimerie principale Tunis. Mars 1999 6. [Garcia] M C Paulk, C V Weber, S M Garcia, M B Chrissis, M Bush. Key Practices of the Capability Maturity Model, Version 1.1. SEI 1993. 7. [Hau] B-A Genest, T H Nguyen, Principes et techniques de la gestion de projets, Les ditions Sigma Delta 2002. 8. [IEEE1008] IEEE/ANSI Std 1008. Standard for Software Unit Testing. 1997 9. [IEEE1016] IEEE Std 1016. IEEE Recommended Practice for Software Design Descriptions. 1998 10. [IEEE1028] IEEE Std 1028. IEEE Standard for Software Reviews. 1997 11. [IEEE1058] IEEE Std 1058. IEEE Standard for Software Project Management Plans. 1998 12. [IEEE1061] IEEE Std 1061. IEEE Standard for a Software Quality Metrics Methodology. 1998 13. [IEEE730] IEEE Std 730. IEEE Standard for Software Quality Assurance Plans. 1998 14. [IEEE828] IEEE Std 828. IEEE Standard for Software Configuration Management Plans. 1998 15. [IEEE830] IEEE Std 830. Recommended Practice for Software Requirements Specifications. 1998 16. [ISO/CEI9126] ISO/CEI9126. Technologie de linformation valuation des produits logiciels Caractristiques de qualit et directives dutilisation. 1991. 17. [ISO8402] ISO 8402. Qualit vocabulaire.. 1986. 18. [ISO9000-3] ISO 9000-3. Normes pour la gestion de la qualit et lassurance de la qualit, Partie 3 : Lignes directrices pour lapplication de lISO 9001 au dveloppement, la mise disposition et la maintenance du logiciel. 1991

72

19. [ISO9001] ISO 9001. Systme qualit - Modle pour lassurance de la qualit en conception/dveloppement, production installation et soutien aprs vente. 1987 20. [ISO9004] ISO 9004. Gestion de la qualit et lments de systme qualit. 1987 21. [ISO9004-2] ISO 9004-2. Gestion de la qualit et lments de systme qualit, Partie 2. 1991. 22. [LAFNOR] AFNOR. Le plan qualit du logiciel. Imprimerie nouvelle 1998. 23. [Martin] J-P Martin. Qualit du logiciel et systme qualit. Masson 1992. 24. [Paulk ] M C Paulk, C V Weber, B Curtis, M B Chrissis. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley. 1995 25. [Perry] W E.Perry. Quality Assurance for Information System. A Wiley-Qed Publication 1991. 26. [Pres2001] R S Pressman, Software Engineerieng : A Practitioners Approch, Mc Graw Hill, 2001. 27. [Rakitin] S R Rakitin. Software Verification and Validation. Artech House 1997. 28. [Rivard] S Rivard, J Talbot. Le dveloppement de systme dinformation. Presses de luniversit du Qubec. 2000. 29. [Schulmeyer] G G Schulmeyer, J I Mcmanus. Handbook of Software Quality Assurance. Prentice Hall Ptr. 1999 30. [Sommerville] I Sommerville, Le gnie logiciel, ditions Addison-Wesley France, 1992. 31. [Zubrow] D Zubrow, Whayes, J Siegel, D Goldenson, Maturity Questionnaire, CMU/SEI 1994

73

Annexe 1 Correspondance entre ISO 9000-3 et ISO 9001 Exigence ISO 9000-3 Responsabilit de la direction Systme qualit Audits internes du systme qualit Actions correctives Revues des contrats Spcifications des besoins de lacheteur Plan qualit Conception et ralisation Exigence ISO 9001 Responsabilit de la direction Systme qualit Audits qualit interne Actions correctives Revues de contrats Revue de contrats Matrise de la conception Systme qualit Matrise de la conception Matrise de la conception Matrise des processus Matrise du produit non conforme Tests et validation Matrise de la conception Contrles et essais Matrise des quipements de contrle, de mesure et dessai - Matrise du produit non conforme Rception Reproduction, livraison, et installation Contrles et essai Manutention stockage conditionnement et livraison Contrles et essais Matrise du produit non conforme - Manutention stockage conditionnement et livraison Gestion de configuration Matrise de la conception Matrise des documents Identification et traabilit du produit tats de contrles et dessais Matrise du produit non conforme. Matrise des documents Enregistrements relatifs la qualit Mesures Matrise des documents Enregistrements relatifs la qualit Techniques statistiques

74

Rgles, pratiques et conventions

Matrise des procds Matrise des quipements de contrle, de mesure et dessai

Outils et techniques

Matrise des procds Matrise des quipements de contrle, de mesure et dessai

Achats Logiciels inclus Formation

Achats Produit fourni par lacheteur Formation

75

Annexe 2 Correspondance entre les exigences de la norme ISO 9001 et les secteurs-cls du modle CMM Exigence ISO 9001 ISO 9001- .1 Responsabilit de la direction ISO 9001.2 Systme qualit CMM 2.2 Planification des projets CMM 2.5 Assurance de qualit du logiciel ISO 9001.3 Revue des contrats ISO 9001.4 Contrle de la conception CMM 2.1 Gestion des exigences CMM 2.4 Gestion des sous-contrats CMM 2.2 Planification des projets CMM 2.3 Suivi et surveillance des projets CMM 2.6 Gestion des configurations du logiciel CMM 3.4 Gestion intgre du logiciel CMM 3.5 Ingnierie des produits logiciels CMM 3.6 Coordination entre les groupes CMM 3.7 Revues par les pairs CMM 2.6 Gestion des configurations du logiciel CMM 2.4 Gestion des sous-contrats CMM 3.4 Gestion intgre du logiciel ISO 9001.7 Produits fournis par le client ISO 9001.8 Identification et traabilit des produits CMM 2.6 Gestion des configurations du logiciel CMM 3.5 Ingnierie des produits logiciels Secteurs-cls CMM CMM 2.2 Planification des projets CMM 2.3 Suivi et surveillance des projets CMM 2.5 Assurance de qualit du logiciel CMM 3.5 Ingnierie des produits logiciels

ISO 9001.5 Contrle des documents ISO 9001. 6 Achats

ISO 9001. 9 Contrle du processus

CMM 2.2 Planification des projets CMM 2.3 Suivi et surveillance des projets CMM 3.2 Dfinition du processus pour lorganisation CMM 3.5 Ingnierie des produits logiciels CMM 3.5 Ingnierie des produits logiciels CMM 3.7 Revues par les pairs 76

ISO 9001.10 Inspections et tests

CMM 3.7 Revues par les pairs CMM 3.5 Ingnierie des produits logiciels

ISO 9001.11 quipement dinspection, de CMM 5.2 Gestion des changements mesure et de test technologiques ISO 9001.12 Statut des inspections et tests ISO 9001.13 Contrle des produits nonconformes ISO 9001.14 Action correctrice CMM 2.6 Gestion des configurations du logiciel CMM 3.5 Ingnierie des produits logiciels

CMM 2.6 Gestion des configurations du logiciel

CMM 2.5 Assurance de qualit du logiciel CMM 2.6 Gestion des configurations du logiciel CMM 5.1 Prvention des dfectuosits CMM 2.6 Gestion des configurations du logiciel CMM 3.5 Ingnierie des produits logiciels

ISO 9001.15 Manipulation, entreposage, emballage et livraison ISO 9001.16 Documents de qualit ISO 9001.17 Audits internes de qualit

CMM 2.5 Assurance de qualit du logiciel ISO 9001.18 Formation ISO 9001.19 Service ISO 9001.20 Techniques statistiques CMM 3.3 Programme de formation CMM 3.5 Ingnierie des produits logiciels CMM 4.1 Gestion quantitative du processus

77