CYCLE DE VIE DU LOGICIEL

Alfred Strohmeier
Laboratoire de Génie Logiciel - Département d’Informatique
Ecole Polytechnique Fédérale de Lausanne

Table des matières

1. Crise du logiciel et génie logiciel
2. Domaine du génie logiciel
3. Cycle de vie du logiciel
4. Cycle de développement du logiciel
5. Phases du cycle de développement
6. Autres modèles de développement
7. Notion de système
Références

1. Crise du logiciel et génie logiciel

Alors que le matériel informatique a fait, et continue de faire, des pro-
grès très rapides, le logiciel, l'autre ingrédient de l'informatique, traverse
une véritable crise. Etant donné que cette crise a été décelée en 1969 déjà et
qu'elle dure toujours, il serait plus approprié de parler d'une maladie chroni-
que.
La crise du logiciel (software crisis) peut tout d'abord se percevoir à
travers ses symptomes:
• Le coût de développement d'un logiciel est presque impossible à
prévoir et le délai de livraison n'est que rarement respecté. On cite
ainsi dans la littérature des dépassements moyens du coût budgeté et
du délai prévu respectivement de 70% et 50%.
• La qualité du logiciel livré est souvent déficiente. Le produit ne
satisfait pas les besoins de l'utilisateur, il consomme plus de ressour-
ces que prévu et il est à l'origine de pannes.
• La maintenance du logiciel est difficile, coûteuse et souvent à l'ori-
gine de nouvelles erreurs. Mais en pratique, il est indispensable

1 13. Mar 2000

 d'adapter les logiciels car leurs environnements d'utilisation chan-
gent et les besoins des utilisateurs évoluent.
• Il est rare qu'on puisse réutiliser un logiciel existant ou un de ses
composants pour confectionner un nouveau système, même si celui-
ci comporte des fonctions similaires. Tout amortissement sur plu-
sieurs projets est ainsi rendu impossible.

La crise du logiciel a ensuite des conséquences économiques:

aujourd'hui le coût du logiciel est supérieur à celui du matériel. Même si des
chiffres précis font défaut, les experts sont unanimes quant à la tendance:
partant d'une proportion 50%-50% en 1965, et passant par 70%-30% en
1975, ce rapport avait atteint 80%-20% en 1985. Mais pas seulement en pro-
portion, en valeur également, le coût du logiciel croît à une vitesse vertigi-
neuse. On peut montrer que cette inflation des coûts est surtout due aux frais
de maintenance, situés actuellement entre 40% et 75% du coût total d'un
système informatique (matériel et logiciel). Or ces frais de maintenance
résultent avant tout de la qualité déficiente du logiciel, au moment de sa
livraison déjà ou après qu'il ait évolué.
La raison de fond de la crise du logiciel réside dans le fait qu'il est
beaucoup plus difficile de créer des logiciels que le suggère notre intuition.
Comme les solutions informatiques sont essentiellement constituées de
composants immatériels, tels des programmes, des données à traiter, des
procédures et de la documentation, on sous-estime facilement leur com-
plexité. Déjà la taille des programmes montre que cette complexité est sou-
vent bien réelle: un million de lignes pour un logiciel de commande et de
navigation d'un avion moderne, le décuple pour une station orbitale.
Pour maîtriser la complexité des systèmes logiciels, il convient de pro-
céder selon une démarche bien définie, de se baser sur des principes et
méthodes, et d'utiliser des outils performants. On arrive ainsi à gérer des
projets complexes et à élaborer scientifiquement des solutions. Le génie
logiciel (software engineering) cherche donc à établir et à utiliser des princi-
pes sains d'ingénierie dans le but de développer économiquement du logiciel
qui est fiable et qui fonctionne efficacement sur des machines réelles.
Arrivé à ce point, il nous semble important de définir un certain nom-
bre de notions inhérentes au génie logiciel.
Commençons par la notion de logiciel. L'Organisation internationale
de normalisation, appelée brièvement ISO, a défini en 1981 le logiciel
(software) comme une création intellectuelle rassemblant des programmes,
des procédures, des règles et de la documentation utilisés pour faire fonc-
tionner un système informatique. Pour renforcer le caractère intellectuel du
logiciel, l'ISO précise en plus que le logiciel existe indépendemment des
supports utilisés pour le transporter, ce qui sous-entend qu'il ne faut pas con-

2 13. Mar 2000

fondre le logiciel avec son support.
Le mot génie, utilisé en général accompagné d'un adjectif, comme dans
génie civil, génie chimique ou génie atomique, désigne, d'après le Petit
Robert, les connaissances et techniques de l'ingénieur. Ce terme est donc
synonyme de science de l'ingénieur (engineering) qui peut être définie
comme l'application des sciences et mathématiques par laquelle les proprié-
tés de la matière et les sources d'énergie de la nature sont rendues utiles à
l'homme dans des constructions, machines, produits, systèmes et procédés
(traduit de l'anglais d'après le dictionnaire Webster).
Une première définition du génie logiciel consiste donc à dire qu'il
s'agit de la science de l'ingénieur-informaticien spécialiste du logiciel. En
explicitant cette définition, on peut encore affirmer que le génie logiciel est
l'application des sciences et mathématiques par laquelle les possibilités d'un
équipement informatique sont rendues utiles à l'homme à l'aide de program-
mes, de procédures, de règles et de la documentation associée [1].
Remarquons maintenant que le mot anglais engineering possède par
ailleurs un sens plus restrictif traduit en français par ingénierie, dont c'est la
seule acception. D'après le Petit Robert, l'ingénierie est l'étude globale d'un
projet industriel sous tous ses aspects (techniques, économiques, financiers
et sociaux) coordonnant les études particulières de plusieurs équipes de spé-
cialistes. Une deuxième définition possible, complémentaire de la première,
du génie logiciel est donc la suivante: Le génie logiciel cherche à établir et à
utiliser des principes sains d'ingénierie dans le but de développer économi-
quement du logiciel qui satisfait les besoins, qui est fiable et qui fonctionne
efficacement sur des machines réelles (d'après Fritz Bauer, 1969).
L'une et l'autre des définitions que nous venons de voir montrent que
l'objectif premier du génie logiciel, comme d'ailleurs de toutes les sciences
de l'ingénieur, n'est pas l'acquisition de nouvelles connaissances, mais plutôt
leur mise en application, donc l'accumulation de savoir-faire. Il en résulte
que le génie logiciel ne constitue qu'une petite partie de l'informatique, mot
intraduisible en anglais si ce n'est par informatics, puisqu'il inclut à la fois la
science et la technique du traitement de l'information, alors que l'anglais uti-
lise des termes spécifiques: computer science, d'une part, computer enginee-
ring et software engineering, d'autre part.

2. Domaine du génie logiciel

Une autre façon d'appréhender le génie logiciel est d'en définir le con-
tenu. Ce contenu peut être structuré de différentes façons, chacune mettant
l'accent sur un autre point de vue.
Comme toute science de l'ingénieur, le génie logiciel est régi par des

3 13. Mar 2000

règles et des normes (standard). L'association professionnelle IEEE a éla-
boré une classification des normes du génie logiciel ayant la référence
ANSI/IEEE 1002 [2].
Une première classification caractérise les contenus des normes par des
mots-clés que nous allons décrire ci-dessous (fig. 1).
Procédé (process) Profession
Méthode (method) Titre et fonction (occupational title)
Technique (technique) Code de déontologie (code of ethics)
Outil (tool) Certification (certification)
Mesure (measurement) License (licensing)
Formation (curriculum)
Produit (product)
Analyse (requirement) Notation (notation)
Conception (design) Terminologie (nomenclature)
Composant (component) Représentation (representation)
Plan (plan) Langage (language)
Rapport (report)

Fig. 1 Classification des normes du génie logiciel d'après le contenu

(Tableau extrait de ANSI/IEEE 1002)
Un procédé (process) décrit la suite des actions et opérations à entre-
prendre pour développer un produit ou fournir un service. Les actions et
opérations utilisent des méthodes (method), techniques (technique) et outils
(tool). Pour évaluer un procédé, ou un produit, on effectue des mesures
(measurement). Un procédé répond donc aux questions: qui doit faire le tra-
vail? que faut-il faire? comment faut-il faire le travail? quand faut-il le
faire? et à quel niveau de détail faut-il faire le travail?
Les produits (product) sont les résultats documentés des activités de
développement et de maintenance, et fournissent les bases pour des activités
futures. La norme d'un produit précise son format et son contenu.
Les normes de la profession (professional standard) traitent des
aspects du génie logiciel qui en font une profession, ou en tout cas une spé-
cialité de l'informatique. Un plan d'études d'ingénieur en génie logiciel en
est un exemple.
Les notations (notation) constituent le moyen de communication entre
professionnels.
En résumé, dans cette vue du génie logiciel, on peut dire que le résultat
d'un procédé est un produit, et qu'un procédé est mis en oeuvre par des per-
sonnes qui utilisent des méthodes, techniques, outils et notations communs à
la profession.
En se référent toujours à ANSI/IEEE 1002, on peut également décrire
le contenu du génie logiciel en énumérant les activités typiques qui en font
partie (fig. 2).

4 13. Mar 2000

 Ingénierie du produit (product engineering)
Analyse des besoins (requirements analysis)
Conception (design)
Codage (coding)
Intégration (integration)
Conversion (conversion)
Débogage (debugging)
Support du produit (product support)
Maintenance (maintenance)
Vérification et validation (verification and validation)
Revues et audits (reviews and audits)
Analyse du produit (product analysis)
Test (testing)
Gestion technique (technical management)
Gestion du processus (process management)
Gestion du produit (product management)
Gestion des ressources (resource management)

Fig. 2 Classification des activités du génie logiciel

(Tableau extrait de ANSI/IEEE 1002)
Une activité (job function) est un processus identifiable du génie logi-
ciel. Les activités s'effectuent souvent en parallèle. Par exemple, un docu-
ment de conception peut être mis à jour pendant que des composants
logiciels sont implémentés. Il n'existe pas de séquence temporelle stricte
entre activités, puisque la planification, l'exécution et le suivi d'une activité
chevauchent certainement d'autres activités.
Les activités peuvent être subdivisées en trois groupes: les activités
d'ingénierie du produit, les activités de vérification et de validation, et les
activités de gestion technique. Ces trois groupes contiennent les activités
majeures se déroulant en parallèle, visant à produire, vérifier et piloter, sans
être concentrées dans une seule phase du cycle de vie.
Les activités d'ingénierie du produit (product engineering function)
sont celles qui sont nécessaires pour définir, réaliser et supporter le logiciel
qui constitue le produit final. Nous reviendrons en détail sur ces activités
quand nous parlerons du cycle de vie du logiciel.
Les activités de vérification et de validation (verification and valida-
tion function) sont les activités techniques déployées pour maîtriser la qua-
lité du produit. La validation (validation) d'un produit, qu'il s'agisse d'un
produit intermédiaire ou final, revient à s'assurer qu'on a construit le bon
produit. Les critères appliqués sont donc externes au produit lui-même.
Valider un produit final revient à s'assurer qu'il est conforme à son cahier
des charges et qu'il donne satisfaction à ses utilisateurs. Pour qu'une concep-

5 13. Mar 2000

tion soit valide, il faut qu'elle prenne en compte tous les éléments énoncés
lors de l'analyse.
La vérification (verification) d'un produit consiste à s'assurer que le
produit est bien construit, ou autrement dit, que sa construction satisfait les
exigences de qualité spécifiées. La vérification d'un document revient à
s'assurer que les règles de structuration et de présentation sont respectées,
que le document est complet, non ambigü et cohérent, par exemple. Pour un
programme, on peut vérifier que les règles de style ont été respectées et que
les tests qu'il a subi sont suffisants.
La différence entre validation et vérification n'est en pratique pas aussi
nette que nous venons de le faire croire. On les utilise donc souvent de façon
interchangeable, donnant un sens plutôt plus général à vérification, et réser-
vant parfois le terme validation à la validation du produit final.
Pour illustrer notre propos, supposons par exemple qu'on veuille
s'assurer de la qualité d'un sous-programme. Il est certainement nécessaire
de montrer que son code est conforme à sa spécification élaborée lors de la
conception détaillée, ce qui signifie par exemple que son interface est cor-
recte et que l'algorithme est implémenté correctement. Bien entendu, on
s'assurera également, et ce travail se fera en parallèle, que les règles de style
de programmation ont été respectées. On constate sur cet exemple qu'il est
vain de vouloir séparer et distinguer les actions de vérifier et de valider, et
pour ne pas alourdir le discours, on parle simplement de vérification du
sous-programme.
Les actions qu'on peut entreprendre pour valider et vérifier un produit
et sa construction sont de nature extrêmement diverse. Les moyens peuvent
être manuels ou automatiques. Selon ANSI/IEEE 610.12 [3], une inspection
(inspection) ou revue (review) consiste à examiner en détail une spécifica-
tion, une conception ou du code par une personne ou un groupe de person-
nes, différent de l'auteur, pour déceler des défauts, des violations de normes
de développement ou d'autres problèmes. Si une telle investigation est effec-
tuée par un organisme indépendant de l'organisation à laquelle appartient
l'auteur, on parle aussi d'un audit (audit). Un audit a plus généralement pour
but de déterminer que les procédures, instructions, règles et normes de déve-
loppement, ainsi que d'autres exigences contractuelles, sont adéquates et
respectées, et que le produit final a été effectivement réalisé. Un audit éva-
lue donc le processus de développement.
L'activité de test (testing) consiste à exécuter sur ordinateur un pro-
gramme ou un de ses composants pour vérifier que les résultats effectifs
correspondent à ceux qui sont attendus, et qu'il satisfait d'autres exigences et
contraintes, par exemple de performance. Parfois la notion de test est éten-
due et comprend aussi des activités d'inspection, surtout quand elles sont
effectuées par des moyens automatiques.

6 13. Mar 2000

 Les activités de gestion technique (technical management function)
sont celles qui planifient, structurent et pilotent les activités d'ingénierie.
L'adjectif technique est utilisé pour exclure les activités purement adminis-
tratives telles le paiement des salaires ou la comptabilité générale. Le sujet
de la gestion technique peut être un processus, un produit ou une ressource.
La gestion du processus (process management) comprend la direction,
le suivi et la coordination des travaux entrepris pour développer un produit
ou fournir un service. L'assurance de qualité est un exemple de gestion d'un
processus.
La gestion du produit (product management) comprend la définition, la
coordination et le suivi des caractéristiques d'un produit pendant son déve-
loppement. La gestion de la configuration en est un exemple.
La gestion des ressources (resource management) comprend l'identifi-
cation, l'estimation, l'allocation et la surveillance de ressources utilisées
pour développer un produit ou fournir un service.
La gestion d'un projet (project management) est reliée à la gestion
technique de la façon suivante: la gestion d'un projet est l'utilisation, par une
ou plusieurs organisations, des activités de gestion technique pour dévelop-
per un produit à l'aide de ressources spécifiées.
Une troisième et dernière façon de décrire le contenu du génie logiciel
repose sur l'étude de son cycle de vie. Nous en parlerons en détail par la
suite.

3. Cycle de vie du logiciel

Le développement et l'évolution d'un logiciel doit être vu comme un
processus, appelé un peu abusivement le processus du logiciel (software
process). Ce processus est composé de sous-processus qui communiquent
entre eux et dont certains évoluent en parallèle. Chaque processus peut être
caractérisé par ses conditions de déclenchement, les activités déployées, les
ressources utilisées, les produits résultants et ses critères de terminaison.
Les activités faisant partie d'un processus peuvent à leur tour être décompo-
sées en activités et tâches plus élémentaires.
Le processus du logiciel peut être l'objet d'observations (qu'est-ce qui
se fait dans la pratique?) ou d'études théoriques (comment faut-il procé-
der?). Il n'existe pas qu'un seul processus du logiciel, ni en pratique, ni en
théorie, pour des raisons multiples: la diversité des applications informati-
ques et des logiciels y relatifs, la disparité entre les méthodes, techniques et
outils (y compris les langages de programmation) utilisés pour développer
des logiciels, et enfin les différences de "culture" et d'habitude aussi bien
des organisations que des personnes.

7 13. Mar 2000

 On pourrait aussi définir le génie logiciel en disant que son objet est
l'étude, la modélisation et la mise en pratique du processus du logiciel. La
figure 3 montre l'ensemble des processus et sous-processus que le groupe de
travail de l'ISO, ISO/JTC 1/SC7/WG3, a retenu pour l'architecture du pro-
cessus du logiciel, et qui inclut les propositions du groupe de travail P1074
de l’organisation américaine IEEE, largement reprise par la norme [10]
Modélisation du cycle de vie du logiciel (software life cycle model)
Gestion de projet (project management)
Initiation du projet (project initiation)
Pilotage et suivi du projet (project monitoring and control)
Gestion de qualité du logiciel (software quality management)
Pré-développement (pre-development)
Besoins de l'utilisateur ou du système (user/system requirements)
Conception du système (system design)
Développement (development)
Besoins en logiciels (software requirements)
Conception architecturale (architectural design)
Conception détaillée (detailed design)
Codage (code)
Intégration (integration)
Réception du logiciel (software acceptance)
Intégration du système (system integration)
Test de terrain (field test)
Post-développement (post-development)
Installation (installation and checkout)
Exploitation (operation)
Maintenance et support du logiciel (software maintenance and support)
Retrait (retirement)
Processus globaux (integral processes)
Vérification et validation (verification and validation)
Gestion de la configuration du logiciel (software configuration management)
Développement de la documentation (documentation development)
Formation (training)

Fig. 3 Architecture du processus du logiciel

(Software process architecture, ISO/JTC1/SC7/WG3)

Le terme processus du logiciel est relativement récent. Il est presque

synonyme de cycle de vie du logiciel (software life cycle), terme qui privilé-
gie, peut-être un peu trop exclusivement, une vision temporelle du proces-
sus du logiciel. De façon générale, on peut dire que le cycle de vie du
logiciel est la période de temps s'étalant du début à la fin du processus du
logiciel. Il commence donc avec la proposition ou la décision de développer

8 13. Mar 2000

un logiciel et se termine avec sa mise hors service. Quand on subdivise le
cycle de vie, on obtient des phases (phase), des étapes (stage) et des sous-
étapes (step).
Mais cette vision purement temporelle du cycle de vie est trop simplifi-
catrice. De fait, une description ou modélisation du cycle de vie précise bel
et bien les activités à entreprendre, le moment où il faut les entreprendre et
les dépendances entre ces activités (fig. 4). Vu sous cet angle, les notions de
processus du logiciel et de cycle de vie du logiciel sont très proches, et nous
les utiliserons donc de façon interchangeable.
La partie du cycle de vie consacrée au développement à proprement
parler s'appelle le cycle de développement du logiciel (software develop-
ment cycle) et correspond au processus de développement du logiciel
(software development process). Le cycle de développement du logiciel
commence avec la décision de développer un logiciel et se termine avec la
livraison du logiciel et son installation. Nous commencerons par décrire les
activités qui précèdent et qui suivent le cycle de développement, ce dernier
faisant l'objet d'une section particulière.
Le développement est précédé d'une phase préparatoire que nous
appellerons avant-projet (concept exploration) et qu'on nomme aussi étude
d'opportunité ou étude préalable. Cette phase a comme objectif de répondre
aux questions suivantes:
• pourquoi développer le logiciel ?
• comment procéder pour faire ce développement ?
• quels moyens faut-il mettre en oeuvre ?

Elle comprend à la fois des aspects techniques et de gestion. Parmi les

tâches techniques, groupées sous le terme étude préalable, on peut citer:
• dresser un état de l'existant et faire une analyse de ses forces et fai-
blesses;
• identifier les idées ou besoins de l'utilisateur;
• formuler des solutions potentielles;
• faire des études de faisabilité;
• planifier la transition entre l'ancien logiciel et le nouveau, s'il y a
lieu;
• affiner ou finaliser l'énoncé des besoins de l'utilisateur.

La préparation de la gestion du projet est appelée initiation du projet

(project initiation), et comprend les tâches suivantes:
• représenter les activités à entreprendre dans un modèle;
• prévoir les ressources nécessaires au projet;
• mettre en place les environnements de développement et de support;
• identifier les procédures et normes spécifiques au projet et les mesu-

9 13. Mar 2000

 13. Mar 2000
avant-projet développement exploitation et retrait
maintenance
planification du projet
pilotage et suivi du projet évaluation
gestion de initiation du
projet projet
gestion de qualité
analyse
conception
implémentation
test
activités étude maintenance
retrait

10
techniques préalable installation et assistance
vérification et validation
gestion de la configuration
développement de la documentation
formation
cycle de développement du logiciel
cycle de vie du logiciel
Fig. 4 Cycle de vie du logiciel
 res à mettre en place pour contrôler leur application;
• planifier la gestion du projet.

Le résultat de l'avant-projet est consigné dans un document appelé

cahier des charges du projet ou spécification du projet (project specifica-
tion). Celui-ci énonce donc les spécifications techniques, administratives et
financières du but, des besoins, de la portée et des limites du projet, ainsi
que ses relations avec d'autres projets, selon la norme ISO 2382-20 [4].
Une fois que le logiciel a été développé, il sera mis en exploitation.
Entre les deux se situe une phase transitoire, appelée installation (installa-
tion). Elle est en général prise en charge par l'équipe de développement pour
un logiciel fait sur mesure, en particulier pour un développement interne. A
l'opposé, pour un logiciel à large diffusion, l'acheteur se charge de l'installa-
tion, éventuellement avec l'assistance du service après-vente du distributeur.
Quoi qu'il en soit, l'installation comprend les tâches suivantes:
• planifier l'installation;
• distribuer le logiciel;
• installer le logiciel et son environnement (cadre organisationnel,
matériel, données);
• vérifier le logiciel dans son environnement opérationnel;
• mettre hors service tout logiciel censé avoir été remplacé par le nou-
veau logiciel;
• mettre en place des mises à jour.

Après l'installation suit la phase d'exploitation et de maintenance (ope-

ration and maintenance phase). Le logiciel est maintenant employé dans
son environnement opérationnel, son comportement est surveillé et, si
nécessaire, il est modifié. Cette dernière activité s'appelle la maintenance du
logiciel (software maintenance). Il peut être nécessaire de modifier le logi-
ciel pour corriger des défauts, pour améliorer ses performances ou autres
caractéristiques, pour adapter le logiciel à un nouvel environnement ou pour
répondre à des nouveaux besoins ou à des besoins modifiés. On peut donc
distinguer entre la maintenance corrective, la maintenance perfective et la
maintenance adaptative. Sauf pour des corrections mineures, du genre
dépannage, la maintenance exige en fait que le cycle de développement soit
réappliqué, en général sous une forme simplifiée. Une fois qu'une version
modifiée du logiciel a été développée, il faut bien entendu la distribuer. De
plus, il est en général nécessaire de fournir à l'exploitant du logiciel une
assistance technique et un support de consultation.
En résumé, on peut dire que la maintenance et le support du logiciel
comprennent les tâches suivantes:
• effectuer des dépannages pour des corrections mineures;

11 13. Mar 2000

 • réappliquer le cycle de développement pour des modifications plus
importantes;
• distribuer les mises à jour;
• fournir l'assistance technique et un support de consultation;
• maintenir un journal des demandes d'assistance et de support.

A un moment donné, on décide de mettre le logiciel hors service. Les

tâches correspondantes sont accomplies durant la phase de retrait (retire-
ment phase) et comprennent:
• avertir les utilisateurs;
• effectuer une exploitation en parallèle du logiciel à retirer et de son
successeur;
• arrêter le support du logiciel.

4. Cycle de développement du logiciel

Après avoir passé en revue la phase qui le précède et les phases qui lui
succèdent, nous pouvons revenir sur le cycle de développement du logiciel
(fig. 4).
Un certain nombre d'activités accompagnent nécessairement tout le
cycle de développement: la gestion du projet, la vérification et validation, le
développement de la documentation, la gestion de la configuration, et la for-
mation. Nous allons commencer par décrire ces activités et nous parlerons
plus tard des phases du cycle de développement.
La gestion du projet (project management) comprend l'affinement et
les modifications de la planification du projet, le pilotage et le suivi du pro-
jet, et la gestion de la qualité.
La planification du projet (project planning) a comme buts de générer
une décomposition du projet en activités et tâches plus élémentaires ayant
des interrelations minimales, et de produire une structure de référence pour
le pilotage et le suivi du projet. Elle définit donc les tâches, le calendrier, les
ressources, l'allocation de ces ressources aux tâches et les procédures du
projet.
Le pilotage et le suivi du projet (project monitoring and control) con-
siste à enregistrer les faits sur l'avancement du projet, à comparer cet avan-
cement avec la planification, et à entreprendre, si nécessaire, des mesures
correctives.
La gestion de la qualité du logiciel (software quality management)
comprend l'ensemble des activités de gestion déployées pour garantir que le
processus de développement engendre un produit de qualité. Il s'agit en
quelque sort du processus qui pilote les activités de vérification et de valida-

12 13. Mar 2000

tion, dont la nature est technique et dont nous avons déjà parlé. La gestion
de la qualité du logiciel comprend donc les tâches suivantes:
• planifier le programme de qualité;
• implémenter un système de comptes-rendus de problèmes et
d'actions correctives;
• définir un programme pour mesurer la qualité;
• piloter et contrôler l'application du programme de qualité;
• recommander des améliorations pour les programmes de qualité
futurs.

L'exécution du programme de qualité est prise en charge par les activi-

tés de vérification et de validation qui sont les suivantes:
• déterminer les produits à évaluer et les procédures d'évaluation;
• collectionner et analyser les informations;
• planifier l'effort de test;
• développer des spécifications et procédures de test;
• faire les vérifications et validations, et exécuter les tests.

La gestion de la qualité du logiciel et les activités de vérification et de

validation sont parfois regroupées sous le terme assurance de qualité du
logiciel (software quality assurance, SQA).
La documentation (documentation) est un élément essentiel dans le
développement d'un logiciel: elle fait partie du produit à réaliser; elle maté-
rialise l'avancement des travaux, car chaque phase est concrétisée par la pro-
duction d'un ou plusieurs documents; elle constitue le support de
communication entre les différents intervenants du projet. On peut distin-
guer trois types de documents: les documents de gestion du projet, les docu-
ments techniques de réalisation, les manuels d'utilisation et d'exploitation.
La documentation de développement et le logiciel lui-même sont cons-
titués d'un grand nombre d'éléments qui évoluent durant tout le cycle de vie.
Le but de la gestion de la configuration (configuration management) est de
maîtriser cette évolution. La gestion de la configuration comprend donc
l'ensemble des activités suivantes:
• identifier et définir les éléments de configuration et toutes leurs rela-
tions;
• archiver les éléments de configuration, aussi bien leurs états initiaux
que leurs états successifs;
• contrôler les modifications des éléments de configuration, ce qui
inclut pour chaque modification: autoriser le changement, vérifier
que le nouvel état est complet et cohérent, enregistrer le nouvel état,
annoncer la modification, mettre à disposition le nouvel état.

13 13. Mar 2000

 Les entités suivantes et leurs composants peuvent jouer le rôle d'élé-
ments de configuration (configuration item), c'est-à-dire être pris en charge
par la gestion de la configuration:
• les documents de gestion du projet;
• les documents techniques de réalisation;
• les manuels d'utilisation et d'exploitation;
• les programmes sources et les moyens permettant de produire et de
reproduire le programme machine;
• les jeux de données de tests, y compris leurs résultats, les procédures
et scénarios de test.

Identifier les éléments de configuration revient à opérer un choix parmi

tous les éléments possibles et affecter à chaque élément retenu un identi-
fiant. Cet identifiant doit être unique et doit permettre de déterminer la
nature et la version de l'élément. Il faut également définir les liens entre les
identifiants des éléments de configuration ce qui constitue la nomenclature
du logiciel et de son développement.

5. Phases du cycle de développement

Après avoir passé en revue les activités qui accompagnent tout le cycle
de développement, nous allons maintenant présenter le découpage classique
du cycle de développement en phases. Ce découpage correspond au modèle
classique dite de la cascade (waterfall model). Tous les modèles du cycle de
développement ne sont pas les mêmes, mais l'idée est toujours la même: le
logiciel est développé en phases discrètes, chacune ayant un résultat défini
et un critère de terminaison défini, et chaque phase est achevée avant que
ne commence la suivante. Le modèle classique du cycle de développement
(fig. 4) comprend les phases suivantes: analyse, conception, implémenta-
tion, test, et éventuellement phase d'installation, dont nous avons déjà parlé.
D'autres noms sont parfois donnés à ces phases et un découpage plus fin est
souvent utile.
Chaque phase a des entrées et des sorties, qui sont généralement des
documents et parfois des produits. Toute sortie d'une phase servira d'entrée à
une phase ultérieure, souvent celle qui suit immédiatement, mais pas tou-
jours. Certaines activités déployées pendant une phase lui sont donc spécifi-
ques et d'autres sont destinées à préparer les phases qui suivent. Dérivé du
modèle de la cascade, le modèle en V du cycle de développement (fig. 5)
montre non seulement l'enchaînement des phases successives, mais aussi les
relations logiques entre phases plus éloignées.
L'application stricte du modèle en phases prescrit qu'on complète

14 13. Mar 2000

niveau de détail

installation et
analyse test de réception

conception intégration et
générale test d’intégration

conception
détaillée tests unitaires

implémentation

enchaînement lien de validation temps

Fig. 5 Modèle en V du cycle de développement

entièrement une phase avant de passer à la suivante. Dans la pratique, il

arrive cependant qu'au cours d'une phase on découvre des erreurs commises
dans une phase antérieure ou même l'absence d'éléments essentiels qui
auraient dû être fournis par une phase antérieure. Il peut donc être nécessaire
de revenir sur une phase précédente. Si tel est le cas, il faut parcourir à nou-
veau toutes les phases à partir de la phase révisée pour répercuter partout les
modifications.
Lors de la phase d'analyse, également appelée phase de spécification
(requirements phase, analysis phase, definition phase), on analyse les
besoins de l'utilisateur ou du système englobant et on définit ce que le logi-
ciel devra faire. Le résultat de la phase d'analyse est consigné dans un docu-
ment appelé cahier des charges du logiciel (à ne pas confondre avec le
cahier des charges du projet) ou spécification du logiciel, en anglais:
software requirements, software specification ou requirements specification.
La spécification représente un modèle de ce qui est nécessaire et un
énoncé du problème pris en compte. La spécification est élaborée par une
approche itérative de modélisation et d'analyse de la réalité modélisée. Une
spécification est en général non constructive: elle n'est donc pas une solu-
tion du problème. On peut encore dire qu'une spécification présente une vue
externe du logiciel, c'est-à-dire tout ce qui peut être perçu sans pénétrer dans
la structure interne du logiciel.
Il est essentiel qu'une spécification ne définisse que les caractéristiques
essentielles du logiciel pour laisser de la place aux décisions de conception.

15 13. Mar 2000

Souvent la spécification est donc intentionnellement vague dans les domai-
nes où des détails supplémentaires sont impossibles ou non pertinents. En
effet, la spécification excessive, appelée surspécification, peut induire des
augmentations substantielles des coûts de développement et des inefficaci-
tés dans l'utilisation et l'exécution d'un logiciel, car des solutions mieux
adaptées sont exclues par la surspécification.
Une spécification comporte les éléments suivants:
• description de l'environnement du logiciel;
• spécification fonctionnelle (functional specification), qui définit tou-
tes les fonctions que le logiciel doit offrir;
• comportement en cas d'erreurs, c'est-à-dire dans les cas où le logiciel
ne peut pas accomplir une fonction;
• performances requises (performance requirements), par exemple:
temps de réponse, encombrement en mémoire, sécurité de fonction-
nement;
• interfaces avec l'utilisateur (user interface), en particulier le dialo-
gue sur terminal, la présentation des écrans, la disposition des états
imprimés, etc.
• interfaces avec d'autres logiciels;
• interfaces avec le matériel;
• contraintes de réalisation, telles que l'environnement de développe-
ment, le langage de programmation à utiliser, les procédures et nor-
mes à suivre, etc.

La figure 6 montre un plan possible pour le document de spécification,

inspiré de la norme IEEE 830:1993 [5]. Notre plan se fonde sur l'hypothèse
qu'on a adopté une approche fonctionnelle; on entend par ce terme une
démarche qui part des fonctions principales que le logiciel doit offrir et qui
décompose ensuite celles-ci en fonctions plus élémentaires et en opérations.
Le plan est complété par des éléments de description des structures de don-
nées (section 2.2. et chapitre 3 de la figure 6). Si une autre approche est
choisie, telle une méthode basée sur le concept d’objet, il faudrait évidem-
ment organiser ce document en termes d'objets et de classes. La norme IEEE
830:1993 fait des propositions pour huit approches différentes.
Il est judicieux de préparer pendant la phase d'analyse les procédures
qui seront mises en oeuvre pour vérifier que le logiciel, une fois construit,
est conforme à la spécification. Cette évaluation peut revêtir plusieurs for-
mes et comprendre plusieurs activités, en particulier l'exécution de tests.
Pour notre part, nous l'appellerons test de réception (acceptance test). A ce
stade du cycle de développement, le document correspondant a un caractère
incomplet et comprend essentiellement un plan de test de réception.
Durant la phase d'analyse, on produit également une version provisoire

16 13. Mar 2000

des manuels d'utilisation et d'exploitation du logiciel. Nous reviendrons plus
tard sur le contenu de ces manuels.
La phase d'analyse est suivie de la phase de conception (design phase),
généralement décomposée en deux phases successives dont la première est
appelée conception générale, conception globale, conception préliminaire
ou conception architecturale (preliminary design ou architectural design), et
la deuxième conception détaillée (detailed design). A partir du document de
spécification, la phase de conception doit fournir une réponse à la question:
"Comment réaliser le logiciel ?".
Commençons par décrire les activités entreprises lors de la conception
générale.
Si nécessaire, il faut commencer par l'ébauche de plusieurs variantes de
solutions et choisir celle qui offre le meilleur rapport entre coûts et avanta-
ges.
Il faut ensuite figer la solution retenue, la décrire et la détailler. En par-
ticulier, il faut décrire l'architecture de la solution, c'est-à-dire son organisa-
tion en entités, les interfaces de ces entités et les interactions entre ces
entités. Ce processus de structuration doit être poursuivi jusqu'à ce que tous
les éléments du document de spécification ont été pris en compte. Le résul-
tat de cette démarche est un document de conception générale.
Durant la phase de conception générale, il faut également préparer la
phase d'intégration. A cet effet, il faut élaborer un plan d'intégration, y com-
pris un plan de test d'intégration.
La conception détaillée affine la conception générale. Elle commence
par décomposer les entités découvertes lors de la conception générale en
entités plus élémentaires. Cette décomposition doit être poursuivie jusqu'au
niveau où les entités sont faciles à implémenter et à tester, c'est-à-dire cor-
respondent à des composants logiciels élémentaires. Ce niveau dépend for-
tement du langage de programmation retenu pour l'implémentation: le
niveau ne sera pas le même pour un langage de quatrième génération, un
langage procédural classique ou un langage d'assemblage. Il faut ensuite
décrire chaque composant logiciel en détail: son interface, les algorithmes
utilisés, le traitement des erreurs, ses performances, etc. L'ensemble de ces
descriptions constitue le document de conception détaillée.
Pendant la conception détaillée, il faut également préparer la vérifica-
tion des composants logiciels élémentaires qui fera l'objet de la phase des
tests unitaires. Le résultat est consigné dans un document appelé plan de
tests unitaires. Si nécessaire, il faut de plus compléter le plan d'intégration,
car de nouvelles entités ont pu être introduites pendant la conception
détaillée.
Après la conception détaillée, on peut passer à la phase d'implémenta-
tion, également appelée phase de construction, phase de réalisation ou phase

17 13. Mar 2000

Table des matières
Résumé
1. Introduction
1.1. Buts et destinataires du document
1.2. Domaine du logiciel
(nom du logiciel, à quoi sert le logiciel et quels sont ses limites, quels en sont les apports
et bénéfices)
1.3. Définitions, acronymes et abréviations
1.4. Références bibliographiques
(le cas échéant on peut renvoyer à une annexe)
1.5. Plan du document
(que contient le document, comment est-il organisé)
2. Description générale
2.1. Environnement du logiciel
(décrire l'environnement de fonctionnement du logiciel; si le logiciel est une partie d'un
système plus grand, décrire les fonctions et interfaces de tous les composants de ce
système; décrire les équipements matériels utilisés par le logiciel)
2.2. Modèle conceptuel
(décrire sans détails inutiles les structures de données et fonctions principales du logiciel
et leurs interrelations et interactions)
2.3. Caractéristiques des utilisateurs
2.4. Contraintes générales
(normes et réglementations à appliquer; limites du matériel; interfaces avec d'autres ap-
plications; langage de programmation imposé; fiabilité et sécurité)
2.5 Hypothèses et dépendances
(énoncer toutes les hypothèses et éléments dont dépend la spécification, le but étant de
cerner les cas où une modification de la spécification peut devenir nécessaire)
3. Spécifications des structures de données
(ce chapitre comprend une section par structure de données)
3.n. Nom de la structure de données
3.n.1. Introduction
(but et essence)
3.n.2. Définition de la structure de données
(par exemple à l'aide du modèle entité-association; donc attributs, entités, associations;
leurs unités de mesure, leurs cardinalités, les contraintes d'intégrité)
3.n.3. Volumes et fréquences
4. Spécifications fonctionnelles
4.n. Nom de la fonction
4.n.1. Introduction
(but et essence)
4.n.2. Entrées
(provenances des entrées; leurs quantités; les unités de mesure; temps et fréquences; in-
tervalles des valeurs valides avec précision et tolérances; interventions de l'opérateur)
Fig. 6 Plan possible du document de spécification

18 13. Mar 2000

 4.n.3. Sorties
(comme pour entrées et de plus: messages d'erreurs)
4.n.4. Traitements
(validation des entrées; description et séquence des opérations; méthodes utilisées pour
effectuer les opérations telles que équations mathématiques, modèles économiques, etc.;
paramètres modifiés par les opérations; traitement des erreurs; fonctionnement en mode
dégradé; vérification des sorties)
5. Erreurs
(récapitulation du traitement des entrées et sorties non valides et des situations exceptionnelles)
6. Interfaces externes
6.1. Interfaces d'utilisateur
(mode d'interaction, formats d'écran, disposition et contenus des menus et rapports, temps
entre entrées et sorties, possibilité de paramétrisation, messages d'erreurs)
6.2. Interfaces matérielles
(caractéristiques logiques des interfaces; quelles unités physiques sont supportées et quels
sont les protocoles utilisés, etc.)
6.3. Interfaces logicielles
(pour chaque logiciel utilisé explicitement, par exemple système de gestion de bases de
données, bibliothèque de fonctions mathématiques, services du système d'exploitation, il
faut préciser: le nom, son numéro de version, sa provenance, le but de son utilisation, et
définir l'interface, éventuellement en renvoyant à une annexe ou un autre document)
7. Spécifications de performances
(les contraintes de performance attribuables à des fonctions particulières sont décrites dans les sec-
tions du chapitre 4; ici on précise des points tels que: nombre de terminaux, nombre d'utilisateurs
simultanés; nombre de fichiers et enregistrements, taille des tables et fichiers, nombre de transac-
tions et volume de données traitées par période de temps en charge normale et en charge de pointe)
8. Contraintes de conception
(conformité à des normes, règlement et procédures; limitations du matériel; etc.)
9. Autres caractéristiques
(propriétés de qualité du logiciel telles que disponibilité, sécurité, maintenabilité, portabilité, etc.)
10. Autres contraintes
10.1. Bases de données
(à développer avec le produit)
10.2. Exploitation
(modes d'exploitation, opérations de sauvegarde, etc.)
10.3. Adaptation à un site
(travaux d'adaptation pour l'installation sur un site particulier)
Glossaire
Index
Annexes

Fig. 6 Plan possible du document de spécification (suite)

19 13. Mar 2000

de codage (implementation phase, construction phase, coding phase). Lors
de cette phase, la conception détaillée est traduite dans un langage de pro-
grammation. Il faut également préparer les données nécessaires à l'exploita-
tion du logiciel, soit en les saisissant, soit en convertissant des données déjà
existantes. La phase d'implémentation fournit donc les composants logiciels
sur support informatique; on peut citer les sources et objets compilés, les
comptes-rendus des résultats de compilation, les références croisées internes
et externes des composants. Elle doit également fournir une liste des com-
mandes de production du logiciel, par exemple les commandes de compila-
tion, et une description de l'environnement de production.
La phase d'implémentation est suivie de la phase de test (test phase).
Durant cette phase, les composants du logiciel sont évalués et intégrés, et le
logiciel lui-même est évalué pour déterminer s'il satisfait la spécification
élaborée lors de la phase d'analyse. Cette phase est en général subdivisée en
plusieurs phases.
Lors des tests unitaires (unit test), on évalue chaque composant indivi-
duellement pour s'assurer qu'il est conforme à la conception détaillée. Si ce
n'est déjà fait, il faut élaborer pour chaque composant un jeu de données de
tests. Il faut ensuite exécuter le composant avec ce jeu, comparer les résul-
tats obtenus aux résultats attendus, et consigner le tout dans le document des
tests unitaires. S'il s'avère qu'un composant comporte des erreurs, il est ren-
voyé à son auteur, qui devra diagnostiquer la cause de l'erreur puis corriger
le composant. Le test unitaire de ce composant est alors à reprendre.
Après avoir effectué avec succès les tests unitaires de tous les compo-
sants, on peut procéder à leur assemblage, qui est effectué pendant la phase
d'intégration (integration phase). Pendant cette phase, on vérifie également
la bonne facture des composants assemblés, ce qu'on appelle le test d'inté-
gration (integration test). On peut donc distinguer les actions suivantes:
construire par assemblage un composant à partir de composants plus petits;
exécuter les tests pour le composant assemblé et enregistrer les résultats;
comparer les résultats obtenus aux résultats attendus; si le composant n'est
pas conforme, engager la procédure de modification; si le composant est
conforme, rédiger les comptes-rendus du test d'intégration et archiver sur
support informatique les sources, objets compilés, images exécutables, les
jeux de tests et leurs résultats.
Après avoir intégré le logiciel, on peut l'installer dans son environne-
ment d'exploitation, ou dans un environnement qui simule cet environne-
ment d'exploitation, et le tester pour s'assurer qu'il se comporte comme
requis dans la spécification élaborée lors de la phase d'analyse. Cette phase
s'appelle la phase d'installation (installation phase ou installation and
check-out phase). Les tests effectués durant cette phase prennent des noms
variés selon leur nature. On parle parfois de validation, comme la norme

20 13. Mar 2000

française Z 67-130 [6]. Si l'on veut insister sur le fait que ces tests doivent
préparer la décision du mandant d'accepter ou non le logiciel, on utilise les
termes test d'acceptance, test de recette ou test de réception (acceptance
test). Enfin, s'il s'agit de montrer le comportement et les performances du
logiciel dans son environnement d'exploitation réel, le terme test d'exploita-
tion est d'usage (operational test).
Les manuels d'utilisation et d'exploitation doivent être prêts au plus
tard lors de l'installation du logiciel. Selon la complexité de ce dernier, la
documentation d'utilisation est organisée en un ou plusieurs documents qui
pourraient être les suivants:
• guide d'installation;
• manuel d'introduction ou guide de l'utilisateur;
• manuel de référence;
• mémento ou aide-mémoire;
• manuel de l'opérateur.

Dans ce texte, nous nous contentons de proposer un plan pour un docu-

ment unique, appelé manuel de l'utilisateur (user's manual), largement ins-
piré de la norme française Z 67-122 [7] (fig. 7).
Le document principal élaboré durant une phase prend souvent le
même nom que la phase, éventuellement en ajoutant le mot document ou
dossier pour éviter les confusions. La figure 8 donne la liste des documents
à produire au minimum, la phase où un document est élaboré complètement
ou partiellement, révisé ou complété, et les phases où il constitue un élément
essentiel en entrée.

6. Autres modèles de développement

Il existe plusieurs variantes du cycle de développement constituant
autant de modèles de développement d'un logiciel.
Le modèle élémentaire utilisé dans les premiers jours de l'informatique
consistait à coder et réparer (code and fix). Il faut bien admettre qu'il est
encore utilisé bien souvent aujourd'hui. Ce modèle comprend deux étapes:
écrire un peu de code, puis améliorer le code et corriger les erreurs. On com-
mence donc par coder et on réfléchit ensuite aux besoins, à la conception,
aux tests et à la maintenance. Ce modèle entraîne trois difficultés principa-
les:
• Après un certain nombre de corrections, le code devient tellement
mal structuré que les corrections ultérieures deviennent très chères.
Ce fait met en évidence le besoin d'une phase de conception préala-
ble au codage.

21 13. Mar 2000

Table des matières
Résumé
1. Identification du logiciel
(nom du logiciel, numéro de version; langue d'utilisation; auteur ou éditeur du logiciel; marque et
modèle du matériel ainsi que nom et version du système d'exploitation, si plusieurs variantes du
logiciel sont disponibles; informations contractuelles telles que garantie, responsabilité, droit de li-
cence, service après-vente)
2. Introduction
(description générale du logiciel, ce qu'il peut faire, ses limites, la terminologie utilisée; plan du
manuel; références bibliographiques)
3. Environnement du logiciel
(préciser l'environnement d'utilisation du logiciel: environnement matériel, configurations matéri-
elles minimale et conseillée, environnement logiciel, y compris système d'exploitation)
4. Installation du logiciel
(décrire toutes les manipulations nécessaires pour rendre le logiciel opérationnel: connexion de pé-
riphériques, chargement de fichiers, modification de paramètres, etc.)
5. Démarrage du logiciel
(décrire comment on démarre le logiciel installé)
6. Guide de l'utilisateur
(montrer à l'aide d'exemples simples comment l'utilisateur peut mettre en oeuvre les principales
fonctions offertes par le logiciel)
7. Manuel de référence
7.1. Commandes et messages
(décrire les formats et fonctions des commandes et préciser leurs limites éventuelles
d'utilisation; énumérer les messages affichés en réponse aux différentes commandes, pré-
ciser leurs significations et décrire les mesures à prendre en réponse à ces messages; on
se contentera de décrire les messages dont le sens ne va pas de soi ou qui sont codés)
7.2. Données
(décrire la nature, le contenu, la structure logique et le format des données d'entrée et de
sortie)
7.3. Fichiers
(Décrire des fichiers utilisés ou créés par le logiciel)
7.4. Erreurs
(décrire tous les contextes d'erreurs ainsi que les messages qui leur sont liés; indiquer les
opérations de reprise applicables aux différentes erreurs)
7.5. Dispositifs d'aide
(décrire l'accès et l'utilisation de ces dispositifs et fournir les dispositions d'écran y rela-
tives, s'il y a lieu)
Glossaire
Index

Fig. 7 Plan possible du manuel d’utilisateur

•
22 13. Mar 2000
 intégration installation
phases avant- conception conception implémen- tests
analyse et test et test de
projet générale détaillée tation unitaires
documents d’intégration réception
cahier des charges
du projet

spécification

conception générale

conception détaillée

listages

tests unitaires ?

23
test d’intégration ?

test de réception ?
manuels d’utilisation
et d’exploitation ? ?

document élaboré entièrement pendant la phase document partiellement élaboré pendant la phase

document en entrée de la phase ? document éventuellement complété pendant la phase

Fig. 8 Documents et phases

13. Mar 2000

 • Fréquemment, même un logiciel bien conçu satisfait si mal les
besoins des utilisateurs qu'il est soit rejeté, soit redéveloppé à grands
frais. On perçoit ainsi la nécessité d'une phase d'analyse des besoins
antérieure à celle de la conception.
• Comme les tests et modifications ne sont pas préparés, il est coûteux
de corriger le code.

Ces difficultés ont bien entendu été reconnues et, en réaction, le

modèle de la cascade (waterfall model), déjà exposé, a été développé. Rap-
pelons que ce modèle prescrit que le logiciel doit être développé en phases
successives, une phase ne pouvant se terminer que lorsque des critères bien
définis sont satisfaits. Pour les premières phases, les critères de complétude
sont des documents complètement élaborés. Pour certains types de logiciels,
ce modèle est très bien adapté, mais pas pour tous.
Une première difficulté survient s'il est difficile d'obtenir de la part de
l'utilisateur un énoncé complet et cohérent de ses besoins. Il est alors possi-
ble de construire une maquette (prototype) qui simule le comportement du
logiciel tel qu'il sera perçu par l'utilisateur. Cette technique est fréquemment
utilisée pour mettre au point l'interface de l'utilisateur. Quand la maquette a
été acceptée, et cela peut nécessiter plusieurs itérations, il est possible de
figer le résultat de l'analyse, c'est-à-dire de rédiger une spécification du logi-
ciel.
Mais parfois la situation est plus grave: l'environnement du logiciel est
tellement mouvant, qu'il est illusoire de fonder le développement sur une
spécification figée. Le modèle de développement évolutif cherche à traiter
ce cas. Dans ce modèle, on applique itérativement le cycle de développe-
ment classique, mais sans s'attarder trop, donc sans détailler les phases. A
chaque itération, on étend un logiciel opérationnel, l'évolution étant déter-
minée par des expériences gagnées au cours de l'exploitation. Avec ce
modèle de développement, les utilisateurs disposent rapidement d'un sys-
tème opérationnel et d'une base réaliste pour déterminer les améliorations
souhaitées du produit.
Ce modèle est bien adapté aux applications programmées à l'aide de
langages de quatrième génération et pour lesquelles les exigences en fiabi-
lité ne sont pas trop élevées.
Néanmoins, ce modèle comporte des désavantages majeurs. Il est
généralement difficile de le distinguer du modèle "coder et réparer" et il
comporte donc potentiellement les mêmes dangers. Il est également fondé
sur l'hypothèse souvent non réaliste que le logiciel opérationnel sera suffi-
samment flexible pour être adapté à des évolutions non prévues. Une telle
hypothèse est injustifiée dans deux circonstances au moins: i) plusieurs
applications qui ont évolué indépendamment les unes des autres doivent être

24 13. Mar 2000

intégrées; ii) un nouveau logiciel doit remplacer peu à peu un grand système
existant.
Une autre approche conduit au modèle transformationnel. Celui-ci sup-
pose qu'il existe un moyen qui convertit automatiquement une spécification
formelle d'un logiciel en un programme qui satisfait cette spécification. Les
étapes prescrites sont donc les suivantes:
• élaborer une spécification formelle;
• transformer automatiquement la spécification en code;
• améliorer les performances du code résultant en donnant des indica-
tions d'optimisation au système de transformation;
• expérimenter le produit résultant;
• ajuster la spécification en se basant sur les résultats d'utilisation, et
reprendre tout le cycle.

Le modèle transformationnel évite de devoir modifier du code qui est

devenu mal structuré après des optimisations répétées. Il économise égale-
ment le temps et les coûts dus aux activités intermédiaires de conception,
de codage et de test.
Malheureusement, la transformation automatique n'est disponible que
pour des petits logiciels et uniquement dans quelques domaines très limités:
petites applications avec un tableur ou un langage de quatrième génération,
et quelques problèmes de l'informatique de base.
Le dernier modèle qu'on pourrait encore signaler est le modèle en spi-
rale (spiral model), dû à Boehm [8]. Il s'agit d'un modèle assez complexe
qui intègre une vue évolutive au modèle en cascade par une approche fon-
dée sur l'analyse et la gestion des risques.
Le lecteur pourra trouver d’autres modèles et plus de détails sur les
modèles discutés ici dans l’excellent ouvrage [9].

7. Notion de système
Un logiciel peut être considéré comme un système, mais très souvent le
logiciel n'est qu'une partie d'un système plus général. Le développement du
logiciel pose alors des problèmes supplémentaires. De plus, la terminologie
utilisée peut alors prêter à confusion puisque le terme système, par exemple,
peut désigner le système logiciel ou le système englobant dont le logiciel
fait partie.
Un système (system) est un ensemble structuré d'éléments apparentés
ou interconnectés de telle façon qu'ils forment un tout organique. On parle
ainsi du système solaire, du système digestif, du système routier, du système
de sécurité sociale, d'un système informatique et du système d'information

25 13. Mar 2000

d'une entreprise. Toute organisation sociale, et en particulier une entreprise
commerciale ou industrielle, peut aussi être considérée comme un système.
Les systèmes sont souvent imbriqués: un système contient d'autres sys-
tèmes, appelés des sous-systèmes, et lui-même est contenu dans un système
plus grand qui constitue son environnement. Ainsi, le système solaire appar-
tient à la voie lactée et comprend le sous-système formé de la terre et de la
lune.
Un système a des objectifs, utilise des ressources, et produit des résul-
tats. Un système d'information (information system) est un système dont le
résultat premier est de l'information. Il peut avoir des résultats secondaires
qui ont trait à la surveillance d'informations pour le compte du système
englobant. L'information n'est pas seulement un résultat mais également une
ressource importante utilisée par les systèmes d'information.
Si tout ou partie d'un système d'information est automatisée, c'est-à-
dire utilise des moyens informatiques, nous parlerons d'un système informa-
tique (computer-based system); ce terme ne désignera parfois que la partie
automatisée du système.
Il existe beaucoup de genres différents de systèmes d'information; par
exemple: systèmes d'informations factuelles (fact retrieval system), systè-
mes de recherche documentaire (document retrieval system), systèmes
d'aide à la décision (decision support system), systèmes temps réel (real-
time system), systèmes bureautiques (office system), systèmes incorporés
(embedded system), systèmes de surveillance (control system), et systèmes
basés sur les connaissances (knowledge-based system). Très souvent plu-
sieurs types de systèmes d'information sont combinés en un seul système
d'information.
Un système d'information supporte une certaine fonction. Par exemple,
dans une entreprise commerciale le système d'information peut supporter la
fonction de vente.
Les systèmes d'information sont normalement imbriqués, et l'environ-
nement d'un système d'information est un autre système d'information. Le
système d'information du plus haut niveau peut être l'organisation tout
entière. L'organisation est également un système qui en tant que tel a un
objectif. Cet objectif est parfois énoncé sous la forme vague d'une politique
ou d'une doctrine. Dans tous les cas, cet objectif est sujet à des contraintes,
par exemple des règlementations légales.
Lors du développement d'un logiciel, on peut distinguer deux situa-
tions très différentes: i) le logiciel constitue le système, ii) le logiciel n'est
qu'une partie d'un système plus grand qu'il s'agit de développer.
La première situation est bien plus facile à maîtriser, si ce n'est parce
que les ingénieurs du logiciel se retrouvent entre eux. Des exemples typi-
ques sont le développement d'un compilateur, d'un système de gestion de

26 13. Mar 2000

bases de données, d'un tableur ou d'autres utilitaires. Le cycle de vie tel que
nous l'avons exposé est alors applicable sans modification.
Si le logiciel ne constitue qu'une partie du système à développer, la
situation se complique, car il faut répartir, puis coordonner le travail de plu-
sieurs équipes ayant des compétences différentes, et par conséquent souvent
aussi des "cultures" différentes. On peut tout d'abord penser à un système
qui comporte à la fois du matériel informatique et du logiciel, le développe-
ment d'un processeur et de son logiciel de base faisant évidemment partie de
cette catégorie. Un autre exemple est l'automatisation, toujours partielle, du
système d'information d'une entreprise ou d'une de ses fonctions, comme les
ventes. Dans ce cas, le système d'information ne comporte pas que des
machines et des logiciels, mais également des hommes qui préparent, analy-
sent et consultent des informations. L'automatisation nécessite donc entre
autres qu'une organisation adéquate soit étudiée et mise en place dans
l'entreprise.
Dans tous les cas cités, le développement du logiciel s'insère dans le
cadre du développement d'un système. Le cycle de développement du logi-
ciel ne constitue alors qu'un élément du cycle de développement du système
(fig. 9).
Il est important de comprendre l'articulation de ces deux cycles. Un
projet de développement d'un système commence par une phase d'analyse
du système (system requirements) qui est suivie d'une phase de conception
du système (system design). Lors de cette phase, on décrit l'architecture du

analyse installation et
du système test du système

intégration du
conception système et test
du système d’intégration

analyse test du logiciel

conception et implémentation

développement du logiciel

développement du matériel

développement du cadre organisationel

Fig. 9 Modèle de développement d’un système

27 13. Mar 2000

système et on alloue les fonctions du système au matériel, au logiciel et aux
hommes. Cette démarche aboutit donc à une définition des besoins en logi-
ciel (software requirements) qui constituera l'élément technique essentiel
pour démarrer le développement du logiciel. Une fois que le logiciel et les
autres composants du système ont été développés, il faut procéder à leur
intégration, appelée intégration du système (system integration), puis à l'ins-
tallation du système (system installation).

Références
[1] Boehm, B. W.; Software engineering economics; Prentice-Hall, 1981, 0-13-
822122-7.
[2] ANSI/IEEE 1002:1987; Standard taxonomy for software engineering standards.
[3] ANSI/IEEE 610.12:1990; Glossary of software engineering terminology.
[4] ISO 2382-20:1990; Technologies de l'information - Vocabulaire - Partie 20:
Développement de système.
[5] IEEE 830:1993; IEEE Recommended practice for software requirements
specifications.
[6] Z 67-130; Recommendation de plan qualité logiciel; AFNOR, 1987.
[7] Z 67-122; Documentation d’utilisation des progiciels; AFNOR, 1988; (identique à
la partie 1 de la norme internationale ISO 9127:1988).
[8] Boehm, B. W.; “A Spiral Model of Software Development and Enhancement”,
IEEE Computer 21 (May 1988), pp. 61-72.
[9] Schach S. R.; Software Engineering; Irwin, Boston, 1993 (second edition).
[10] ISO/IEC 12207:1995; Information technology - Software life cycle processes.
.

28 13. Mar 2000