Vous êtes sur la page 1sur 8

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

REE
N, 6
Juin1998
Modèles de développement du logiciel

Une fois développé, un logiciel est mis en exploitation. rend les contrôles délicats et la véritable application d'un
Se posent alors des problèmes de maintenance, qu'il processus dépend beaucoup de la discipline et de la compé-
s'agisse de corriger des défauts, d'améliorer certaines tence des développeurs et de la volonté de leur encadrement.
caractéristiques, ou de suivre les évolutions des besoins ou Une notion de maturité du processus de développement
de l'environnement. a été définie récemment par le SEI'. On classifie les pro-
La maintenance peut remettre en cause d'une manière cessus de développement selon cinq niveaux de maturité :
significative les fonctions du système et implique de ce fait initial, reproductible, défini, géré, optimisé.
un processus de redéveloppement. C'est pourquoi on parle Un niveau peut être attribué à un ensemble de projets
de cycle de vie du logiciel quand on considère l'exploita-
ayant suivi le même processus dans une même organisa-
tion et la maintenance en plus du développement. tion. Il est déterminé par des questionnaires, des entretiens
Comme dans les autres domaines, le choix d'un processus et des examens des documents produits. Il faut noter que
de développement est fonction des caractéristiques du futur questionnaires et entretiens ne s'adressent pas seulement
produit ainsi que du contexte du développement : il faut aux équipes de développement mais à l'ensemble de l'or-
prendre en compte des aspects techniques, des aspects liés à ganisation.
l'organisation et des aspects humains. D'où la nécessité de Les cinq niveaux sont caractérisés de la manière suivante :
disposer de modèles de développement généraux, qui décri- - Initial : le processus est chaotique ; les coûts, délais et
vent les enchaînements et les interactions entre activités.
la qualité sont imprévisibles ; les problèmes à résoudre en
Un tel modèle permet de définir un processus de déve-
priorité sont la gestion de projet, la gestion de configura-
loppement pour un projet donné en précisant les méthodes, tion et l'organisation de l'assurance qualité.
outils, et autres modalités associés à chacune des activités. - Reproductible : le processus est artisanal et dépend
Les premiers modèles de développement de logiciel ont
beaucoup des individus ; les délais sont fiables, les coûts et
été conçus dans un contexte où le savoir-faire se résumait à la qualité sont variables, les méthodes sont mal définies ou
" programmer et traquer les erreurs ".
mal suivies ; les problèmes à résoudre en priorité sont la
À la fin des années 60, le concept de développement en formation, le choix de techniques précises et un renforce-
étapes (ou phases) est apparu. Une étape se termine par la ment des contrôles qualitatifs.
production de documents qui sont vérifiés et validés avant - Défini : le processus est bien suivi mais essentiellement
de passer à l'étape suivante. Cela permet de contrôler d'une manière qualitative ; les délais et les coûts sont
l'avancement des activités en cours et la validité des résul-
fiables, la qualité est variable, les méthodes sont définies ;
tats intermédiaires.
les problèmes à résoudre en priorité sont l'analyse et les
Il est intéressant de noter que les notions d'étapes et mesures du processus et du produit (renforcement des
d'activités sont différentes. Une étape peut faire intervenir contrôles quantitatifs).
plusieurs activités ; par exemple, une étape de conception - Géré : le processus est contrôlé et mesuré ; la qualité
du produit peut faire intervenir une activité de spécifica-
est fiable.
tion globale, une activité de maquettage et une activité de
- Optimisé : chaque projet est analysé afin d'améliorer le
validation. De plus, une activité peut se dérouler pendant
processus, donc les coûts, les délais, et la qualité.
plusieurs étapes ou même pendant tout le processus (par
Selon des résultats publiés en 1989 puis en 1991, de
exemple, l'activité de documentation).
l'ordre de 80 % des organisations américaines examinées
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- par le SEI étaient au niveau 1 (mais 30 % à la limite du
niveau 2), environ 15 % au niveau 2, et quelques brillantes
qué pour son aspect trop séquentiel, bien qu'il ait apporté
individualités au niveau 3. Il n'y a pas de données publiées
une amélioration très significative.
sur la situation en France.
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- LES ACTIVITÉS
fication. Ce modèle est actuellement le plus utilisé.
Les différentes activités techniques nécessaires au déve-
Enfin le récent modèle en spirale (voir §.4), plus com-
loppement d'un logiciel sont maintenant définies de façon
plet et plus complexe, introduit de nouveaux aspects plus précise. Chaque activité utilise et produit des docu-
comme l'analyse de risques, et l'utilisation systématique ments (textes, programmes, traces d'exécution, etc.). Pour
de maquettes pour s'assurer de la bonne compréhension chacune d'entre elles on précise brièvement ses données,
des besoins. son résultat et son rôle.
Ces modèles de développement ont pour but d'obtenir des
2 SoftwareEngineering
Institute: il s'agit d'un organismecréépar le DoD
processus de développement rationnels, reproductibles et
(Department of Defense,américain)et l'universitéCarnegieMellonà des
contrôlables. Il n'est pas certain que ce but soit atteint à fins d'expertise,de certificationet de formationdans le domainedu génie
100 % dès qu'on applique un modèle : la nature du logiciel logiciel.

REE
N, 6
Juin1998
LE GÉNIE LOGICIEL : LES CONCEPTS

Selon le processus de développement retenu et la nature Il est important de ne pas faire de choix d'implémenta-
du logiciel à produire, ces activités ont plus ou moins tion prématurés lors de cette activité : il est trop difficile
d'importance. Dans certains cas, elles peuvent même être d'anticiper leurs conséquences sur la réalisation finale en
inutiles, par exemple, lorsque le logiciel à produire est une termes de performances, ressources, ou même de faisabilité.
évolution d'un produit existant.
Conceptions architecturale et détaillée
Analyse des besoins L'activité de conception consiste à enrichir la descrip-
Le but de cette activité est d'éviter de développer un tion du logiciel de détails d'implémentation afin d'aboutir
logiciel non adéquat. On va donc étudier le domaine d'ap- à une description très proche d'un programme. Elle se
plication, ainsi que l'état actuel de l'environnement du déroule souvent pendant deux étapes : l'étape de concep-
futur système afin d'en déterminer les frontières, le rôle, tion architecturale et l'étape de conception détaillée.
les ressources disponibles et requises, les contraintes d'uti- L'étape de conception architecturale a pour but de
lisation et de performance, etc. décomposer le logiciel en composants plus simples. On
La particularité de cette activité est que ses données sont précise les interfaces et les fonctions de chaque composant.
fournies par des experts du domaine d'application et par A l'issue de cette étape, on obtient une description de l'ar-
les futurs utilisateurs. L'équipe de développement doit éta- chitecture du logiciel et un ensemble de spécifications de
blir un dialogue avec ces spécialistes du domaine d'appli- ses divers composants.
cation qui ne sont pas forcément des informaticiens. L'étape de conception détaillée fournit, pour chaque
De ce fait les méthodes utilisées ne relèvent pas directe- composant, une description de la manière dont les fonc-
ment des techniques informatiques, mais plutôt des tions du composant sont réalisées : algorithmes, représen-
sciences cognitives : entretiens, questionnaires, observa- tation des données
tions de l'existant, études de situations similaires. La frontière entre l'activité de spécification et les activi-
Le résultat de cette activité est un ensemble de docu- tés de conception est souvent floue. En effet, il ne serait
ments décrivant les aspects pertinents de l'environnement pas raisonnable de spécifier un système indépendamment
du futur système, son rôle et sa future utilisation. Un de toute considération de faisabilité.
manuel d'utilisation préliminaire est parfois produit. Le fait que la conception soit possible démontre la faisa-
Le partage entre logiciel et matériel, quand il ne va pas bilité : l'activité de conception commence souvent pendant
de soi, est défini en liaison avec les études de faisabilité. la spécification, et peut la remettre en cause.

L'analyse des besoins est l'activité essentielle au début De plus, dans de nombreux contextes, il existe des
du processus de développement. Elle est alors menée en contraintes de réalisation qui amènent à anticiper sur la
liaison avec les études de faisabilité et la planification. conception au moment de la spécification.
Cependant, elle se poursuit durant tout le processus de
développement (car des questions relatives aux besoins et Programmation
à l'environnement peuvent apparaître), et durant tout le Cette activité consiste à passer du résultat de la concep-
cycle de vie du logiciel (maintenance évolutive). tion détaillée à un ensemble de programmes ou de compo-
sants de programmes. Elle est la mieux maîtrisée et la
Spécification globale mieux " outillée " : dans certains cas elle est même automa-
Le but de cette activité est d'établir une première des- tisée.
cription du futur système. Ses données sont les résultats de Actuellement, l'activité de programmation ne représente
l'analyse des besoins ainsi que des considérations de tech- que de 15 à 20 % de l'effort de développement d'un logi-
nique et de faisabilité informatique. Son résultat est une ciel, voire seulement 10 % selon certains chiffres. La spé-
description de ce que doit faire le logiciel en évitant des cification et la conception représentent environ 40 % de
décisions prématurées de réalisation (on dit quoi, on ne dit l'effort dans un projet bien conduit. La validation et la
pas comment). vérification représentent de l'ordre de 40 % de l'effort total
Cette description 3 va servir de point de départ au déve- de développement.
loppement. Une première version du manuel de référence
Gestion de configurations et intégration
est parfois produite, ainsi que des compléments au manuel
d'utilisation. La gestion de configurations a pour but de permettre la
Cette activité est fortement corrélée avec l'analyse des gestion des composants du logiciel, d'en maîtriser l'évolu-
besoins avec laquelle des échanges importants sont néces- tion et les mises à jour tout au long du processus de déve-
saires : dans les modèles de développement présentés plus loppement.
loin ces activités sont souvent regroupées dans la même étape. Jusque récemment, cette activité n'était informatisée que
Elle est aussi corrélée avec l'activité de validation (voir § 1.6). pour les textes de programmes et les autres documents
étaient gérés à part. Avec l'apparition d'environnements
3Cettedescription
estsouvent
appelée spécification technique
debesoins
: STB. intégrés de développement, tous les documents relatifs au

REE
NI 6
juin 1998
Modèles de développement du logiciel

- le test système consiste à tester le système sur son futur


développement d'un logiciel peuvent être traités de maniè-
re homogène. site d'exploitation, dans des conditions opérationnelles et
L'intégration consiste à assembler tout ou partie des au-delà (surcharge, défaillances matérielles,...).
composants d'un logiciel pour obtenir un système exécu-
Rôle du maquettage
table. Cette activité utilise la gestion de configuration pour
assembler des versions cohérentes de chaque composant. La principale difficulté de l'activité de validation est due
Souvent il existe plusieurs choix possibles pour certains à l'imprécision des besoins et des caractéristiques du systè-
me à développer.
composants ; cela correspond à des variantes du logiciel,
en particulier pour des systèmes d'exploitation différents. Ces besoins sont exprimés dans les termes du domaine
Les activités de gestion de configuration et d'intégration d'application, et souvent ils ne sont même pas complète-
ment exprimés.
permettent de gérer ces variantes.
Le maquettage, ou prototypage rapide 5 peut aider à
Validation et vérification résoudre ce problème. Cette activité consiste à développer
Le problème de l'adéquation des résultats de l'analyse très rapidement un programme qui est une ébauche du
des besoins et de la spécification globale est délicat. futur système : il n'en a pas les performances, ni toutes les
La question posée est : a-t-on décrit le " bon " système, fonctionnalités, et ne répond pas aux exigences de qualité
c'est-à-dire un système qui répond à l'attente des utilisa- d'un produit fini.
teurs et aux contraintes de leur environnement ? Ce programme est ensuite soumis à des scénarios en liai-
L'activité qui a pour but de s'assurer que la réponse à son avec les futurs utilisateurs afin de préciser leurs
cette question est satisfaisante s'appelle la validation. besoins ou leurs souhaits. On parle alors de maguette
Par opposition, l'activité qui consiste à s'assurer que les exploratoire.
descriptions successives du logiciel, et, in fine, le logiciel Cette activité peut également intervenir lors d'une étape
lui-même, satisfont la spécification globale s'appelle la de conception : des choix différents peuvent être expéri-
vérification 4. mentés et comparés au moyen de maquettes. On parle alors
La question à laquelle on répond est : le développement de maquette expérimentale.
est-il correct par rapport à la spécification de départ ? Il est important de bien définir les objectifs d'une opéra-
tion de prototypage rapide, et d'en tenir compte pour la
L'analyse des besoins et la spécification globale sont
donc intrinsèquement liées à l'activité de validation. De conception de la maquette.
même, les activités de conception et de programmation
impliquent de la vérification. LE MODÈLE DE LA CASCADE
La validation consiste essentiellement en des revues et
Le principe du modèle de la cascade (ou modèle de la
inspections de spécifications ou de manuels, et du prototy- chute d'eau) est très simple : on convient d'avoir un cer-
page rapide (voir le paragraphe suivant). tain nombre d'étapes (ou phases).
La vérification inclut également des inspections de spé-
Une étape doit se terminer à une certaine date, par la
cifications ou de programme, ainsi que de la preuve et du
production de certains documents ou logiciels.
test.
Les résultats de l'étape sont soumis à une revue appro-
Une preuve porte sur une spécification détaillée ou un
fondie, et on ne passe à l'étape suivante que quand ils sont
programme et permet de prouver que celle-ci ou celui-ci
jugés satisfaisants.
satisfait bien la spécification de départ.
Dans l'exemple de la figure 1, certaines étapes portent le
Le test consiste à rechercher des erreurs dans une spéci-
nom d'une activité : cela signifie que l'activité est essen-
fication ou un programme. Cette recherche peut se faire
tielle pour cette étape, mais n'impose pas qu'elle n'ait lieu
par examen ou analyse du texte : dans ce cas on parle de
que dans cette étape.
test statique ; ou alors par des exécutions sur un sous-
De plus d'autres activités interviennent. Par exemple, le
ensemble fini des données possibles : on parle alors de test
contrôle technique ou la gestion de configurations sont
dynami9ue.
présents tout au long du processus.
On distingue plusieurs types de test selon l'avancement
L'interaction entre étapes et activités sert de base pour
du développement :
définir les résultats requis de chaque étape.
- 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. En touterigueur,le mot
effet, la premièreactivité se fait par rapport au mondeextérieur, la françaismaquettecorrespondmieuxà la notionconsidérée.Mais la tra-
deuxièmeresteinterneau développement de logiciel. 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

Vous aimerez peut-être aussi