Chapitre 2

Les activités du développement

Quelle que soit la manière de développer du logiciel, un ensemble d’activités sont nécessaires
au cours du processus.
Les caractérisations et dénominations de ces activités ne sont pas normalisées, ou plus
exactement il existe une pléthore de normes produites par des organismes tels que
l’ISO (International Organization for Standardization), l’AFNOR (Association française
de normalisation), l’IEEE (Institute of Electrical and Electronics Engineers), le DoD
(Department of Defense) pour les applications militaires aux USA, ou l’ESA (European
Space Agency), chacune avec ses nuances propres.
Le statut de ces activités dans le processus de développement peut beaucoup varier. Dans
les processus classiques (en cascade ou en V, cf. paragraphe 4.1) certaines de ces activités
s’enchaînent logiquement et constituent des « stades du développement ». D’autres se
retrouvent incluses dans différents stades, comme la vérification, voire dans tous les stades,
comme la documentation. Dans les processus agiles (cf. paragraphe 4.4) certaines activités
sont entremêlées, comme le recueil des besoins et l’analyse et spécification des besoins,
car elles sont pratiquées par des équipes pluridisciplinaires mêlant clients et informaticiens.
Alors que dans les approches classiques, les client (MOA) et les informaticiens (MOE) les
réalisent séparément et successivement en s’échangeant des documents.
Ce chapitre décrit ces différentes activités en restant aussi indépendant que possible des
processus de développement. Celles qui relèvent de l’ingénierie des besoins en amont de
la conception, qui sont au cœur de l’ouvrage, sont présentées plus en détail que celles en aval
du développement.
18 Partie 1. Le développement logiciel

2.1 LE RECUEIL DES BESOINS

Synonymes : capture, élucidation, « élicitation », identification, expression des besoins (ou
exigences).

2.1.1. La notion de besoin

Au démarrage d’un projet, le client (qui demande et souvent paye le développement) et les
futurs utilisateurs finaux ont une idée brute de ce qu’ils souhaitent qui peut mêler des attentes
plus ou moins précises avec des idées de conception. On parle souvent de besoins bruts ou
besoins client. Les architectes décrivent le même phénomène avec leurs clients qui expriment
spontanément plutôt des détails de conception (ex. : une maison avec une tour, une véranda,
un toit végétalisé, etc.) que de véritables besoins liés à leur âge, au nombre et à l’âge de leurs
enfants, à leur style de vie et loisirs favoris, etc.
Pour établir et documenter les véritables besoins d’une application, il faut étudier son contexte
métier (processus, règles, standards, etc.), l’état actuel de son environnement (l’existant), son
rôle attendu, les ressources disponibles et requises, les performances espérées, les contraintes
d’utilisation, etc.
Dans un premier temps, l’application est vue « de l’extérieur », du point de vue de l’utilisateur
(MOA), comme une boîte noire dont seul le comportement externe importe. Dans un second
temps, l’analyse approfondie des besoins conduit la MOE à « ouvrir la boîte noire » pour
caractériser plus précisément les besoins de l’application (besoins produit). Ces deux temps
peuvent être soit distincts, soit entremêlés si les parties (MOA et MOE) sont réunies dans une
même équipe.
Les besoins analysés décrivent ce que l’application doit faire dans l’environnement qui est le
sien (ses buts), les principaux services qu’elle doit rendre (besoins fonctionnels), les exigences
qualitatives souhaitées (cf. paragraphe 1.3) et les contraintes sous lesquelles l’application
doit s’exécuter et être développée. Ces deux dernières catégories sont souvent regroupées
sous la dénomination de « besoins non fonctionnels ». Les exigences de qualité doivent être
mesurables et vérifiables contrairement aux autres besoins et contraintes.

F IGURE 2.1 Classification des besoins

2 • Les activités du développement 19

Remarque : Le terme « exigence » est parfois considéré comme un simple synonyme de

« besoin » et parfois réservé, comme ici, aux besoins non fonctionnels vérifiables.

2.1.2. Définition de l’activité

L’activité de recueil des besoins recouvre la réflexion conduite pour bien appréhender le
problème, construire et formuler les besoins bruts. La collecte des informations peut se faire
par des entretiens, des questionnaires, des groupes de travail, des brainstormings, la lecture
de documentations, l’observation in situ des utilisateurs, la collecte d’exemples (scénarios),
etc. Dans tous les cas, il faut se méfier des connaissances tacites, souvent non explicitées par
ceux qui y sont accoutumés, et des différences ou conflits entre points de vue différents.
Le terme « recueil » a été retenu ici parmi tous ceux proposés pour traduire le terme anglais
elicit car il a plusieurs sens tous pertinents qui incluent la cueillette, le rassemblement de
choses éparses et l’enregistrement par écrit de quelque chose.
Entrée : L’idée brute d’une nouvelle application.
Principales questions à se poser [BR05] :
– À qui l’application est-elle destinée ?
– Pourquoi est-elle attendue ?
– Quels problèmes doit-elle résoudre ? Quel est son périmètre ?
– Quelles seront ses conditions d’utilisation ?
– Quand est-elle attendue ?
– Comment fonctionnera-t-elle ?

Sortie : Il n’y a de sortie matérialisée par un document que si l’activité de recueil constitue
une phase isolée. C’est le cas dans les processus classiques en cascade ou en V (cf. paragraphe
4.1), où l’activité de recueil des besoins est sous le contrôle de la maîtrise d’ouvrage (MOA),
bien séparée de la maîtrise d’œuvre (MOE). Le document d’expression des besoins (ou cahier
des charges client) assure l’interface entre MOA et MOE. Il constitue le point de départ de la
phase ultérieure d’analyse et spécification des besoins par la MOE.
Dans les approches agiles (cf. paragraphe 4.4), toute la réflexion sur les besoins est effectuée
au sein d’une équipe mixte MOA+MOE. Il n’y a pas nécessité de sortie formalisée à l’activité
de recueil. La compréhension partagée des besoins bruts résultant des discussions entre toutes
les parties prenantes permet d’enchaîner immédiatement la suite du processus.
Difficultés : « The hardest single part of building a software system is deciding precisely
what to build » (« La partie la plus difficile de la construction d’un logiciel consiste à définir
précisément quoi construire ») [Bro87].
Cela résulte entre autres choses :
– De problèmes de compréhension : les développeurs et le client ne parlent pas le même
langage. Les utilisateurs ne connaissent pas vraiment leurs besoins. Les développeurs
connaissent mal le domaine de l’application.
– De problèmes humains : conflits, rétention d’information, etc.
– De problèmes de volatilité des besoins.
20 Partie 1. Le développement logiciel

2.1.3. Le document d’expression des besoins

Quand il existe, ce document n’est pas contractuel. Il décrit succinctement les besoins
essentiels, sans donner d’indications sur la manière dont il vont être satisfaits.
Le document d’expression des besoins contient souvent les rubriques suivantes :

Positionnement stratégique de l’application~: importance, bénéfices

attendus, conséquences d’une non réalisation, etc.
Utilisateurs~: destinataires, nombre (total, en simultanéité),
localisation (locale, distante), compétences, etc.
Services attendus~: principaux services attendus, priorités
(avec 2 ou 3 niveaux).
Evolutions prévisibles~: du périmètre fonctionnel, du périmètre
d’utilisation, etc.
Contexte technique~: matériel et logiciel.
Contraintes d’exploitation~: plages horaires, tolérances
d’interruption, temps de réponse, etc.
Echéances~: démarrage possible, date de terminaison souhaitée,
disponibilité des personnes concernées, etc.

Les besoins bruts sont répertoriés de manière informelle (en langue naturelle) ou parfois
semi-formelle, sous une forme compréhensible par des non informaticiens. Dans la catégorie
semi-formelle, les arbres de buts décrits au paragraphe suivant, les textes structurés et les
scénarios sont souvent utilisés à ce stade. Le document d’expression des besoins peut inclure
également des ébauches ou maquettes des interfaces homme-machine (IHM) et un glossaire
pour fixer le vocabulaire du projet.

2.1.4. Les réflexions en amont des besoins

Il faut souligner que la réflexion sur un projet démarre souvent très en amont du recueil des
besoins. Un projet d’informatisation s’inscrit en général dans une stratégie de développement
technologique qui s’inscrit elle-même dans la stratégie générale de l’organisation.
Ces deux stratégies doivent être « alignées », c’est-à-dire mises en cohérence. Ce processus
d’alignement stratégique, conduit par la maîtrise d’ouvrage stratégique (MOAS), c’est-à-
dire les dirigeants et décideurs au plus haut niveau, peut fonctionner dans les deux sens.
Classiquement c’est la stratégie de développement technologique qui s’aligne sur la stratégie
globale de l’organisation. Mais les technologies Web et Web 2.0 par exemple peuvent
devenir le fondement de nouvelles stratégies et de nouveaux avantages concurrentiels pour
les organisations. À l’occasion d’un projet d’informatisation, la stratégie globale peut être
infléchie.
Cet ouvrage n’explore pas plus avant ces questions de stratégie globale des organisations.
À un niveau plus opérationnel, de plus en plus d’approches d’ingénierie des besoins, dites
« GORE » pour Goal-Oriented Requirements Engineering [DLF93], donnent la priorité à
la question du « pourquoi ? » (définir les buts ou objectifs) sur les questions du « quoi ? »
(définir les besoins fonctionnels) et du « comment ? » (définir les besoins non fonctionnels).
En explicitant le pourquoi on peut espérer développer des applications plus pertinentes
2 • Les activités du développement 21

pour l’organisation, avec des fonctionnalités qui concrétisent réellement la satisfaction des
objectifs retenus.
Les buts aident à se focaliser sur l’essentiel et évitent de se perdre dans les détails. Ils
peuvent être exprimés à différents niveaux d’abstraction dans des arbres de décomposition
de buts (souvent des arbres ET/OU). Cette représentation permet de mettre en évidence des
alternatives et d’éventuelles contradictions entre buts.

F IGURE 2.2 Un arbre de décomposition de buts

Les besoins sont dérivés des buts. Contrairement aux buts qui sont des intentions générales,
les besoins sont soit des services qui doivent être offerts, soit des contraintes, soit des
exigences mesurables et testables.
Exemple
« L’application doit être facile à utiliser » est un but qui peut être raffiné en deux exigences
mesurables et vérifiables : « les utilisateurs doivent être capables d’utiliser les fonctions du
système après une formation de 3 heures » et « le nombre moyen d’erreurs faites par les
utilisateurs ne doit pas excéder 2 par jour ».

2.1.5. Le maquettage des interfaces homme-machine

Les maquettes permettent une première approche de l’interface homme-machine (IHM) de
l’application. Il s’agit de déterminer ce que souhaite l’utilisateur en termes d’organisation
générale des écrans, d’organisation visuelle des principaux contenus, de capacités d’action et
d’interaction, etc. Cette première approche doit être discutée, analysée et validée.
Ce genre de maquette peut être simplement ébauché à la main, produit avec des logiciels
généraux de dessin ou avec des outils spécialisés de maquettage d’IHM.
Les avantages de faire intervenir ce maquettage dès le début du processus de développement
sont multiples : aide au recueil des besoins, support de communication avec les clients et
utilisateurs, moyen de concrétiser la progression du travail d’analyse, etc.
22 Partie 1. Le développement logiciel

2.2 L’ANALYSE ET LA SPÉCIFICATION DES BESOINS

Synonymes : analyse et spécification des exigences, analyse et spécification, analyse,
spécification.

2.2.1. Définition de l’activité

L’analyse et la spécification des besoins prolonge l’activité de recueil des besoins. Elle vise
à établir une compréhension en profondeur des besoins très souvent via la construction de
modèles plus ou moins formels. L’analyste (MOE) « entre à l’intérieur de la boîte noire ».
La réflexion concerne le détail des fonctionnalités offertes, le comportement observable de
l’application pour ses utilisateurs, les exigences de qualité, etc.
[BR05] insiste sur le caractère progressif du travail de recueil et d’analyse. Dans les
approches classiques, il est souvent nécessaire de réaliser plusieurs itérations pour parvenir à
une compréhension satisfaisante partagée entre toutes les parties prenantes (MOA et MOE).
Dans les approches agiles, cette progression se fait de manière plus naturelle et fluide au sein
des équipes mixtes MOA+MOE.
Entrée : Besoins bruts résultant du recueil des besoins.
Tâches à réaliser : Il faut raffiner, structurer, vérifier et valider les besoins. Pour atteindre ces
objectifs, il est souvent utile de modéliser le problème pour approfondir la compréhension de
ce qui est attendu et modéliser la solution pour vérifier qu’elle répond de manière adéquate
aux besoins. On distingue plus précisément trois activités de modélisation :
– La modélisation des processus métiers : il s’agit de spécifier le « contexte métier », pour
l’essentiel qui fait quoi, quand et où dans le métier.
– La modélisation du domaine : il s’agit de spécifier les concepts fondamentaux du domaine
cible de l’application, essentiellement dans un modèle des classes du domaine.
Remarque : La distinction entre « contexte métier » et « domaine » n’est pas très claire.
Certains préfèrent utiliser « modélisation conceptuelle » à la place de « modélisation du
domaine », mais cette dernière expression reste de loin la plus utilisée.
– La modélisation de l’application : il s’agit de spécifier les aspects informatiques de
l’application visibles pour les utilisateurs, essentiellement dans un modèle des classes de
l’application.

Une fois raffinés, les besoins doivent être vérifiés par relecture, revue ou inspection
(cf. paragraphe 2.9.4.) pour y détecter erreurs, incohérences et autres défauts, et validés par
la négociation, pour s’assurer que les parties prenantes les comprennent de la même façon et
les acceptent.
Sortie : Il n’y a de sortie matérialisée par un document que si l’activité d’analyse et de
spécification constitue une phase isolée. C’est le cas dans les processus classiques en cascade
ou en V (cf. paragraphe 4.1), où l’activité d’analyse et spécification est sous le contrôle de la
maîtrise d’œuvre (MOE), bien séparée de la maîtrise d’ouvrage (MOA). Dans les approches
objet, l’analyse se concrétise par des modèles de classes, d’états et d’interactions. L’ensemble
des modèles élaborés à ce stade s’intègre dans le dossier de spécification des besoins ou
cahier des charges (détaillé). Ce document permet à la MOA et à la MOE de s’accorder sur
les besoins ainsi documentés.
2 • Les activités du développement 23

Dans les approches agiles (cf. paragraphe 4.4), toute la réflexion sur les besoins est effectuée
au sein d’une équipe mixte MOA+MOE. La formalisation est beaucoup plus légère car le
processus menant à une compréhension partagée ne passe pas prioritairement par l’écrit.

2.2.2. Le document de spécification des besoins

Dans les approches classiques, le document d’expression des besoins constitue souvent le
fondement du contrat entre maître d’ouvrage et maître d’œuvre. C’est la référence légale
pour déterminer quand le maître d’œuvre a terminé son travail. Un document précis limite
beaucoup le risque de contentieux.
Le détail du contenu peut varier notablement selon la nature et le contexte du projet. La norme
IEEE Std 830 propose le plan suivant :

1. Introduction
1.1. But du document
1.2. Portée de l’application : ce qu’elle fait et ne fait pas
1.3. Définitions, acronymes et abréviations (vocabulaire du projet)
1.4. Références (documents utilisés)
1.5. Vue d’ensemble du document
2. Description générale
2.1. Perspective de l’application
Environnement dans lequel s’inscrit le projet (stratégie, enjeux,
domaine, etc.)
Caractéristiques : autonome ou embarqué, avec quels composants,
interfaces matérielles, logicielles, utilisateur, etc.
2.2. Fonctions de l’application
Spécification détaillée des besoins fonctionnels (textuelle et
éventuellement semi formelle)
2.3. Caractéristiques de l’utilisateur
Expérience, expertise technique, niveau de formation, etc.
2.4. Contraintes
Tous les éléments qui risquent de limiter les options offertes
au concepteur (contraintes de développement, structurelles,
de performances, de sécurité, méthodologiques, etc.) .
2.5. Hypothèses et dépendances
Par exemple, système d’exploitation, matériel, etc.
3. Besoins spécifiques
Interfaces externes, modes de fonctionnement, gestion des données,
conformité à des standards, exigences qualitatives, etc.
4. Annexes (par exemple, les modèles construits pour la compréhension
du domaine, des processus et de l’application).
5. Table des matières
6. Index

On trouve également assez souvent un budget et un planning prévisionnel, des indications

sur le déploiement, l’exploitation et la maintenance de l’application, sur la formation des
utilisateurs, et une définition précise des responsabilités de la MOA et de la MOE.
24 Partie 1. Le développement logiciel

Dans le document de spécification des besoins, ceux-ci sont souvent classés en catégories
d’importance. Par exemple la technique de hiérarchisation des besoins MoSCoW définit
quatre classes repérées par les lettres M,S,C,W :
– M comme Must : besoin essentiel et incontournable.
– S comme Should : besoin important, mais qui pourrait éventuellement être satisfait
autrement.
– C comme Could : besoin optionnel, à satisfaire seulement si on a le temps.
– W comme Won’t : besoin non nécessaire maintenant mais qui pourrait éventuellement être
considéré plus tard.

Les besoins peuvent aussi être classés selon leur stabilité prévisible dans le temps, comme
« immuable », « plutôt stable », « plutôt volatil ».

2.2.3. Différentes formes de spécification des besoins

a) Informelle
Les spécifications en langage naturel ont l’avantage d’être facilement accessibles à tous,
en particulier aux clients et utilisateurs finaux. Mais elles présentent également beaucoup
d’inconvénients. Elles peuvent souffrir de nombreuses ambiguïtés, avec plusieurs sens pour
un même mot selon les personnes et les contextes. Certains traitements, comme la recherche
des contradictions, des oublis et des redondances, sont très difficiles, voire impossibles, à
automatiser. La simple recherche d’une information n’est pas chose aisée et le risque de
mélanger spécification et conception est important.

b) Semi-formelle
Une première possibilité est le langage naturel structuré, comme les user stories et les cas
d’utilisation qui seront étudiés en détail aux chapitres 10 et 11. La rédaction est guidée par
un modèle de description avec des règles de rédaction précises et documentées.
On peut aussi recourir pour certains aspects à du pseudocode, c’est-à-dire à une description
algorithmique de l’exécution d’une tâche, ce qui donne une vision plus opérationnelle du
système.
Les langages visuels (graphiques) sont aussi très populaires. La spécification utilise différents
diagrammes, accompagnés de texte structuré ou non. C’est l’approche retenue par UML avec
les cas d’utilisation, les diagrammes de cas et les diagrammes complémentaires, structurels et
comportementaux, qui seront présentés dans la suite de cet ouvrage. Les notations visuelles
sont intuitives, faciles à apprendre et à utiliser. Par contre, elles conservent souvent une
certaine dose d’imprécision et se prêtent mal aux analyses automatiques.

c) Formelle
La spécification exploite un formalisme mathématique, comme des langages logiques ou
des modèles formels de comportement. Les descriptions sont analysables automatiquement
et peuvent être utilisées pour automatiser la vérification et le test du logiciel. Par contre,
l’apprentissage et la maîtrise de ces approches sont difficiles.
2 • Les activités du développement 25

En pratique, l’utilisation des langages formels apparaît se limiter aux logiciels critiques (en
avionique, espace, santé, nucléaire, etc.) ou aux parties critiques de certains gros logiciels.

d) Qualités recherchées
Quelle que soit la forme retenue, on cherche toujours à éviter au maximum le bruit (éléments
inutiles qui empêchent de saisir l’essentiel), le silence (absence d’information sur une
caractéristique du problème), la sur-spécification (introduction d’éléments de la solution),
les contradictions, les ambiguïtés, les références avant (utilisation d’une information qui est
définie ultérieurement) et les vœux pieux (souhaits irréalisables) [Mey85].

2.2.4. Les besoins non fonctionnels

Il existe des check-lists pour recenser les besoins non fonctionnels. Par exemple, FURPS+
qui sont les initiales en anglais des principales catégories :
– Functionality : fonctions, capacités, sécurité, etc.
– Usability : facteurs humains, aide, documentation, etc.
– Reliability : fréquence des pannes, possibilité de récupération, etc.
– Performance : temps de réponse (un délai inférieur à un dixième de seconde est
imperceptible, alors qu’un délai d’une seconde commence à devenir problématique),
débit, exactitude, consommation de ressources, etc.
– Supportability : adaptabilité, maintenance, configurabilité, etc.

Le + de FURPS+ correspond à des facteurs complémentaires :

– langages, outils, aspects matériel, etc.,
– contraintes d’interfaçage avec des systèmes externes,
– aspects juridiques, licences, etc.

2.2.5. Modélisation du domaine vs modélisation de l’application

a) Modèle du domaine
La modélisation du domaine décrit à l’aide d’un diagramme de classes les objets (concepts)
essentiels qui existent dans l’environnement au sein duquel s’inscrit l’application. On parle
également d’« objets conceptuels » ou d’« objets métier ». Les classes correspondantes sont
caractérisées par des attributs et ne portent pas en général d’opérations.
Il est possible qu’un objet conceptuel devienne ultérieurement un « objet logiciel » mais
ce n’est pas systématique. Certains objets conceptuels sont décomposés en plusieurs objets
logiciels. D’autres concepts ne sont pas représentés, ou pas représentés comme des objets
mais par exemple comme des attributs. Et bien entendu des objets logiciels supplémentaires
peuvent apparaître, comme des structures de données ou des objets de l’interface homme-
machine.
26 Partie 1. Le développement logiciel

Plusieurs approches ont été suggérées pour déterminer les classes du domaine :
– identifier les noms et groupes nominaux des descriptions textuelles du domaine,
– réutiliser et adapter des modèles existants ou « patrons d’analyse » (analysis patterns),
– utiliser des listes types de classes d’objets conceptuelles.
Ces approches seront présentées en détail au chapitre 8.
Il est souvent difficile de construire du premier jet un modèle de classes du domaine
« satisfaisant » et « complet ». Une tel modèle se construit le plus souvent en plusieurs
itérations, en approfondissant progressivement la connaissance du domaine en lien avec les
« experts » de ce domaine.

b) Modèle de l’application
Le modèle (conceptuel) d’une application décrit l’organisation générale de cette application
telle qu’elle est perçue par ses utilisateurs.
Il s’exprime par un diagramme de classes qui ajoute aux classes du domaine retenues pour
l’application, les principaux « artefacts » visibles par les utilisateurs et approuvés par eux (à
l’exclusion des artefacts d’implantation). On parle souvent de « classes frontière » (boundary
classes) et de « classes contrôleur ». Dans un tel modèle, les principales opérations de chaque
classe sont spécifiées.

2.3 LA CONCEPTION ARCHITECTURALE ET DÉTAILLÉE

2.3.1. Caractéristiques
À ce stade, qui correspond logiquement au troisième stade du développement, les concepteurs
doivent s’accorder sur la manière dont l’application doit être construite pour répondre au
problème défini lors de l’analyse des besoins.
En anglais, on résume souvent la différence entre analyse et conception par les formules
do the right thing (faire ce qu’il faut) pour l’analyse et do the thing right (le faire
correctement) pour la conception.
Cette solution qui satisfait la spécification des besoins s’exprime à deux niveaux.
– La description architecturale de l’application en termes de ses composants, des relations
entre ses composants et des relations avec son environnement.
Les composants d’une architecture peuvent être non seulement des composants logiciels,
mais aussi des bases de données, des flux de messages ou d’événements, ainsi que les
éléments physiques sur lesquels ces composants sont déployés, comme les serveurs, les
clients, les intergiciels (middleware), etc.
– La description détaillée de la conception de l’application qui peut comprendre :
• la réalisation des fonctionnalités par les composants,
• la structuration des données,
• l’organisation précise des interfaces, humaines (IHM) et logicielles, etc.
2 • Les activités du développement 27

Un précédent ouvrage, complémentaire de celui-ci, détaille les principes et concepts

essentiels de la conception architecturale et détaillée, en termes de patrons de conception, de
principes de conception et d’architectures [Lon14].

2.3.2. Patron de conception vs patron d’analyse

a) Patron de conception

Un patron de conception (design pattern) est une solution générale à un problème de

conception logicielle courant, validé par l’expérience. En général, un patron de conception
décrit une structure de classes et d’interfaces, et s’applique donc au développement de
logiciels utilisant la programmation orientée objet (quel que soit le langage). Les patrons
peuvent être combinés au sein d’une conception.

La description d’un patron de conception comporte le plus souvent : son nom, le problème
à résoudre (le contexte), la solution sous la forme d’une certaine configuration de classes et
d’interfaces, les forces (avantages) de cette solution.

Les noms des patrons constituent une sorte de « langage commun » entre les concepteurs et
avec les programmeurs.

Exemple : Le patron « Observateur » [Gam+95] permet de définir une dépendance de un à

plusieurs, de l’observé aux observateurs.

F IGURE 2.3 Le schéma de classes du patron de conception Observateur

Quand l’observé change d’état, les observateurs qui se sont enregistrés auprès de lui via la
méthode ajoute sont notifiés par notifie. Ils se mettent à jour (méthode miseAJour)
en récupérant l’état de l’observé par getEtat.
28 Partie 1. Le développement logiciel

b) Patron d’analyse
Un patron d’analyse est défini par Martin Fowler comme une « idée qui a été utile dans
un certain contexte d’application et qui sera probablement utile dans d’autres » [Fow97]. Il
précise que ces patrons reflètent des structures conceptuelles liées aux aspects fonctionnels
plutôt qu’aux implantations logicielles.
Les patrons d’analyse permettent de répondre à des questions telles que : Comment
représenter une quantité ? Une mesure ? Une organisation ? Une tâche à accomplir ? Une
période ? Etc.
Exemple : Le patron Event analysis montre comment capturer la mémoire de quelque chose
d’intéressant, appelé « événement », qui affecte le domaine considéré.

F IGURE 2.4 Le patron d’analyse Event analysis

2.4 L’IMPLANTATION
Le stade de l’implantation de l’application qui fait suite logiquement à sa conception,
comprend d’abord le codage dans le(s) langage(s) cible(s) de l’ensemble des fonctionnalités
qui doivent être incluses dans la livraison (release). La livraison peut correspondre à un
sous-ensemble du système ou au système complet selon le processus de développement
suivi. Le codage est le plus souvent manuel avec quelques éléments qui peuvent être générés
à partir des modèles de conception.
Les différents composants doivent ensuite être testés isolément (tests unitaires). Puis leur
assemblage doit être progressivement testé (tests d’intégration), jusqu’au test de la livraison
complète (tests de validation ou tests système). Enfin, l’application peut être fournie en « bêta
test » à quelques utilisateurs avant son déploiement effectif.
L’équipe de développement doit également produire toutes les informations et documents
utiles au déploiement et à l’exploitation de l’application, comme les manuels utilisateurs, le
« paquet d’installation », les guides d’installation, etc. Tous ces éléments doivent également
être soigneusement vérifiés.

2.5 LE DÉPLOIEMENT
Le stade du déploiement de l’application fait suite logiquement à son implantation. Chaque
déploiement recouvre un ensemble d’activités comme la livraison sur les sites concernés,
l’installation (manuelle ou automatisée), la configuration, la mise en pré-production puis en
production et la formation des utilisateurs.
2 • Les activités du développement 29

Une organisation pour la remontée des questions, problèmes et suggestions doit également
être mise en place.
Il est important que les utilisateurs soient très précisément informés de ce qui est déployé
et des limitations existantes de la livraison, pour éviter des attentes inconsidérées et des
déceptions de leur part. Il est peu recommandé de déployer une livraison insuffisamment
testée qui risque de traumatiser durablement les utilisateurs.

2.6 LA MAINTENANCE
Le stade de la maintenance débute dès que l’application est déployée. Elle prend trois formes
principales :
– La maintenance corrective correspond à l’identification et la correction des erreurs
détectées pendant le fonctionnement de l’application.
– La maintenance perfective correspond à l’amélioration des performances ou de la
maintenabilité et à l’ajout de fonctionnalités.
– La maintenance adaptative correspond à l’adaptation du logiciel aux changements de son
environnement : modifications des règles métier, modifications des formats des données,
modifications de l’environnement d’exécution, etc.

Concrètement, il s’agit avant tout de gérer le flux des remontées d’information en provenance
des utilisateurs. Il peut s’agir :
– de rapports d’anomalie (bug reports),
– de demandes de modification (change requests),
– de demandes d’extension (feature requests).
Ces demandes doivent être analysées et triées, puis planifiées et traitées quand elles le
méritent. De nombreux outils existent pour faciliter cette gestion, comme Bugzilla, Jira,
Trac, etc.
En général, le flux des remontées s’accroît progressivement avec le temps. Finalement, devant
l’importance de l’effort et du budget de maintenance, qui représente couramment 60 à 70 %
du budget alloué au logiciel, la nécessité de refondre (reengineering) ou de renouveler les
applications finit par s’imposer.
Plus globalement, la gestion du parc applicatif peut impliquer l’utilisation de techniques :
– d’inventaire et de cartographie du parc (ou plus ambitieusement « d’urbanisation du
système d’information »),
– de restructuration automatique des codes et des données,
– d’ingénierie de rétro-conception (reverse engineering) qui consiste à analyser les
codes sources pour créer automatiquement des représentations à un plus haut niveau
d’abstraction facilitant leur compréhension,
– d’ingénierie de (re)construction (forward engineering) pour produire une nouvelle
application à partir d’une ancienne.
30 Partie 1. Le développement logiciel

2.7 LA VÉRIFICATION ET LA VALIDATION (V&V)

2.7.1. La vérification
La vérification vise à montrer qu’un produit, quel qu’il soit, satisfait sa spécification, c’est-
à-dire un ensemble de propriétés qui ont été explicitées. C’est un processus « interne » à
l’équipe de développement et relativement « objectif ».

F IGURE 2.5 Vérification et validation

Elle peut se matérialiser pour les programmes par :

– des examens ou revues du code pour s’assurer de la conformité aux spécifications,
– des tests, établis à partir des spécifications : exécution d’un programme sur des données
choisies dans le but de détecter des non-conformités,
– des preuves de programmes basées sur des méthodes de déduction,
– des vérifications de modèle (model-checking), basées sur des méthodes d’exploration du
graphe d’états du système, etc.

La vérification a des limites pratiques sur lesquelles on reviendra et des limites théoriques,
liées à l’indécidabilité algorithmique. Par exemple, aucun algorithme ne peut prouver :
– qu’un programme est une implantation correcte de sa spécification,
– qu’un programme se termine,
– que deux programmes calculent la même chose.

2.7.2. La validation
La validation vise à montrer que l’application, et en particulier sa spécification, satisfait les
besoins du client. Au contraire de la vérification, c’est un processus « externe », conduit avec
les clients, et plutôt « subjectif » (cf. figure 2.5).
2 • Les activités du développement 31

Elle peut se concrétiser par :

– de l’analyse des buts,
– de la modélisation,
– du prototypage rapide,
– des tests d’acceptation et d’utilisabilité,
– des examens ou revues des spécifications, etc.

2.7.3. Les tests

a) Définition

« Tester, c’est exécuter un programme dans l’intention d’y trouver des anomalies ou des
défauts » [Mye79].
En toute rigueur, les termes « erreur », « défaut » et « anomalie » devraient être distingués.
L’erreur est effectuée par le concepteur ou le programmeur. Elle se matérialise par un défaut
dans le code qui produit une anomalie lors de l’exécution, c’est-à-dire une différence entre le
comportement observé et le comportement attendu.

erreur → défaut → anomalie

Un test se définit avec quatre éléments (cf. figure 2.6) :

– l’objectif (spécification) du test,
– le cas de test, c’est-à-dire un ensemble de données à fournir en entrée,
– le scénario de test, c’est-à-dire la séquence d’actions à exécuter (programme de test),
– l’oracle, qui dit le résultat attendu.

F IGURE 2.6 Les éléments d’un test

32 Partie 1. Le développement logiciel

b) Limites
Le test est une méthode de vérification partielle : « Tester permet seulement de révéler la
présence d’erreurs mais jamais leur absence » [Dij72]. En effet, le test est un processus fini
alors que le nombre d’exécutions possibles d’un programme est potentiellement infini. Il faut
faire face à l’explosion combinatoire des cas à tester. On y parvient grâce à des heuristiques de
choix des données de test, comme l’analyse partitionnelle en classes d’équivalence, les tests
aux limites des différentes classes, les approches combinatoires qui garantissent que chaque
couple de deux valeurs est testé au moins une fois (pairwise testing), les tests aléatoires, etc.

c) Classification
Il existe trois axes principaux de classification des tests, comme le montre la figure suivante.

F IGURE 2.7 Les axes de classification des tests

On peut tout d’abord classer les tests selon leur position dans le cycle de vie : tests
unitaires, tests d’intégration, tests système, tests d’acceptation et tests de non-régression
après modification (cf. paragraphe 4.1.2.).
On peut ensuite classer les tests selon l’objectif de qualité visé : tests de conformité aux
fonctionnalités attendues, tests de robustesse en cas d’utilisations imprévues, tests de sécurité
en cas d’attaques, tests de performance, etc.
On peut enfin distinguer les tests fonctionnels de type « boîte noire » et les tests structurels
de type « boîte blanche ». Les premiers ne nécessitent pas de connaître la structure interne
de l’application. Ils permettent d’assurer la cohérence entre spécification et code, mais
sont aveugles aux défauts fins de programmation. Les seconds se fondent sur la structure
interne de l’application, souvent représentée de manière abstraite sous la forme d’un graphe.
Ils sont adaptés à la recherche des défauts fins de programmation, mais sont aveugle aux
fonctionnalités absentes. Les deux types sont donc tout à fait complémentaires.
2 • Les activités du développement 33

2.8 LA DOCUMENTATION
La documentation est une activité présente à tous les stades qui cible aussi bien les
développeurs que les clients et les utilisateurs.
La documentation technique à destination de l’équipe de développement est le moyen de
créer une base commune de référence qui évite par exemple la perte d’informations lors du
départ d’un développeur et facilite l’intégration de nouveaux développeurs. Elle comprend
les modèles d’analyse et de conception, la documentation du code – algorithmes, interfaces
de programmation (API), maquettes, prototypes –, les jeux de tests, etc.
Il a parfois été préconisé d’aller plus loin en répertoriant tous les choix faits à chaque stade
du développement, avec un objectif de traçabilité. Chaque choix est relié à ceux qui l’ont
précédé et dont il dérive. On parle de « logique de conception » ou design rationale. C’est
une approche ambitieuse et lourde à mettre en œuvre.
La qualité de la documentation technique dépend à sa création des revues qui en sont faites,
puis du système de mise à jour qui doit permettre de la garder en conformité avec les
évolutions du logiciel. À noter que dans les approches agiles, il est souvent affirmé que
le code lui-même, abondamment commenté, et les jeux de tests constituent la meilleure
documentation technique et la seule qui a une chance de rester toujours à jour.
Pour les clients, la documentation permet de donner une certaine compréhension de l’état
d’avancement du projet de développement.
Pour les utilisateurs, la documentation finale doit inclure les manuels d’utilisation et les
aides en ligne. Les utilisateurs, ou le plus souvent certains d’entre eux, peuvent fortement
contribuer à conserver la documentation à jour en remontant tous les problèmes qu’ils y
détectent.

2.9 LES ACTIVITÉS DE GESTION

Elles prennent place tout au long du développement et recouvrent la gestion de projet, la
gestion de configuration, la gestion des besoins et la gestion de la qualité.

2.9.1. La gestion de projet

a) Définition

Le concept de « projet » recouvre « un processus unique 1 qui consiste en un ensemble

d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans
le but d’atteindre un objectif conforme à des exigences spécifiques telles que des contraintes
de délais, de coûts et de ressources » (norme ISO 10006).
Gérer un projet signifie prendre toutes les mesures nécessaires pour faire en sorte qu’il
atteigne ses objectifs en termes de qualité des livrables (deliverables), de respect des délais,
de respect des coûts et de satisfaction du client.

1. Non répétitif.
34 Partie 1. Le développement logiciel

La gestion de projet classique se décline selon trois dimensions complémentaires :

– Prévoir, c’est-à-dire structurer et planifier le projet.
La structuration d’un projet consiste à comprendre et expliciter les différents livrables à
produire puis à définir les activités qui seront nécessaires pour aboutir à ces productions.
La planification d’un projet consiste à prévoir l’ordonnancement des activités et
l’utilisation des ressources.
– Contrôler, afin de pouvoir piloter le projet.
Le pilotage d’un projet consiste à identifier au plus tôt tous les problèmes rencontrés, en
particulier les dérapages de planning et de coûts, afin de mettre en place des mesures
correctives.
– Animer, c’est-à-dire gérer l’équipe projet.
Le management d’une équipe consiste à créer les conditions de la réussite, en organisant
et accompagnant le travail au quotidien, en maintenant la cohérence des objectifs de
chacun avec l’objectif global, en évaluant les résultats et les performances et en maintenant
motivation et harmonie au sein de l’équipe.

b) Approche classique et approche agile

On distingue aujourd’hui deux grandes approches en gestion de projet, assez radicalement
opposées : l’approche « classique » (appelée aussi approche « prédictive ») et l’approche
« agile » (appelée aussi approche « adaptative »). Le tableau ci-après récapitule de manière
schématique les différences essentielles entre les deux approches en termes de structuration,
planification, pilotage du projet et management des équipes.

Domaine Approche classique Approche agile

Structuration Périmètre et exigences définis
au début et supposés stables.
Structuration rigide produit/processus.
Qualité évaluée sur le produit fini.
Planification Planification détaillée rigide.
Changements éventuellement admis,
relèvent de procédures spécifiques.
Pilotage Conformité aux plans, analyse écarts.
Documentation systématique.
Management Chef de projet, contrôle hiérarchique.
Spécialisation des participants.
Définition au fil de l’eau d’une suite
d’incréments fonctionnels.
Incréments opérationnels.
Feedback rapide du client.
Planification au fil de l’eau.
Changements attendus,
relèvent du processus normal.
Un seul indicateur : fait/reste à faire.
Documentation légère : code, tests.
Auto-organisation, initiatives.
Partage et transparence.

Le paragraphe suivant résume les principaux outils de la gestion de projet classique. La

gestion de projet agile sera détaillée au chapitre 5, à l’occasion de la présentation des
démarches agiles XP et Scrum.
2 • Les activités du développement 35

c) Les outils de la gestion de projet classique

➤ La structure de découpage de projet
La « structure de découpage de projet » ou Work Breakdown Structure (WBS) est une
décomposition sous forme arborescente des activités, purement statique, c’est-à-dire sans
notion d’ordonnancement.

F IGURE 2.8 Une structure de découpage de projet (WBS)

La racine de l’arbre est le projet tout entier et les feuilles sont les tâches considérées comme
élémentaires, c’est-à-dire bien définies et donc faciles à gérer : entrées et résultat (livrable)
clairement identifiés, responsabilité confiée à des acteurs précis, ressources nécessaires
connues, durée et coût évaluables.
La WBS facilite la préparation du graphe PERT pour l’ordonnancement des tâches ainsi que
la préparation du budget et la définition des missions confiées à chaque acteur.

➤ Le graphe PERT
Le graphe PERT (Program Evaluation and Review Technique) permet d’évaluer la durée
totale d’un projet et de détecter les tâches critiques ne supportant aucun retard.
Le point de départ de sa construction est la liste de toutes les tâches, avec pour chacune sa
durée et la liste des tâches antérieures.
Exemple
Le graphe PERT décrit les contraintes d’antériorité entre tâches. Les tâches constituent les
arcs du graphe et les états d’avancement du projet, les sommets 2 . Les arcs sont orientés de
l’état de début vers l’état de fin de la tâche et étiquetés par les durées des tâches. Les numéros
des sommets sont conformes à l’ordre de succession des états.
Pour concevoir le graphe PERT, on classe les tâches par niveaux :

2. Il existe d’autres méthodes, comme la méthode des potentiels, où les tâches sont les sommets et les arcs sont
les dépendances.
36 Partie 1. Le développement logiciel

Tâche Tâche(s) antérieure(s) Durée

A – 6
B – 5
C A 4
D B 6
E C 5
F A, D 6
G E, F 4

– au niveau 0, les tâches commençantes qui n’ont pas de tâches antérieures,

– au niveau 1, les tâches dont les tâches antérieures sont de niveau 0,
– au niveau i (i 2), les tâches dont les tâches antérieures sont de niveau inférieur avec au
moins une tâche de niveau i − 1.

On construit le graphe en intégrant les tâches par niveaux croissants et en respectant toutes les
contraintes d’antériorité. Pour exprimer certaines contraintes d’antériorité, il faut introduire
des tâches fictives de durée nulle (figurées en pointillés sur le dessin du graphe ci-dessous).
Il faut essayer d’en limiter le nombre au maximum.
Exemple
Le tableau précédent définit quatre niveaux de tâches : A et B sont au niveau 0, C et D au
niveau 1, E et F au niveau 2 et G au niveau 3. À partir de ces niveaux, on peut construire le
graphe de la figure 2.9 qui respecte toutes les contraintes d’antériorité avec une seule tâche
fictive.

F IGURE 2.9 Le graphe PERT

La date au plus tôt de l’étape i (ti ) représente le temps minimum pour l’atteindre. Elle se
détermine de proche en proche, par ordre de sommet croissant, à partir de l’entrée du graphe,
par : t1 = 0 et tj = max(ti + dij ) pour tous les i précédant j, où dij est la durée de la tâche
ij.
Exemple
t1 = 0, t2 = 0 + 6 = 6, t3 = 0 + 5 = 5, t4 = 6 + 4 = 10, t5 = max(6 + 0, 5 + 6) = 11,
t6 = max(11 + 6, 10 + 5) = 17, t7 = 17 + 4 = 21.
2 • Les activités du développement 37

La date au plus tard de l’étape i (Ti ) représente le temps maximum pour l’atteindre sans
augmenter la durée totale du projet. Elle se détermine de proche en proche, à partir de la
sortie (n) du graphe, par : Tn = tn et Ti = min(Tj − dij ) pour tous les j suivant i.
Exemple
T7 = 21, T6 = 21 − 4 = 17, T5 = 17 − 6 = 11, T4 = 17 − 5 = 12, T3 = 11 − 6 = 5,
T2 = min(11 − 0, 12 − 4) = 8, T1 = min(8 − 6, 5 − 5) = 0.
On a toujours t1 = T1 = 0 et t T pour tout sommet. La marge totale d’une tâche (M T )
représente le retard maximal qu’on peut prendre dans sa réalisation sans retarder l’ensemble
du projet. Elle vaut : M Tij = Tj − ti − dij .
Exemple
Calcul des marges totales du graphe précédent :

Tâche Marge totale

A M T12 = 8 − 0 − 6 = 2
B M T13 = 5 − 0 − 5 = 0
C M T24 = 12 − 6 − 4 = 2
D M T35 = 11 − 5 − 6 = 0
E M T46 = 17 − 10 − 5 = 2
F M T56 = 17 − 11 − 6 = 0
G M T67 = 21 − 17 − 4 = 0

Les tâches critiques sont celles dont la marge totale est nulle. Il existe toujours un chemin
critique allant de l’entrée à la sortie et composé uniquement de tâches critiques. Il est
représenté en traits épais dans le dessin de la figure 2.9.

➤ Le diagramme de Gantt
Le diagramme de Gantt est un outil de planification où chaque tâche est représentée par une
ligne. Les colonnes représentent les jours, semaines ou mois du calendrier selon la durée du
projet.

F IGURE 2.10 Un diagramme de Gantt

38 Partie 1. Le développement logiciel

Le temps estimé pour une tâche se modélise par une barre horizontale dont l’extrémité gauche
est positionnée sur la date prévue de démarrage et l’extrémité droite sur la date prévue de fin
de réalisation. Les tâches peuvent s’enchaîner séquentiellement ou bien être exécutées en
parallèle. Il est possible de faire apparaître aussi sur le diagramme de Gantt les ressources,
humaines ou matérielles, afin de faciliter l’estimation des besoins et des coûts.

2.9.2. La gestion de configuration

La gestion de configuration consiste à gérer, d’une part, la description technique d’un
système en termes de composants et, d’autre part, l’ensemble des modifications opérées sur
les composants au cours de la vie du système.
En développement logiciel, la gestion de configuration sert principalement à tracer tous les
changements opérés par l’équipe de développeurs sur les codes sources de l’application
et les artefacts associés (tests unitaires, fichiers de configuration, etc.) sous forme de
versions-révisions-corrections successives. Elle peut servir également à gérer les évolutions
des documents associés, comme les dossiers d’analyse et de conception ou les manuels
utilisateurs. Elle s’appuie sur des logiciels de gestion de versions et de configurations, soit
centralisés comme CVS et Subversion (SVN), soit décentralisés (répartis) comme Git ou
Mercurial.
Plus précisément, la gestion de configuration couvre les domaines suivants.

F IGURE 2.11 La gestion de configuration

a) La définition et l’identification des composants du système

Exemple

F IGURE 2.12 Historique de l’évolution d’un composant

2 • Les activités du développement 39

On note dans cet exemple une identification classique des composants par un numéro
de version (correspondant à une refonte ou extension majeure), un numéro de révision
(correspondant à une amélioration des performances, de la présentation ou un ajout de
fonctionnalité mineure) et un numéro de correction (correspondant à la correction d’une ou
plusieurs erreurs).

b) Le contrôle des changements

Il définit comment et quand les changements sont opérés et inclut les aspects suivants :
– contrôle d’accès,
– gestion des requêtes de changement (change request),
– définition et respect d’un processus de changement,
– suivi des erreurs et des corrections,
– propagation des changements,
– travail individuel en isolation (dans un espace de travail),
– résolution des conflits (fusion), etc.

c) La (re)construction du système
Une configuration cohérente du système complet est reconstruite à partir des composants
versionnés.

d) La traçabilité et l’information
La traçabilité implique l’historisation des composants et des processus de changement.
L’information inclut statistiques, rapports d’avancement, requêtes, etc.

2.9.3. La gestion des besoins

Le gestion des besoins recouvre principalement leur documentation dans un référentiel, leur
traçabilité sous différentes formes et leur versionnement.

a) La documentation des besoins

Chaque besoin est caractérisé par un ensemble d’attributs. Les principaux d’entre eux sont un
identifiant, un nom, une description, une source, une stabilité, une criticité et une priorité.
Dans les projets de grande taille, le référentiel des besoins doit pouvoir être interrogé et filtré
à volonté.

b) La traçabilité des besoins

Elle doit permettre de répondre à trois questions essentielles. D’où provient le besoin
(traçabilité amont) ? Quels autres besoins lui sont liés (traçabilité entre besoins) ? Comment
est-il relié aux autres informations comme les documents de conception, l’implantation, les
utilisateurs (traçabilité aval) ?
40 Partie 1. Le développement logiciel

c) Le versionnement et la configuration des besoins

Les besoins évoluent tout au long du cycle de vie du logiciel. La maintenance adaptative
et la maintenance perfective résultent pour partie de ces évolutions continuelles (cf.
paragraphe 2.6). Il faut enregistrer l’état des besoins à tous les stades pour pouvoir les
retrouver si nécessaire. Chaque version des besoins est repérée par un numéro de version.
Une configuration regroupe un ensemble cohérent de versions des besoins, avec une seule
version par besoin. Elle peut par exemple correspondre aux besoins associés à une certaine
livraison du logiciel.

2.9.4. La gestion de la qualité

a) Contrôle qualité et assurance qualité
Ces deux aspects sont souvent distingués au sein de la gestion de la qualité.

➤ Contrôle qualité
Le contrôle qualité est l’ensemble de toutes les actions qui permettent d’assurer que les
artefacts du développement satisfont leurs critères de qualité. Ces actions se pratiquent tout
au long du développement. Pour les codes, on peut pratiquer des contrôles statiques, c’est-
à-dire sans exécution, comme les relectures (revues et inspections), les analyses de code,
les preuves formelles, etc., ainsi que des contrôles dynamiques, c’est-à-dire en exécutant les
codes, comme les tests ou le prototypage. Pour les autres artefacts, on peut pratiquer des
relectures, des vérifications de modèle (model checking), etc.

➤ Assurance qualité
L’assurance qualité recouvre la mise en place et la gestion de l’infrastructure qui englobe tous
les moyens permettant de produire du logiciel de qualité : méthodes, outils, gestion de projet,
contrôle qualité, etc. Ces moyens sont décrits dans le plan d’assurance qualité.
Les gestionnaires et les techniciens doivent recevoir toutes les informations nécessaires pour
établir leur confiance dans la qualité du logiciel produit.

b) Les relectures
On distingue toute une série de techniques apparentées :
– l’autocorrection ou relecture personnelle, considérée comme de faible efficacité, car il est
toujours difficile de trouver ses propres erreurs,
– la relecture croisée avec un collègue, déjà plus efficace, surtout quand elle est systématisée
comme dans la pratique du développement en binôme des approches agiles,
– la revue informelle (walkthrough) où un lecteur résume paragraphe par paragraphe le
document qui est discuté informellement par le groupe de revue, considérée comme
d’efficacité moyenne,
– la revue structurée autour d’une check-list de défauts et d’un secrétaire qui dirige les
débats, considérée comme plus efficace,
2 • Les activités du développement 41

– l’inspection, plus lourde à mettre en œuvre mais qui présente la meilleure efficacité. Le
travail s’organise selon le processus suivant qui est planifié :

1. Préparation :
- recherche des défauts selon une check-list par des inspecteurs,
- rédaction d’un rapport de défauts basé sur un formulaire type.
2. Réunions avec un modérateur, les inspecteurs, un secrétaire pour noter
les décisions et l’auteur du document pour répondre aux questions :
- examen des défauts,
- prise de décision.
3. Suivi :
- vérification des corrections ou nouvelle inspection.

2.10 LA DISTRIBUTION EFFORTS/ERREURS/COÛTS

Il est intéressant en conclusion d’analyser la ventilation des efforts, des erreurs et du coût
selon les différentes activités du développement logiciel.

F IGURE 2.13 Distribution efforts/erreurs/coûts

En termes d’efforts, il faut remarquer que le codage ne représente qu’un pourcentage assez
faible de l’effort total (de l’ordre de 20 %).
En termes d’erreurs et de coûts, on peut souligner que plus de la moitié des erreurs peut être
attribué à des déficiences dans la spécification des besoins. Ces erreurs génèrent plus de 80 %
du coût de maintenance ! L’ingénierie des besoins constitue donc bien un enjeu majeur pour
le développement du logiciel.
42 Exercices

EXERCICES

Exercice 2.1. L’ingénierie des besoins

Le processus d’ingénierie des besoins est représenté comme suit par Petko Valtchev :

Que recouvre la négociation les besoins ?

Exercice 2.2. Besoins fonctionnels et non fonctionnels

On considère une application de contrôle d’ascenseurs.
Donner des exemples de besoins fonctionnels et non fonctionnels pour ce type d’application.

Exercice 2.3. La difficulté à spécifier rigoureusement un problème

La règle de notation d’un examen est la suivante : « L’examen comporte 20 questions à
réponses multiples. Chaque bonne réponse rapporte 1 point. Chaque mauvaise réponse fait
perdre 1/3 de point. Chaque question sans réponse donne 0 point. »
a) Cette spécification est-elle claire et non ambiguë ? Pour le vérifier, calculer la note des 3
étudiants suivants :

Noms Réponses Réponses Sans Doubles

correctes incorrectes réponse réponses
Dupont 10 5 5
Dutif 4 16
Duduche 10 3 4 3 (1 juste et 1 fausse chaque fois)

b) Proposer une spécification plus précise.

2 • Les activités du développement 43

Exercice 2.4. La difficulté à tester rigoureusement un problème

Un programme reçoit en entrée trois entiers a, b et c qui représentent les longueurs des côtés
d’un triangle. Le programme détermine si le rectangle est équilatéral (trois côtés égaux),
isocèle (deux côtés égaux au moins) ou quelconque – scalène – (trois côtés différents).
Un expert du domaine rappelle que la somme des longueurs de deux côtés d’un triangle est
toujours strictement supérieure à la longueur du troisième côté (en tout cas en géométrie
euclidienne et si on considère qu’un triangle d’aire nulle n’est pas un triangle. . . ).
Donner le jeu de test le plus exhaustif possible. Glenford Myers [Mye79], l’auteur de cet
exercice, signale que les développeurs expérimentés ne trouvent en moyenne que la moitié
des cas des tests qu’il suggère.

Exercice 2.5. Arbre de buts

Soit l’arbre de buts ET/OU suivant, concernant une application de gestion d’une bibliothèque.
Commenter ce graphe et le conflit entre buts qu’il recèle.

Exercice 2.6. Relectures de code

a) Trouver et corriger quatre défauts dans le code Java suivant :
int factorielle(int n) {
int f;
while (n >= 0) {
n = n-1;
f = f*n;
}
return n;
}

b) Trouver et corriger cinq défauts dans le code Java suivant :

44 Exercices

int indicePremierElementNul(int[] tab) {

int i;
if (tab.length > 0)
for(i=1; i <= tab.length; i++)
if (tab[i] = 0)
return i;
else
System.out.println("tab est vide");
return -2;
return -1;
}

Exercice 2.7. PERT

Soit le projet comportant les tâches suivantes.
a) Construire le graphe PERT correspondant.
b) Calculer les dates au plus tôt, les dates au plus tard, les marges totales et le chemin critique.

Tâche Tâche(s) antérieure(s) Durée

A – 3
B A 1
C A 5
D B 6
E B 4
F C, D, I 2
G E, F 9
H – 5
I H 8
J H 2
K I 3
L J, K 7