See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/270982108

Modèles de développement du logiciel

Article  in  Revue de l Electricité et de l Electronique · January 1998

DOI: 10.3845/ree.1998.059

CITATIONS READS

0 4,649

1 author:

Marie-Claude Gaudel
Laboratoire de Recherche en Informatique
114 PUBLICATIONS   1,791 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Marie-Claude Gaudel on 13 March 2015.

The user has requested enhancement of the downloaded file.

 DOSSIER Mots-clés :

Logiciel
Modèles de
odèles de développement
développement,
Cycle de vie.
du logiciel

par Marie-Claude GAUDEL, Bruno MARRE, Françoise SCHLIENGER,

Laboratoire de Recherche en Informatique, Université de Paris-Sud

G. BERNOT, Laboratoire de méthodes informatiques, Université d'Evry

Comme d'autres produits, le logiciel a

donné lieu à l'élaboration de modèles
de développement : développement en
étapes, modèle de la cascade, modèle
en V, modèle en spirale, modèles par
incréments.
Comme tout produit manufacturé complexe, un logiciel
est produit en suivant un certain processusl. Mais le
domaine du logiciel présente des particularités. Par
exemple, il n'y a pas de problèmes de fabrication en série :
une fois qu'une version du logiciel est réalisée, sa repro-
duction se fait par simple copie.
Un processus de développement du logiciel fait donc une
large place à l'analyse des besoins, à la conception et à la
validation.
On peut voir la partie technique du développement d'un
logiciel comme l'établissement d'une suite de descriptions
de plus en plus précises et de plus en plus proches d'un
programme exécutable et de sa documentation. Les pas-
sages d'une description à une autre sont souvent appelés
des raffinements successifs. Cette vue sous-tend la plupart
des approches existantes. Mais elle est simplificatrice car
elle ne prend pas en compte une des caractéristiques du
processus de développement de logiciel qui est sa nature
itérative, certaines étapes déclenchant la révision du résul-
tat des étapes précédentes.
Par exemple, la détection d'erreurs au moment du test va
provoquer un retour sur la programmation ou la concep-
tion. De même, la conception peut faire apparaître des pro-
blèmes de spécification, etc.
Enfin, une autre particularité du développement de logi-
ciel est l'invisibilité de celui-ci : il est difficile d'observer
un logiciel en cours de développement et de se persuader
que le processus se déroule correctement.
D'où l'importance des documents intermédiaires
duits, des notations utilisées pour les descriptions, des acti-
vités de vérification et des outils de visualisation.
1 On pourraitaussiutiliserle terme" procédéde production
". Mais l'ex-
pression" processusde développementdu logiciel" semblemaintenant
consacrée.
Peu à peu, on a défini de façon précise les activi-
tés techniques nécessairesau développement d'un
logiciel : analyse des besoins, spécification globa-
le, conceptions architecturale et détaillée, pro-
grammation, gestion de configurations et intégra-
tion, validation et vérification, maquettage ou pro-
totypage rapide.
Le modèle de la cascade matérialise l'enchaîne-
ment des étapes de développement mais on lui
préfère souvent le modèle en V, plus récent, qui
présente une approche plus réaliste de l'articula-
tion entre les activités de réalisation et celles de
validation-vérification. Le modèle en spirale, plus
général, met !'accent sur l'analyse des risques.
Les modèles par incréments, où un seul sous-
ensemble des composants est développé à la fois,
souvent utiliséspour les grands projets, permettent
de mieux lisser dans le temps l'effort de dévelop-
pement et les effectifs, mais présentent davantage
de risques.
Detailed definitions have gradually been develo-
ped to describe the technical activities involved in
software development : needs analysis ; general
specification ; architectural and detailed design;
coding ; configuration management and integra-
tion ; validation and verification ; modelling and
rapid prototyping.
The cascade model describes sequencing of the
development stages, but the more recent V model
is often preferred, as it gives a more realistic pictu-
re of the relationship between the production and
va ! idation-verification activities. The more general
spiral model emphasizes risk control aspects.
pro-
: Incremental models, in which only a single subset
of the components is developed at a time, are
often used for major projects; they afford better
planning of development workload and personnel
requirements, but entail higher risks.

REE
N, 6
Juin1998

Une fois développé, un logiciel est mis en exploitation.
Se posent alors des problèmes de maintenance, qu'il
s'agisse de corriger des défauts, d'améliorer certaines
caractéristiques, ou de suivre les évolutions des besoins ou
de l'environnement.
La maintenance peut remettre en cause d'une manière
significative les fonctions du système et implique de ce fait
un processus de redéveloppement. C'est pourquoi on parle
de cycle de vie du logiciel quand on considère l'exploita-
tion et la maintenance en plus du développement.
Comme dans les autres domaines, le choix d'un processus
de développement est fonction des caractéristiques du futur
produit ainsi que du contexte du développement : il faut
prendre en compte des aspects techniques, des aspects liés à
l'organisation et des aspects humains. D'où la nécessité de
disposer de modèles de développement généraux, qui décri-
vent les enchaînements et les interactions entre activités.
Un tel modèle permet de définir un processus de déve-
loppement pour un projet donné en précisant les méthodes,
outils, et autres modalités associés à chacune des activités.
Les premiers modèles de développement de logiciel ont
été conçus dans un contexte où le savoir-faire se résumait à
" programmer et traquer les erreurs ".
À la fin des années 60, le concept de développement en
étapes (ou phases) est apparu. Une étape se termine par la
production de documents qui sont vérifiés et validés avant
de passer à l'étape suivante. Cela permet de contrôler
l'avancement des activités en cours et la validité des résul-
tats intermédiaires.
Il est intéressant de noter que les notions d'étapes et
d'activités sont différentes. Une étape peut faire intervenir
plusieurs activités ; par exemple, une étape de conception
du produit peut faire intervenir une activité de spécifica-
tion globale, une activité de maquettage et une activité de
validation. De plus, une activité peut se dérouler pendant
plusieurs étapes ou même pendant tout le processus (par
exemple, l'activité de documentation).
Le modèle de ce type le plus connu est le modèle de la
cascade (voir § 2). Ce type de modèle a été assez vite criti-
qué pour son aspect trop séquentiel, bien qu'il ait apporté
une amélioration très significative.
Les années 80 ont vu l'émergence du modèle en V (voir
§ 3), où les dépendances entre étapes sont plus élaborées et
où l'accent est mis sur les activités de validation et de véri-
fication. Ce modèle est actuellement le plus utilisé.
Enfin le récent modèle en spirale (voir §.4), plus com-
plet et plus complexe, introduit de nouveaux aspects
comme l'analyse de risques, et l'utilisation systématique
de maquettes pour s'assurer de la bonne compréhension
des besoins.
Ces modèles de développement ont pour but d'obtenir des
processus de développement rationnels, reproductibles et
contrôlables. Il n'est pas certain que ce but soit atteint à
100 % dès qu'on applique un modèle : la nature du logiciel
Modèles de développement du logiciel
rend les contrôles délicats et la véritable application d'un
processus dépend beaucoup de la discipline et de la compé-
tence des développeurs et de la volonté de leur encadrement.
Une notion de maturité du processus de développement
a été définie récemment par le SEI'. On classifie les pro-
cessus de développement selon cinq niveaux de maturité :
initial, reproductible, défini, géré, optimisé.
Un niveau peut être attribué à un ensemble de projets
ayant suivi le même processus dans une même organisa-
tion. Il est déterminé par des questionnaires, des entretiens
et des examens des documents produits. Il faut noter que
questionnaires et entretiens ne s'adressent pas seulement
aux équipes de développement mais à l'ensemble de l'or-
ganisation.
Les cinq niveaux sont caractérisés de la manière suivante :
- Initial : le processus est chaotique ; les coûts, délais et
la qualité sont imprévisibles ; les problèmes à résoudre en
priorité sont la gestion de projet, la gestion de configura-
tion et l'organisation de l'assurance qualité.
- Reproductible : le processus est artisanal et dépend
beaucoup des individus ; les délais sont fiables, les coûts et
la qualité sont variables, les méthodes sont mal définies ou
mal suivies ; les problèmes à résoudre en priorité sont la
formation, le choix de techniques précises et un renforce-
ment des contrôles qualitatifs.
- Défini : le processus est bien suivi mais essentiellement
d'une manière qualitative ; les délais et les coûts sont
fiables, la qualité est variable, les méthodes sont définies ;
les problèmes à résoudre en priorité sont l'analyse et les
mesures du processus et du produit (renforcement des
contrôles quantitatifs).
- Géré : le processus est contrôlé et mesuré ; la qualité
est fiable.
- Optimisé : chaque projet est analysé afin d'améliorer le
processus, donc les coûts, les délais, et la qualité.
Selon des résultats publiés en 1989 puis en 1991, de
l'ordre de 80 % des organisations américaines examinées
par le SEI étaient au niveau 1 (mais 30 % à la limite du
niveau 2), environ 15 % au niveau 2, et quelques brillantes
individualités au niveau 3. Il n'y a pas de données publiées
sur la situation en France.
LES ACTIVITÉS
Les différentes activités techniques nécessaires au déve-
loppement d'un logiciel sont maintenant définies de façon
plus précise. Chaque activité utilise et produit des docu-
ments (textes, programmes, traces d'exécution, etc.). Pour
chacune d'entre elles on précise brièvement ses données,
son résultat et son rôle.
2 SoftwareEngineering
Institute: il s'agit d'un organismecréépar le DoD
(Department of Defense,américain)et l'universitéCarnegieMellonà des
fins d'expertise,de certificationet de formationdans le domainedu génie
logiciel.
REE
N, 6
Juin1998
 LE GÉNIE LOGICIEL
Selon le processus de développement retenu et la nature
du logiciel à produire, ces activités ont plus ou moins
d'importance. Dans certains cas, elles peuvent même être
inutiles, par exemple, lorsque le logiciel à produire est une
évolution d'un produit existant.
Analyse des besoins
Le but de cette activité est d'éviter de développer un
logiciel non adéquat. On va donc étudier le domaine d'ap-
plication, ainsi que l'état actuel de l'environnement du
futur système afin d'en déterminer les frontières, le rôle,
les ressources disponibles et requises, les contraintes d'uti-
lisation et de performance, etc.
La particularité de cette activité est que ses données sont
fournies par des experts du domaine d'application et par
les futurs utilisateurs. L'équipe de développement doit éta-
blir un dialogue avec ces spécialistes du domaine d'appli-
cation qui ne sont pas forcément des informaticiens.
De ce fait les méthodes utilisées ne relèvent pas directe-
ment des techniques informatiques, mais plutôt des
sciences cognitives : entretiens, questionnaires, observa-
tions de l'existant, études de situations similaires.
Le résultat de cette activité est un ensemble de docu-
ments décrivant les aspects pertinents de l'environnement
du futur système, son rôle et sa future utilisation. Un
manuel d'utilisation préliminaire est parfois produit.
Le partage entre logiciel et matériel, quand il ne va pas
de soi, est défini en liaison avec les études de faisabilité.
L'analyse des besoins est l'activité essentielle au début
du processus de développement. Elle est alors menée en
liaison avec les études de faisabilité et la planification.
Cependant, elle se poursuit durant tout le processus de
développement (car des questions relatives aux besoins et
à l'environnement peuvent apparaître), et durant tout le
cycle de vie du logiciel (maintenance évolutive).
Spécification globale
Le but de cette activité est d'établir une première des-
cription du futur système. Ses données sont les résultats de
l'analyse des besoins ainsi que des considérations de tech-
nique et de faisabilité informatique. Son résultat est une
description de ce que doit faire le logiciel en évitant des
décisions prématurées de réalisation (on dit quoi, on ne dit
pas comment).
Cette description 3 va servir de point de départ au déve-
loppement. Une première version du manuel de référence
est parfois produite, ainsi que des compléments au manuel
d'utilisation.
Cette activité est fortement corrélée avec l'analyse des
besoins avec laquelle des échanges importants sont néces-
saires : dans les modèles de développement présentés plus
loin ces activités sont souvent regroupées dans la même étape.
Elle est aussi corrélée avec l'activité de validation (voir § 1.6).
3Cettedescription
estsouvent
appelée spécification technique
debesoins
: STB.
REE
NI 6
juin 1998
: LES CONCEPTS
Il est important de ne pas faire de choix d'implémenta-
tion prématurés lors de cette activité : il est trop difficile
d'anticiper leurs conséquences sur la réalisation finale en
termes de performances, ressources, ou même de faisabilité.
Conceptions architecturale et détaillée
L'activité de conception consiste à enrichir la descrip-
tion du logiciel de détails d'implémentation afin d'aboutir
à une description très proche d'un programme. Elle se
déroule souvent pendant deux étapes : l'étape de concep-
tion architecturale et l'étape de conception détaillée.
L'étape de conception architecturale a pour but de
décomposer le logiciel en composants plus simples. On
précise les interfaces et les fonctions de chaque composant.
A l'issue de cette étape, on obtient une description de l'ar-
chitecture du logiciel et un ensemble de spécifications de
ses divers composants.
L'étape de conception détaillée fournit, pour chaque
composant, une description de la manière dont les fonc-
tions du composant sont réalisées : algorithmes, représen-
tation des données
La frontière entre l'activité de spécification et les activi-
tés de conception est souvent floue. En effet, il ne serait
pas raisonnable de spécifier un système indépendamment
de toute considération de faisabilité.
Le fait que la conception soit possible démontre la faisa-
bilité : l'activité de conception commence souvent pendant
la spécification, et peut la remettre en cause.
De plus, dans de nombreux contextes, il existe des
contraintes de réalisation qui amènent à anticiper sur la
conception au moment de la spécification.
Programmation
Cette activité consiste à passer du résultat de la concep-
tion détaillée à un ensemble de programmes ou de compo-
sants de programmes. Elle est la mieux maîtrisée et la
mieux " outillée " : dans certains cas elle est même automa-
tisée.
Actuellement, l'activité de programmation ne représente
que de 15 à 20 % de l'effort de développement d'un logi-
ciel, voire seulement 10 % selon certains chiffres. La spé-
cification et la conception représentent environ 40 % de
l'effort dans un projet bien conduit. La validation et la
vérification représentent de l'ordre de 40 % de l'effort total
de développement.
Gestion de configurations et intégration
La gestion de configurations a pour but de permettre la
gestion des composants du logiciel, d'en maîtriser l'évolu-
tion et les mises à jour tout au long du processus de déve-
loppement.
Jusque récemment, cette activité n'était informatisée que
pour les textes de programmes et les autres documents
étaient gérés à part. Avec l'apparition d'environnements
intégrés de développement, tous les documents relatifs au

développement d'un logiciel peuvent être traités de maniè-
re homogène.
L'intégration consiste à assembler tout ou partie des
composants d'un logiciel pour obtenir un système exécu-
table. Cette activité utilise la gestion de configuration pour
assembler des versions cohérentes de chaque composant.
Souvent il existe plusieurs choix possibles pour certains
composants ; cela correspond à des variantes du logiciel,
en particulier pour des systèmes d'exploitation différents.
Les activités de gestion de configuration et d'intégration
permettent de gérer ces variantes.
Validation et vérification
Le problème de l'adéquation des résultats de l'analyse
des besoins et de la spécification globale est délicat.
La question posée est : a-t-on décrit le " bon " système,
c'est-à-dire un système qui répond à l'attente des utilisa-
teurs et aux contraintes de leur environnement ?
L'activité qui a pour but de s'assurer que la réponse à
cette question est satisfaisante s'appelle la validation.
Par opposition, l'activité qui consiste à s'assurer que les
descriptions successives du logiciel, et, in fine, le logiciel
lui-même, satisfont la spécification globale s'appelle la
vérification 4.
La question à laquelle on répond est : le développement
est-il correct par rapport à la spécification de départ ?
L'analyse des besoins et la spécification globale sont
donc intrinsèquement liées à l'activité de validation. De
même, les activités de conception et de programmation
impliquent de la vérification.
La validation consiste essentiellement en des revues et
inspections de spécifications ou de manuels, et du prototy-
page rapide (voir le paragraphe suivant).
La vérification inclut également des inspections de spé-
cifications ou de programme, ainsi que de la preuve et du
test.
Une preuve porte sur une spécification détaillée ou un
programme et permet de prouver que celle-ci ou celui-ci
satisfait bien la spécification de départ.
Le test consiste à rechercher des erreurs dans une spéci-
fication ou un programme. Cette recherche peut se faire
par examen ou analyse du texte : dans ce cas on parle de
test statique ; ou alors par des exécutions sur un sous-
ensemble fini des données possibles : on parle alors de test
dynami9ue.
On distingue plusieurs types de test selon l'avancement
du développement :
- le test unitaire consiste à tester des composants isolés ;
- le test d'intégration consiste à tester un ensemble de
composants qui viennent d'être assemblés ;
'On utiise aussilestermesvérificationexterneet vérification interneen
: Cesdeuxtermes serontutilisésindifféremment.
effet, la premièreactivité se fait par rapport au mondeextérieur, la
deuxièmeresteinterneau développement de logiciel.
Modèles de développement du logiciel
- le test système consiste à tester le système sur son futur
site d'exploitation, dans des conditions opérationnelles et
au-delà (surcharge, défaillances matérielles,...).
Rôle du maquettage
La principale difficulté de l'activité de validation est due
à l'imprécision des besoins et des caractéristiques du systè-
me à développer.
Ces besoins sont exprimés dans les termes du domaine
d'application, et souvent ils ne sont même pas complète-
ment exprimés.
Le maquettage, ou prototypage rapide 5 peut aider à
résoudre ce problème. Cette activité consiste à développer
très rapidement un programme qui est une ébauche du
futur système : il n'en a pas les performances, ni toutes les
fonctionnalités, et ne répond pas aux exigences de qualité
d'un produit fini.
Ce programme est ensuite soumis à des scénarios en liai-
son avec les futurs utilisateurs afin de préciser leurs
besoins ou leurs souhaits. On parle alors de maguette
exploratoire.
Cette activité peut également intervenir lors d'une étape
de conception : des choix différents peuvent être expéri-
mentés et comparés au moyen de maquettes. On parle alors
de maquette expérimentale.
Il est important de bien définir les objectifs d'une opéra-
tion de prototypage rapide, et d'en tenir compte pour la
conception de la maquette.
LE MODÈLE DE LA CASCADE
Le principe du modèle de la cascade (ou modèle de la
chute d'eau) est très simple : on convient d'avoir un cer-
tain nombre d'étapes (ou phases).
Une étape doit se terminer à une certaine date, par la
production de certains documents ou logiciels.
Les résultats de l'étape sont soumis à une revue appro-
fondie, et on ne passe à l'étape suivante que quand ils sont
jugés satisfaisants.
Dans l'exemple de la figure 1, certaines étapes portent le
nom d'une activité : cela signifie que l'activité est essen-
tielle pour cette étape, mais n'impose pas qu'elle n'ait lieu
que dans cette étape.
De plus d'autres activités interviennent. Par exemple, le
contrôle technique ou la gestion de configurations sont
présents tout au long du processus.
L'interaction entre étapes et activités sert de base pour
définir les résultats requis de chaque étape.
En touterigueur,le mot
françaismaquettecorrespondmieuxà la notionconsidérée.Mais la tra-
ductiondirectede l'anglais rapid prototyping est plus habituelle.
REE
N°6
Juin1998
 LE GÉNIE LOGICIEL : LES CONCEPTS

LE MODÈLE EN V

Ce modèle rend explicite le fait que les premières étapes

du développement, qui ont trait surtout à la construction
j m* Analyse
besoins
! du logiciel, doivent préparer les dernières étapes, qui font
1, il
intervenir essentiellement les activités de validation et de
vérification.
duproduit La figure 2 donne un exemple de modèle en V. Il y a
il
deux sortes de dépendances entre étapes :
Concepnon
Conception ! - celles matérialisées par des traits gras obliques, qui
detaiHée
détaillée j
il correspondent à l'enchaînement et à l'itération éventuelle
du modèle de la cascade ; les étapes se déroulent donc
\ ! Codage -
Codage)
'- séquentiellement en suivant le V de gauche à droite ;
- celles matérialisées par les flèches ombrées, qui repré-
't,\ il Intégration sentent le fait qu'une partie des résultats de l'étape de
départ est utilisée directement par l'étape d'arrivée ; par
iL ! ïnsta))
ation exemple, à l'issue de la conception architecturale, le proto-
cole d'intégration et les jeux de test d'intégration doivent
être complètement décrits.
Exploitation
etmaintenance Le principe de ce modèle est qu'avec toute décomposi-
tion doit être décrite la recomposition, et que toute descrip-
tion d'un composant est accompagnée des tests qui per-
1. Modèle de la cascade.
mettront de s'assurer qu'il correspond à sa description.
Ce principe évite un écueil bien connu de la spécifica-
tion de logiciel : on énonce une propriété qu'il est impos-
sible de vérifier objectivement une fois le logiciel réalisé.
De plus, l'obligation de concevoir les jeux de test et
Dans sa première version, le modèle ne comportait que
leurs résultats oblige à une réflexion et à des retours sur la
les flèches descendantes, qui matérialisent l'enchaînement
description en cours. Enfin, les étapes de la branche droite
des étapes, et ne prévoyait pas d'itération.
du V peuvent être mieux préparées et planifiées.
Les flèches ascendantes ont été ajoutées par la suite et
expriment le principe qu'une étape ne remet en cause que
l'étape précédente. Dans les faits, ce principe reste souvent
un voeu pieux et il y a toujours des problèmes qui se propa-
gent de bas en haut.
Les versions actuelles de ce modèle font apparaître la
validation-vérification dans chaque étape. On trouve donc Analyse des
successivement : besoins et Installat l
fnstaHationet
faisabilité test sysi testsyst&me
- avec la faisabilité et l'analyse des besoins de la valida- 1
tion ;
- avec la conception du produit et la conception !--------) ) --------
Test
détaillée, de la vérification ; Spécification d'acceptation d'acceptation
- avec le codage, du test unitaire ;
- avec l'intégration, du test d'intégration, puis du test I
d'acceptation ; i n In ion et test
- avec l'installation, du test système. architecturale
L d .tégration
Il existe de nombreux documents, normes ou recom-
mandations, qui décrivent très précisément des étapes et
leurs caractéristiques pour ce type de modèle (IEEE, Conception Test unitaire
CcepMn
détaillée Testunitaire
AFNOR).
Cependant ce modèle, séduisant par sa simplicité, est s
souvent abandonné au profit du modèle en V, plus récent,
Programmation
qui présente une approche plus réaliste de l'articulation
entre les activités de réalisation et celles de validation-
vérification. 2. Modèle en V.

REE
6
38 juin 1998
1
" , -1 1 " "
1- t-i1
 Modèles de développement du logiciel

LE MODÈLE EN SPIRALE La figure 4 donne la liste des dix risques majeurs et,

pour chacun, des mots-clés indiquent des solutions à envi-

Ce modèle, proposé par B. Boehm en 1988, est beau-
sager. Cette liste est donnée à titre d'exemple et de point
coup plus général que les précédents et peut les inclure. de départ d'une analyse de risque : elle doit être adaptée à
Il met l'accent sur une activité particulière, l'analyse de
chaque contexte.
risques : chaque cycle de la spirale, qui apparaît à la figure
3, se déroule en quatre phases représentées par des qua- La mise en oeuvre du modèle
drants : Un développement selon ce modèle commence par une
1. détermination des objectifs du cycle, des alternatives analyse préliminaire de besoins qui est affinée au cours des
pour les atteindre, des contraintes, à partir des résultats des premiers cycles, en prenant en compte les contraintes et
cycles précédents, ou, si il n'y en a pas, d'une analyse pré- l'analyse des risques.
liminaire des besoins. Le modèle utilise systématiquement des maquettes, qui
2. analyse des risques, évaluation des alternatives, éven- durant ces cycles sont de nature exploratoire. Les troi-
tuellement maquettage ; sièmes quadrants des cycles suivants correspondent à de la

3. développement et vérification de la solution retenue ; conception, les choix étant guidés par des maquettes expé-
4. revue des résultats et planification du cycle suivant. rimentales. Le dernier cycle se termine par la fin d'un pro-
cessus de développement classique.
Le quadrant 3 correspond à un développement ou à une
La mise en oeuvre de ce modèle demande des compétences
portion de développement classique, et un des modèles
et un effort importants. De plus, ce modèle a été moins expé-
précédents (de la cascade ou en V) peut s'appliquer : son
choix peut faire partie des alternatives à évaluer. rimenté que les précédents et est moins documenté.
Du fait qu'il fait abondamment appel à l'analyse de
L'originalité de ce " super " modèle est d'encadrer le déve-
loppement proprement dit par des phases consacrées à la risques, il paraît a priori raisonnable de limiter son utilisa-
détermination des objectifs et à l'analyse de risque. tion complète à des projets innovants, à risques, et dont les

enjeux sont importants.

Les risques majeurs du développement
de logiciel

Un des intérêts du modèle en spirale est de fournir des . Défaillance de personnel : embauche de personnel de

listes des risques encourus lors d'un développement de haut niveau ; adéquation entre profil et fonction ; esprit

logiciel et de suggérer des solutions. d'équipe ; formation mutuelle ; personnes- clés.

. Calendrier et budget irréalistes : estimation détaillée

des coûts et calendriers ; développement incrémental ;

Analyse de risque 2 réutilisation ; élagage des besoins.

Analyse
derisque Développement de fonctions inappropriées : analyse de
l'organisation ; analyse de la mission ; formulation des
Analyscderisque concepts opérationnels ; revues d'utilisateurs ; manuel
Prototype d'utilisation précoce.
Prototype
desobjectifs,, ; s ue
Développement d'interfaces utilisateurs inappro-
desalternatives,
des contraintes prototype2 ; priées : maquettage ; scénarios et revues d'utilisateurs ;
Prototype 1
analyse des tâches.
desobjectifs../\ \ \ \ · Produit " plaqué or " : élagage des besoins ; maquetta-
ng général
p lan
P n Concepts sii lation, modélisation, benchmuk
ge ; analyse des coûts-bénéfices ; conception prenant en
du
du-pprojet
0 d'opération
compte les coûts.
Volatilité des besoins : seuil élevé de modification ;
) Plan
Test de
\/
développement Validation des besoin Conception masquage d'information ; développement incrémental où
détaillé
les derniers incréments sont les plus changeants.
· Composants externes manquants : inspections ; essais
suvre
d'
4 3égat.n
i et mesures ; analyse de compatibilité.
etde
detest
test Vérif-cation tégration - Tâches externes défaillantes : audit avant attribution de
ettest sous-traitance ; contrats avec bonus ; revues.
Test
Misee système . Problèmes de performances : simulations ; modélisa-
oeuvre
tions ; essais et mesures ; maquettage.

Exigences démesurées par rapport à la technologie :

analyses techniques de faisabilité, maquettage.

3. Modèle de la spirale. 4. Risques majeurs.

REE
N'6
Juin 1998
11,
, -.-i i
 LE GÉNIE LOGICIEL : LES CONCEPTS

conception conception programmation 1 tests

incrément 1
architecturale détaillée

conception conception programmation.

incrément 2
architecturale détaillée

conception conception.
incrément 3
architecturale détaillée

temps

5. Modèle par incrément.

Dans les autres cas, l'analyse de risque garde néanmoins La spécification du noyau, des incréments, et de leurs
tout son intérêt et on peut l'introduire dans les modèles interactions doit donc être faite globalement, au début du

classiques, dans une ou plusieurs étapes. projet.

Les incréments doivent être aussi indépendants que pos-

MODÈLES PAR INCRÉMENTS sible, aussi bien fonctionnellement qu'au niveau des calen-

Dans les modèles présentés jusqu'ici, il est implicite driers de développement.

qu'après une décomposition en composants (qui résulte de

la conception architecturale), ces composants sont déve-

loppés indépendamment les uns des autres, en parallèle ou Bibliographie

en séquence, selon les ressources disponibles.
[1] BOEHM (B.W.) : A spiral model of software development
Dans les modèles par incréments, un seul sous-ensemble and enhancement, IEEE Computer, vol. 21, n° 5, pp. 61-72,
des composants est développé à la fois : un logiciel noyau Mai 1988.

est tout d'abord développé, puis des incréments sont suc-

[2] DE MARCO JT.), LISTER (T.) : Les hommes de l'ordinateur,
cessivement développés et intégrés.
Masson, 1991.
Le processus de développement de chaque incrément est
un des processus classiques. [31 HUMPHREY JW.S.) : Managing thé Software Process,
Les avantages de ce type de modèle sont nombreux : Addison-Wesley, 1989.
- chaque développement est moins complexe ;
[4] Mc DERM ! D (J.A.) Ed : Software Engineer's Reference Book,
- les intégrations sont progressives ;
Chapitre 15, Butterworths, 1991.
- il peut y avoir des livraisons et des mises en service

après chaque intégration d'incrément.

Marie-Claude GAUDEL a obtenu sa thèse d'état en 1981 à l'INPL
Cette approche est souvent utilisée pour de grands pro-
(Nancy), alors qu'elleétait chercheurà l'INRIA. Elle a ensuitedirigé l'équipede
jets, fonctionnant par appels d'offres et sous-traitances. génielogiciel desLaboratoiresde Marcoussis(Alcatel-Alsthom-recherches) jus-
Ce modèle permet également de mieux lisser dans le qu'en 1984.Actuellement,elle est professeurà l'universitéde Paris-Sudà Orsay
et effectue ses recherchesau Laboratoirede rechercheen informatique (LRI)
temps l'effort de développement et les effectifs. En effet dont elle a été le directeurde 1985à 1991.Sondomainede rechercheest la spé-
dans les modèles de la cascade ou en V, cet effort et ces cificationformellede logiciel.Sesprincipaux résultats concernent le traitement
effectifs augmentent beaucoup au moment de la spécifica- des exceptions, la réutilisation et le test. Marie-Claude Gaudel est docteur
Honoris Causade l'EPFL et a reçu récemmentla médaille d'argentdu CNRS
tion détaillée pour diminuer significativement au moment
pour l'ensemblede sestravaux.
du test d'intégration. De plus, les compétences nécessaires
Bruno MARRE est chargé de recherche au CNRS, au Laboratoire de
varient beaucoup selon les étapes.
rechercheen informatiqueà Orsay(LRI, URA 410 du CNRS). Il s'intéresseà la
Dans la plupart des modèles par incréments, les dévelop- validation et à la vérification de logiciels à partir de spécificationsformelles.il
étudiel'utilisation desformalismes de spécifications et l'assistance
à la sélection
pements se recouvrent comme dans la figure 5, ce qui per-
dejeux en testsfonctionnels.
met d'atténuer ce problème.
Ces modèles présentent également des risques impor- Françoise SCHLIENGER a obtenusa thèseen 1984, sur un environne-
ment Ada intégrantdesspécifications algébriques, aprèsavoir passédeuxans
tants et doivent être utilisés avec précaution. dansl'équipe de Génielogiciel desLaboratoiresde Marcoussis.Elle est actuel-
Le risque majeur est de voir remettre en cause le noyau lementmaîtrede conférences dansuneFormationd'ingénieurs en informatique
de la Faculté d'Orsay(FIIFO, Université Paris-Sud)et effectue ses recherches
ou les incréments précédents. Un autre risque est d'être
au Laboratoirede recherchesen informatique(LRI). Sestravaux actuelsportent
incapable d'intégrer un incrément. sur les méthodesd'analyse,de spécificationet de conceptionorientées-objets.

REE
N'6
juin 1998

View publication stats