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 maîtrise du processus de développement ...................................................... 5
Développement de méthodes structurées 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, responsabilités, rôles.............................. 8
Gestion des ressources : gestion de projet, gestion des configurations.............. 9
Méthodes, techniques et outils de production et de mesure ............................. 10
1.6 ASSURANCE QUALITE ...............................................................................10
Définition ......................................................................................................... 10
Organisation ..................................................................................................... 10
Contrôle 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
 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 nécessite la mise
en œuvre de méthodes, techniques et outils dépassant largement le cadre de la seule
programmation, regroupés sous le vocable général de Génie Logiciel.. Le terme est apparu
pour la première fois lors d'une conférence de l'OTAN à Garmisch en 1969, a commencé à se
répandre dans les années 80, notamment avec l'arrivée sur le marché d'ateliers de génie
logiciel (AGL). Il faut attendre le milieu des années 70 pour que le terme émerge : la
première conférence sur le génie logiciel a lieu en 1973 et la revue IEEE Transactions on
Software Engineering existe depuis 1975.
Le Génie Logiciel est à rapprocher du Génie civil, Génie mécanique ou Génie chimique.
La réalisation d'un pont ne peut être menée sans de méthodologie, de même la réalisation d'un
logiciel nécessite un minimum de précautions qui garantissent sa faisabilité, sa qualité et sa
fiabilité .

Nouveaux besoins
Processus Nouveau système
de production de logiciels ou système modifié
ou besoins
changés
cahier des charges ou prototype

Système composants
existant

Génie logiciel
=
Méthodes, techniques, outils

Figure 1.0 : La production de logiciel sous contrôle du génie logiciel

La programmation est une discipline récente purement intellectuelle, certains la

qualifiaient même d'art [Knuth, The art of software programming] ; pour ces raisons, on y
trouve des attitudes et des habitudes qui paraîtraient étranges dans d'autres disciplines plus
mures. Notamment le syndrome du "not invented here" ; on n'imagine pas un ingénieur
mécanicien réinventer la roue ou fabriquer ses propres vis et boulons alors qu'un
programmeur préfère souvent réécrire ses propres lignes de code plutôt que réutiliser un code
développé par d'autres. La lutte contre cette tendance naturelle est un défi majeur de
l'industrie informatique d'aujourd'hui connu sous le vocable réutilisation.
L'aspect ludique de la discipline renforce la dérive vers les comportements
individualistes.

Génie logiciel Anne-Marie Hugues © 19/12/02 1-1

 La programmation est une activité immatérielle : pour un néophyte, il peut sembler peu
dispendieux de démolir et reconstruire une architecture logicielle alors que l'on réfléchirait à
deux fois avant d'agir de même concernant une autoroute ou un bâtiment.
Le logiciel modifie l'environnement de celui qui l'utilise dans des proportions telles que
l'on a du mal à définir précisément et durablement des spécifications stables.
La maintenance occupe une part importante du budget et du temps consacré au
développement d'un logiciel. Elle peut revêtir différentes formes :
maintenance corrective: destinée à corriger des "bugs"
maintenance évolutive: adaptative ou perfective
Il est important de prendre conscience des enjeux majeurs représentés par la maintenance
67% du coût total est consacré à la maintenance
dont 48% consacrés à réparer des défauts
60% des défauts correspondent à des erreurs de spécification et de conception

D'un point de vue économique, tout comme il convient de distinguer Chimie et Génie
Chimique, il faut différencier programmation et génie logiciel. En chimie si deux réactions
différentes conduisent au même produit on n'a aucune raison de préférer l'une à l'autre. Alors
que le génie chimique différenciera parmi ces deux réactions celle qui met en jeu les produits
de base les moins chers par exemple. De même le Génie Logiciel tiendra compte en
particulier des coûts de formation et des implications à long terme lors de l'introduction de
nouvelles techniques de programmation. Au début des années 80 deux livres marquent la
prise de conscience de la nécessité de rationaliser les développements informatiques et de les
inscrire dans un contexte économique général.
B. Boehm dans Software Economics à partir d'une analyse des données menée sur les
projets informatiques de la firme TRW, définit une méthode de régression permettant
d'évaluer le coût d'un projet logiciel (COCOMO)1 en se basant sur le nombre de lignes de
code source estimées. C'est une des premières démarches en faveur de la mesure d'effort. La
méthode a été mise à jour en 2000 pour tenir compte de l'aspect réutilisation dans les projets
logiciels.
Frédéric BROOKS, dans "The Mythical Man Month"2 analyse les principaux échecs du
développement de l'OS/360. Malgré le succès relatif du projet, on constate:
- la présence de nombreuses erreurs résiduelles dans les premières versions,
- un retard important dans la livraison du produit
- que la place mémoire occupée est plus importante que prévu,
- que le coût réel est plusieurs fois celui estimé initialement.
Ce livre vient d'être réédité sans grands changements…Nous en retenons les différences
essentielles entre un programme3 et un produit logiciel intégré dans un système. Un
produit peut être utilisé, testé, maintenu, étendu, généralisé par une autre personne que le
programmeur initial. Un produit doit être suffisamment testé, documenté. Coût estimé par
Brooks pour développer un produit: Coût du programme x 3
On s'intéresse ensuite à la différence entre un programme et un programme intégré dans un
système, il s'agit d'une collection de plusieurs programmes qui interagissent. Il en résulte
un besoin de coordination, la nécessité d'établir des interfaces, de gérer la consommation des
ressources, une plus grande difficulté à organiser les tests. Le coût estimé par Brooks est
alors supérieur ou égal au Coût du programme x 3 .D'où le coût estimé pour un produit
logiciel intégré: Coût 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 séance de travaux pratiques

1-2 Anne-Marie Hugues © 19/12/02 Génie logiciel

 PROGRAMME
INTEGRE
DANS UN SYSTEME
(Interfaces,
PROGRAMME
Intégration, ...)

PRODUIT
PRODUIT
LOGICIEL
LOGICIEL
(Généralisation,
Tests, INTEGRE
Documentation, DANS UN SYSTEME
Maintenance)

Figure 1.1 : Comparaison Produit/Programme (d'après F Brooks)

Dans son livre, Frédéric Brooks met également en garde contre l'effet deuxième système.
Le développement de la deuxième version d'un produit ne prend pas forcément beaucoup
moins de temps que la première; il faut apprendre à se méfier de l'"Optimisme" des
ingénieurs logiciels. L'exemple cité est celui de la release 1.0 d' OS/360. Dans la première
version un temps considérable a été passé à automatiser la création 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 avancées technologiques de plus en plus rapides font de
l'obsolescence du savoir un élément critique de la gestion de projet informatiques.
Cette rapidité d'évolution des technologies explique que la crise du logiciel découverte
dans les années 80 ne soit qu'imparfaitement vaincue aujourd'hui: dès qu'un remède est
trouvé, l'évolution de la technique le rend partiellement obsolète….

1.2. ASPECTS HISTORIQUES : EVOLUTION DE L'INFORMATIQUE

L'informatique est une discipline jeune, l'industrie informatique s'est organisée en 20 ans là
où d'autres industries ont mis plus d'un siècle…

La programmation apparue dans les années 45-58 était alors le domaine réservé de
quelques ingénieurs mathématiciens qui programmaient en assembleur des programmes de
calcul scientifique sur mesure, à distribution limitée sur des machines volumineuses de
puissance inférieure à celle d'une calculette actuelle; machines expérimentales d'abord (
ENIAC, EDVAC ) puis commerciales SEA CAB500, BULL GAMMA3, UNIVAC, IBM
701.
Dans les années 58-75 l'informatique se développe considérablement à la fois côté
scientifique (langages FORTRAN) et dans le domaine de la gestion (langage COBOL). Les
premiers systèmes d'exploitation Multi-Utilisateurs apparaissent (IBM 360, Vax VMS, Bull
Gecos…) systèmes propriétaires qui lient l'utilisateur au constructeur. Les programmes
peuvent être activés en batch (l'un à la suite de l'autre) sur des architectures centralisées, les
premiers systèmes temps réel 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 matériels pèsent très lourd à cette époque, beaucoup plus que
le temps passé à développer les programmes. Nombre de programmes développés à cette
époque ont été concernés par le fameux bug du passage à l'an 2000….Parmi les entreprises
les plus avancées (DOD, NASA, constructeurs informatiques..) certaines perçoivent la crise
du logiciel qui va se faire jour (1969).

Génie logiciel Anne-Marie Hugues © 19/12/02 2-3

 Pendant les années 75-90, l'innovation apportée par les bases de données relationnelles
concomitante au déferlement de la micro informatique et à l'avènement des réseaux, a sorti
les Directions Informatiques de leur tour d'ivoire, en mettant l'informatique à la portée des
utilisateurs. On prend progressivement conscience de la nécessité de maîtriser le
développement de logiciels alors que le prix du hardware diminue et que le coût de
l'informatique doit prendre en compte non seulement les coûts de développement mais aussi
les coûts de maintenance (corrective et évolutive). Le système ouvert Unix a libéré les
informaticiens du joug des constructeurs, désormais tout système vise à l'hétérogénéité et à la
portabilité, l'informatique embarquée temps réel envahit peu à peu le quotidien (transactions
bancaires, réservations, électroménager, véhicules…). On passe des systèmes centralisés aux
systèmes distribués. 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
stratégique des systèmes d'information, la Direction Informatique cède progressivement la
place à une Direction de l'Informatique et de l'Organisation (début des années 80) dans les
grandes entreprises. On constate l'avènement de nombreux consultants en organisation.

Informatique partout
fiabilité
crise sécurité
aide à la décision
e-business
Logiciels scientifiques
Temps réel,
progiciels ERP
Logiciels
embarqués,
scientifiques Réseaux,
Logiciels et de gestion Micro informatique Internet
sur mesure FORTRAN puces Intranet
calcul COBOL systèmes distribués 3 tiers
scientifique multi-utilisateurs client-serveur serveurs
systèmes propriétaires Bases de données d ’applications
systèmes de fichiers Unix
Assembleur batch, temps réel puces
ENIAC
1945 1958 1970 1990 2000

Figure 1.2 : 50 ans d'informatique

Durant les années 90 l'omniprésence d'Internet ou d'Intranet dans les applications oblige à
reconsidérer les architectures client-serveur établies quelques années plus tôt au profit
d'architectures 3 tiers prenant en compte des serveurs d'applications et non plus seulement des
serveurs de données.
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 intègrent les
opérations les plus courantes et offrent à leurs clients des produits standardisés à 80% et
facilement (!?) paramétrables pour les 20% restant. Les outils d'aide à la décision
(datawarehouse, data mining) font leur apparition. En matière de commerce électronique (e-
commerce) les contraintes de sécurité et de fiabilité sont pratiquement aussi fortes qu'en
informatique temps réel (logiciels embarqués dans satellites, logiciels de contrôle de centrale
nucléaires….) alors que les budgets consacrés et les temps de développement se veulent
radicalement inférieurs…
En conclusion le logiciel est aujourd'hui présent partout, sa taille et sa complexité
augmentent de façon exponentielle, les exigences de qualité sont de plus en plus sévères… la

1-4 Anne-Marie Hugues © 19/12/02 Génie logiciel

crise du logiciel apparue dans les années 70 n'est toujours pas franchement résolue même si
de grands progrès ont été réalisés dans de nombreux domaines…

1.3. LA CRISE DU LOGICIEL

Mise en évidence au début des années 70, la crise se caractérise par
l'absence de maîtrise des projets, au niveau des coûts et des délais,
la mauvaise qualité des produits: les produits ne répondent pas aux besoins définis et des
erreurs résiduelles persistent dans le produit final
un stock important de projets en attente faute d'une gestion rigoureuse
Quelques exemples de logiciels défaillants:
− 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 Vénus( années 60)
− vers Mars (99)
− La panne ATT (1990)
− L’échec d’Ariane 5 (1996)
− La poste (1998)
− Et les erreurs que l'on ignore : logiciels de surveillance médicale défaillants

….et l ’an 2000 (qui a fait dépenser des millions de $ pour des logiciels développés pour la
plupart en pleine crise du logiciel) qui a finalement été bien absorbée sans provoquer
trop de défaillances.

1.4 LES REPONSES A LA CRISE:

La maîtrise du processus de développement

Pour maîtriser le développement, une organisation doit choisir et appliquer un modèle de
processus définissant:
- Les phases du développement: définitions des besoins, spécifications,
planification, conception, codage, tests...
- Les produits intermédiaires: prototype, documentations...
- Les critères 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 différents modèles de cycle de vie au chapitre 2.

Développement de méthodes structurées et d'outils CASE

Dans les années 75-90 les méthodes structurées se développent (SA/RT, SADT, Ward et
Mellor, modèle entités-relations...) ainsi que les métriques et outils permettant de les mettre
en œuvre. (ateliers de Génie Logiciel ou outils CASE Computer.Aided.Software.Engineering).
A cette époque, au sein des directions informatiques (et de l'organisation), de nouveaux
services apparaissent : "méthodes et qualité", chargés de définir les bonnes pratiques en
matière de développement logiciel, de choisir les bons outils CASE. Le langage ADA (83)
développé à la demande du DOD (Department of Defense américain) est le fer de lance de
cette rationalisation qui passe par un développement systématique et contrôlé par le

Génie logiciel Anne-Marie Hugues © 19/12/02 2-5

compilateur, ce langage est le premier à mettre à l'ordre du jour la réutilisation systématique
d'éléments de bibliothèques ("packages") fournis avec le compilateur.
De grands programmes de recherche sont lancés :
Europe: ESPRIT, ALVEY, Software Factory
Etats-Unis: ADA, STARS, SDI,
Japon: 5ième Génération (ICOT)

Le paradigme objet
Dans les années 90 la crise n'est toujours pas résolue. Si les méthodes structurées
s'avéraient 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 développements 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 nécessité à réutiliser les
connaissances et à les partager.
Dans le domaine de la maintenance également, les méthodes structurées n'ont pas fait leurs
preuves. Le problème vient du fait que les méthodes structurées sont soit orientées données
soit orientées actions et que la modification d'un élément du logiciel impacte d'autres
éléments de manière relativement imprévisible.
Un nouveau paradigme voit le jour en 80 (Smalltalk) et devient très populaire dans les
années 90, c'est le paradigme objets qui encapsule actions et données. Ceci facilite la
maintenance car la localisation de l'erreur se fait plus facilement. L'objet masque la structure
interne des données qui sont accédées uniquement à travers des messages. Chaque objet est
autonome. En outre la définition de l'héritage et de la généricité permet la réutilisation
d'objets déjà développés dans un autre contexte.

message message
dépôt retrait

retrait
dépot
compte compte

solde

message
solde

Approche structurée Approche objets

Figure 1. 3 : Introduction à l'approche objets

Les années 90 ont ainsi vu l'avènement de nombreuses techniques visant à rationaliser le

processus de développement : approche objets, normalisation des interfaces et des langages,
définition d'ORB (Object Request Broker) facilitant l'échange entre les différents objets
composant un logiciel.
Un écrémage au niveau des AGL s'est opéré. Des outils d'aide à la programmation rapide
(?) utilisant des langages de 4ème génération permettent à des non informaticiens de définir
rapidement leurs propres applications. La réutilisation systématique de biens logiciels oblige
l'entreprise à revoir son processus de développement logiciel et vraisemblablement à se

1-6 Anne-Marie Hugues © 19/12/02 Génie logiciel

réorganiser. Les environnements de programmation autour des langages objets Java ou C++
facilitent la réutilisation de bibliothèques de classes prédéfinies

Approche
Paradigme objets composants
Politique qualité, outils GL: Java beans
langages C++, Java Active X
méthodes structurées
ORB (CORBA) serveurs
outils GL : d ’applications
environnements CASE
Modèles de langages (ADA…) Réseaux,
cycles de Réseaux, Internet
client/serveur 3 tiers
développement Micro informatique hétérogénéité
Bases de données e-business
la crise: Aide à la décision
coûts Temps réel, systèmes Réutilisation
datawarehouse
délais embarqués
qualité

1970 1980 1990 2000

Figure 1.4 : 30 ans d’avancées technologiques et méthodologiques

L'approche composants
Les années 2000 seront placées sous le signe de la programmation à base de composants
réutilisables. Cette approche peut être vue comme une forme ultime de la programmation par
objets, ou plus simplement comme un assemblage de briques logicielles prédéfinies, orientés
techniques ou métiers, et conçues dans le but d'être réutilisées (ce qui n'est pas forcément le
cas d'objets définis dans un contexte particulier et réutilisés par hasard). Cette démarche
s'appuie sur les technologies Java Beans, active X…mais nécessite une réorganisation du
processus de développement logiciel.

En conclusion, on peut dire que si la crise du logiciel est aujourd'hui résorbée parce que
mieux connue, elle est loin d'être terminée même si les services méthodes 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 avancées rapides de la
technologie rendent possibles des applications jusqu'alors inenvisageables et obligent sans
cesse à reconsidérer les vérités que l'ont croyait acquises.

L'informatique est aujourd'hui une industrie mure pour laquelle des éléments d'assurance
qualité peuvent être mis en place et qui diffèrent selon le type de produit à fabriquer et le
contexte dans lequel le produit sera utilisé : les contraintes seront différentes selon que l'on
fabrique un logiciel amateur ou un logiciel professionnel, selon que le logiciel est stratégique
pour une entreprise ou vital pour une population….

Génie logiciel Anne-Marie Hugues © 19/12/02 2-7

1.5 LES MOTEURS DE LA QUALITE

Objectifs
Les objectifs de qualité rejoignent bien souvent les objectifs de productivité
- Adéquation aux besoins
− Efficacité temps/espace
− Fiabilité
− Sécurité,
− Intégrité
− Testabilité, Traçabilité
− Adaptabilité, Maintenabilité,
− Convivialité (interface, aide et documentation)
− Pérennité (facilité de la maintenance)
L'assurance qualité vise à atteindre les objectifs de qualité, réduire le nombre d'erreurs
résiduelles , maîtriser les coûts et la durée du développement sans nuire à l’innovation et à la
créativité.
Les moteurs de l'assurance qualité sont multiples : on peut citer
− L'organisation du processus : découper le processus pour le maîtriser
− Les ressources humaines : les équipes doivent être motivées pour mettre en place des
procédures qualité
− L'utilisation de techniques, méthodes, outils
− Les considérations managériales, politiques et économiques : considérer le retour sur
investissement de la mise en place de procédures qualité par une analyse coûts
bénéfices.
Nous revenons sur chacun de ces aspects dans les chapitres concernés.

Organiser le processus : cycle de vie, responsabilités, rôles

Comme tout produit, un logiciel a un cycle de vie, il naît, vit et meurt ; autrement dit, il est
créé, distribué sur un marché ou bien mis en exploitation et disparaît pour cause
d'obsolescence. La phase de maintenance évolutive a pour objectif de retarder la phase de
disparition.
Le cycle de développement des logiciels s'insère dans le cycle de vie global du produit, on
l'appelle souvent abusivement cycle de vie des logiciels.

Retardement de la disparition par la maintenance évolutive

Figure 1.5 Cycle de vie d'un produit

La maîtrise du processus de développement passe par un découpage en activités

- Séquentielles (verticales) : Spécifications, Conception, …
- Permanentes (horizontales) : Gestion de projet, Gestion des configurations…
Chaque activité sera validée avant de passer à la suivante.
Chaque projet est découpé en éléments maîtrisables. Par exemple au niveau de la
conception globale on essaiera de décomposer en modules aussi indépendants que possible,
ce qui facilitera le codage , l'intégration et la maintenance.

1-8 Anne-Marie Hugues © 19/12/02 Génie logiciel

 Ce découpage 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é élémentaire, chaque phase est placée sous la responsabilité d'un acteur,
les recommandations pour l'assurance qualité insistent toutes sur la notion rôle, il faut définir
- Qui fait,
- Qui approuve,
- Qui vérifie,
- Qui valide,
- Qui est consulté.
L'enchaînement des activités est défini à l'avance selon l'un des modèles de processus qui
sera vu au chapitre 2.

tâches Est équipiers

responsable

processus

outils

Productions méthodes
intermédiaires

Figure 1.6 : Organiser le processus

Gestion des ressources : gestion de projet, gestion des configurations

Comme tout projet industriel, un projet logiciel nécessite une gestion stricte des ressources
tant humaines que matérielles et logicielles. Cette activité est transversale au projet et met en
œuvre des techniques communes à tout type de projet ainsi que d'autres plus spécifiques que
nous étudierons au chapitre 3. Il s'agit ici de
− savoir évaluer coûts et délais
− définir et ordonnancer les tâches, planifier la réalisation, l'intégration, la
validation…
− établir un système de contrôle pour tous les produits intermédiaires du cycle de
vie, dans le but de détecter le plus tôt possible: défauts, erreurs, omissions,
ambiguïtés, incohérences, hypothèses incorrectes, ….
− organiser la formation sur les méthodes, les outils , les nouvelles technologies
− motiver les équipes, anticiper les problèmes, ne pas brider la créativité, détecter la
résistance au changement
La gestion de configurations est spécifique aux projets logiciels. Les produits logiciels
sont constitués de différents éléments qui évoluent au cours du temps et qui peuvent différer
d'une installation à l'autre. La gestion des configurations est activité transversale essentielle
qui consiste à

Génie logiciel Anne-Marie Hugues © 19/12/02 2-9

 − contrôler l'ensemble des données constituant le système:
− documents
− sources
− jeux de tests
− plans d'intégration….
− assurer la cohérence des divers composants
− construire/reconstruire un système
pendant tout le cycle de vie (développement et maintenance).
De nombreux outils existent qui facilitent cette tâche, sous Unix la conjonction de
make/rcs permet de gérer les versions et la reconstruction du système.

Méthodes, techniques et outils de production et de mesure

L'analyse, la conception, le développement et le test du produit constituent le cœur de la
production logicielle. Depuis les années 80, de gros efforts ont été faits sur les outils
permettant de rationaliser et/ou automatiser ces tâches.
Dans la suite du cours on insistera particulièrement sur
- les méthodes de spécification et de conception qu'elles soient structurées ou
orientées objets
- les méthodes de validation et vérification
- l'outillage : le poste de travail de l'ingénieur logiciel
les ateliers de génie logiciel incluant outils d'analyse, générateur de code,
environnement de développement et de mise au point , outils de tests, outils de
mesures de performances…
L'amélioration d'un processus passe par sa connaissance précise, il est nécessaire
d'organiser des collectes de données pour mesurer:
- Coûts,
- Délais,
- 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

Définition
Assurance qualité : "Mise en œuvre d'un ensemble approprié de dispositions préétablies et
systématiques destinées à donner confiance en l'obtention de la qualité requise." (AFNOR)
Plus précisément toutes les normes qualité insistent sur trois aspects essentiels :
communication, contrôle, organisation.

Organisation
Le processus de développement est classiquement organisé en différentes phases
conformément à la figure 1.7

1-10 Anne-Marie Hugues © 19/12/02 Génie logiciel

 Définir les besoins
Spécifier
Supporter
planifier

Distribuer
concevoir

Qualifier
Développer
valider

Figure 1.7 : Les phases du cycle de vie d'un produit logiciel

Une tâche essentielle du chef de projet est d'organiser ces différentes phases et de les lier à
des activités en y affectant les ressources nécessaires tant humaines que logicielles ou
matérielles. L'enchaînement des activités constituera le workflow du projet.. Chaque activité
débouche sur un produit intermédiaire dont la production détermine la fin de l'activité et qui
devra être contrôlé avant de passer à l'activité suivante.

Contrôle
L'assurance qualité passe par des contrôles réguliers et inclut
- la validation(du latin "VALIDARE", déclarer valide) permet de répondre à la question
"sommes nous en train de faire le bon produit? "
- la vérification(du latin "VERITAS ", la vérité): répond à la question "est ce que nous
faisons le produit correctement"
Comme le montre la figure 1.8 les erreurs sont de plus en plus coûteuses à réparer
lorsqu'elles sont découvertes tard dans le cycle de vie: d'où le rôle primordial de contrôles
intermédiaires. La validation et la vérification sont en partie garanties par la mise en place des
d'inspections, revues, relectures pour tous les produits intermédiaires du développement
(prototypes/ maquettes, documents de spécification, de conception, code, jeux de tests)

Génie logiciel Anne-Marie Hugues © 19/12/02 2-11

 400
Projets 74-80

IBM AS /400 (94)

300

200

100

0
besoins planification codage maintenance
specification conception intégration

Figure 1.8 coût relatif de correction des erreurs en fonction de leur découverte, source IBM

L'inspection est une lecture critique d'un document (spécification, conception, code, plan
d'intégration...); elle est destinée à améliorer la qualité d'un document.
De manière générale, l'inspection est faite par une équipe indépendante du projet
constituée par: un Modérateur, un Experts(s), Secrétaire , le client, éventuellement un
banquier, un représentant du service qualité...
Pour qu'elle puisse être profitable, une inspection doit donner lieu à la rédaction de fiches
de défauts avec une échelle de gravité et la définition des responsabilités concernant la
correction des défauts.
Les inspections sont à la base des décisions prises en revues. Une revue est une réunion
permettant de valider une des phases du cycle de vie.
On distingue
- les revues produits: état d'un projet sous ses différents aspects: Techniques, Financiers,
Commerciaux, Calendrier, ...
- les revues techniques (celles qui nous intéressent le plus dans le cadre de ce cours): elles
permettent de fournir au marketing et à l'unité de développement une évaluation des
aspects techniques du projet et des coûts de réalisation
- les réunions de décision: elles valident le passage à la phase suivante et font bien
souvent suite à l'une des deux précédentes.
Exemple d'après Boehm
Un logiciel de réservation aérienne (Univac-United Airlines) d'un coût 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 prévues.
Ceci aurait pu être évité par des inspections et des revues intermédiaires et l'analyse d'un
prototype

Communication
Même si l'assurance qualité ne doit pas être confondue avec une production intensive et
bureaucratique de documentation, elle insiste sur la nécessité de communiquer à différents
niveaux:

1-12 Anne-Marie Hugues © 19/12/02 Génie logiciel

- entre développeurs et environnement, (clients avant le développement, support pendant la
phase de maintenance) : cahier des charges, dossier d'analyse, manuel d'installation,
dossier de conception, plan projet , plan qualité
- entre les développeurs. (dossier d'analyse, dossier de conception, plan qualité,
commentaires du code, résultats de tests…)
Certains documents sont plus spécifiquement dédiés à 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é décrit les procédures définies par une entreprise ou une organisation
pour atteindre ses objectifs de qualité.
Il répertorie les méthodes et procédures à utiliser pour:
- Gestion de projets
- Réalisation, Vérification, Validation,
- Evaluation de la Qualité (Mesures).
en s'appuyant sur:
- Rédaction de standards, normes (ISO, DOD..) , conventions, guides,
- Expérience acquise des projets, pour améliorer le processus.

Plan qualité
Le plan qualité logiciel définit, pour un projet donné, en accord avec le manuel qualité
de l'entreprise, les méthodes techniques et outils permettant d'atteindre les objectifs de qualité
pour un coût donné. Le plan qualité fait partie des éléments 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 procédures qualité s'appuient sur la rédaction de normes et de standards, on citera
particulièrement :
− la norme DOD 2167 A pour les applications militaires ,
− la norme ISO 9001 (ISO 9000-3 ) pour les applications civiles adoptée par 60 pays
(USA, Europe, Japon...). C'est aujourd'hui un passage quasi obligé pour une SSII d'être
estampillée ISO 9001 pour pouvoir répondre à un appel d'offres. Il est à noter que la
certification est payante et valable 3 ans. La norme ISO 9000 devrait être remplacée en
2001.
La grille CMM n’est pas une norme, elle peut toutefois servir de référence 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
spécialement logiciel)
ISO 9000-1 recommandations pour l’utilisation de ces standards
ISO 9001 : le standard à utiliser pour la fourniture de logiciels, la référence
en matière de certification pour le logiciel
ISO 9003 : guide pour l’utilisation des standards ISO 9001 pour la
fourniture de logiciels

Génie logiciel Anne-Marie Hugues © 19/12/02 2-13

 Philosophie ISO 9001 :
Toute opération influençant la qualité doit être sous contrôle.
Le contrôle doit être visible

Le chapitre 4 de la norme définit les 20 éléments de qualité à respecter

− Responsabilités du management
− Définition d’un système de qualité
− Analyse du contrat entre client et fournisseur
− Contrôle de la conception
− Documentation et contrôle des données
− Spécification des achats et fournitures
− Contrôle des produits fournis par le client
− Identification des produits et traçabilité
− Contrôle du processus
− Nécessité de mettre en œuvre des tests et inspections
− Contrôle des inspections et tests, mesures des outils de tests
− Statut des tests et inspections
− Contrôle des produits non conformes
− Actions correctives et préventives
− Emballage, stockage, livraison,
− Contrôle des enregistrements concernant la qualité
− Audit qualité internes
− Organiser la formation
− Service après vente
− Techniques statistiques

On voit bien sur cette liste que ISO 9001 ne vise pas spécialement la fourniture de logiciels et
doit être adaptée dans le cadre d’une 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).

Définir le cadre de l’assurance qualité

Responsabilités du management
Les responsabilités du management recouvrent : la définition d’une politique qualité, la mise
en place d’une organisation et la validation périodique du système qualité.

Définition d’un système qualité

La politique qualité doit être documentée dans un manuel qualité conforme aux normes en
vigueur et aux habitudes de l’entreprise. Il est important que les procédures qualité mises en
place trouvent l’agrément des développeurs et ne soient pas perçues comme un frein à leur
créativité mais plutôt 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 s’engager sur un contrat irréaliste.

Contrôler le développement
Ce paragraphe vise à encourager le fournisseur à documenter et contrôler le processus de
développement.

1-14 Anne-Marie Hugues © 19/12/02 Génie logiciel

Planification du développement et de la qualité
Définition du calendrier, des différentes phases du projet, des critères qualité

Organisation du travail
En particulier organisation des espaces de travail

Contrôle des Spécifications (Design input)

ISO 9000 requiert des spécifications rigoureuses et complètes. En logiciel tout le monde
sait que ceci est en général un vœu pieux. Un autre paragraphe des recommandations prévoit
donc les procédures de prise en compte de changements dans les spécifications.
Afin de définir ces spécifications, des outils peuvent être utilisés (en particulier tous les outils
d’aide à l’analyse tels que AMC Designor , Rational Rose…

Sortie de la conception (Design output)

La conception peut être réalisée à la main, elle peut également être générée plus ou
moins automatiquement. Dans tous les cas, la phase de conception doit produire une
architecture logicielle et de la documentation

Contrôle de la Conception (Design review),

Dans tous les cas la conception nécessite un contrôle rigoureux par des inspections qui
peuvent être réalisées au moyen de listes de défauts typiques. Pour moi ces trois subtilités des
recommandations sont redondantes entre elles et je les ai réunies dans un même paragraphe.

Validation vérification ( Design verification, Design validation)

Il s’agit ici des procédures de validation/ vérification du code . Elles sont classiquement
réalisées à base d’analyse statique, de tests fonctionnels et de tests structurels. Le Béta test
pris en charge par le client doit explicitement figurer dans le contrat si une telle décision de
qualification est adoptée. Il est tout à fait fondamental d’être capable de rendre compte des
résultats des tests et des jeux de tests qui ont été effectués. Les critères d’arrêt doivent être
définis dans un plan de tests, on doit pouvoir prouver qu’on les a atteints.

Modification de la conception et des spécifications

Il faut vérifier la cohérence des changements demandés avec le développement déjà
réalisé. ISO9000 requiert une procédure rigoureuse d’acceptation des modifications
Gérer les activités de support

Gestion des configurations : Déjà vu .

Gestion de la documentation et des données

Le standard demande que quiconque a besoin des documents puisse y accéder. Le
standard demande que tout document soit approuvé et que les versions des documents soient
cohérentes entre elles et cohérentes avec le code qu’elles documente.

Contrôle des Achats, de la sous-traitance, et des fournitures procurées par le client

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

Traçabilité
Cette rubrique concerne le suivi tout au long du cycle de développement des liens qui
peuvent exister entre cahier des charges et spécifications, spécifications et conception,
conception et codage.

Génie logiciel Anne-Marie Hugues © 19/12/02 2-15

 La norme impose de savoir répondre aux questions suivantes
De quel document initial cette spécification s’inspire-t-elle ?
A quelle spécification, à quel document de conception ce bout de code est il relié ?
Quelles sont les corrections ou améliorations qui ont été réalisées dans tel module ?
A partir de quel code source cet exécutable a-t-il été généré
A partir de quel outil cet exécutable a-t-il été généré ?
Qu’est il advenu de chaque rapport d’incident ? A t il été pris en compte, corrigé ? la nouvelle
version a-t-elle été distribuée ?

C’est souvent à cause de ce chapitre que les impétrants à la certification se font rejeter.
Voici quelques exemples
La mauvaise version d’un fichier source a été cataloguée
Un erreur est répertoriée comme réparée et ne l’est pas
Un manager ou un chef de projet a été incapable de montrer quelles versions des
sources étaient utilisées au moment des tests
Incapacité de montrer les différentes demandes de modifications ou rapports
d’incidents
Contrôle de production (process control)
Il s’agit ici du contrôle de la production des disquettes, CD ou tout autre media sur
lequel le produit final sera livré. Le contrôle de production du développement a été vu
précédemment.
A vérifier également que la bonne version soit livrée en ce qui concerne les
bibliothèques, jeux de tests, documentation…
Inspection et tests
Là encore il s’agit d’inspecter le matériel livré (disquettes .. ), la validation du code
ayant été vue précédemment.
Contrôle des équipements de tests
Peu applicable en informatique. On peut par exemple tester les horloges pour les
programmes temps réel…
Statut des Inspections et tests ( Inspection and tests status)
On doit pouvoir à tout moment savoir si un document, un code source…a été inspecté,
validé ou est en attente de validation.
En aucun cas un document non validé ne doit servir de base à de nouveaux
développements.
Les documents inspectés et validés doivent être conservés dans un espace différent de ceux
qui ne le sont pas.
Contrôle des produits non conformes
Les produits non conformes doivent être identifiés. On doit pouvoir fournir une
procédure qui permet de corriger rapidement les erreurs et de valider les modules ainsi
corrigés.
Actions correctives et préventives
La norme est assez floue à ce propos car elle ne prévoyait pas l’amélioration des
produits ; alors qu’en 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
traçabilité vues précédemment
S’assurer qu’il existe une procédure de report des erreurs, s’assurer que toute erreur
reportée est un jour corrigée, pouvoir répondre sans hésiter à la question « telle erreur a t elle
été corrigée.
Stockage, livraison, emballage
Une fois les produits développés, il faut les stocker, les emballer et les acheminer vers
le client, cette étape a peu de rapports avec le cours mais doit être envisagée avec attention (
par exemple étiqueter les CD rom peut prendre un certain temps …)

1-16 Anne-Marie Hugues © 19/12/02 Génie logiciel

Contrôle des enregistrements qualité
On veillera à garder trace de tous les enregistrements qualité effectués en interne
(inspection, tests..) et chez les clients (mesures statistiques en particulier, erreurs reportées et
le sort qui leur a été réservé…)
Audit qualité interne
Il s’agit de vérifier que les plans qualité sont respectés dans l’entreprise de manière
générale. On pourra le prouver si on a fait une procédure sérieuse de collecte de données. Il
faut pouvoir produire une procédure d’audit lors de la certification ou de son renouvellement.
Formation
La norme encourage la formation programmée à tous les niveaux:
- Nouvelles techniques, nouveaux langages
- Formation aux méthodes qualité
- Formation aux méthodes de gestion de projet
Service après vente
Prévoir un contrat de maintenance. On a déjà abordé le fond du problème précédemment.
Les critiques qui sont émises en général par rapport à ce paragraphe :
- Pas de contrat de maintenance
- Méthode de maintenance spécifiques pour un vieux produit non documentée
- Pas de procédures de maintenance
- Rien de prévu pour tester après une activité de maintenance (en général on peut au
moins repasser et mettre à jour les tests de non régression)

Méthodes statistiques
Dans une industrie de production il est important de pouvoir prélever des échantillons au
hasard et de les tester. En logiciel rien de commun. Les tests statistiques consistent à faire des
mesures a posteriori en phase d’exploitation:
- Nombre de pannes
- Nombre d’erreurs découvertes (par le client, par le fournisseur)
- Temps moyen entre deux pannes
- Durée moyenne d’indisponibilité .

Le Capability Maturity Model

La grille de maturité du Software Engeering Institute de Carnegie mellon University (SEI)
aujourd’hui appelée Capability Maturity Model4 est certainement une rivale de la norme ISO
9000 (ou plus exactement des recommandations ISO 9000-3) en matière de qualité de
développement de produits logiciels.
Développé dès les années 70 pour le compte du DOD qui souhaitait évaluer ses sous
traitants, ce modèle a été largement adopté dans le civil. Le SEI est encore aujourd’hui
largement soutenu par le DOD.
Le principal intérêt que ses promoteurs et ses adeptes voient au modèle CMM est son
élaboration en vue d’une utilisation dans un contexte de développement logiciel et non pas,
comme c’est le cas pour ISO 9000, une adaptation d’une norme multi-domaines au cas
particulier du génie logiciel.

4 Le CMM a été introduit en 1986, il s'appelait alors Process maturity model.

Aujourd’hui un autre modèle voit le jour : le Personnal Software Process qui permet à chaque ingénieur de
s’améliorer personnellement contrastant en cela avec le CMM qui vise lui à l’amélioration globale de
l’organisation. Des résultats récents prouvent que l’utilisation du PSP contribue à l’amélioration de la qualité et
de la productivité globale.

Génie logiciel Anne-Marie Hugues © 19/12/02 2-17

 Par ailleurs, le CMM permet à ses utilisateurs de se positionner dans une grille sur laquelle
ils pourront évoluer et progresser, ce qui n’est pas prévu dans la norme ISO 9000.

Toutefois étant donnée la popularisation de la norme ISO 9000 en Europe et dans le

Monde, il est indéniable qu’une certification ISO 9000 permet de remporter un certain
nombre de marchés et cet aspect ne doit pas être négligé. Nous verrons qu’il peut
éventuellement en être de même avec CMM.
Philosophie CMM :
La grille CMM permet de classifier une organisation (SSII ou service informatique
d’une entreprise) qui développe du logiciel selon sa compétence.
Cette grille identifie 5 niveaux de maturité (d’où son nom) pour ces organisations
1 niveau initial : le logiciel est développé sans méthode prédéfinie. Le
développement repose sur la compétence de quelques personnes, il est
impossible de récupérer l’expérience acquise dans un projet lors du
développement d’un autre projet, on ne peut prédire en terme de gestion de
projet des éléments aussi importants que la taille ou le coût d’un projet. Les
réactions se font essentiellement en fonction des crises et non pas de façon
systématique et planifiée.
Beaucoup d’organisations sont malheureusement encore aujourd’hui assez proches
du niveau 1

2 niveau reproductible (repeatable) : il existe un système commun de

management de projet et des techniques de contrôle. La gestion de projet et la
planification sont faites sur des bases reproductibles. Des activités de mesures
commencent à être mises en place, en particulier au niveau des coûts et des
délais. On réagit de façon planifiée et non plus en fonction des crises. Les
problèmes sont traités au fur et à mesure qu’ils arrivent et ne sont pas
accumulés jusqu’à provoquer une crise majeure. Les mesures utilisées pendant
un projet permettent de prévoir ce qui sera susceptible de se passer pour les
projets futurs.

3 défini : il existe un système commun pour toutes les activités de développement

de logiciel à la fois du point de vue managérial et technique. Des mesures sont
faites régulièrement pour améliorer le processus. Des revues sont mises en
place afin de garantir la qualité du logiciel.

4 géré (managed) : le procédé de développement logiciel est stable et permet de

garantir un niveau constant de qualité. Des objectifs précis de qualité et de
productivité sont affectés à chaque projet. Des mesures régulières5 permettent
de garder sous contrôle ces deux indicateurs, et des actions correctrices sont
prises dès qu’une divergence par rapport aux objectifs est constatée. Des
procédés de mesure statistiques sont mis en place afin de déterminer s’il s’agit
d’un manquement passager aux objectifs ou bien s’il s’agit d’une 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 n’est encore arrivée aux niveaux 4 et 5 qui sont donc des objectifs pour les
prochaines années.

5 Par exemple le nombre de fautes détectées sur 1000 lignes de code, l’objectif correspondant peut être de
diminuer ce chiffre

1-18 Anne-Marie Hugues © 19/12/02 Génie logiciel

 5 en optimisation constante (optimizing) : le processus de développement porte
en lui les moyens de réaliser sa propre optimisation. Des contrôles statistiques sur
le processus sont utilisés pour guider l’organisation. Le processus intègre un feed
back provenant de ces mesures.

Pour pouvoir s’améliorer l’organisation doit avoir connaissance de son niveau de maturité
actuel et définir celui auquel elle souhaite arriver. Le CMM lui donne des indications sur les
actions à entreprendre, c’est à dire une liste d’objectifs intermédiaires qui lorsqu’ils seront
tous atteints conféreront à l’organisation le niveau qu’elle vise.6 Elle fixe elle-même les
priorités et définit un plan d’action.
Le SEI produit des questionnaires que les organisations remplissent et qui servent de base
à un audit réalisé par des équipes du SEI. Le but est de mettre en évidence les lacunes de
l’organisation et de l’aider à établir son plan d’action pour atteindre le niveau souhaité.
Les expériences montrent que le passage d’un niveau à un autre peut durer de 18 mois à 3
ans. Mais le passage du niveau 1 au niveau 2 dure en général de 3 à 5 ans.

Les apports du CMM

Des résultats publiés montrent que se positionner dans la grille CMM permet d’accroître
la rentabilité. Par exemple le département Logiciel de Hughes Air Craft à Fullerton Californie
a dépensé environ 500.000$ entre 87 et 90 pour améliorer son processus de production de
logiciels. Pendant cette période ils sont passés du niveau 2 au niveau 3, avec de bons espoirs
d’atteindre les niveaux 4 et 5. Ils estiment qu’aujourd’hui ils économisent 2 millions de $ par
an, ces économies proviennent de la diminution du nombre de crises, du nombre d’heures
supplémentaires, de l’amélioration de la compétence des employés et la diminution du turn-
over. Ceci n’est qu’un exemple pris parmi tant d’autres. Une entreprise qui est passée du
niveau 1 au niveau 3 en 1993 a constaté un retour sur investissement de 7.70 pour 1. Un
article fait état de résultats constatés sur 1300 projets et compare les durées, coûts et qualité
suivant le niveau de l’entreprise dans la grille CMM. Les chiffres sont particulièrement
éloquents, mais il faut tout de même souligner qu’il ne s’agit que de résultats obtenus par
modélisation pour les niveaux 4 et 5.

CMM Durée Effort Fautes Fautes Coût total de

En mois En détectées détectées chez le développement
calendaires hommes mois. pendant le client
développement
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 n’en est pas une
CMM est dédié à l’industrie du logiciel, ISO 9000 définit un cadre pour les rapports clients
fournisseurs.

6 Par exemple pour atteindre le niveau 2, l’organisation devra mettre en œuvre des procédures d’assurance
qualité (en particulier détection et correction des défauts), une gestion de configurations sérieuse, des méthodes
de gestion de projet. Au niveau 5, les prérequis sont plutôt la prévention des défauts (et non plus leur correction
comme au niveau 2) et l’assurance zéro défaut (par la mise en œuvre de techniques de preuves par exemple)

Génie logiciel Anne-Marie Hugues © 19/12/02 2-19

 CMM est plus détaillé et spécifique.
ISO 9000 établit un niveau acceptable de management de projet auquel le fournisseur doit
souscrire pour que les relations client-fournisseur puissent s’établir avec certaines garanties
de qualité pour le client ; alors que CMM permet au fournisseur de s’auto-évaluer et de
progresser sur une grille allant de 1 à 5.
Plusieurs articles sont parus qui établissent qu’une entreprise de logiciel certifiée ISO 9000
atteint à peu près le niveau 2 et réciproquement.
Certaines exigences d’ISO 9000 et en particulier toutes celles faisant référence au client,
ne sont absolument pas couvertes par CMM (par exemple la notion de contract review, la
notion d’actions correctives et préventives…)
Il semble plus facile d’atteindre le niveau 2 en CMM que la certification ISO 9000.
Toutefois cette dernière étant parfois vitale pour une entreprise on pourrait conseiller de se
servir de la grille CMM pour progresser en vue d’une certification ISO 9000.
Il est à noter que le CMM prend de plus en plus d’importance, en particulier, Le
département de l’US Air Force a stipulé que toute entreprise souhaitant répondre à l’un de ses
appels d’offres doit avoir atteint le niveau 3 du CMM en 1998, ceci devrait s’étendre à
l’ensemble 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 créer un standard international d'amélioration 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 matière de
rapports clients/fournisseurs. La grille SPICE comporte 10 niveaux, les méthodes 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

1-20 Anne-Marie Hugues © 19/12/02 Génie logiciel