1.LA PROBLEMATIQUE DU

LOGICIEL

1 LA PROBLEMATIQUE DU LOGICIEL....................................................................1 1.1. GENIE LOGICIEL OU L'ART DE PRODUIRE DU LOGICIEL..............1 1.2. ASPECTS HISTORIQUES : EVOLUTION DE L'INFORMATIQUE .....3 1.3. LA CRISE DU LOGICIEL ..............................................................................5 1.4 LES REPONSES A LA CRISE: ......................................................................5

La matrise du processus de dveloppement ...................................................... 5 Dveloppement de mthodes structures et d'outils CASE ............................... 5 Le paradigme objet............................................................................................. 6 L'approche composants ...................................................................................... 7

1.5 LES MOTEURS DE LA QUALITE .....................................................................8 Objectifs8 Organiser le processus : cycle de vie, responsabilits, rles.............................. 8 Gestion des ressources : gestion de projet, gestion des configurations.............. 9 Mthodes, techniques et outils de production et de mesure ............................. 10

1.6 ASSURANCE QUALITE...............................................................................10 Dfinition ......................................................................................................... 10 Organisation ..................................................................................................... 10 Contrle 11 Communication ................................................................................................ 12

1.7 NORMES QUALITE............................................................................................13 La norme ISO 9001 .......................................................................................... 13 Le Capability Maturity Model.......................................................................... 17 Comparaison Iso9000 - CMM.......................................................................... 19 Le projet SPICE ............................................................................................... 20

1.8 REFERENCES................................................................................................20

Gnie logiciel Anne-Marie Hugues 19/12/02 1-1

1 LA PROBLEMATIQUE DU LOGICIEL

1.1. GENIE LOGICIEL OU L'ART DE PRODUIRE DU LOGICIEL La production de logiciel tout comme celle de n'importe quel autre bien ncessite la mise

en uvre de mthodes, techniques et outils dpassant largement le cadre de la seule programmation, regroups sous le vocable gnral de Gnie Logiciel.. Le terme est apparu pour la premire fois lors d'une confrence de l'OTAN Garmisch en 1969, a commenc se rpandre dans les annes 80, notamment avec l'arrive sur le march d'ateliers de gnie logiciel (AGL). Il faut attendre le milieu des annes 70 pour que le terme merge : la premire confrence sur le gnie logiciel a lieu en 1973 et la revue IEEE Transactions on Software Engineering existe depuis 1975.

Le Gnie Logiciel est rapprocher du Gnie civil, Gnie mcanique ou Gnie chimique. La ralisation d'un pont ne peut tre mene sans de mthodologie, de mme la ralisation d'un logiciel ncessite un minimum de prcautions qui garantissent sa faisabilit, sa qualit et sa fiabilit .

Nouveau systme ou systme modifi

Processus de production de logiciels

Nouveaux besoins

ou besoinschangs

composantsSystmeexistant

cahier des charges ou prototype

Gnie logiciel=

Mthodes, techniques, outils

Figure 1.0 : La production de logiciel sous contrle du gnie logiciel La programmation est une discipline rcente purement intellectuelle, certains la

qualifiaient mme d'art [Knuth, The art of software programming] ; pour ces raisons, on y trouve des attitudes et des habitudes qui paratraient tranges dans d'autres disciplines plus mures. Notamment le syndrome du "not invented here" ; on n'imagine pas un ingnieur mcanicien rinventer la roue ou fabriquer ses propres vis et boulons alors qu'un programmeur prfre souvent rcrire ses propres lignes de code plutt que rutiliser un code dvelopp par d'autres. La lutte contre cette tendance naturelle est un dfi majeur de l'industrie informatique d'aujourd'hui connu sous le vocable rutilisation.

L'aspect ludique de la discipline renforce la drive vers les comportements individualistes.

1-2 Anne-Marie Hugues 19/12/02 Gnie logiciel

La programmation est une activit immatrielle : pour un nophyte, il peut sembler peu dispendieux de dmolir et reconstruire une architecture logicielle alors que l'on rflchirait deux fois avant d'agir de mme concernant une autoroute ou un btiment.

Le logiciel modifie l'environnement de celui qui l'utilise dans des proportions telles que l'on a du mal dfinir prcisment et durablement des spcifications stables.

La maintenance occupe une part importante du budget et du temps consacr au dveloppement d'un logiciel. Elle peut revtir diffrentes formes :

maintenance corrective: destine corriger des "bugs" maintenance volutive: adaptative ou perfective

Il est important de prendre conscience des enjeux majeurs reprsents par la maintenance 67% du cot total est consacr la maintenance dont 48% consacrs rparer des dfauts 60% des dfauts correspondent des erreurs de spcification et de conception

D'un point de vue conomique, tout comme il convient de distinguer Chimie et Gnie

Chimique, il faut diffrencier programmation et gnie logiciel. En chimie si deux ractions diffrentes conduisent au mme produit on n'a aucune raison de prfrer l'une l'autre. Alors que le gnie chimique diffrenciera parmi ces deux ractions celle qui met en jeu les produits de base les moins chers par exemple. De mme le Gnie Logiciel tiendra compte en particulier des cots de formation et des implications long terme lors de l'introduction de nouvelles techniques de programmation. Au dbut des annes 80 deux livres marquent la prise de conscience de la ncessit de rationaliser les dveloppements informatiques et de les inscrire dans un contexte conomique gnral.

B. Boehm dans Software Economics partir d'une analyse des donnes mene sur les projets informatiques de la firme TRW, dfinit une mthode de rgression permettant d'valuer le cot d'un projet logiciel (COCOMO)1 en se basant sur le nombre de lignes de code source estimes. C'est une des premires dmarches en faveur de la mesure d'effort. La mthode a t mise jour en 2000 pour tenir compte de l'aspect rutilisation dans les projets logiciels.

Frdric BROOKS, dans "The Mythical Man Month"2 analyse les principaux checs du dveloppement de l'OS/360. Malgr le succs relatif du projet, on constate:

- la prsence de nombreuses erreurs rsiduelles dans les premires versions, - un retard important dans la livraison du produit - que la place mmoire occupe est plus importante que prvu, - que le cot rel est plusieurs fois celui estim initialement.

Ce livre vient d'tre rdit sans grands changementsNous en retenons les diffrences essentielles entre un programme3 et un produit logiciel intgr dans un systme. Un produit peut tre utilis, test, maintenu, tendu, gnralis par une autre personne que le programmeur initial. Un produit doit tre suffisamment test, document. Cot estim par Brooks pour dvelopper un produit: Cot du programme x 3

On s'intresse ensuite la diffrence entre un programme et un programme intgr dans un systme, il s'agit d'une collection de plusieurs programmes qui interagissent. Il en rsulte un besoin de coordination, la ncessit d'tablir des interfaces, de grer la consommation des ressources, une plus grande difficult organiser les tests. Le cot estim par Brooks est alors suprieur ou gal au Cot du programme x 3 .D'o le cot estim pour un produit logiciel intgr: Cot du programme x 9

1 Cf chapitre 3 2 L'unit de calcul de la taille d'un projet est l'homme x mois (man month) 3 typiquement un programme fabriqu par un tudiant lors d'une sance de travaux pratiques

Gnie logiciel Anne-Marie Hugues 19/12/02 2-3

PROGRAMME

PROGRAMMEINTEGREDANS UN SYSTEME(Interfaces, Intgration, ...)

PRODUITLOGICIEL

(Gnralisation, Tests,

Documentation, Maintenance)

PRODUITLOGICIEL

INTEGREDANS UN SYSTEME

Figure 1.1 : Comparaison Produit/Programme (d'aprs F Brooks) Dans son livre, Frdric Brooks met galement en garde contre l'effet deuxime systme.

Le dveloppement de la deuxime version d'un produit ne prend pas forcment beaucoup moins de temps que la premire; il faut apprendre se mfier de l'"Optimisme" des ingnieurs logiciels. L'exemple cit est celui de la release 1.0 d' OS/360. Dans la premire version un temps considrable a t pass automatiser la cration d'overlays par l'diteur de liens alors que dans la version suivante, l'introduction de la pagination rendait les overlays inutiles...Aujourd'hui les avances technologiques de plus en plus rapides font de l'obsolescence du savoir un lment critique de la gestion de projet informatiques.

Cette rapidit d'volution des technologies explique que la crise du logiciel dcouverte dans les annes 80 ne soit qu'imparfaitement vaincue aujourd'hui: ds qu'un remde est trouv, l'volution de la technique le rend partiellement obsolte.

1.2. ASPECTS HISTORIQUES : EVOLUTION DE L'INFORMATIQUE L'informatique est une discipline jeune, l'industrie informatique s'est organise en 20 ans l

o d'autres industries ont mis plus d'un sicle La programmation apparue dans les annes 45-58 tait alors le domaine rserv de

quelques ingnieurs mathmaticiens qui programmaient en assembleur des programmes de calcul scientifique sur mesure, distribution limite sur des machines volumineuses de puissance infrieure celle d'une calculette actuelle; machines exprimentales d'abord ( ENIAC, EDVAC ) puis commerciales SEA CAB500, BULL GAMMA3, UNIVAC, IBM 701.

Dans les annes 58-75 l'informatique se dveloppe considrablement la fois ct scientifique (langages FORTRAN) et dans le domaine de la gestion (langage COBOL). Les premiers systmes d'exploitation Multi-Utilisateurs apparaissent (IBM 360, Vax VMS, Bull Gecos) systmes propritaires qui lient l'utilisateur au constructeur. Les programmes peuvent tre activs en batch (l'un la suite de l'autre) sur des architectures centralises, les premiers systmes temps rel font leur apparition en informatique industrielle. Dans les entreprises, on assiste une main mise de la Direction Informatique sur l'ensemble de l'entreprise. Les investissements matriels psent trs lourd cette poque, beaucoup plus que le temps pass dvelopper les programmes. Nombre de programmes dvelopps cette poque ont t concerns par le fameux bug du passage l'an 2000.Parmi les entreprises les plus avances (DOD, NASA, constructeurs informatiques..) certaines peroivent la crise du logiciel qui va se faire jour (1969).

1-4 Anne-Marie Hugues 19/12/02 Gnie logiciel

Pendant les annes 75-90, l'innovation apporte par les bases de donnes relationnelles concomitante au dferlement de la micro informatique et l'avnement des rseaux, a sorti les Directions Informatiques de leur tour d'ivoire, en mettant l'informatique la porte des utilisateurs. On prend progressivement conscience de la ncessit de matriser le dveloppement de logiciels alors que le prix du hardware diminue et que le cot de l'informatique doit prendre en compte non seulement les cots de dveloppement mais aussi les cots de maintenance (corrective et volutive). Le systme ouvert Unix a libr les informaticiens du joug des constructeurs, dsormais tout systme vise l'htrognit et la portabilit, l'informatique embarque temps rel envahit peu peu le quotidien (transactions bancaires, rservations, lectromnager, vhicules). On passe des systmes centraliss aux systmes distribus. L'industrie du logiciel se complique vite alors qu'elle n'en est qu' ses balbutiements. Avec la prise de conscience de la crise du logiciel et de l'importance stratgique des systmes d'information, la Direction Informatique cde progressivement la place une Direction de l'Informatique et de l'Organisation (dbut des annes 80) dans les grandes entreprises. On constate l'avnement de nombreux consultants en organisation.

1945

Logicielssur mesurecalculscientifique

AssembleurENIAC

1958 1990

FORTRANCOBOLmulti-utilisateurssystmes propritairessystmes de fichiersbatch, temps rel

Logicielsscientifiqueset de gestion Micro informatique

pucessystmes distribusclient-serveurBases de donnesUnixpuces

Logiciels scientifiquesTemps rel,progiciels ERPembarqus,

2000

Rseaux,InternetIntranet3 tiersserveursd applications

1970

Informatique partoutfiabilitscuritaide la dcisione-business

crise

Figure 1.2 : 50 ans d'informatique Durant les annes 90 l'omniprsence d'Internet ou d'Intranet dans les applications oblige

reconsidrer les architectures client-serveur tablies quelques annes plus tt au profit d'architectures 3 tiers prenant en compte des serveurs d'applications et non plus seulement des serveurs de donnes.

Au niveau des applications, les exigences s'accroissent : l'informatique de gestion se dote de progiciels de gestion ERP (Enterprise Resource Planning, cf SAP/R3) qui intgrent les oprations les plus courantes et offrent leurs clients des produits standardiss 80% et facilement (!?) paramtrables pour les 20% restant. Les outils d'aide la dcision (datawarehouse, data mining) font leur apparition. En matire de commerce lectronique (e-commerce) les contraintes de scurit et de fiabilit sont pratiquement aussi fortes qu'en informatique temps rel (logiciels embarqus dans satellites, logiciels de contrle de centrale nuclaires.) alors que les budgets consacrs et les temps de dveloppement se veulent radicalement infrieurs

En conclusion le logiciel est aujourd'hui prsent partout, sa taille et sa complexit augmentent de faon exponentielle, les exigences de qualit sont de plus en plus svres la

Gnie logiciel Anne-Marie Hugues 19/12/02 2-5

crise du logiciel apparue dans les annes 70 n'est toujours pas franchement rsolue mme si de grands progrs ont t raliss dans de nombreux domaines

1.3. LA CRISE DU LOGICIEL Mise en vidence au dbut des annes 70, la crise se caractrise par l'absence de matrise des projets, au niveau des cots et des dlais, la mauvaise qualit des produits: les produits ne rpondent pas aux besoins dfinis et des

erreurs rsiduelles persistent dans le produit final un stock important de projets en attente faute d'une gestion rigoureuse Quelques exemples de logiciels dfaillants: La facture de 0F(juste pour rire) La fausse attaque de missiles (Novembre 1979) Les anti-missiles Patriotes (Guerre du Golfe 1991) Les sondes perdues vers Vnus( annes 60) vers Mars (99) La panne ATT (1990) Lchec dAriane 5 (1996) La poste (1998) Et les erreurs que l'on ignore : logiciels de surveillance mdicale dfaillants .et l an 2000 (qui a fait dpenser des millions de $ pour des logiciels dvelopps pour la

plupart en pleine crise du logiciel) qui a finalement t bien absorbe sans provoquer trop de dfaillances.

1.4 LES REPONSES A LA CRISE:

La matrise du processus de dveloppement Pour matriser le dveloppement, une organisation doit choisir et appliquer un modle de

processus dfinissant: - Les phases du dveloppement: dfinitions des besoins, spcifications,

planification, conception, codage, tests... - Les produits intermdiaires: prototype, documentations... - Les critres de changement de phase, - Un cadre pour la gestion de projet.

L'accent est mis sur les phases amont : analyse, conception et non plus seulement sur la programmation.

Nous tudions diffrents modles de cycle de vie au chapitre 2.

Dveloppement de mthodes structures et d'outils CASE Dans les annes 75-90 les mthodes structures se dveloppent (SA/RT, SADT, Ward et

Mellor, modle entits-relations...) ainsi que les mtriques et outils permettant de les mettre en uvre. (ateliers de Gnie Logiciel ou outils CASE Computer.Aided.Software.Engineering). A cette poque, au sein des directions informatiques (et de l'organisation), de nouveaux services apparaissent : "mthodes et qualit", chargs de dfinir les bonnes pratiques en matire de dveloppement logiciel, de choisir les bons outils CASE. Le langage ADA (83) dvelopp la demande du DOD (Department of Defense amricain) est le fer de lance de cette rationalisation qui passe par un dveloppement systmatique et contrl par le

1-6 Anne-Marie Hugues 19/12/02 Gnie logiciel

compilateur, ce langage est le premier mettre l'ordre du jour la rutilisation systmatique d'lments de bibliothques ("packages") fournis avec le compilateur.

De grands programmes de recherche sont lancs : Europe: ESPRIT, ALVEY, Software Factory Etats-Unis: ADA, STARS, SDI, Japon: 5ime Gnration (ICOT)

Le paradigme objet Dans les annes 90 la crise n'est toujours pas rsolue. Si les mthodes structures

s'avraient efficaces pour traiter des programmes de 5000 50000 lignes, elles ne le sont plus pour des produits de 500.000 voire 5.000.000 lignes.

Or les dveloppements sont de plus en plus complexes, de plus en plus longs et l'obsolescence est de plus en plus rapide! Il y a donc une ncessit rutiliser les connaissances et les partager.

Dans le domaine de la maintenance galement, les mthodes structures n'ont pas fait leurs preuves. Le problme vient du fait que les mthodes structures sont soit orientes donnes soit orientes actions et que la modification d'un lment du logiciel impacte d'autres lments de manire relativement imprvisible.

Un nouveau paradigme voit le jour en 80 (Smalltalk) et devient trs populaire dans les annes 90, c'est le paradigme objets qui encapsule actions et donnes. Ceci facilite la maintenance car la localisation de l'erreur se fait plus facilement. L'objet masque la structure interne des donnes qui sont accdes uniquement travers des messages. Chaque objet est autonome. En outre la dfinition de l'hritage et de la gnricit permet la rutilisation d'objets dj dvelopps dans un autre contexte.

dpt retrait

solde

solde

retraitdpot

compte compte

message

message message

Approche structure Approche objets Figure 1. 3 : Introduction l'approche objets Les annes 90 ont ainsi vu l'avnement de nombreuses techniques visant rationaliser le

processus de dveloppement : approche objets, normalisation des interfaces et des langages, dfinition d'ORB (Object Request Broker) facilitant l'change entre les diffrents objets composant un logiciel.

Un crmage au niveau des AGL s'est opr. Des outils d'aide la programmation rapide (?) utilisant des langages de 4me gnration permettent des non informaticiens de dfinir rapidement leurs propres applications. La rutilisation systmatique de biens logiciels oblige l'entreprise revoir son processus de dveloppement logiciel et vraisemblablement se

Gnie logiciel Anne-Marie Hugues 19/12/02 2-7

rorganiser. Les environnements de programmation autour des langages objets Java ou C++ facilitent la rutilisation de bibliothques de classes prdfinies

1970

la crise:cotsdlaisqualit

Modles decycles dedveloppement

1980 1990

Micro informatiqueBases de donnesTemps rel, systmesembarqus

Politique qualit,mthodes structuresoutils GL :environnements CASElangages (ADA)

Rseaux,client/serveurhtrognitAide la dcisiondatawarehouse

Paradigme objetsoutils GL:langages C++, JavaORB (CORBA)

2000

ApprochecomposantsJava beansActive Xserveursd applications

Rseaux,Internet3 tierse-businessRutilisation

Figure 1.4 : 30 ans davances technologiques et mthodologiques

L'approche composants Les annes 2000 seront places sous le signe de la programmation base de composants

rutilisables. Cette approche peut tre vue comme une forme ultime de la programmation par objets, ou plus simplement comme un assemblage de briques logicielles prdfinies, orients techniques ou mtiers, et conues dans le but d'tre rutilises (ce qui n'est pas forcment le cas d'objets dfinis dans un contexte particulier et rutiliss par hasard). Cette dmarche s'appuie sur les technologies Java Beans, active Xmais ncessite une rorganisation du processus de dveloppement logiciel.

En conclusion, on peut dire que si la crise du logiciel est aujourd'hui rsorbe parce que

mieux connue, elle est loin d'tre termine mme si les services mthodes et qualit ont disparu de la plupart des entreprises et que la direction de l'organisation n'est souvent plus qu'un vieux souvenir dans les organigrammes. C'est que les avances rapides de la technologie rendent possibles des applications jusqu'alors inenvisageables et obligent sans cesse reconsidrer les vrits que l'ont croyait acquises.

L'informatique est aujourd'hui une industrie mure pour laquelle des lments d'assurance

qualit peuvent tre mis en place et qui diffrent selon le type de produit fabriquer et le contexte dans lequel le produit sera utilis : les contraintes seront diffrentes selon que l'on fabrique un logiciel amateur ou un logiciel professionnel, selon que le logiciel est stratgique pour une entreprise ou vital pour une population.

1-8 Anne-Marie Hugues 19/12/02 Gnie logiciel

1.5 LES MOTEURS DE LA QUALITE

Objectifs Les objectifs de qualit rejoignent bien souvent les objectifs de productivit - Adquation aux besoins Efficacit temps/espace Fiabilit Scurit, Intgrit Testabilit, Traabilit Adaptabilit, Maintenabilit, Convivialit (interface, aide et documentation) Prennit (facilit de la maintenance) L'assurance qualit vise atteindre les objectifs de qualit, rduire le nombre d'erreurs

rsiduelles , matriser les cots et la dure du dveloppement sans nuire linnovation et la crativit.

Les moteurs de l'assurance qualit sont multiples : on peut citer L'organisation du processus : dcouper le processus pour le matriser Les ressources humaines : les quipes doivent tre motives pour mettre en place des

procdures qualit L'utilisation de techniques, mthodes, outils Les considrations managriales, politiques et conomiques : considrer le retour sur

investissement de la mise en place de procdures qualit par une analyse cots bnfices.

Nous revenons sur chacun de ces aspects dans les chapitres concerns.

Organiser le processus : cycle de vie, responsabilits, rles Comme tout produit, un logiciel a un cycle de vie, il nat, vit et meurt ; autrement dit, il est

cr, distribu sur un march ou bien mis en exploitation et disparat pour cause d'obsolescence. La phase de maintenance volutive a pour objectif de retarder la phase de disparition.

Le cycle de dveloppement des logiciels s'insre dans le cycle de vie global du produit, on l'appelle souvent abusivement cycle de vie des logiciels.

Figure 1.5 Cycle de vie d'un produit

La matrise du processus de dveloppement passe par un dcoupage en activits - Squentielles (verticales) : Spcifications, Conception, - Permanentes (horizontales) : Gestion de projet, Gestion des configurations Chaque activit sera valide avant de passer la suivante. Chaque projet est dcoup en lments matrisables. Par exemple au niveau de la

conception globale on essaiera de dcomposer en modules aussi indpendants que possible, ce qui facilitera le codage , l'intgration et la maintenance.

Retardement de la disparition par la maintenance volutive

Gnie logiciel Anne-Marie Hugues 19/12/02 2-9

Ce dcoupage est garant d'efficacit et de motivation des quipes : il est plus facile de respecter un objectif court terme qu' moyen ou long terme

Chaque activit lmentaire, chaque phase est place sous la responsabilit d'un acteur, les recommandations pour l'assurance qualit insistent toutes sur la notion rle, il faut dfinir

- Qui fait, - Qui approuve, - Qui vrifie, - Qui valide, - Qui est consult.

L'enchanement des activits est dfini l'avance selon l'un des modles de processus qui sera vu au chapitre 2.

processus

tches

Productionsintermdiaires

outils

mthodes

quipiersEstresponsable

Figure 1.6 : Organiser le processus

Gestion des ressources : gestion de projet, gestion des configurations Comme tout projet industriel, un projet logiciel ncessite une gestion stricte des ressources

tant humaines que matrielles et logicielles. Cette activit est transversale au projet et met en uvre des techniques communes tout type de projet ainsi que d'autres plus spcifiques que nous tudierons au chapitre 3. Il s'agit ici de

savoir valuer cots et dlais dfinir et ordonnancer les tches, planifier la ralisation, l'intgration, la

validation tablir un systme de contrle pour tous les produits intermdiaires du cycle de

vie, dans le but de dtecter le plus tt possible: dfauts, erreurs, omissions, ambiguts, incohrences, hypothses incorrectes, .

organiser la formation sur les mthodes, les outils , les nouvelles technologies motiver les quipes, anticiper les problmes, ne pas brider la crativit, dtecter la

rsistance au changement La gestion de configurations est spcifique aux projets logiciels. Les produits logiciels

sont constitus de diffrents lments qui voluent au cours du temps et qui peuvent diffrer d'une installation l'autre. La gestion des configurations est activit transversale essentielle qui consiste

1-10 Anne-Marie Hugues 19/12/02 Gnie logiciel

contrler l'ensemble des donnes constituant le systme: documents sources jeux de tests plans d'intgration.

assurer la cohrence des divers composants construire/reconstruire un systme

pendant tout le cycle de vie (dveloppement et maintenance). De nombreux outils existent qui facilitent cette tche, sous Unix la conjonction de

make/rcs permet de grer les versions et la reconstruction du systme.

Mthodes, techniques et outils de production et de mesure L'analyse, la conception, le dveloppement et le test du produit constituent le cur de la

production logicielle. Depuis les annes 80, de gros efforts ont t faits sur les outils permettant de rationaliser et/ou automatiser ces tches.

Dans la suite du cours on insistera particulirement sur - les mthodes de spcification et de conception qu'elles soient structures ou

orientes objets - les mthodes de validation et vrification - l'outillage : le poste de travail de l'ingnieur logiciel les ateliers de gnie logiciel incluant outils d'analyse, gnrateur de code,

environnement de dveloppement et de mise au point , outils de tests, outils de mesures de performances

L'amlioration d'un processus passe par sa connaissance prcise, il est ncessaire d'organiser des collectes de donnes pour mesurer:

- Cots, - Dlais, - Qualit.(taille, temps, complexit)

Actuellement de nombreux outils sont disponibles sur le march pour aider ces mesures (outils de planification, outils d'analyse statique de code)

1.6 ASSURANCE QUALITE

Dfinition Assurance qualit : "Mise en uvre d'un ensemble appropri de dispositions prtablies et

systmatiques destines donner confiance en l'obtention de la qualit requise." (AFNOR) Plus prcisment toutes les normes qualit insistent sur trois aspects essentiels :

communication, contrle, organisation.

Organisation Le processus de dveloppement est classiquement organis en diffrentes phases

conformment la figure 1.7

Gnie logiciel Anne-Marie Hugues 19/12/02 2-11

SpcifierSupporter

Distribuer

Qualifier

validerDvelopper

Dfinir les besoins

planifier

concevoir

Figure 1.7 : Les phases du cycle de vie d'un produit logiciel Une tche essentielle du chef de projet est d'organiser ces diffrentes phases et de les lier

des activits en y affectant les ressources ncessaires tant humaines que logicielles ou matrielles. L'enchanement des activits constituera le workflow du projet.. Chaque activit dbouche sur un produit intermdiaire dont la production dtermine la fin de l'activit et qui devra tre contrl avant de passer l'activit suivante.

Contrle L'assurance qualit passe par des contrles rguliers et inclut - la validation(du latin "VALIDARE", dclarer valide) permet de rpondre la question

"sommes nous en train de faire le bon produit? " - la vrification(du latin "VERITAS ", la vrit): rpond la question "est ce que nous

faisons le produit correctement" Comme le montre la figure 1.8 les erreurs sont de plus en plus coteuses rparer

lorsqu'elles sont dcouvertes tard dans le cycle de vie: d'o le rle primordial de contrles intermdiaires. La validation et la vrification sont en partie garanties par la mise en place des d'inspections, revues, relectures pour tous les produits intermdiaires du dveloppement (prototypes/ maquettes, documents de spcification, de conception, code, jeux de tests)

1-12 Anne-Marie Hugues 19/12/02 Gnie logiciel

400

300

200

100

0besoins

specificationplanification

conceptioncodage

intgrationmaintenance

Projets 74-80

IBM AS /400 (94)

Figure 1.8 cot relatif de correction des erreurs en fonction de leur dcouverte, source IBM L'inspection est une lecture critique d'un document (spcification, conception, code, plan

d'intgration...); elle est destine amliorer la qualit d'un document. De manire gnrale, l'inspection est faite par une quipe indpendante du projet

constitue par: un Modrateur, un Experts(s), Secrtaire , le client, ventuellement un banquier, un reprsentant du service qualit...

Pour qu'elle puisse tre profitable, une inspection doit donner lieu la rdaction de fiches de dfauts avec une chelle de gravit et la dfinition des responsabilits concernant la correction des dfauts.

Les inspections sont la base des dcisions prises en revues. Une revue est une runion permettant de valider une des phases du cycle de vie.

On distingue - les revues produits: tat d'un projet sous ses diffrents aspects: Techniques, Financiers,

Commerciaux, Calendrier, ... - les revues techniques (celles qui nous intressent le plus dans le cadre de ce cours): elles

permettent de fournir au marketing et l'unit de dveloppement une valuation des aspects techniques du projet et des cots de ralisation

- les runions de dcision: elles valident le passage la phase suivante et font bien souvent suite l'une des deux prcdentes.

Exemple d'aprs Boehm Un logiciel de rservation arienne (Univac-United Airlines) d'un cot de 56 millions de

dollars a t jug inutilisable par manque d'analyse des besoins et d'tude de faisabilit: - 146 000 instructions par transaction, - au lieu de 9 000 prvues.

Ceci aurait pu tre vit par des inspections et des revues intermdiaires et l'analyse d'un prototype

Communication Mme si l'assurance qualit ne doit pas tre confondue avec une production intensive et

bureaucratique de documentation, elle insiste sur la ncessit de communiquer diffrents niveaux:

Gnie logiciel Anne-Marie Hugues 19/12/02 2-13

- entre dveloppeurs et environnement, (clients avant le dveloppement, support pendant la phase de maintenance) : cahier des charges, dossier d'analyse, manuel d'installation, dossier de conception, plan projet , plan qualit

- entre les dveloppeurs. (dossier d'analyse, dossier de conception, plan qualit, commentaires du code, rsultats de tests)

Certains documents sont plus spcifiquement ddis la gestion de la qualit, il s'agit du manuel qualit de l'entreprise et du plan qualit du projet.

Manuel qualit Le manuel qualit dcrit les procdures dfinies par une entreprise ou une organisation

pour atteindre ses objectifs de qualit. Il rpertorie les mthodes et procdures utiliser pour: - Gestion de projets - Ralisation, Vrification, Validation, - Evaluation de la Qualit (Mesures). en s'appuyant sur: - Rdaction de standards, normes (ISO, DOD..) , conventions, guides, - Exprience acquise des projets, pour amliorer le processus.

Plan qualit Le plan qualit logiciel dfinit, pour un projet donn, en accord avec le manuel qualit

de l'entreprise, les mthodes techniques et outils permettant d'atteindre les objectifs de qualit pour un cot donn. Le plan qualit fait partie des lments contractuels liant un client et son fournisseur de logiciels. Il est tabli lors de la phase de planification.

Des exemples de plan qualit sont fournis au chapitre 3.

1.7 NORMES QUALITE Les procdures qualit s'appuient sur la rdaction de normes et de standards, on citera

particulirement : la norme DOD 2167 A pour les applications militaires , la norme ISO 9001 (ISO 9000-3 ) pour les applications civiles adopte par 60 pays

(USA, Europe, Japon...). C'est aujourd'hui un passage quasi oblig pour une SSII d'tre estampille ISO 9001 pour pouvoir rpondre un appel d'offres. Il est noter que la certification est payante et valable 3 ans. La norme ISO 9000 devrait tre remplace en 2001.

La grille CMM nest pas une norme, elle peut toutefois servir de rfrence pour une exigence de qualit.

La norme ISO 9001 ISO : International Standardization Organization ISO 9000 ensemble de recommandations et standards pour la garantie de

la qualit dans les relations clients-fournisseurs (pas spcialement logiciel)

ISO 9000-1 recommandations pour lutilisation de ces standards ISO 9001 : le standard utiliser pour la fourniture de logiciels, la rfrence

en matire de certification pour le logiciel ISO 9003 : guide pour lutilisation des standards ISO 9001 pour la

fourniture de logiciels

1-14 Anne-Marie Hugues 19/12/02 Gnie logiciel

Philosophie ISO 9001 : Toute opration influenant la qualit doit tre sous contrle. Le contrle doit tre visible Le chapitre 4 de la norme dfinit les 20 lments de qualit respecter Responsabilits du management Dfinition dun systme de qualit Analyse du contrat entre client et fournisseur Contrle de la conception Documentation et contrle des donnes Spcification des achats et fournitures Contrle des produits fournis par le client Identification des produits et traabilit Contrle du processus Ncessit de mettre en uvre des tests et inspections Contrle des inspections et tests, mesures des outils de tests Statut des tests et inspections Contrle des produits non conformes Actions correctives et prventives Emballage, stockage, livraison, Contrle des enregistrements concernant la qualit Audit qualit internes Organiser la formation Service aprs vente Techniques statistiques

On voit bien sur cette liste que ISO 9001 ne vise pas spcialement la fourniture de logiciels et doit tre adapte dans le cadre dune assurance qualit en logiciel .

Recommandations ISO 90003 pour la fourniture de logiciels :

Il s'agit d'un guide de recommandations quivalent un standard (lors de toute certification, il faudra justifier tout manquement ces recommandations).

Dfinir le cadre de lassurance qualit

Responsabilits du management Les responsabilits du management recouvrent : la dfinition dune politique qualit, la mise en place dune organisation et la validation priodique du systme qualit.

Dfinition dun systme qualit La politique qualit doit tre documente dans un manuel qualit conforme aux normes en vigueur et aux habitudes de lentreprise. Il est important que les procdures qualit mises en place trouvent lagrment des dveloppeurs et ne soient pas perues comme un frein leur crativit mais plutt comme un cadre rassurant dans lequel ils pourront voluer et produire un travail de qualit.

Evaluation du contrat Il est tout fait indispensable de ne pas sengager sur un contrat irraliste.

Contrler le dveloppement Ce paragraphe vise encourager le fournisseur documenter et contrler le processus de dveloppement.

Gnie logiciel Anne-Marie Hugues 19/12/02 2-15

Planification du dveloppement et de la qualit Dfinition du calendrier, des diffrentes phases du projet, des critres qualit

Organisation du travail En particulier organisation des espaces de travail

Contrle des Spcifications (Design input) ISO 9000 requiert des spcifications rigoureuses et compltes. En logiciel tout le monde

sait que ceci est en gnral un vu pieux. Un autre paragraphe des recommandations prvoit donc les procdures de prise en compte de changements dans les spcifications. Afin de dfinir ces spcifications, des outils peuvent tre utiliss (en particulier tous les outils daide lanalyse tels que AMC Designor , Rational Rose

Sortie de la conception (Design output) La conception peut tre ralise la main, elle peut galement tre gnre plus ou

moins automatiquement. Dans tous les cas, la phase de conception doit produire une architecture logicielle et de la documentation

Contrle de la Conception (Design review), Dans tous les cas la conception ncessite un contrle rigoureux par des inspections qui

peuvent tre ralises au moyen de listes de dfauts typiques. Pour moi ces trois subtilits des recommandations sont redondantes entre elles et je les ai runies dans un mme paragraphe.

Validation vrification ( Design verification, Design validation) Il sagit ici des procdures de validation/ vrification du code . Elles sont classiquement

ralises base danalyse statique, de tests fonctionnels et de tests structurels. Le Bta test pris en charge par le client doit explicitement figurer dans le contrat si une telle dcision de qualification est adopte. Il est tout fait fondamental dtre capable de rendre compte des rsultats des tests et des jeux de tests qui ont t effectus. Les critres darrt doivent tre dfinis dans un plan de tests, on doit pouvoir prouver quon les a atteints.

Modification de la conception et des spcifications Il faut vrifier la cohrence des changements demands avec le dveloppement dj

ralis. ISO9000 requiert une procdure rigoureuse dacceptation des modifications

Grer les activits de support

Gestion des configurations : Dj vu .

Gestion de la documentation et des donnes Le standard demande que quiconque a besoin des documents puisse y accder. Le

standard demande que tout document soit approuv et que les versions des documents soient cohrentes entre elles et cohrentes avec le code quelles documente.

Contrle des Achats, de la sous-traitance, et des fournitures procures par le client

Les recommandations de la norme dans ces domaines tout fait fondamentaux ne concernent pas vraiment ce cours.

Traabilit

Cette rubrique concerne le suivi tout au long du cycle de dveloppement des liens qui peuvent exister entre cahier des charges et spcifications, spcifications et conception, conception et codage.

1-16 Anne-Marie Hugues 19/12/02 Gnie logiciel

La norme impose de savoir rpondre aux questions suivantes De quel document initial cette spcification sinspire-t-elle ? A quelle spcification, quel document de conception ce bout de code est il reli ? Quelles sont les corrections ou amliorations qui ont t ralises dans tel module ? A partir de quel code source cet excutable a-t-il t gnr

A partir de quel outil cet excutable a-t-il t gnr ? Quest il advenu de chaque rapport dincident ? A t il t pris en compte, corrig ? la nouvelle version a-t-elle t distribue ?

Cest souvent cause de ce chapitre que les imptrants la certification se font rejeter. Voici quelques exemples

La mauvaise version dun fichier source a t catalogue Un erreur est rpertorie comme rpare et ne lest pas Un manager ou un chef de projet a t incapable de montrer quelles versions des

sources taient utilises au moment des tests Incapacit de montrer les diffrentes demandes de modifications ou rapports

dincidents Contrle de production (process control)

Il sagit ici du contrle de la production des disquettes, CD ou tout autre media sur lequel le produit final sera livr. Le contrle de production du dveloppement a t vu prcdemment.

A vrifier galement que la bonne version soit livre en ce qui concerne les bibliothques, jeux de tests, documentation Inspection et tests

L encore il sagit dinspecter le matriel livr (disquettes .. ), la validation du code ayant t vue prcdemment. Contrle des quipements de tests

Peu applicable en informatique. On peut par exemple tester les horloges pour les programmes temps rel

Statut des Inspections et tests ( Inspection and tests status) On doit pouvoir tout moment savoir si un document, un code sourcea t inspect,

valid ou est en attente de validation. En aucun cas un document non valid ne doit servir de base de nouveaux

dveloppements. Les documents inspects et valids doivent tre conservs dans un espace diffrent de ceux qui ne le sont pas.

Contrle des produits non conformes Les produits non conformes doivent tre identifis. On doit pouvoir fournir une

procdure qui permet de corriger rapidement les erreurs et de valider les modules ainsi corrigs.

Actions correctives et prventives La norme est assez floue ce propos car elle ne prvoyait pas lamlioration des

produits ; alors quen informatique les produits voluent dans le temps . Le paragraphe 4.14 donne quelques indications qui de mon point de vue sont redondantes avec les notions de traabilit vues prcdemment

Sassurer quil existe une procdure de report des erreurs, sassurer que toute erreur reporte est un jour corrige, pouvoir rpondre sans hsiter la question telle erreur a t elle t corrige. Stockage, livraison, emballage

Une fois les produits dvelopps, il faut les stocker, les emballer et les acheminer vers le client, cette tape a peu de rapports avec le cours mais doit tre envisage avec attention ( par exemple tiqueter les CD rom peut prendre un certain temps )

Gnie logiciel Anne-Marie Hugues 19/12/02 2-17

Contrle des enregistrements qualit On veillera garder trace de tous les enregistrements qualit effectus en interne

(inspection, tests..) et chez les clients (mesures statistiques en particulier, erreurs reportes et le sort qui leur a t rserv)

Audit qualit interne

Il sagit de vrifier que les plans qualit sont respects dans lentreprise de manire gnrale. On pourra le prouver si on a fait une procdure srieuse de collecte de donnes. Il faut pouvoir produire une procdure daudit lors de la certification ou de son renouvellement. Formation

La norme encourage la formation programme tous les niveaux: - Nouvelles techniques, nouveaux langages - Formation aux mthodes qualit - Formation aux mthodes de gestion de projet

Service aprs vente Prvoir un contrat de maintenance. On a dj abord le fond du problme prcdemment. Les critiques qui sont mises en gnral par rapport ce paragraphe :

- Pas de contrat de maintenance - Mthode de maintenance spcifiques pour un vieux produit non documente - Pas de procdures de maintenance - Rien de prvu pour tester aprs une activit de maintenance (en gnral on peut au

moins repasser et mettre jour les tests de non rgression)

Mthodes statistiques Dans une industrie de production il est important de pouvoir prlever des chantillons au

hasard et de les tester. En logiciel rien de commun. Les tests statistiques consistent faire des mesures a posteriori en phase dexploitation:

- Nombre de pannes - Nombre derreurs dcouvertes (par le client, par le fournisseur) - Temps moyen entre deux pannes - Dure moyenne dindisponibilit .

Le Capability Maturity Model La grille de maturit du Software Engeering Institute de Carnegie mellon University (SEI)

aujourdhui appele Capability Maturity Model4 est certainement une rivale de la norme ISO 9000 (ou plus exactement des recommandations ISO 9000-3) en matire de qualit de dveloppement de produits logiciels.

Dvelopp ds les annes 70 pour le compte du DOD qui souhaitait valuer ses sous traitants, ce modle a t largement adopt dans le civil. Le SEI est encore aujourdhui largement soutenu par le DOD.

Le principal intrt que ses promoteurs et ses adeptes voient au modle CMM est son laboration en vue dune utilisation dans un contexte de dveloppement logiciel et non pas, comme cest le cas pour ISO 9000, une adaptation dune norme multi-domaines au cas particulier du gnie logiciel.

4 Le CMM a t introduit en 1986, il s'appelait alors Process maturity model. Aujourdhui un autre modle voit le jour : le Personnal Software Process qui permet chaque ingnieur de

samliorer personnellement contrastant en cela avec le CMM qui vise lui lamlioration globale de lorganisation. Des rsultats rcents prouvent que lutilisation du PSP contribue lamlioration de la qualit et de la productivit globale.

1-18 Anne-Marie Hugues 19/12/02 Gnie logiciel

Par ailleurs, le CMM permet ses utilisateurs de se positionner dans une grille sur laquelle ils pourront voluer et progresser, ce qui nest pas prvu dans la norme ISO 9000.

Toutefois tant donne la popularisation de la norme ISO 9000 en Europe et dans le

Monde, il est indniable quune certification ISO 9000 permet de remporter un certain nombre de marchs et cet aspect ne doit pas tre nglig. Nous verrons quil peut ventuellement en tre de mme avec CMM. Philosophie CMM :

La grille CMM permet de classifier une organisation (SSII ou service informatique dune entreprise) qui dveloppe du logiciel selon sa comptence.

Cette grille identifie 5 niveaux de maturit (do son nom) pour ces organisations 1 niveau initial : le logiciel est dvelopp sans mthode prdfinie. Le

dveloppement repose sur la comptence de quelques personnes, il est impossible de rcuprer lexprience acquise dans un projet lors du dveloppement dun autre projet, on ne peut prdire en terme de gestion de projet des lments aussi importants que la taille ou le cot dun projet. Les ractions se font essentiellement en fonction des crises et non pas de faon systmatique et planifie.

Beaucoup dorganisations sont malheureusement encore aujourdhui assez proches du niveau 1

2 niveau reproductible (repeatable) : il existe un systme commun de

management de projet et des techniques de contrle. La gestion de projet et la planification sont faites sur des bases reproductibles. Des activits de mesures commencent tre mises en place, en particulier au niveau des cots et des dlais. On ragit de faon planifie et non plus en fonction des crises. Les problmes sont traits au fur et mesure quils arrivent et ne sont pas accumuls jusqu provoquer une crise majeure. Les mesures utilises pendant un projet permettent de prvoir ce qui sera susceptible de se passer pour les projets futurs.

3 dfini : il existe un systme commun pour toutes les activits de dveloppement

de logiciel la fois du point de vue managrial et technique. Des mesures sont faites rgulirement pour amliorer le processus. Des revues sont mises en place afin de garantir la qualit du logiciel.

4 gr (managed) : le procd de dveloppement logiciel est stable et permet de

garantir un niveau constant de qualit. Des objectifs prcis de qualit et de productivit sont affects chaque projet. Des mesures rgulires5 permettent de garder sous contrle ces deux indicateurs, et des actions correctrices sont prises ds quune divergence par rapport aux objectifs est constate. Des procds de mesure statistiques sont mis en place afin de dterminer sil sagit dun manquement passager aux objectifs ou bien sil sagit dune divergence grave par rapport aux standards de productivit et de qualit.

Bien que de nombreuses entreprises aient atteint les niveaux 2 et 3, pratiquement aucune nest encore arrive aux niveaux 4 et 5 qui sont donc des objectifs pour les prochaines annes.

5 Par exemple le nombre de fautes dtectes sur 1000 lignes de code, lobjectif correspondant peut tre de

diminuer ce chiffre

Gnie logiciel Anne-Marie Hugues 19/12/02 2-19

5 en optimisation constante (optimizing) : le processus de dveloppement porte en lui les moyens de raliser sa propre optimisation. Des contrles statistiques sur le processus sont utiliss pour guider lorganisation. Le processus intgre un feed back provenant de ces mesures.

Pour pouvoir samliorer lorganisation doit avoir connaissance de son niveau de maturit

actuel et dfinir celui auquel elle souhaite arriver. Le CMM lui donne des indications sur les actions entreprendre, cest dire une liste dobjectifs intermdiaires qui lorsquils seront tous atteints confreront lorganisation le niveau quelle vise.6 Elle fixe elle-mme les priorits et dfinit un plan daction.

Le SEI produit des questionnaires que les organisations remplissent et qui servent de base un audit ralis par des quipes du SEI. Le but est de mettre en vidence les lacunes de lorganisation et de laider tablir son plan daction pour atteindre le niveau souhait.

Les expriences montrent que le passage dun niveau un autre peut durer de 18 mois 3 ans. Mais le passage du niveau 1 au niveau 2 dure en gnral de 3 5 ans.

Les apports du CMM Des rsultats publis montrent que se positionner dans la grille CMM permet daccrotre

la rentabilit. Par exemple le dpartement Logiciel de Hughes Air Craft Fullerton Californie a dpens environ 500.000$ entre 87 et 90 pour amliorer son processus de production de logiciels. Pendant cette priode ils sont passs du niveau 2 au niveau 3, avec de bons espoirs datteindre les niveaux 4 et 5. Ils estiment quaujourdhui ils conomisent 2 millions de $ par an, ces conomies proviennent de la diminution du nombre de crises, du nombre dheures supplmentaires, de lamlioration de la comptence des employs et la diminution du turn-over. Ceci nest quun exemple pris parmi tant dautres. Une entreprise qui est passe du niveau 1 au niveau 3 en 1993 a constat un retour sur investissement de 7.70 pour 1. Un article fait tat de rsultats constats sur 1300 projets et compare les dures, cots et qualit suivant le niveau de lentreprise dans la grille CMM. Les chiffres sont particulirement loquents, mais il faut tout de mme souligner quil ne sagit que de rsultats obtenus par modlisation pour les niveaux 4 et 5.

CMM Dure En mois calendaires

Effort En hommes mois.

Fautes dtectes pendant le dveloppement

Fautes dtectes chez le client

Cot total de dveloppement

Niveau 1 29.8 593.5 1348 61 5 440 000$ Niveau 2 18.5 143 328 12 1 311 000$ Niveau 3 15.2 79.5 182 7 728 000$ Niveau 4 12.5 42.8 97 5 392 000$ Niveau 5 9.0 16 37 1 146 000$

Comparaison Iso9000 - CMM ISO 9000 est une norme, CMM nen est pas une CMM est ddi lindustrie du logiciel, ISO 9000 dfinit un cadre pour les rapports clients

fournisseurs.

6 Par exemple pour atteindre le niveau 2, lorganisation devra mettre en uvre des procdures dassurance qualit (en particulier dtection et correction des dfauts), une gestion de configurations srieuse, des mthodes de gestion de projet. Au niveau 5, les prrequis sont plutt la prvention des dfauts (et non plus leur correction comme au niveau 2) et lassurance zro dfaut (par la mise en uvre de techniques de preuves par exemple)

1-20 Anne-Marie Hugues 19/12/02 Gnie logiciel

CMM est plus dtaill et spcifique. ISO 9000 tablit un niveau acceptable de management de projet auquel le fournisseur doit

souscrire pour que les relations client-fournisseur puissent stablir avec certaines garanties de qualit pour le client ; alors que CMM permet au fournisseur de sauto-valuer et de progresser sur une grille allant de 1 5.

Plusieurs articles sont parus qui tablissent quune entreprise de logiciel certifie ISO 9000 atteint peu prs le niveau 2 et rciproquement.

Certaines exigences dISO 9000 et en particulier toutes celles faisant rfrence au client, ne sont absolument pas couvertes par CMM (par exemple la notion de contract review, la notion dactions correctives et prventives)

Il semble plus facile datteindre le niveau 2 en CMM que la certification ISO 9000. Toutefois cette dernire tant parfois vitale pour une entreprise on pourrait conseiller de se servir de la grille CMM pour progresser en vue dune certification ISO 9000.

Il est noter que le CMM prend de plus en plus dimportance, en particulier, Le dpartement de lUS Air Force a stipul que toute entreprise souhaitant rpondre lun de ses appels doffres doit avoir atteint le niveau 3 du CMM en 1998, ceci devrait stendre lensemble du DOD.

Le projet SPICE Le projet SPICE (Software Process Improvement and Capability dEtermination) est un

effort conjoint de l'ISO et de l'IEC pour crer un standard international d'amlioration du processus de production du logiciel. Il s'appuie sur les recommandations du SEI et l'auto valuation sur la grille CMM et s'inspire des recommandations ISO 9000 en matire de rapports clients/fournisseurs. La grille SPICE comporte 10 niveaux, les mthodes d'valuation ont une granularit plus fine. La norme SPICE devrait entrer en vigueur en 2001.

1.8 REFERENCES F. BROOKS The Mythical Man-Month Addison-Wesley, 1982 B. BOEHM Software Engineering Economics Prentice-Hall, 1981