INTITULE DU COURS

LE GENIE LOGICIEL
Promotion : BAC+4 INFORMATIQUE
Volume horaire : 60 HEURES (45 heures de CM et TD + 15 heures de TP)

TITULAIRE DU COURS
Elam KYUNGU LUKOMBA, Assistant
Concepteur des systèmes d’information
Téléphone : +243(0) 990526886
E-mail : elamkyungu@gmail.com

PRE-REQUIS
- Algorithmique et méthodes de programmation I et II
- Langages de programmation
- Technique des bases de données
- Conception de systèmes d'information
- Méthodes d’analyse informatique

OBJECTIFS

Objectif général
Ce cours a pour but de présenter le génie logiciel comme un corpus bien structuré de
connaissances et de techniques utilisables dans le processus de production du logiciel.
Objectifs spécifiques
De manière spécifique, le cours poursuit les objectifs suivants :
1. Présenter le génie logiciel comme science et art en fournissant une circonscription de
cette discipline, sa terminologie (termes, concepts et notions), son histoire, son
évolution à ce jour et ses orientations futures.
2. Présenter la méthodologie de l'ingénierie du logiciel en donnant les concepts
méthodologiques, les modèles de cycles de vie et modèles de processus existants, avec
un accent particulier sur les approches nouvelles.
3. Présenter les activités de développement et maintenance du logiciel et les activités de
management de projets logiciels ainsi que les théories et techniques associées.

CONTENU DU COURS

CHAPITRE I : GÉNÉRALITÉS SUR LE LOGICIEL ET LE GÉNIE LOGICIEL

CHAPITRE II : LA MÉTHODOLOGIE DU GÉNIE LOGICIEL
CHAPITRE III. L'INGÉNIERIE DES EXIGENCES LOGICIELLES
CHAPITRE IV. LA GESTION DE PROJETS DE DÉVELOPPEMENT DU LOGICIEL
CHAPITRE V. LA CONCEPTION DU LOGICIEL
CHAPITRE VI. LA CONSTRUCTION ET LE TEST DU LOGICIEL
STRATEGIES D’EVALUATION
- Travaux dirigés à l’occasion des séances de cours
- Travaux pratiques
- Interrogations et Examen
- Présence et participation.
 Chapitre I.
GÉNÉRALITÉS SUR LE LOGICIEL ET LE GÉNIE LOGICIEL

I.1 Généralités sur le logiciel

I.1.1 Quelques définitions et termes apparentés

a) Le logiciel
a.1) Quelques définitions
Étymologiquement, le terme « logiciel » dérive du mot « logique », par opposition à « physique
ou matériel ». Il fut créé en 1972, d’après Wikipédia, du terme anglais Software. La traduction
française a été officialisée par un arrêté publié au Journal Officiel du 17 janvier 1982.
De nombreuses définitions sont proposées pour le terme logiciel. On en trouve qui sont
simples voire simplistes, mais aussi des plus élaborées. On en trouve qui sont proposées par des
auteurs à titre individuel, mais aussi qui sont proposées par des institutions. Dans l’ensemble,
elles reprennent un certain nombre d’éléments communs. Dans les paragraphes qui suivent, nous
passons en revue quelques définitions issues de références importantes, ensuite l'on peut
s'exercer à formuler une définition propre.
Le Journal Officiel français du 22/12/1981 définit le logiciel comme l’ensemble de
programmes, procédés et règles, et éventuellement de la documentation relatifs au
fonctionnement d’un ensemble de traitements de l’information.
Le glossaire IEEE 610.12-1990 relatif à la terminologie du génie logiciel définit le logiciel
comme l’ensemble de programmes informatiques, procédures et éventuellement la
documentation associée et les données permettant le fonctionnement des programmes.
Selon le professeur Julius Marcelin Nkelifack, le logiciel est défini comme un ensemble de
programmes informatiques (codes sources, éditables, exécutables), mais également les données
qu’ils utilisent et les documents se rapportant à ces programmes et nécessaires à leur
installation, utilisation, développement et maintenance : spécifications, schémas conceptuels,
jeux de test, guide d'installation, mode d’emploi, etc.
Pour le professeur Roger S. Pressman, le logiciel égale (1) les instructions (programmes
informatiques) qui, quand on les exécute, fournissent les fonctions et les performances
attendues, (2) les structures de données qui permettent aux programmes de manipuler
correctement l’information et (3) les documents qui décrivent le fonctionnement et l’utilisation
de ces programmes.
a.2) Les éléments constitutifs d'un logiciel
En croisant les différentes définitions, trois éléments reviennent : le logiciel est constitué
de programmes et procédures, de données et d'une documentation éventuelle.
Les programmes et procédures fournissent les fonctions et performances attendues, c'est-
à-dire qu'ils réalisent les opérations de traitement de l'information attendues du logiciel par
l'utilisateur. On a, d'une part, le(s) programme(s) principal(aux) et, d'autre part, les sous-
programmes (procédures et fonctions) (Cf. les cours d'algorithmique et de langages de
programmation). Sur l'ordinateur, les programmes existent sous forme de code source (fichiers
de code source ou fichiers sources tout court), de programmes exécutables (fichiers
exécutables) et de bibliothèques de fonctions réutilisables (fichiers de bibliothèques statiques
ou dynamiques).
Les fichiers de données empaquetés dans le logiciel, par opposition aux fichiers exécutables
et fichiers de bibliothèques, permettent de sauvegarder les paramètres de configuration et
d'autres données nécessaires au fonctionnement des programmes.

Page 1
 La documentation, c'est l'ensemble des documents papier ou des fichiers numériques faisant
partie du logiciel et destinés à décrire le fonctionnement et l'utilisation des programmes et du
logiciel de manière global.
b) Quelques termes apparentés au terme « logiciel »
À côté voire à la place du terme « logiciel », d’autres termes sont couramment utilisés, y
compris dans le milieu des informaticiens. Il s'agit, entre autres, des termes suivants : système
logiciel, application logicielle, programme (informatique), progiciel. Même si cela peut paraître
peu important, dans ce cours consacré au génie logiciel, nous trouvons l’opportunité de préciser
les petites nuances existant entre ces différents termes.
Afin d'éviter toute confusion qui pourrait résulter de l’utilisation du terme logiciel pour
désigner indifféremment un programme et un vrai logiciel, certaines personnes préfèrent le
terme système logiciel. Ici alors, un système logiciel peut être vu comme un ensemble de
programmes, de fichiers de documentation et de fichiers de configuration, etc. Tandis qu’un
programme fait référence à un jeu d’instruction exécutant une fonction ou une procédure
spécifique, un système logiciel désigne quant à lui un ensemble de programmes, de
documentations et de données.
Dans tous les cas, un logiciel est plus qu’un programme, plus qu’un ensemble de programmes
; si donc le terme « logiciel » est utilisé, il vaut mieux qu’il signifie « système logiciel ».
Une application logicielle, ou application tout court, est un logiciel considéré comme un moyen
informatique pour réaliser une tâche d'un utilisateur. En entreprise, par exemple, une
application peut servir à faciliter le travail ou augmenter la productivité des employés
(informatique de gestion). En famille, elle peut servir à la réalisation de tâches personnelles, à
l’apprentissage des enfants ou des adultes, au divertissement, etc. ( informatique domestique).
Un autre concept important c'est la « suite logiciel ». Wikipédia définit une suite logicielle
comme un ensemble de logiciels applicatifs ou d'outils de programmation offrant de
fonctionnalités liées, et possédant souvent une interface graphique plus ou moins similaire. C'est
le cas de suites bureautiques comme LibreOffice ou Microsoft Office, de suites multimédia
comme Adobe CS, etc.
I.1.2 La classification de produits logiciels
On peut classifier les produits logiciels selon plusieurs critères couvrant différents points
de vue. Les critères les plus courants sont : la licence du logiciel (point de vue juridique ou de
la propriété intellectuelle), l'utilisation à laquelle est destinée le logiciel sur l'ordinateur (point
de vue fonctionnel), le coût d'acquisition ou le marché ciblé ( point de vue économique ).
a) Selon la licence du logiciel : logiciel libre – logiciel propriétaire
En droit commercial, une licence de logiciel est généralement définie comme un contrat par
lequel le titulaire des droits d'auteur sur un programme informatique définit avec son
cocontractant (exploitant ou utilisateur) les conditions dans lesquelles ce programme peut être
utilisé, diffusé ou modifié.
Une licence peut être libre ou propriétaire. Une licence libre est une licence s'appliquant à
une œuvre de l'esprit par laquelle l'auteur concède tout ou partie des droits que lui confère le
droit d'auteur, en laissant au minimum les possibilités de modification, de rediffusion et de
réutilisation de l'œuvre dans des œuvres dérivées. Ces libertés peuvent être soumises à
conditions, notamment l'application systématique de la même licence aux copies de l'œuvre et
aux œuvres dérivées, principe nommé copyleft.
Un des aspects souvent mal compris du principe de licence libre est que celui-ci ne traite
pas de la valeur marchande de la diffusion des œuvres. Une œuvre sous licence libre n'est pas
nécessairement disponible gratuitement, pas plus qu'une œuvre disponible gratuitement n'est
Page 2
nécessairement libre. Cette confusion est entretenue par le double-sens du mot anglais free
(libre ou gratuit), c'est pourquoi le terme « libre » (français) est parfois employé en anglais,
comme dans l'expression « software libre ».
Les licences libres les plus populaires sont : la GNU General Public License (GNU GPL) ou
licence publique générale en français, la GNU Lesser General Public License (GNU LGPL) ou
licence publique générale amoindrie en français, la GNU Free Documentation License (GNU FDL)
ou licence de documentation libre, la licence BSD, la licence Apache, la licence Mozilla publique
(MPL), etc.
Une licence propriétaire ou licence privative est toute licence qui n'est pas libre. Plus
explicitement, c'est une toute licence qui définit des conditions d'utilisation entravant un des
droits donnés par les licences libres, à savoir utiliser, étudier, modifier, dupliquer ou diffuser
l'œuvre sur laquelle porte la licence. L'achat de telles licences ne correspond pas à l'achat d'une
œuvre ; l'acquisition concerne un droit d'utilisation limité au cadre établi par la licence, le
transfert de propriété n'existant qu'en cas de vente du droit d'auteur ou brevet associé.
Par définition, un logiciel libre est un logiciel dont l’utilisation, l’étude, la modification et la
duplication en vue de sa diffusion sont permises, techniquement et légalement. Exemples : le
système d'exploitation GNU/Linux, le navigateur web Mozilla Firefox.
Un logiciel propriétaire est un logiciel dont le contrat de licence stipule que seul l’auteur du
logiciel est agréé de le modifier. Exemples : le système d'exploitation Microsoft Windows, le
lecteur PDF Adobe Reader, l'atelier de génie logiciel Enterprise Architect.
b) Selon l'utilisation faite : logiciel d'application – logiciel système – logiciel de support
Selon l'utilisation faite, on distingue : le logiciel d'application, le logiciel système et le
logiciel de support.
Le logiciel d'application, appelé également logiciel applicatif ou application ou applicatif est
tout logiciel conçu pour répondre à des besoins spécifiques d’un utilisateur ; il permet à
l’utilisateur de réaliser une tâche précise. Exemples : un logiciel de paie des agents dans une
entreprise.
On trouve habituellement plusieurs types de logiciels d'application désignés de manière
spécifique. Par exemple : Dactylogiciel, Didacticiel, Exigiciel, Maliciel, et bien d'autres. En
somme, il s'agit de logiciel d'application désignés en fonction de l'utilisation précise (ex :
dactylogiciel = logiciel d'apprentissage de la dactylographie).
Le logiciel système est tout logiciel conçu pour faciliter le fonctionnement et la maintenance
d’un système informatique et ses programmes. Exemples : les systèmes d’exploitation (MS
Windows, GNU/Linux, ...), les explorateurs de fichiers (Windows Explorer, Nautilus, …), les
gestionnaires de programmes et utilitaires associés ( Ubuntu Software Center, apt-get, …), etc.
Le logiciel de support est tout logiciel qui aide au développement ou à la maintenance d’autres
logiciels. Exemples : compilateurs (Free Pascal Compiler, MS Visual C++ Compiler, GCC, …),
éditeurs de code source ( Notepad++, nano, …), les environnements de développement intégrés
(Microsoft Visual Studio, Eclipse IDE, NetBeans IDE, CodeBlocks IDE, …), etc.
c) Selon le coût d'acquisition : logiciel gratuit – logiciel payant
Selon le coût d'acquisition, on distingue le logiciel gratuit, celui qui est utilisable
gratuitement, et le logiciel payant, dont l'utilisation se fait moyennant des frais d'acquisition.
d) Selon le marché ciblé : progiciel – logiciel spécifique
Selon le marché ciblé par la production d'un logiciel, on peut distinguer le logiciel générique
ou progiciel du logiciel spécifique.
Le logiciel spécifique est tout logiciel développé pour un client particulier. Les ingénieurs
construisent le logiciel uniquement pour ce client. Dans cette classe, on trouve essentiellement

Page 3
des logiciels conçus pour des appareils électroniques, des systèmes réalisés pour informatiser
des activités d’un processus métier, des systèmes de contrôle aériens, etc. Exemple : Logiciel
quelconque de vente demandé par un magasin lushois.
Le progiciel ou logiciel générique est tout logiciel développé par un éditeur pour un marché
ouvert, sans cibler un client particulier. Dans cette classe on trouve les logiciels développés
pour PCs tels que les bases de données, les traitements de texte, les logiciels de retouches
d’images, les logiciels de gestion de projets, etc. Des exemples : la suite bureautique Microsoft
Office, le logiciel de retouche d'image Adobe Photoshop.
I.1.3 Les familles de produits logiciels
On retrouve plusieurs familles de logiciels selon l’usage qu’on en fait ou selon d’autres
caractéristiques : les systèmes d’exploitation, les systèmes embarqués, les systèmes temps
réels, les applications web, les logiciels bureautiques, les logiciels PC, les logiciels de calcul
scientifiques, les logiciels de modélisation et de simulation, les applications de gestion, etc.
La diversité de familles de logiciels conduit les ingénieurs du logiciel à disposer de plusieurs
méthodes, techniques et outils de travail de manière à choisir les plus adaptés à un projet
particulier. Il n’existe pas de méthode ou technique universelle permettant de produire tous les
logiciels.
I.1.4 De l'importance du logiciel
Des économistes modernes considèrent l’information comme le quatrième facteur de
production à côté de la nature, de l’argent et du travail. Certains établissent même que
l’information est le patrimoine le plus important dans les organisations, leur ressource-clé. Sans
vouloir plonger dans cette polémique et peu importe la place qu’une organisation peut réellement
accorder à l’information dont elle dispose, il s’agit, tout de même, d’une ressource importante,
vitale et cette ressource est manipulée, traitée, stockée, transmise d’un poste à un autre grâce
au logiciel. Le logiciel est le moyen par excellence de traitement de l’information ; c’est le
produit informatique de premier ordre.
Puisque les organisations ne peuvent se passer du traitement de l’information, elles ne
peuvent se passer du logiciel. Notre monde moderne n'aurait pas pu tourner autant qu’il le fait
s’il n’y avait pas de logiciel. De nombreuses activités personnelles ou organisationnelles sont
informatisées et dépendantes du logiciel. Dans certains cas, il est tout simplement impossible
de réaliser des traitements manuellement, le logiciel s’imposant alors obligatoirement. Et cela
touche même les activités critiques du domaine du civil et du militaire. Le professeur Ian
Sommerville appelle cette caractéristique du logiciel la « dépendabilité ».
Du fait de la dépendabilité des logiciels, il est important, si pas indispensable, pour
l'industrie du logiciel de parvenir à développer des produits fiables à 99,99 %.
I.1.5 De la qualité des produits logiciels
La qualité de logiciels est définie du point de vue des clients et utilisateurs et du point de
vue des ingénieurs développeurs. Pour les clients et utilisateurs, la qualité d’un logiciel est son
aptitude à répondre aux besoins pour lesquels il a été conçu. Pour les développeurs, un logiciel
est de qualité s’il est facile à modifier et moins cher à faire évoluer. La qualité du logiciel est
une appréciation globale du logiciel. Les problèmes de qualité des logiciels, connus depuis la
première heure du développement logiciel, sont, par ailleurs, à l’origine du génie logiciel.
La qualité du logiciel s’exprime en termes de facteurs (ou caractéristiques) et d’attributs
(ou souscaractéristiques). Un facteur de qualité désigne une propriété du logiciel susceptible
d’être requise par le client, l’utilisateur ou le développeur. Cette propriété affecte
significativement la qualité globale du logiciel.

Page 4
 La norme ISO/IEC 9126 « Technologies de l’information : Qualités des produits logiciels »
définit et décrit une série de caractéristiques de qualité d’un produit logiciel qui peuvent être
utilisées pour spécifier les besoins des clients et des utilisateurs.
Chaque caractéristique est détaillée en sous-caractéristiques, et pour chacune d’elles, la
norme propose une série de mesures à mettre en place pour évaluer la conformité du produit
développé par rapport aux attentes.
La dernière version de la norme ISO/IEC 9126 date de 2001, révision de la version de 1991.
Elle définit comme caractéristiques : la capacité fonctionnelle, la fiabilité, l’efficacité, la
maintenabilité et la portabilité.
• La capacité fonctionnelle (functionality) : Ensemble d’attributs portant sur l’existence
d’un ensemble de fonctions et leurs propriétés données. Les fonctions sont celles qui
satisfont aux besoins exprimés ou implicites. Elle répond à la question : Est-ce que le
logiciel répond aux besoins fonctionnels exprimés ? Ses sous-caractéristiques sont :
aptitude ou pertinence (suitability), exactitude (accuracy), interopérabilité (
interoperability), conformité (compliance), sécurité (security), disponibilité (availability
).
• La fiabilité (Reliability) : Ensemble d’attributs portant sur l’aptitude du logiciel à
maintenir son niveau de service dans des conditions précises et pendant une période
déterminée. Ses sous-caractéristiques sont : maturité (maturity), tolérance aux fautes
(fault tolerance), capacité de récupération (recoverability).
• La facilité d'usage (Usability) : Ensemble d’attributs portant sur l’effort nécessaire
pour l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini
ou implicite d’utilisateurs. Ses sous-caractéristiques sont : facilité de compréhension
(understandability), facilité d’apprentissage ( learnability), facilité d’exploitation
(operability), pouvoir d’attraction.
• Le rendement/efficacité (Efficiency) : Ensemble d’attributs portant sur le rapport
existant entre le niveau de service d’un logiciel et la quantité de ressources utilisées,
dans des conditions déterminées. Ses souscaractéristiques sont : comportement
temporel (time behaviour), utilisation des ressources (resource behaviour).
• La maintenabilité (Maintainability) : Ensemble d’attributs portant sur l’effort
nécessaire pour faire des modifications données. Ses sous-caractéristiques sont :
facilité d’analyse (analysability), facilité de modification (changeability), stabilité
(stability), facilité à être testé (testability).
• La portabilité (Portability) : Ensemble d’attributs portant sur l’aptitude du logiciel à
être transféré d’un environnement à un autre. Ses sous-caractéristiques sont : facilité
d’installation (installability), facilité de migration (replaceability), adaptabilité
(adaptability), conformité propre à la portabilité (compliance).
La norme ISO/CEI 9126 a été reprise et complétée par la norme ISO 25000, également
appelée « SQuaRE (pour Software Quality Requirements and Evaluation, Exigences et
évaluation de la qualité logiciel) ».
Apparaissent alors de nouvelles caractéristiques : il s’agit de la sécurité et la compatibilité.
• La sécurité (Security) : La sécurité est à l’aptitude à se protéger et à protéger les
données de toute force de menace ou d’attaque, interne ou externe. Ses sous-
caractéristiques sont : la confidentialité, l’intégrité, la non répudiation, l’authenticité, la
comptabilisation. La confidentialité est l’aptitude d’un logiciel de cacher les données et
le montrer uniquement aux personnes autorisées. L’intégrité est l’aptitude du logiciel à
protéger les données contre les modifications non autorisées. La non répudiation est

Page 5
 l’aptitude du logiciel à prouver qu’une action a eu lieu. L’authenticité est l’aptitude du
logiciel à identifier ses utilisateurs et à s’assurer que toute identité fournie peut être
vérifiée. La comptabilisation est l’aptitude du logiciel à attribuer chaque action à son
auteur.
• La compatibilité (Compatibility) : Ses sous-caractéristiques sont : la coexistence et
l’interopérabilité.
I.1.6 De la complexité du produit logiciel et de la production du logiciel
Dans la théorie systémique, un système est complexe s’il est constitué de plusieurs éléments
divers, entremêlés, en interrelations et en interactions. Chaque élément de l’ensemble est défini
par ses propres caractéristiques et contraintes que le système doit gérer pour pouvoir
maintenir sa cohésion interne et continuer à remplir ses fonctions dans son environnement. Les
systèmes logiciels, indépendamment de leur taille ou de leur importance, sont complexes.
Plusieurs raisons sont à la base de cette complexité, les plus évidentes étant la nature même du
logiciel, les besoins changeant de ses utilisateurs, le souci de sophistication, les imperfections
inhérentes à la nature de personnes qui le construisent et la diversité des attributs de qualité.
• La nature du logiciel : La nature du logiciel est la principale source de sa complexité
Les systèmes logiciels sont abstraits et intangibles. Ils ne sont régis ni par les lois
physiques, ni par les propriétés des objets matériels, ni par les processus de fabrication
que connaissances les produits habituels. Pour cela, il n’y a pas de limite aux potentiels
du logiciel, ce qui pourrait avoir pour conséquence de simplifier la construction du
logiciel. Cependant, puisqu’il y a absence de contraintes physiques, les systèmes logiciels
peuvent rapidement devenir extrêment complexes, difficile à comprendre et coûteux à
modifier. Pouvoir gérer la complexité du logiciel est le problème majeur qui donne des
maux de tête aux spécialistes de la chose.
• Les besoins changeants : Les demandes croissantes de logiciels sophistiqués
contribuent aussi à la complexité Les logiciels doivent être construits et livrés
rapidement ; les clients demandent des systèmes de plus en plus sophistiqués.
• Les erreurs humaines : L’impossibilité de produire du logiciel parfait contribue aussi à
la complexité. Il est pratiquement impossible pour les ingénieurs de produire du logiciel
parfait, sans erreur. Errare humanum est, disaient les latins.
• Le besoin de maintenance : Le besoin de modifier ou de faire évoluer le logiciel dans le
temps contribue aussi à la complexité. Donner aux ingénieurs la possibilité de revenir
pour modifier le logiciel complexifie davantage son développement, dès l’instant que le
code doit être écrit de telle sorte qu’il soit aisé de le changer sans revenir à zéro.
• Le manque de compétences : S’il est relativement aisé d’écrire des programmes
informatiques sans utiliser les méthodes et les techniques du génie logiciel, le manque
de formations adéquates en génie logiciel conduit au développement de logiciels plus
coûteux et moins fiables.
• La diversité des attributs de qualité : Le nombre élevé et le caractère parfois
contradictoire des attributs de la qualité de produits logiciels contribuent également à
sa complexité.
I.2 Généralités sur le génie logiciel

I.2.1 La crise du logiciel et la naissance du génie logiciel

Le terme « Crise du logiciel », « Software crisis » en anglais, désigne la situation générale
qui caractérisa les échecs de développement logiciel dans les années 60 et 70. Dans son essence,

Page 6
 le terme fait référence à la difficulté d’écrire de programmes informatiques corrects,
compréhensibles et vérifiables.
On retiendra trois principales causes à l’origine de ce phénomène :
• la complexité du logiciel,
• les attentes trop importantes des clients et utilisateurs et
• les changements à apporter aux produits logiciels.
Les causes de la crise du logiciel étaient liées à la complexité que présentait le processus de
développement du logiciel et du matériel informatique.
Des faits tels que le non-respect des budgets et délais, l’inefficacité des produits logiciels,
le faible niveau de qualité du logiciel en général, le non-respect des exigences, la difficulté de
maintenir le code source, le taux élevé de projets abandonnés étaient manifestes et
caractéristiques de cette crise.
Plutôt que de s’attarder sur les faits du passé, il est plus utile d'insister sur le caractère
actuel de la crise du logiciel. Les difficultés rencontrées par les programmeurs entre 60 et 70
sont loin d’être passées. D'ailleurs, elles persistent aujourd'hui encore. Nous vivons tous,
chacun à sa manière, la crise du logiciel. Par exemple, une étude de l'industrie du logiciel réalisée
en 2004 par le Standish Group1 et ayant ciblé un échantillon de 9236 projets de développement
logiciel a fourni les statistiques étonnantes ci-dessous. Ces données attestent clairement de
l'actualité de la crise du logiciel.

Projets couronnés de succès (29 Projets terminés hors budget,

%) hors délai ou avec moins de
fonctionnalités (53 %)
Projets échoués (18 %)

igure 1: Statistiques de réussite et échec de projets logiciels (Standish

Group, 2004).

D’où l’intérêt de maîtriser le génie logiciel, parce qu’on l’a justement inventé pour répondre
à cette crise et maîtriser la production du logiciel. La section suivante donne un aperçu du génie
logiciel ; les chapitres suivants s’étaleront sur tous les aspects théoriques et pratiques de la
discipline. I.2.2 Quelques définitions et termes apparentés
a) Le développement logiciel
Par développement logiciel, abrégé dev, software development en anglais, il faut entendre
l’ensemble des activités consistant à créer des produits logiciels. Il s'agit, au sens inclusif
du terme, de la capture et le développement des besoins des utilisateurs et autres parties
prenantes, de la conception de l'architecture, des interfaces et des composants du
logiciel, de l'écriture et du test du code source, jusqu'à la sortie d'une édition stable (
stable release en anglais) du logiciel. Mais au sens plus restreint, le terme développement
fait surtout allusion aux activités qui tournent autour du code source, à savoir l'écriture
et le test.

1
Le Standish Group International, Inc. ou Standish Group est une société internationale de consultance en études et
recherches fondée en 1985, très connue pour ses statistiques et rapports relatifs aux projets de mise en œuvre de
systèmes dans les secteurs public et privé.
Page 7
 On appelle développeur la personne ou l'organisation dont la conception, le développement
et commercialisation de produits logiciels est la profession ou l'activité professionnelle
principale. S'agissant de personnes physiques, au sens inclusif, tout professionnel qui travaille
à la réalisation d'un produit logiciel peut être appelé développeur. Dans ce sens, le terme
développeur vient en quelque sorte remplacer le terme analysteprogrammeur sous l'influence
de l'anglais. Néanmoins, au sens restreint, le terme qualifie uniquement les programmeurs,
excluant les analystes, les chefs de projets, les rédacteurs techniques, et parfois les testeurs.
S'agissant des organisations, on préférera le terme « éditeur » pour désigner toute entreprise
qui développe (édite) des produits logiciels. En anglais, éditeur se traduira alors par « software
vendor » ou « software company » et non par « editor » qui traduit « éditeur de texte ». Les
grands éditeurs de logiciels du marché à l'échelle planétaire incluent, entre autres, Microsoft
Corporation, Oracle Corporation, Systems, Applications & Products in Data Processing (SAP),
Symantec Corporation, Adobe Systems Incorporated, etc.
Beaucoup de personnes écrivent des programmes. Par exemple, certains bureaucrates
écrivent des procédures d’automatisation de tâches sur leurs tableurs tels que LibreOffice
Calc ou Microsoft Excel, certains scientifiques et ingénieurs écrivent des programmes pour
traiter leurs données expérimentales, d’autres encore écrivent des programmes pour s’occuper,
s’amuser, s’auto-former ou réaliser des travaux pratiques dans les cours de langages de
programmation. Au sens large, on peut appeler ça du développement logiciel. Toutefois,
l’essentiel du développement logiciel consiste en une activité professionnelle où le logiciel est
développé pour des besoins critiques des entreprises, ou destiné à être embarqué dans des
équipements spécifiques, ou à être intégré dans un système d’information informatisé ou dans
un autre système logiciel plus important.
Le logiciel professionnel est souvent construit par une équipe d’ingénieurs plutôt qu’un
individu, et souvent destiné à être utilisé par des personnes autres que ses développeurs. Il
comprend de nombreuses voire des milliers de fonctionnalités et doit pouvoir être maintenu et
changé pendant de longues années.
b) La programmation informatique et le génie logiciel
Beaucoup de personnes qui pratiquent la programmation informatique se considèrent voire
se font passer pour des ingénieurs logiciels. Il vous est déjà peut-être arrivé de penser la même
chose après que vous avez écrit un programme un peu plus complexe que le calcul de la
factorielle, ou l’enregistrement d’un client dans une base de données MySQL. Si tel est votre
cas, vous êtes bien loin de la vérité.
Le logiciel est un produit complexe qui inclut autre chose que les programmes. De même, le
développement logiciel professionnel est une activité complexe, bien au-dessus des seules
compétences de programmeur et, nous ne cesserons jamais de le répéter. Pour pouvoir
développer des logiciels de qualité, vous avez besoin d’acquérir des connaissances et des
compétences dans des domaines autres que les technologies de programmation, notamment le
processus d’ingénierie, la méthodologie de développement, les exigences, la modélisation, la
conception, le test, la gestion de projets, etc. La programmation informatique n’est pas le génie
logiciel ; c’est juste un des domaines de compétence indispensable à la pratique du génie logiciel.
c) Le génie logiciel
Le Journal Officiel français du 31/12/1983 définit le génie logiciel comme l’ensemble des
activités de conception et de mise en œuvre de produits et procédures tendant à rationaliser
la production du logiciel et son suivi.
Julius Marcelin Nkelifack définit le génie logiciel comme l’ensemble de méthodes, outils et
techniques utilisés pour développer et maintenir le logiciel dans le but d’assurer la qualité et la
productivité et de respecter les contraintes de délais et de budget.
Page 8
 Dans leur ouvrage Programmation orientée objet en C++ : Une approche évolutive, Marylène
Micheloud et Medard Rieder l’expliquent en ces termes : Le génie logiciel (anglais software
engineering) est une science de génie industriel qui étudie les méthodes de travail et les bonnes
pratiques des ingénieurs qui développent des logiciels.
Le génie logiciel est la discipline qui fournit le cadre systématique au développement du
logiciel ; c’est aussi la science appliquée traitant de la production du logiciel. En bref, le génie
logiciel est l’application de l’ingénierie à la production du logiciel. L’ingénierie est le
développement systématique, discipliné, planifié de produits et services nécessaires (utiles) à
la résolution de problèmes de la vie quotidienne. Elle est caractérisée par l’utilisation intensive
des théories, principes, méthodes, techniques et outils issus des disciplines mathématiques,
scientifiques et économiques, le respect de contraintes telles que les délais, les budgets, etc.
Le génie logiciel s’intéresse en particulier aux procédures systématiques qui permettent
d’arriver à ce que des logiciels de grande taille correspondent aux attentes du client, soient
fiables, aient un coût d’entretien réduit et de bonnes performances tout en respectant les
délais et les coûts de construction.
La contribution principale du génie logiciel à l'industrie du logiciel est l'apport d'une
démarche méthodique et reproductible dans le processus de production du logiciel là où la talent
et l'expérience personnelle des développeurs étaient la règle. Quelqu'un qui agirait sans aucune
méthode se lance dans un projet de développement logiciel immédiatement. Il va se mettre à
écrire du code pour répondre aux exigences du client. S'il ne structure pas son travail de
manière rigoureuse, il se heurtera à de nombreux problèmes : manque de clarté dans la
description des besoins des utilisateurs, glissements hors du cahier des charges, difficultés
d'estimer les coûts et les délais de réalisations, etc. Et il ne finira sans doute jamais son travail,
découragé par la difficulté, ou alors le bâclera, et le produit logiciel développé perdra toute sa
qualité, et donc son utilité. La première étape de la méthode, c'est justement de freiner l'élan.
Travailler avec méthode, ça commence par ne pas commencer. Il faut se donner le temps de la
réflexion, de l'analyse et de la conception. Il faut d'abord prendre de la distance par rapport
à son travail pour ne pas l'accomplir machinalement. Il faut se rendre compte que rien n'est
évident et se poser les questions qui viennent naturellement, à savoir « pourquoi ce travail ? »,
« quels en sont les enjeux ? », « quel en est l'objectif ? », etc.
I.2.3 L'objet d'étude, la portée et les objectifs du génie logiciel
a) L'objet d'étude et la portée du génie logiciel
Le génie logiciel étudie la production du logiciel. La production du logiciel est une activité
humaine et organisationnelle de création de produits logiciels ; elle est fondée sur l'utilisation
de méthodes, techniques et outils. Le résultat de cette activité est le produit logiciel.
De ce fait, le génie logiciel s’intéresse à tous les aspects de la production du logiciel, de la
première étape à la dernière. Il étudie et développe des théories, méthodes, techniques et
outils utilisables dans la production du logiciel. Il ne se limite pas aux activités techniques de la
production du logiciel ; il s’étend également à l’organisation et à la gestion de projets logiciels.
b) Le but et les objectifs du génie logiciel
Le but du génie logiciel est de parvenir à maîtriser tous les paramètres de la production du
logiciel. Quatre objectifs spécifiques sont poursuivis :
1. Assurer la qualité du logiciel ;
2. Réduire les coûts de production ;
3. Réduire les délais de production ;
4. Augmenter la productivité des développeurs.

Page 9
I.2.4 Le génie logiciel dans le monde professionnel
a) Les fondements des pratiques de l'ingénierie du logiciel
Le génie logiciel est d’abord une discipline d’ingénierie ; il vise à doter les développeurs de
logiciels informatiques de connaissances et compétences nécessaires à la construction, à
l’exploitation et à la maintenance de produits logiciels de qualité dans un contexte personnel ou
industriel. La réalisation d’un tel but passe par l’application d’un processus et d’une méthodologie
de développement efficace, suivie d’une maîtrise poussée des technologies de programmation
informatique et d’un management de projets efficient. Ce cours vise justement de vous en
apprendre les fondements. Il appartiendra à tout un chacun de se perfectionner et de gagner
le respect réservé aux ingénieurs professionnels par le travail.
Même si chaque projet de développement logiciel est particulier en soi, toutes les pratiques
professionnelles du génie logiciel reposent sur quelques principes essentiels qui devraient
caractériser tous les projets de développement logiciel :
• L'utilisation d'un processus efficace : L’organisation qui construit un logiciel doit
plannifier le processus de développement et avoir des idées claires du produit à réaliser
et des délais de production. Le processus n’est pas universel, à chaque logiciel conviendra
un processus différent. Cependant, l’idée même d’utiliser un processus de développement
efficace est essentielle.
• Le développement des exigences : Comprendre et gérer les exigences est important. Il
faut pouvoir identifier et satisfaire les besoins et les attentes des utilisateurs. Le
système logiciel construit doit pouvoir être livré dans le respect des délais et des
budgets fixés.
• Le respect de la qualité du logiciel : La dépendabilité et la performance d’importantes
caractéristiques pour n’importe quel type de logiciel. Les logiciels doivent fonctionner
comme prévu, sans failles et doivent être disponibles chaque fois que les utilisateurs en
ont besoin. Ils doivent fonctionner en toute sûreté et, dans la mesure du possible, se
sécuriser contre toute attaque externe. Ils doivent mêmement fonctionner
efficacement et éviter le gaspillage de ressources du système informatique.
• La réutilisation de ressources existantes : Il faut pouvoir réutiliser les ressources
existantes de manière à réduire les coûts et les délais. Par ressources existantes, on
peut par exemple entendre les bibliothèques et frameworks de développement, les codes
sources existants, etc.
• Le travail en équipe : L'envergure des produits et systèmes logiciels modernes requière
la collaboration de plusieurs acteurs et spécialistes et une synergie d'équipe. L'époque
du « programmeur en chef » et du « programmeur talentueux » est, aujourd'hui, révolue.
b) La recherche scientifique en génie logiciel
Le génie logiciel est aussi une discipline scientifique, une discipline de recherche, la science
de la production du logiciel. C’est la discipline scientifique qui étudie les méthodes, les
techniques, les outils, les processus et les activités de construction du logiciel. En tant que telle,
la science du génie logiciel cherche à comprendre les caractéristiques des méthodes,
techniques, outils, processus, activités de développement logiciel et à comprendre les
comportements des acteurs (clients, utilisateurs, ingénieur, etc.) participant aux projets
logiciels ; elle cherche aussi à développer de nouvelles méthodes et techniques, de nouveaux
outils et processus plus adaptés aux besoins des ingénieurs logiciels, à renforcer les capacités
de ces derniers et à optimiser les activités de production du logiciel.
La majorité des recherches dans ce domaine procèdent par le paradigme expérimental,
quand bien même on trouve aussi des études analytiques. Alors que certaines études portent
Page 10
uniquement sur les aspects techniques de la construction du logiciel, des études de plus en plus
nombreuses incluent les aspects humains et sociaux qui entourent la production du logiciel,
favorisant ainsi des approches pluridisciplinaires et des méthodes adaptées des sciences
sociales et humaines. Ces études partent de l’hypothèse que l’évaluation du travail de production
de logiciels en soi requiert l’étude des activités humaines exécutées tout au long des projets.
La deuxième considération est que la conception de logiciels informatiques ou des systèmes
interactifs en général doit être centrée sur l’utilisateur humain et que leur qualité est évaluée
en fonction de leur degré d’adéquation avec les caractéristiques de l’utilisateur humain
considéré vis-à-vis de la tâche à accomplir avec le système dans un contexte de travail
déterminé. La première considération est centrale à la recherche en génie logiciel parce qu’elle
concerne l’ingénierie du logiciel proprement dite ; en revanche, la deuxième intéresse surtout
les chercheurs en interaction homme-machine, elle concerne un aspect du produit logiciel, pas
directement la démarche de production.
Dans la pratique, on retrouve deux paradigmes de recherche en génie logiciel : le paradigme
analytique et le paradigme expérimental. Le paradigme analytique comprend une seule méthode,
la méthode analytique (ou mathématique) qui utilise l’approche déductive. Le paradigme
expérimental comprend les méthodes empiriques (l’expérimentation contrôlée, l’étude de cas,
l’enquête, l’ethnographie, la recherche-action), la méthode scientifique et la méthode
d’ingénierie, toutes procédant par l’approche inductive. Toutes les méthodes disposent de
techniques permettant de collecter et traiter à la fois les données qualitatives et les données
quantitatives. Internet regorge de nombreux articles sur la recherche scientifique en génie
logiciel.
c) La profession d'ingénieur du logiciel
Les ingénieurs et professionnels du logiciel bénéficient d’un encadrement de la part de
plusieurs organismes et institutions existantes, notamment en Amérique et en Europe. Chez
nous en R.D.Congo, ce n’est pas encore le cas. Beaucoup de certifications professionnelles
existent aussi, les plus populaires étant la Certified Software Development Associate (CSDA)
et la Certified Software Development Professional (CSDP) de la Computer Society du IEEE
(IEEE-CS), la Certified Associate in Software Quality (CASQ), la Certified Manager of
Software Quality (CMSQ), la Certified Sofware Quality Analyst, la Certified Software Quality
Engineer (CSQE), la Certified Associate in Software Testing (CAST), la Certified Software
Tester (CSTE) et la Certified Manager of Software Testing (CMST) du QAI Global Institute.
Le génie logiciel s’intéresse également à l’éthique et déontologie de la pratique de la
profession d’ingénieur logiciel. On notera le Code d’éthique et déontologie professionnelle que
doit signer toute personne désirant intégrer la profession des ingénieurs du logiciel et être
reconnu comme tel par ses pairs.
Le Code déontologique contient huit principes reliés au comportement et aux décisions
prises par les ingénieurs logiciels professionnels, qu’ils soient praticiens, éducateurs,
gestionnaires, superviseurs, décideurs ou encore apprentis et étudiants ingénieurs. Les
principes identifient les relations éthiques qui régissent les personnes, les groupes et les
organisations, ainsi que les obligations principales associées à ces relations. Les articles de
chaque principe illustrent quelques-unes des obligations assorties à ces relations. Ces
obligations sont fondées sur l’humanisme des ingénieurs logiciels, sur l’attention spéciale qu’ils
sont tenus d’accorder aux personnes touchées par leur travail et sur les éléments uniques de la
pratique du génie logiciel. Le Code prescrit ces obligations pour quiconque se réclame du titre
d’ingénieur logiciel ou aspire à le devenir.

Page 11
 La version abrégée du Code d’éthique et déontologie de l’ingénieur logiciel rédigée par le
groupe de travail IEEE-CS/CAM et approuvé conjointement par l’Association for Computer
Machinery (ACM) et la IEEE-CS, stipule ce qui suit :

Les ingénieurs logiciels doivent s’engager à faire de l’analyse, de la spécification, de

la conception, du développement, du test et de la maintenance une profession utile
et respectée. En accord avec leur engagement à la santé, la sécurité et le bien du
public, les ingénieurs logiciels doivent adhérer aux principes suivants :

1. Le public. Les ingénieurs logiciels doivent agir dans l’intérêt public en tout temps.

2. Le client et l'employeur. Les ingénieurs logiciels doivent agir d’une manière qui sert
le mieux possible les intérêts de leurs clients et de leur employeur, toujours en
fonction de l’intérêt public.

3. Le produit. Les ingénieurs logiciels doivent s’assurer que leurs produits et les
modifications connexes sont conformes aux normes professionnelles les plus
élevées possibles.
4. Le jugement. Les ingénieurs logiciels doivent maintenir leur intégrité et leur
indépendance dans leur jugement professionnel.
5. La gestion. Les gestionnaires et les responsables de génie logiciel doivent souscrire
à une approche éthique de la gestion du développement et de la maintenance des
logiciels et s’employer à en faire la promotion.
6. La profession. Les ingénieurs logiciels doivent s’assurer de l’intégrité et la
réputation de la profession en tenant compte de l’intérêt public.
Les collègues. Les ingénieurs logiciels doivent être justes et appuyer leurs
7.
collègues.
Soi-même. Les ingénieurs logiciels doivent être en situation d’apprentissage
8.
continu et promouvoir une approche éthique à la pratique de leur profession.

Page 12
 Chapitre II.
LA MÉTHODOLOGIE DE L'INGÉNIERIE DU LOGICIEL

Ce chapitre poursuit les objectifs spécifiques suivants :

1. Présenter les concepts et éléments méthodologiques de l'ingénierie du logiciel.
2. Présenter les modèles de cycle de vie traditionnels et récents.
3. Donner un aperçu exhaustif des activités d'ingénierie du logiciel ainsi que les produits
logiciels correspondants.
4. Présenter les principes généraux, les phases et les activités du processus unifié de
développement logiciel UP.
5. Présenter l'approche agile et quelques méthodes agiles courantes.

À l'issue du chapitre, l'étudiant devrait être en mesure de :

1. Définir et comprendre les concepts et éléments de la méthodologie de l'ingénierie du
logiciel.
2. Lister les modèles de cycle de vie existants et, pour chaque modèle, fournir les principes
fondamentaux, les phases, les forces, les faiblesses et les éléments de comparaison aux
autres modèles.
3. Lister et positionner dans le cycle de vie les activités de l'ingénierie du logiciel ainsi que
les produits logiciels associés.
4. Comprendre les principes fondamentaux, les phases et les processus logiciels d'UP.
5. Comprendre les fondements et les notions essentielles de l'approche agile et lister les
méthodes agiles les plus courantes.
II.1 Définition de concepts et notions

II.1.1 Le produit logiciel

Le glossaire de terminologie du génie logiciel (IEEE Std 610.12-1990) définit un élément
logiciel (software item en anglais) comme tout document ou tout fichier informatique
constitutif d'un logiciel. Il peut s'agir d'une unité de code source écrit par les programmeurs,
un code objet (c.-à-d. une unité de code compilé), un programme exécutable, un fichier de
données de contrôle, un document papier ou un fichier de documentation faisant partie d'un
logiciel. Un paquet comprenant deux ou plusieurs de ses éléments peut également être appelé
élément logiciel dès l'instant qu'il est considéré comme un tout.
Le même glossaire définit un produit logiciel (software product en anglais) comme un paquet
d'éléments logiciels livrable aux utilisateurs. Il s'agit donc d'un ensemble de programmes,
procédures, et éventuellement de la documentation et de données associées à ces programmes
empaqueté pour former un produit livrable, qu'il s'agisse d'un logiciel complet ou d'un ensemble
limité de composants du logiciel. Au sens général, un simple élément logiciel peut être aussi
appelé produit logiciel dès l'instant qu'il s'agit d'un résultat issu d'un travail d'ingénierie du
logiciel réalisé par un individu ou une équipe d'individus.
II.1.2 Le cycle de vie, la phase et le processus d'ingénierie du logiciel
a) Notions
La production du logiciel est un travail intellectuel complexe, long et généralement étalé sur
plusieurs mois voir années avant d'obtenir le produit logiciel escompté. Pendant ce temps-là,
plusieurs personnes vont intervenir et réaliser des tâches diverses et distinctes. Il est alors
plus logique de considérer le processus complet de production du logiciel comme un ensemble,

Page 13
l'ensemble de toutes ces tâches. Les tâches peuvent être regroupées, selon leurs finalités, en
activités, ces dernières étant d'un plus haut niveau de complexité de réalisation.
De ce fait, le projet logiciel doit être découpé (par le chef de projet) afin de répartir, dans
le temps, les activités et tâches de production et les ressources nécessaires. Pour Soraya
Sakhraoui (PhD) 2 , découper un projet consiste à identifier des sous-ensembles quasi-
autonomes, ayant les caractéristiques suivantes :
• Chaque sous-ensemble donne lieu à un résultat bien défini ;
• La charge propre à chaque membre de l'équipe peut être évaluée ;
• Les contraintes d'enchaînement entre les sous-ensembles sont repérables : certains
sous-ensembles peuvent être réalisés parallèlement, d'autres sont liés par des
contraintes d'antériorité ;
• Le découpage est fait à des maillages différents, un sous-ensemble étant souvent à son
tour décomposé.
On utilise deux critères de découpage pour découper un projet : l’un est temporel, l’autre
est structurel. Le critère structurel permet d’organiser le travail en se basant sur la structure
du produit final : la décomposition fait apparaître les différents modules qu’il faut obtenir. Le
critère temporel est utilisé dans la plupart des projets pour répartir le travail dans le temps.
b) Processus, activité et tâche
b.1) Définitions
Au sens général, un processus d'ingénierie ou processus de production industrielle est une
suite d'activités interdépendantes et coordonnées visant à transformer des éléments en
entrée en résultats ; ces activités consomment de l'énergie et des ressources et
observent des contraintes bien définies.
En génie logiciel, on distingue plusieurs processus, entre autres le processus de
développement logiciel et le processus de génie logiciel. On appelle processus de développement
logiciel le processus complet par lequel les besoins des utilisateurs sont transformés en produit
logiciel final livrable aux commanditaires. Ce processus consiste à capturer les besoins des
utilisateurs, traduire ces besoins en exigences logicielles (fonctionnalités et contraintes de
fonctionnement du logiciel), transformer ces exigences en conception, implémenter la
conception en code source, tester le code, compiler le code en produit logiciel final et, parfois,
aller jusqu'à déployer le produit logiciel pour son exploitation.
Le processus de développement logiciel est subdivisé en plusieurs processus spécifiques
spécialisés appelés processus d'ingénierie du logiciel. Un processus de génie logiciel, appelé
également processus logiciel ( à ne pas confondre avec un programme exécution en système
d'exploitation), est une suite d'activités techniques, collaboratives ou administratives, appelées
parfois sous-processus si elles sont complexes, permettant de transformer des produits
logiciels en entrée en produits logiciels en sortie. Un processus de génie logiciel est donc un
ensemble de travaux de production, de collaboration ou de gestion réalisés par les ingénieurs
du logiciel, les gestionnaires de projets et bien d'autres acteurs lors de la création d'un produit
logiciel. Ces processus incluent, par exemple : l'ingénierie des exigences, la conception
logicielle, la construction logicielle, le test logiciel, la gestion de la configuration, la gestion de
l'assurance qualité, et bien d'autres encore.
Un processus logiciel est subdivisé en activités. Une activité de génie logiciel, appelée plus
simplement activité, est un ensemble de travaux visant à atteindre un objectif donné ou à
fournir un résultat déterminé dans un processus de génie logiciel. Par exemple, le processus

2
Voir les détails sur la page http://cte.univ-setif.dz/coursenligne/SiteGLA-Sakhraoui/Chapitre1.html.
Page 14
d'ingénierie des exigences inclut comme activités la capture des exigences, l'analyse des
exigences, la spécification des exigences, etc.
Une activité est subdivisée en tâches. Une tâche est tout travail élémentaire donné à
accomplir à un individu ou une petite équipe d'individus et visant à atteindre un objectif simple
et précis ou à réaliser un produit logiciel élémentaire et tangible, en suivant une procédure ou
une technique bien définie. Par exemple, dans l'activité de capture des exigences, on peut citer
la tâche d'élaboration d'un modèle de cas d'utilisation par la technique des cas d'utilisation ;
dans l'activité de conception des interfaces utilisateurs, on peut citer la tâche d'élaboration
du modèle de travail d'un utilisateur par la technique de l'analyse des tâches.
La figure ci-dessous résume graphiquement les relations entre le processus, l'activité et la
tâche.

Figure 2: Découpage d'un processus de génie logiciel en

activités et tâches.

b.2) Flux des activités d'un processus

Toutes les activités et tâches susmentionnées de production, exploitation et évolution de

produits logiciels ne se réalisent pas toujours de manière séquentielle. D’un projet à un autre,
on peut les coordonner les activités d'un processus de plusieurs manières telles que certaines
peuvent être exécutées alternativement ou en parallèle, entrecoupées ou répétées un certain
nombre de fois. D'autre par, on peut entrer dans un processus et ses activités une ou plusieurs
fois durant le projet. On appelle flux des activités d'un processus ou simplement flux d'un
processus, la manière de coordonner ou encore d'enchaîner la réalisation des activités de ce
processus.
Il existe quatre types de base de flux de processus : la séquence, la sélection, l’itération et
le parallélisme. Dans l’enchaînement séquentiel, les activités sont exécutées en séquence
linéaire, les unes après les autres, pour l’ensemble du développement logiciel. Une activité est
itérative si elle peut être répétée autant de fois. Deux activités sont alternatives si l’une est
exécutée en exclusion de l’autre. Deux activités sont parallèles si elles peuvent être exécutées
concurremment.
b.3) Catégorisation des processus
On regroupe les processus par catégories selon la finalité des activités réalisées. On
distingue : les processus de base, les processus de support, les processus de gestion, les
processus transversaux ou processus inter-projets.
• Les processus de base incluent les processus de développement, d'exploitation ou de
maintenance de produits logiciels.
• Les processus supports consistent en des processus réalisés par intermittence et de
manière continue durant toute la période allant de la naissance à la mise hors service
Page 15
 d'un produit logiciel. Quelques exemples : la gestion de configuration, la gestion de
l'assurance qualité, la vérification et validation.
• Les processus organisationnels consistent en des processus d'appui à l'ingénierie du
logiciel en vue de satisfaire des besoins organisationnels ; ils incluent : la formation,
l'assistance technique, la gestion de l'infrastructure d'un projet logiciel, etc.
• Les processus inter-projets sont des processus traitant des aspects relatifs à plusieurs
projets au sein d'une organisation.
• Les processus de gestion de projets logiciels incluent les processus de planification et
estimation des coûts et délais, gestion de ressources, gestion de risques, gestion des
acteurs de projets ainsi que la coordination des processus sus-énumérés.
b.4) Processus normatif vs processus descriptif
Un processus de génie logiciel peut être normatif ou descriptif. On appelle processus
normatif (prescriptive process en anglais) la prescription des activités telles qu’on souhaite
qu’elles se réalisent. Une telle prescription vient avant le début même du développement. En
général, on tire cette description d’un modèle de processus établi (voir la notion de modèle de
processus plu bas). On appelle processus descriptif la description des activités qui ont été
réalisées lors de la production d’un logiciel donné. Cette description survient après que le logiciel
ait été produit, par exemple pour permettre d’analyser l’efficacité du processus utilisé ou pour
comprendre les tâches réalisées par l’équipe de développement.
b.5) Modèle de processus

Un modèle de processus est un processus de référence décrivant des activités-types et

tâches-types, susceptibles d’être exécutées de manière reproductible dans une classe de
projets. Un processus concret donné peut être basé sur un modèle de processus.
Roger S. Pressman précise que toutes les activités, actions et tâches de production logicielle
résident à l’intérieur du modèle de processus. Le modèle de processus définit les relations entre
ces activités, actions et tâches et avec lui-même.
Un modèle de processus a pour but de fournir un ensemble de processus-types afin de
normaliser les activités de développement logiciel et ainsi de faciliter la communication entre
toutes les parties prenantes (clients, fournisseurs, etc.).
c) Cycles d'un projet logiciel
c.1) Cycle de développement d'un logiciel
Le cycle de développement d'un logiciel est la période de temps allant de la demande d'un
logiciel jusqu'à sa livraison. Cette période couvre l'ensemble des processus permettant de
spécifier et transformer les exigences logicielles en un produit logiciel livrable. Ces processus
sont : le processus d'ingénierie des exigences, le processus de conception du logiciel, le
processus d'implémentation du logiciel, le processus de test du logiciel et,
parfois, le processus de déploiement du logiciel.

Figure 3: Les processus du cycle de

développement d'un logiciel.

Page 16
 c.2) Cycle de vie d'un logiciel

Le cycle de vie d'un logiciel est la période de temps qui couvrent toutes les activités de
développement, exploitation, maintenance et évolution du logiciel ; elle commence quand naît
l'idée de créer le logiciel (naissance du logiciel) et s'arrête quand le logiciel n'est plus en service
(mort du logiciel). Le cycle de vie d'un logiciel inclut le cycle de développement auxquels
s'ajoutent d'autres processus permettant d'assurer la gestion de la configuration, l'assurance
qualité, le déploiement, la maintenance, le support aux utilisateurs, l'évolution du logiciel, etc.
Le cycle de vie d'un logiciel peut inclure plusieurs cycles de développement permettant
d'améliorer et de faire évoluer le logiciel. La maintenance consiste à modifier la conception et
l'implémentation initiales du logiciel afin de corriger des défauts rencontrés dans l'utilisation
(maintenance corrective), d'améliorer l'efficacité et la maintenabilité (maintenance perfective)
ou d'adapter le logiciel à un nouvel environnement ou un environnement modifié (maintenance
adaptative). Les correctifs (patchs en anglais) sont installés chez les utilisateurs sous formes
de mises à jour ou de packs et permettront de corriger les défauts de fonctionnement,
améliorer la sécurité, améliorer les performances globales et bien d'autres attributs de la
qualité du logiciel. L'évolution consiste à intégrer de nouvelles fonctionnalités au logiciel. Elle
se traduit par le développement de nouvelles versions du logiciel.
La notion de cycle (de vie ou de développement) d'un logiciel ajoute une dimension temporelle
à la réalisation des processus de génie logiciel. En effet, les processus individuels tels que
l'ingénierie des exigences, la conception logicielle, la construction logicielle, n'ont pas de
relation temporelle déterminant comment les combiner. C'est le cycle qui détermine le flux des
processus (sont-ils séquentiels, alternatifs, parallèles, entremêlés,
itérés ?) et leur étalement dans le temps.

Par rapport à la dimension temporelle du cycle vie du logiciel, le projet est souvent découpé en phases. Une
phase est une période de temps pendant laquelle se réalisent un certain nombre d'activités et
tâches visant à élaborer un produit logiciel majeur. Le cycle de vie est donc l'ensemble ordonné
de phases.
À chaque phase est attaché un résultat à produire appelé livrable.
Il faut dire qu’aujourd’hui, les logiciels de l’industrie ne meurent pas facilement ; les éditeurs
continuent à les faire évoluer jusqu’à l’infini. Schach et Seriai (2015) écrivent, de ce fait, que
la maintenance et l'évolution sont considérées comme les processus les plus préoccupants du
développement logiciel de nos jours. En effet, par rapport au cycle de vie global d'un logiciel, la
conception et la construction initiales ne sont qu'une infime partie de travaux comparativement

Page 17
aux travaux que demanderont la maintenance et l'évolution du logiciel. Il faut alors, au départ,
concevoir et implémenter le logiciel de manière à faciliter des modifications futures.
c.3) Intérêt du découpage du cycle de vie d'un projet logiciel en phases et processus
Julius-Marcelin Nkenlikack et Walt Scacchi expliquent qu’il y a intérêt à découper un long
cycle de vie d'un projet logiciel en éléments simples et gérables. En effet, le découpage du cycle
de vie d’un projet logiciel en phases, processus, activités et tâches plus simples permet de
définir des jalons intermédiaires permettant deux choses :
1. la validation du développement logiciel, c’est-à-dire la conformité du logiciel avec les
besoins exprimés, et
2. la vérification du processus de développement, c’est-à-dire l’adéquation des méthodes
mises en œuvre.
L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant plus élevé
qu’elles sont détectées tardivement dans le cycle de vie. Le découpage du cycle de vie permet
de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa
réalisation et les coûts associés.
d.4) Modèle de cycle de vie
Un modèle de cycle de vie est la description d'un cycle de vie type incluant des phases-types
et processustypes et qui est reproductible entre plusieurs projets.
II.1.3 La méthode de génie logiciel
Une méthode de génie logiciel est un ensemble de canons (principes, règles formelles ou
informelles, voies à suivre) destinés à guider le développement, l'exploitation, la maintenance
et l'évolution de produits logiciels. Elle définit des principes et règles, une démarche
systématique matérialisée par un modèle de cycle de vie avec phases, processus et activités
associés, et des notations permettant de structurer, planifier, réaliser et contrôler le
développement, l'exploitation, la maintenance et l'évolution d'un produit logiciel.
La méthode de génie logiciel est donc le cadre intégrateur des outils et autres éléments
méthodologiques de l'ingénierie du logiciel.
Il existe plusieurs méthodes en génie logiciel. Parmi les méthodes traditionnelles les plus
connues, on peut citer la méthode SSADM (Structured Systems Analysis and Design Method).
Les méthodes les plus en vogue aujourd'hui sont : le Processus unifié de développement
logiciel (UP) et méthodes dérivées (RUP, 2TUP, …), les méthodes agiles (RUP, 2TUP, XP, Scrum,
Open UP, …).
II.2 Quelques modèles de cycle de vie

II.2.1 Le développement exploratoire (Code-and-Fix) et le développement en tunnel

Le modèle Code-and-Fix (Codage et correction) est un modèle informel caractérisé par un
développement logiciel sans spécifications ni conception. Le programmeur commence le
processus de développement directement par la production du code source. Le code sera,
ensuite, testé et débogué jusqu’à ce qu’il soit satisfaisant.

Page 18
 Figure 5: Le modèle exploratoire ou modèle Code-and-Fix (Schach
2011).

Le modèle de « développement en tunnel » est aussi une manière imagée de désigner

l’absence de modèle de développement. Dans les projets qui suivent la démarche en tunnel, il
est globalement impossible de savoir ce qui se passe. Le développement est en cours, les gens
travaillent – souvent beaucoup – mais aucune information fiable n’est disponible, ni sur l’état
d’avancement du logiciel, ni sur la qualité des éléments déjà développés. Ce genre de modèle de
développement n’est adapté que pour les petits projets, avec un nombre très limité de
participants.

II.2.2 Le modèle séquentiel linéaire ou modèle en cascade

Les idées séminales du modèle de cycle de vie en cascade à une présentation faite par
Herbert D. Benington à un symposium sur les méthodes avancées de programmation tenu en
1956.
Le modèle de cycle de vie en cascade tel que nous le connaissons aujourd'hui est présenté
dans un article de 1970 rédigé par Winston W. Royce. Néanmoins, l'appellation « en cascade
(waterfall en anglais) » figure pour la première fois dans un article de 1976 rédigé par Thomas
E. Bell et T. A. Thayer.

Page 19
 Le modèle a été largement employé depuis, pour la description générale des activités liées
au développement de logiciels. Par exemple, le département américain de la défense (DoD) l'a
érigé en standard, le standard DODSTD-2167A.
Dans ce modèle le principe est très simple : le cycle de vie est découpé en phases ou étapes
successives. À chaque phase correspond un processus de génie logiciel tel qu'on ne distingue
pas pas deux concepts. Chaque phase se termine à une date précise par la production de certains
documents ou produits logiciels. Les résultats sont définis sur la base des interactions entre
phases, ils sont soumis à une revue approfondie et on ne passe à la phase suivante que s’ils sont
jugés satisfaisants. Le développement de logiciels est une séquence de phases qui s’enchaînent
dans un déroulement linéaire, depuis l’analyse des besoins jusqu’à la livraison du produit au client.
Le standard DOD-STD-2167A définit un modèle de cycle de vie à six phases : la conception
préliminaire, la conception détaillée, le codage et test unitaire, l'intégration et le test.
Le modèle initial présenté par Royce inclut également six phases :
1. La phase des exigences du logiciel et du système qui produit le document des exigences
du produit ;
2. La phase d'analyse qui produit des modèles, des schémas et des descriptions des règles
du domaine ;
3. La phase de conception qui produit l'architecture du logiciel ;
4. La phase de codage : il s'agit du développement, du débogage et de l'intégration du
logiciel ; 5. La phase de test : c'est la découverte systématique des défauts ;
6. La phase des opérations : l'installation, la migration, le support et la maintenance du logiciel livré.

Figure 7: Le modèle de cycle de vie en cascade initial (Royce, 1970).

Par rapport au modèle en tunnel, le modèle en cascade est une étape importante dans la
formalisation du processus de la production du logiciel et présente l’énorme avantage de fournir
des points de mesure concrets, sous la forme de documents ; il augmente ainsi la visibilité sur
l’état d’avancement du système en cours de développement.
Néanmoins, le modèle en cascade repose sur une séquence de phases bien cernées. Le projet
produit des documents évalués lors de revues censées valider le passage d’une phase à une autre.
Toutefois, la preuve effective du bon (ou mauvais) fonctionnement du système n’est réalisée
que tardivement dans le cycle – lors de la phase d’intégration – lorsqu’il est possible d’évaluer
concrètement le logiciel. Avant cette phase d’intégration, seuls des documents ont été produits.
Or, ce n’est pas parce qu’un document passe avec succès une étape de validation sur papier que

Page 20
le logiciel qu’il décrit donnera forcément des résultats convaincants. C’est l’inconvénient majeur
de ce modèle de cycle de vie.
II.2.3 Les améliorations du modèle de cycle de vie en cascade
a) Le modèle de cycle de vie en cascade avec retours
Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été
rajoutée ultérieurement sur la base qu’une étape ne remet en cause que l’étape précédente, ce
qui est dans la pratique s’avère insuffisant.
Fig

Figure 8: Le modèle de cycle de vie en cascade avec retours.

b) Le modèle de cycle de vie en V

Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en
cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d’anomalie, de
limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer
de l’information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d’améliorer
le logiciel.
De plus le modèle en V met en évidence la nécessité d’anticiper et de préparer dans les
étapes descendantes les « attendus » des futures étapes montantes : ainsi les attendus des
tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont
définis lors de la conception, etc.

Page 21
 Figure 9: Le modèle de cycle

de vie en V. c) Le modèle en spirale

Le modèle en spirale (Spiral model) a été défini par Barry Boehm en 1988 dans son article
"A Spiral Model of Software Development and Enhancement".
Le modèle en spirale est un modèle de cycle de développement logiciel qui reprend les
différentes étapes du cycle en V. Par l’implémentation de versions successives, le cycle
recommence en proposant un produit de plus en plus complet et dur. Le cycle en spirale met
cependant plus l’accent sur la gestion des risques que le cycle en V.

Figure 10: Le modèle de cycle de vie en spirale (Boehm, 1988).

On distingue quatre phases dans le déroulement du cycle en spirale :
Page 22
 1. Détermination des objectifs, des
alternatives et des contraintes ;
2. Analyse des risques, évaluation des
alternatives ; 3. Développement et vérification
de la solution retenue ;
4. Revue des résultats et vérification du cycle suivant.
II.2.3 Le modèle itératif et incrémental
Le cycle de vie itératif repose sur une idée très simple : lorsqu’un système est trop complexe
pour être compris, conçu ou réalisé du premier coup, voire les trois à la fois, il vaut mieux le
réaliser en plusieurs fois par évolutions. Dans la nature, les systèmes complexes qui
fonctionnent sont toujours des évolutions de systèmes plus simples.

Figure 11: Le modèle de cycle de vie itératif et incrémental.

II.3 Quelques modèles de processus

II.3.1 La norme ISO/CEI 12207

La norme ISO/CEI 12207 « Ingénierie des systèmes et du logiciel – Processus du cycle de
vie du logiciel » est une norme internationale qui décrit un modèle de processus du cycle de vie
du logiciel. Elle s'applique à des acquisitions de logiciels, à des prestations logicielles ou à des
développements de logiciels spécifiques ainsi qu'aux

Figure 12: Les processus directeurs de la norme ISO/IEC 29110 pour les TPO.
activités d'exploitation et de maintenance. La norme est élaborée par le comité technique Joint Technical
Committee 1 de l'ISO/CEI 3 . Sa version actuelle date de 2008 (ISO/CEI 12207:2008) et
remplace la version initiale de 2005.
Chaque processus-type est défini en termes des caractéristiques distinctives. Ces
caractéristiques sont : la désignation ou intitulé du processus, le but de l'exécution du
processus, les résultats observables (attendus) à l'issue du processus, les activités faisant
partie du processus et les tâches constitutives de chaque activité. La norme distingue 3 types

3
L'ISO, Organisation internationale de normalisation, et la CEI, Commission électrotechnique internationale, forment un
système spécialisé pour la normalisation mondiale.
Page 23
de tâches : les tâches obligatoires (ce qui doit être fait) , les tâches recommandées (ce qui
devrait être fait) et les tâches permises (ce qui peut être fait).
II.3.2 La norme ISO/CEI 29110
La norme ISO/CEI 29110 « Ingénierie du logiciel – Profils de cycle de vie pour très petits
organismes (TPO) » est une norme multipartite qui définit une terminologie (parties 29110-1 et
29110-2), un modèle de processus (partie 29110-5) et bien d'autres éléments (parties 29110-3
et 29110-4) pour les très petits organismes ( TPO) d'ingénierie du logiciel. Un TPO est, ici,
entendu comme une entité d'ingénierie du logiciel regroupant 25 personnes ou moins. Cette
norme a été particulièrement élaborée en vue de pallier l'inadéquation des normes
internationales (ISO/CEI 12207 entre autres) aux besoins des TPO. Cette norme permet donc
d'adapter ces normes à l'échelle des TPO.
La norme propose deux processus interdépendants qui sont : le processus de gestion de
projet (Project Management, PM, en anglais) et le processus de mise en œuvre du logiciel
(Software Implementation, SI). Le processus de gestion de projet ( Project Management [PM])
regroupe les activités de gestion, c'est-à-dire les activités permettant d'assurer la qualité, de
maîtriser les coûts (budget), de maîtriser les délais (durée) et d'assurer d'autres aspects de
la gestion du projet. Le processus de mise en œuvre du logiciel (Software Implementation [SI])
inclut les activités techniques, c'est-à-dire l'analyse, la conception, le développement,
l'intégration et les tests de produits logiciels, nouveaux ou modifiés, selon les exigences
établies.

Le processus de gestion de projet inclut les activités suivantes :

1. Planification du projet : Cette activité vise à documenter les détails de planification
nécessaires à la gestion du projet.
2. Exécution de la planification du projet : Cette activité vise à mettre en œuvre le plan
documenté permettant la réalisation du projet.
3. Évaluation et contrôle du projet : Cette activité vise à évaluer la performance du plan
du projet par rapport aux engagements documentés.
4. Clôture du projet : Cette activité vise à produire la documentation et les produits
conformes aux exigences stipulées au contrat.

À l'issue de ce processus, on obtient les produits suivants :

1. Plan du projet : ;
2. Demande de changement ;
3. Enregistrement de réception ;
4. Enregistrement de réunion ;
5. Registre des corrections ;
6. Enregistrement d'avancement ;
7. Résultats de vérification.

Le processus de mise en œuvre du logiciel inclut les activités suivantes :

1. Initiation de la mise en œuvre du logiciel : Cette activité consiste à faire en sorte que
les membres de l'équipe de travail s'engagent à réaliser le plan de projet tel qu'élaboré
au niveau de l'activité de planification du projet du processus de gestion de projet.
2. Analyse des exigences du logiciel : Cette activité consiste à analyser les exigences
établies en accord avec le client et à établir les exigences du projet validées.

Page 24
 3. Architecture et conception détaillée du logiciel : Cette activité consiste à transformer
les exigences logicielles à l'architecture du logiciel à la conception détaillée du logiciel.
4. Construction du logiciel : Cette activité vise à développer le code et les données du
logiciel à partir de la conception du logiciel.
5. Intégration et tests du logiciel : Cette activité vise à faire en sorte que les composants
logiciels intégrés répondent aux exigences logicielles.
6. Livraison du produit : Cette activité vise à fournir le produit logiciel intégré au client.

À l'issue de ce processus, on obtient les produits suivants :

1. Spécification des exigences ;
2. Documentation de l'utilisateur du logiciel ;
3. Conception du logiciel ;
4. Enregistrement de la traçabilité ;
5. Cas et procédures de test ;
6. Composants logiciels ;
7. Logiciel ;
8. Guide d'opération du logiciel ;
9. Documentation de la maintenance ;
10. Rapport de test ;
11. Résultats de la vérification ;
12. Résultats de la validation.

Les rôles intervenants dans les deux processus sont : le client, l'analyste, le concepteur, le
programmeur, le chef technique et le chef de projet. Tous ces rôles, exceptés le client et le
chef de projet, constituent ce qu'on appelle l'équipe de travail.
II.3.3 L'agilité dans le processus d'ingénierie du logiciel
Même si les normes précédemment présentées décrivent exhaustivement l'ensemble des
processus-types de l'ingénierie du logiciel, il n'y a aucune obligation à tous les implémenter dans
ses projets. L'organisation ou l'équipe de développer doivent sélectionner les processus à
implémenter en fonction de leurs besoins spécifiques et non recherche l'exhaustivité. Roger S.
Pressman fait remarquer, en effet, que le processus d’ingénierie du logiciel n’est pas à
considérer comme une prescription rigide que l’équipe doit suivre de façon dogmatique ; il
devrait être agile et adaptable au produit, au projet, à l’équipe et à l’organisation.
L’adaptation d’un processus peut se situer à plusieurs niveaux, notamment :
• les activités et tâches retenues ainsi que leurs interdépendances ;
• le degré de découpage des activités en tâches ;
• les produits logiciels à développer ;
• le degré de détails ou de rigueur dans la description du processus ;
• le degré d’autonomie de l’équipe ;
• etc.

II.4 Le processus unifié de développement logiciel (UP)

Le processus unifié de développement logiciel (UP pour Unified process en anglais) est une
méthode de développement logiciel piloté par les cas d'utilisation, itératif et incrémental,
centré sur l’architecture et orienté vers la diminution des risques. C’est un patron de processus
pouvant être adapté à une large classe de systèmes logiciels, à différents domaines

Page 25
d’application, à différents types d’entreprises, à différents niveaux de compétences et à
différentes tailles de l’entreprise.
II.4.1 Les principes fondamentaux d'UP
• UP est piloté par les cas d'utilisation : Le but principal d’un système informatique est
de satisfaire les besoins du client. Le processus de développement sera donc axé sur
l’utilisateur. Les cas d’utilisation permettent d’illustrer ces besoins. Ils détectent puis
décrivent les besoins fonctionnels (du point de vue de l’utilisateur), et leur ensemble
constitue le modèle de cas d’utilisation qui dicte les fonctionnalités complètes du
système. Toutes les activités, de la spécification de ce qui doit être fait jusqu’à la
maintenance, sont guidées par les cas d’utilisation.
• UP est itératif et incrémental : L’itération est un concept existant en programmation
informatique. L’itération correspond à une répétition d’une séquence d’instructions ou
d’une partie de programme un nombre de fois fixé à l’avance ou tant qu’une condition
définie n’est pas remplie, dans le but de reprendre un traitement sur des données
différentes. De manière générale, elle qualifie donc un traitement ou une procédure qui
exécute un groupe d’opérations de façon répétitive jusqu’à ce qu’une condition bien
définie soit remplie.
Figure 13:

L'itération dans UP.

En appliquant la notion d’itération au processus de développement logiciel, l’ensemble du travail est
divisé en petites itérations, définies à partir du degré d’importance des cas d’utilisation
et de l’étude des risques. Le développement procède par des itérations qui conduisent à
des livraisons incrémentales du système. Les itérations peuvent être conduites en
parallèle. Une itération prend en compte un certain nombre de cas d’utilisation et traite
en priorité les risques majeurs.
• UP est centré sur l'architecture : Dès le départ, le projet place la détermination des
traits de l’architecture en ligne de mire. L’architecture est conçue pour satisfaire les
besoins exprimés dans les cas d’utilisation, mais aussi pour prendre en compte les
évolutions et les contraintes de réalisation. L’architecture doit être simple et se
comprendre de manière intuitive ; elle est conçue avec et pour la réutilisation.
II.4.2 Les phases et processus d'UP
UP gère le processus de développement par deux axes, l’axe horizontal ou axe des phases et
l’axe vertical ou axe des processus ou encore axe des activités.
• L'axe des phases : L’axe horizontal représente le temps et montre le déroulement du
cycle de vie du processus ; cette dimension rend compte de l’aspect dynamique du
processus qui s’exprime en terme de cycles, de phases, d’itérations et de jalons.
• L'axe des processus ou axe des activités : L’axe vertical représente les principaux
enchaînements d’activités, qui regroupent les activités selon leur nature. Cette

Page 26
 dimension rend compte de l’aspect statique du processus qui s’exprime en termes de
composants, de processus, d’activités, d’enchaînements, d’artefacts et de travailleurs.

II.5 Les méthodes agiles

II.5.1 Un aperçu général sur le courant agile

Les entreprises et organisations travaillent actuellement dans un environnement voué à des
changements rapides. Elles doivent pouvoir optimiser leurs activités, répondre aux nouvelles
opportunités et aux nouveaux marchés, gérer la concurrence, offrir de nouveaux produits et
services, etc. En général, même si la RDC est très en retard sur le plan technologique, les
activités des entreprises exploitent énormément les technologies de l’information et de la
communication ; leurs opérations reposent donc sur ces technologies. C’est le cas de la Générale
des Carrières et des Mines (GCM, Gécamines), la Tenke Fungurume Mining (TFM), la Kolwezi
Copper Corporation (KCC), la Boss Mining (BM), et bien d’autres.
Les changements rapides sur le plan économique entraînent des changements rapides sur le
plan technologique. En effet, les technologies doivent s’aligner sur les besoins des utilisateurs
comme l’expliquent plusieurs théories dans le domaine des systèmes d’information. De ce fait,
développer très rapidement des produits technologiques tels que les logiciels est vital et
stratégique.
Même dans le domaine des petites et moyennes entreprises, la rapidité est plus qu’exigée.
Quand un petit magasin ou un hôtel vous demande une application logicielle, l’on s’attend à ce
que vous répondiez déjà dans les 10 jours qui suivent ; rares sont les gérants et propriétaires
qui patienteraient plus d’un mois pour voir le résultat. L’analphabétisme technologique est un
autre facteur expliquant les pressions que reçoivent les développeurs de notre milieu : pour la
plupart de nos clients, développer un logiciel est tout simple, tout est déjà dans l’ordinateur !
Pour toutes ces raisons, il est pratiquement impossible d’identifier tous les besoins des
utilisateurs et de formuler des exigences dans un bref délai. Les exigences initiales sont
appelées à changer et les utilisateurs auraient du mal à comprendre et évaluer le système tant
qu’il ne l’ont pas encore vu fonctionner.
Dans le cas de systèmes logiciels critiques, où analyser et spécifier complètement les
exigences est essentiel, une approche pilotée par un plan est appropriée. Cependant, les
processus logiciels qui attendent à ce que la spécification complète des exigences soit finie
avant la conception, l’implémentation et le test du système ne sont donc pas adaptés à un
développement logiciel rapide. Au fur et à mesure que les exigences changent ou que des
problèmes sont identifiés en rapport avec les exigences déjà établies, la conception ou
l’implémentation du système est à refaire et à tester à nouveau. En conséquence, le processus
doit être rallongé et le produit logiciel final livré avec beaucoup de retard.
Le besoin d’approches et processus capable de développer très rapidement des exigences a
été identifié par plusieurs chercheurs, praticiens et auteurs. IBM a introduit le développement
incrémental dans les années 1980, des langages dits de quatrième génération ont été proposés.
Mais, c’est surtout l’introduction des approches agiles qui a décisivement changé la donne.
Les approches de développement rapide sont conçues pour produire du logiciel dans des
brefs délais. Le logiciel est développé comme une série d’incréments plutôt qu’un tout. Chaque
incrément ajoute de nouvelles fonctionnalités aux précédentes.
L’expression « méthodes agiles » regroupe un ensemble de méthodes d’ingénierie logicielle
ayant trois caractéristiques essentielles, à savoir :

Page 27
 • Les méthodes agiles sont des méthodes de développement incrémentales dans lesquelles
les incréments logiciels sont petits et les nouvelles éditions (releases) du logiciel sont
développés et livrés au client toutes les deux ou trois semaines.
• Ces méthodes impliquent la participation des clients dans le processus de développement
de manière à obtenir un feedback rapide concernant les exigences changeantes.
• Ces méthodes minimisent la documentation en privilégiant des communications
informelles plutôt que des réunions formelles qui génèrent de gros documents écrits.
II.5.2 Le Manifeste agile
La philosophie derrière les méthodes agiles est reflétée dans le manifeste Agile, Manifeste
pour le développement Agile de logiciels de son intitulé complet, qui avait été signé par plusieurs
grands noms du génie logiciel incluant Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland, Dave Thomas à l’origine de ces méthodes. Le manifeste Agile signé en 2001 stipule
ce qui suit4 :

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les
autres à le faire. Ces expériences nous ont amenés à valoriser :

• Les individus et leurs interactions plus que les processus et les outils ;
• Des logiciels opérationnels plus qu’une documentation exhaustive ;

• La collaboration avec les clients plus que la négociation contractuelle ;

• L’adaptation au changement plus que le suivi d’un plan.

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Douze principes pratiques sous-jacents au manifeste ont été énoncés en ces termes :

Nous suivons ces principes :

• Notre plus haute priorité est de satisfaire le client en livrant rapidement et

régulièrement des fonctionnalités à grande valeur ajoutée.

• Accueillez positivement les changements de besoins, même tard dans le projet. Les
processus Agiles exploitent le changement pour donner un avantage compétitif au
client.

• Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines

à quelques mois et une préférence pour les plus courts.

• Les utilisateurs ou leurs représentants et les développeurs doivent travailler

ensemble quotidiennement tout au long du projet.

4
Le site web http://www.agilemanifesto.org est consacré au manifeste Agile.
Page 28
 • Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement
dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

• La méthode la plus simple et la plus efficace pour transmettre de l’information à

l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

• Un logiciel opérationnel est la principale mesure d’avancement.

• Les processus Agiles encouragent un rythme de développement soutenable.

Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être
capables de maintenir indéfiniment un rythme constant.

• Une attention continue à l’excellence technique et à une bonne conception renforce

l’Agilité.

• La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est

essentielle.

• Les meilleures architectures, spécifications et conceptions émergent d’équipes

auto-organisées.

• À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis
règle et modifie son comportement en conséquence.

Les méthodes agiles les plus populaires incluent Extreme Programming, XP (Beck, 1999 ; Beck,
2000),
Scrum (Schwaber et Beedle, 2001 ; Schwaber, 2004 ; Cohn, 2009), Adaptative Software
Development (Highsmith, 2000) , DSDM (Stapleton, 1997 ; Stapleton, 2003), Feature Driven
Development (Palmer et Felsing, 2002). Le succès de ces méthodes a conduit a quelques
intégrations avec des méthodes traditionelles plus centrées sur la modélisation, de là sont nés
le concept de modélisation agile (Ambler et Jeffries, 2002) et quelques instantiations agiles du
Processus unifié de développement logiciel (Larman, 2002).
Bien que ces méthodes agiles sont toutes centrées autour de la notion de développement
incrémental, bien qu’elles adhèrent au manifeste agile et aux principes agiles, elles proposent
différents processus pour y parvenir.
De l’expérience de Ian Sommerville, les méthodes agiles ont eu un succès et sont appropriées
pour certains types de projets :
• Un projet où une compagnie d’ingénierie du logiciel développe un petit ou moyen
produit pour le marché ;
• Un projet de développement d’un système spécifique au sein d’une organisation, où
il y a un engagement clair du client à être impliqué dans le processus de
développement et où il n’y a pas de règles extérieures ou des dispositions de
régulations extérieures qui affectent le logiciel.
Le succès des méthodes agiles a conduit à des tentatives de généralisation de ces méthodes
à d’autres types de projets. Toutefois, leur focalisation sur des projets de petite taille et des
équipes étroitement intégrées ainsi que l’absence de documentation (spécification, conception,
...) essentielle au développement de systèmes complexes ou critiques constituent la source

Page 29
principale des problèmes rencontrées dans ces tentatives. De même, l’application pratique de
certains principes issus du Manifeste Agile n’est pas évidente dans tous les cas. Par exemple, la
disponibilité et l’implication totale du client dans le processus de développement, les
compétences communicationnelles ou techniques des membres de l’équipe, la hiérarchisation des
changements, etc. peuvent être problématiques.
En conséquence, les méthodes agiles doivent pouvoir reposer sur des contrats où le client
paye pour le temps requis pour développer le système plutôt que le développement d’un ensemble
spécifique d’exigences. En cas de problème, il peut être difficile de désigner qui blâmer et à qui
faire payer les délais et ressources supplémentaires.
II.5.3 Un exemple de la méthode agile « Extreme Programming »
a) Présentation générale
Extreme Programming, XP en sigle, est une méthode agile de développement et gestion de
projets logiciels qui se focalise particulièrement sur les aspects de réalisation d'un logiciel et
qui pousse à l'extrême les principes et pratiques simples (d'où son nom). La méthode a été
élaborée par Kent Beck, Ward Cunningham et Ron Jeffries vers la fin des années 1990.
b) Les valeurs et les principes de XP
La méthode XP repose sur 5 valeurs : la communication, la simplicité, le feedback, le courage
et le respect.
Ces cinq valeurs se déclinent en treize pratiques qui se renforcent mutuellement : le client
sur site, le jeu du planning (planning game, planning poker), l'intégration continue, les petites
livraisons, un rythme de travail soutenable, les tests de recette (tests fonctionnels), les tests
unitaires, une conception simple, le refactoring ( remaniement de code source), l'appropriation
collective du code source, le respect de conventions de nommage, la programmation en binôme.
c) Le modèle de cycle de vie de XP
L'extreme programming repose sur des cycles rapides de développement (des itérations de
quelques semaines) dont les étapes sont les suivantes :
• une phase d'exploration détermine les scénarios d'utilisation (user stories) qui seront
fournis pendant cette itération ;
• l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ; •
chaque développeur s'attribue des tâches et les réalise avec un binôme ;
• lorsque tous les tests fonctionnels passent, le produit est livré.
Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le
cycle de la première livraison se caractérise par sa durée et le volume important de
fonctionnalités embarquées. Après la première mise en production, les itérations peuvent
devenir plus courtes (une semaine par exemple).

Figure 14: Le modèle de cycle de vie de XP (Wikipédia, 2014).

Page 30
 Chapitre III.
L'INGÉNIERIE DES EXIGENCES LOGICIELLES

Ce chapitre poursuit les objectifs spécifiques suivants :

1. Présenter les concepts de l'ingénierie des exigences logicielles.
2. Donner un aperçu exhaustif des activités du processus d'ingénierie des exigences ainsi
que les produits logiciels correspondants.
3. Présenter les techniques les plus courantes d'ingénierie des exigences et les appliquer,
un accent particulier étant mis sur les techniques agiles.

À l'issue du chapitre, l'étudiant devrait être en mesure de :

1. Définir et comprendre les concepts de l'ingénierie des exigences logicielles.
2. Lister et décrire les activités de l'ingénierie des exigences ainsi que les produits
logiciels associés.
3. Mettre en œuvre les techniques les plus courantes d'ingénierie des exigences sur des
problèmes fictifs ou concrets de capture, d'analyse, de spécification, de modélisation
ou de validation des exigences.
III.1 Définitions et notions
Lorsqu'une organisation appelle commandite une application logicielle, il s'agit généralement
de satisfaire un ou plusieurs objectifs propres à cette organisation. On peut citer, à titre
d'illustration : l'automatisation d'une partie des tâches d'un poste de travail, l'optimisation –
c'est-à-dire l'amélioration de l'exécution – d'un processus de l'organisation, le contrôle d'une
machine de production, etc.
Les analystes et ingénieurs logiciels ne peuvent, d'emblée, identifier les fonctions et
caractéristiques pertinentes qu'aura le logiciel à produire. En effet, dans la pratique, les tâches
et fonctions organisationnelles à automatiser peuvent être naturellement complexes à
appréhender. D'autre part, la formulation des besoins d'informatisation peut impliquer
plusieurs sources, notamment les clients, les utilisateurs, les experts du domaine d’application,
les règles de gestion, les règles d’organisation, l’environnement dans lequel sera implanté le
logiciel, l'administration étatique, etc.
Il appartient à l'organisation cliente et à ses employés et partenaires de formuler les
objectifs qu'ils visent à atteindre en commanditant le logiciel, mais aussi d'exprimer leurs
besoins par rapport à ce logiciel. En effet, plusieurs théories de l'acceptation et l'utilisation
des TIC indiquent que ces dernières technologies, les produits logiciels entre autres, ne peuvent
rencontrer le succès escompté que si elles s'alignent sur les objectifs et besoins réels des
utilisateurs. De là à justifier la nécessité, pour le génie logiciel, de procéder à une étude
systématique des besoins des clients, partenaires et utilisateurs d'un logiciel avant sa
conception et sa réalisation.
L'on s'accorde donc à considérer que tout projet de production d'un logiciel commence par
l'étude systématique des besoins, ce que nous appelons l'ingénierie des exigences. Le génie
logiciel définit un certain nombre de concepts, d'activités et de techniques permettant
l'ingénierie des exigences.
III.1.1 Concept et notions d'exigence logicielle
a) Le besoin de logiciel

Page 31
 Au sens général, le dictionnaire Wikitionnaire définit le besoin comme : (1) Une privation de
quelque chose qui est nécessaire, (2) Une nécessité, (3) Ce qui peut être utile ou nécessaire à
un projet, à une entreprise, à un but.
Partant de ces définition, on peut définir un besoin de logiciel comme un manque, une
privation de capacités logicielles, c'est-à-dire de capacités de traitement de l'information
jugées nécessaires à la réalisation des buts, des projets, des tâches d'un individu ou d'une
organisation. On sous-entend que, lorsque ces capacités existent, l'individu ou l'organisation
peut aisément atteindre ses buts, réaliser ses projets, exécuter ses tâches, etc.
L'expression de besoins consiste alors, pour l'individu ou l'organisation, à communiquer ses
idées ou ses sentiments au sujet de ses besoins ou à manifester directement ou indirectement,
volontairement ou involontairement ses besoins.
La production d'un nouveau logiciel part donc toujours de l'existence d'un besoin de logiciel.
Ce besoin peut être exprimé par un individu ou une organisation ou identifié par un éditeur de
logiciels après une analyse de marchés.
b) L'exigence logicielle et les concepts associés
b.1) L'exigence logicielle
Le glossaire de la terminologie de l’ingénierie du logiciel définit une exigence logicielle
comme une propriété que le logiciel doit exhiber, une caractéristique qu’il doit avoir, une
contrainte qu’il doit satisfaire pour pouvoir résoudre le problème pour lequel il a été
commandité.
De manière générale, une exigence logicielle est :
• soit une fonctionnalité exécutée ou un service rendu
par le logiciel, • soit une contrainte imposée au
fonctionnement du logiciel,
• soit une contrainte de réalisation imposée au projet.
Les exigences logicielles représentent donc l’ensemble des fonctionnalités et des
contraintes à satisfaire par un logiciel satisfaire ses besoins ou pour résoudre en partie ou en
totalité un problème dans un domaine ou une organisation. À cela, on ajoutera l'ensemble des
contraintes de réalisation du projet logiciel.
On reconnaîtra les exigences logicielles dans les phrases du genre « on voudrait que le
logiciel soit en mesure de ..., le système doit pouvoir … ; j'aimerai que le logiciel fasse ceci ou
cela … ; en moins de 3 secondes, l'application fait ceci ou cela, ... ».
b.2) La fonctionnalité
Une fonctionnalité est une fonction ou un ensemble de fonctions implantées dans le logiciel
permettant à un utilisateur d'effectuer un traitement. Elle représente une capacité de
traitement dont le logiciel doit être doté pour satisfaire les besoins pour lesquels il a été
commandité. Les fonctionnalités d'un logiciel déterminent ce qu'il doit faire ou ne pas faire,
comment doit-il réagir à des données saisies par l’utilisateur, comment va-t-il réagir à des
événements particuliers, comment va-t-il se comporter dans des situations particulières. b.3)
La contrainte de fonctionnement
Une contrainte de fonctionnement est une condition que le logiciel doit satisfaire lorsqu'il
exécute une certaine fonctionnalité ou dans son fonctionnement général. Les contraintes de
fonctionnement imposent généralement des conditions attendues en termes de performance,
de sécurité, etc.
b.4) La contrainte de réalisation
Une contrainte de réalisation est une condition ou un choix technique ou organisationnel à
respecter dans la réalisation du projet. Il peut s'agir d'un choix de modèle de cycle de vie, un

Page 32
choix de modèle de processus, un choix de technologies de programmation, etc. c) Classification
des exigences logicielles
On classifie habituellement les exigences logicielles selon plusieurs critères variés : selon
qu'elles se rapportent au produit logiciel lui-même ou au projet, selon la nature des besoins
couverts, ou encore selon qu'elles se rapportent à une partie spécifique ou à l'ensemble du
produit.
c.1) Exigences du produit – exigences du projet
Selon qu'elles rapportent au produit logiciel lui-même ou au projet, on distingue les
exigences du produit et les exigences du projet.
Par exigences du produit, également appelées paramètres du produit, il faut entendre les
exigences qui ne portent que sur le logiciel à construire, alors que les exigences ou paramètres
du processus définissent des contraintes sur les choix de développement dudit logiciel.
Par exemple « le logiciel doit s’assurer que l’étudiant est en règle avec les frais d’inscription
avant de valider son inscription » est une exigence typique du produit alors que « le logiciel
devra être réalisé en Java » est une exigence du processus.
c.2) Exigences fonctionnelles – exigences non fonctionnelles
Selon la nature des besoins couverts, on distingue les exigences fonctionnelles et les
exigences non fonctionnelles.
Les exigences fonctionnelles décrivent les fonctionnalités du logiciel doit pouvoir exécuter.
Les exigences non fonctionnelles sont celles qui imposent des contraintes de fonctionnement
au logiciel à développer ou qui expriment les caractéristiques de qualité attendues de ce produit.
Les exigences non fonctionnelles s’appliquent en général à l’ensemble du logiciel, plutôt qu’à une
fonctionnalité particulière.
Dans une application web de pré inscription, par exemple, « un candidat peut ajouter des
pièces justificatives à sa demande » est une exigence fonctionnelle. L’ensemble des exigences
fonctionnelles décrit la capacité fonctionnelle du logiciel. De l’autre côté, « plusieurs candidats
doivent pouvoir enregistrer leur demande en même temps » est une exigence non fonctionnelle.
Les caractéristiques de sécurité, les contraintes de performance, les exigences de fiabilité, ...
sont dans cette catégorie.
Ian Sommerville (2011) classifie les exigences non fonctionnelles comme suit :
• Les exigences du produit
◦ Les exigences
d'utilisabilité ◦ Les
exigences d'efficacité
▪ Les exigences de performance
▪ Les exigences d'utilisation de l'espace mémoire
◦ Les exigences de sécurité
◦ Les exigences de fiabilité (dependability)
• Les organisationnelles
◦ Les exigences liées à l'environnement d'exploitation du logiciel
◦ Les exigences opérationnelles
◦ Les exigences liées aux choix de développement
• Les exigences externes
◦ Les exigences liées à l'éthique dans le domaine du
problème ◦ Les exigences liées à la législation en
vigueur.
c.3) Exigences spécifiques – propriétés émergentes
Page 33
 Selon qu'elles se rapportent à une partie spécifique ou à l'ensemble du produit logiciel, on
distingue les exigences spécifiques et les propriétés émergentes.
Certaines exigences sont spécifiques à un composant particulier du logiciel et d’autres sont
telles que leur satisfaction est fonction de l’interaction globale entre les composants du logiciel.
Ces dernières exigences ne dépendent pas d’un seul composant, mais sont étroitement liées à
l’organisation générale du logiciel et aux interrelations et interactions entre composants
(architecture logicielle).
d) Propriétés d'une exigence logicielle de qualité
Une exigence logicielle est bien exprimée si elle est à la fois vérifiable, claire, quantifiable,
complète et consistante avec les autres.
Toute exigence logicielle doit être exprimée de manière à être vérifiable, c’est-à-dire
déterminer facilement si elle est ou non satisfaite par le logiciel. Bien qu’il peut être, dans
certains cas, difficile et coûteux d’y parvenir, les personnes responsables du développement
des exigences et celles responsables de l’assurance qualité doivent s’y évertuer dans la mesure
du possible.
De même, elles doit être exprimée avec clarté et sans ambiguïté. Éviter des exigences
vagues, non vérifiables et dont l’interprétation serait du domaine du subjectif.
En plus de la vérifiabilité, de la clarté et de la non ambiguïté, les exigences logicielles
devraient être exprimées quantitativement chaque fois que cela est faisable.
Elles doivent, mêmement être complètes (décrire toutes les fonctionnalités et contraintes)
et consistantes (pas d’exigences contradictoires ni conflictuelles).
Ainsi dit, « l’interface graphique doit être très attractive », « l’application doit être très
rapide », « l’application doit faciliter la gestion des patients » ne sont pas de bonnes exigences.
Que veut dire « être très attractive » quand on sait que les goûts et les couleurs ne se discutent
pas ? Et « très rapide » veut quel temps de réponse ? En quoi la gestion des patients doit-elle
être « facilitée »?
III.1.2 Concept et notions d'ingénierie des exigences logicielles a) Définition
L’ingénierie des exigences logicielles est le processus consistant à développer les exigences
d'un produit logiciel. Ce processus définit l’ensemble des activités et tâches nécessaires et la
manière de les articuler afin de traduire les besoins des parties prenantes du projet logiciel en
exigences logicielles.
Fig

ure 15: L'input et l'output du processus d'ingénierie des exigences.

L'ingénierie des exigences doit permettre de déterminer les buts, les fonctionnalités et les
contraintes de fonctionnement du logiciel et de déterminer leurs liens avec les spécifications
précises du comportement du logiciel et leur évolution au cours du temps.
• Les buts du logiciel (Le POURQUOI) déterminent le pourquoi du logiciel, c'est-à-dire les
raisons qui motivent les parties prenantes à commanditer le logiciel. La qualité et le
succès du logiciel sont définis en rapport avec sa capacité à remplir ces buts.
• Les fonctionnalités du logiciel (Le QUOI) déterminent les capacités de traitement
implantées dans le logiciel, c'est-à-dire les exigences fonctionnelles.

Page 34
 • Les contraintes de fonctionnement du logiciel (Le QUOI) déterminent les conditions de
fonctionnement imposées au logiciel, c'est-à-dire les exigences non fonctionnelles.
b) Les activités de l'ingénierie des exigences
Le processus d'ingénierie des exigences logicielles défini dans le SWEBOK comprend quatre
activités à savoir : la capture, l’analyse, la spécification et la validation.
1. La capture des exigences logicielles consiste à identifier les principales sources des
exigences et à déterminer comment les ingénieurs peuvent les collecter.
2. L’analyse des exigences logicielles, c’est l’examen approfondi des exigences capturées
afin de détecter et résoudre les conflits entre exigences, déterminer la portée du
logiciel, comment il interagit avec son environnement et aligner les exigences logicielles
sur les exigences du système dans lequel il fonctionnera.
3. La spécification des exigences logicielles consiste à documenter les exigences sur un
support papier ou électronique de telle sorte qu’elles soient systématiquement revues,
évaluées et approuvées.
4. La validation des exigences logicielles est l’examen minutieux des exigences dans le but
de dire si elles correspondent aux attentes des acteurs.
5. À cela, on peut aussi ajouter la gestion des exigences qui est, parfois, considérée comme
une activité de management plutôt qu’une activité d’ingénierie. Cette activité consiste à
gérer les exigences d’un projet de manière à répondre aux problématiques suivantes : la
collecte, la validation, la gestion des priorités, la traçabilité, la gestion du changement,
la gestion de la qualité, le lien avec le reste du projet et avec le contexte.
c)Les caractéristiques du processus d'ingénierie des exigences
Ce processus couvre tout le cycle de vie du logiciel, pas seulement le début du projet. La
gestion du changement et la maintenance des exigences de manière à refléter l’état réel du
logiciel à développer (ou déjà développé) à tout moment constituent la clé de réussite du
processus. Et, bien que, dans la section qui précède, les activités du processus (capture, analyse,
spécification, validation) ont été listées en séquence, le processus luimême doit être itératif et
incrémental et adapté au projet, au produit, à l’équipe et au contexte.
En plus, l’on doit garder à l’esprit que l’ingénierie des exigences n’est pas une activité isolée
; les spécifications logicielles doivent être réellement utiles aux activités subséquentes telles
que la conception ou la construction.
d) Les acteurs du processus d'ingénierie des exigences
Plusieurs entités souhaitent souvent tirer profit du logiciel sous développement. Dans ce
cas, chacun d’eux exprime ses exigences en fonction de ses besoins et de ses intérêts. On peut
distinguer les clients, les utilisateurs, les analystes du marché, les experts et les régulateurs
du domaine, les ingénieurs logiciels, les gestionnaires du projet.
D’emblée, il est impossible de satisfaire les exigences de chaque acteur. Il appartiendra à
l’ingénieur logiciel de négocier le compromis qui sera acceptable par tous, dans le respect des
contraintes du projet.

III.2 Les activités et les techniques d'ingénierie des exigences

III.2.1 La capture et l'analyse des exigences logicielles

La capture des exigences, désignée autrement « Identification des exigences », «
Découverte des exigences », « Acquisition des exigences », en Anglais « Requirements
Elicitation », est la première étape où on se fait une compréhension du problème que le logiciel
va résoudre. À ce niveau, tous les acteurs du projet doivent être identifié et les relations entre
les demandeurs (clients, utilisateurs et autres) et les développeurs identifiées.
Page 35
 Ensuite, il est important de décrire les exigences de manière à pouvoir les valider, les
implémenter et évaluer leur coût. C’est le propre de l’analyse des exigences. On y parvient en
appliquant la classification des exigences, la modélisation, les cas d’utilisation et les revues
techniques.
Étant donné que la communication est l’une des conditions indispensable à une bonne
ingénierie, avant même de commencer le développement logiciel, les spécialistes des exigences
peuvent constituer le canal de cette communication. Ils doivent assurer la médiation entre le
domaine des demandeurs du logiciel et le monde technique des ingénieurs logiciels. a) Sources
des exigences
Les exigences logicielles proviennent habituellement de plusieurs sources qu’il est essentiel
d’identifier et d’évaluer de manière à déterminer leur impact sur le logiciel. Les principales
sources à exploiter sont : le but du logiciel, les demandeurs, l’expertise du domaine de
l’application, l’environnement organisationnel, etc.
a.1) Le but du logiciel
Le but du logiciel, désigné autrement « la préoccupation », « l’importance », « l’intérêt » du
logiciel, fait allusion aux objectifs globaux, de haut niveau du logiciel. Les objectifs du logiciel
sont une source non négligeable d’exigences, parce qu’elles déterminent la motivation même du
logiciel. Malheureusement, ils sont souvent vaguement formulés. Les spécialistes des exigences
doivent donc adopter les techniques les plus appropriées.
Les ingénieurs logiciels doivent se préoccuper aussi d’évaluer la priorité et le coût de chacun
de ces objectifs, notamment en menant une étude de faisabilité.
a.2) Les demandeurs (clients, utilisateurs et autres parties prenantes)
Les ingénieurs logiciels ont besoin d’identifier, de représenter les points de vue des
différents demandeurs du logiciel à l’issue des enquêtes auprès des clients et utilisateurs. Le
risque est imminent d’aboutir à un logiciel non satisfaisant si l’on s’attache à accentuer les
exigences d’une seule catégorie des demandeurs au profit des autres. a.3) La connaissance du
domaine d'application
La connaissance du domaine du problème peut provenir des sources suivantes :
• La littérature technique ;
• Les applications existant dans le domaine du problème ou dans des domaines proches ;
• Les conseils et recommandations des experts du domaine du problème.
Les ingénieurs logiciels ont besoin d’acquérir une connaissance du domaine d’application du
logiciel. Cela leur permet d’inférer la connaissance tacite que les clients et les utilisateurs n’ont
pu articuler.
a.4) L'environnement organisationnel
Dans le cas où le logiciel est destiné à automatiser des tâches d’un employé ou à informatiser
un processus d’une organisation, les ingénieurs doivent tenir compte des facteurs qui régissent
l’organisation du métier tels que la structure de l’organisation, sa culture et sa politique interne.
a.5) L'environnement opérationnel
L’environnement dans lequel le logiciel devra fonctionner doit être bien étudié de manière à
identifier toutes les contraintes de fonctionnement auxquelles devrait se conformer les
logiciels. C’est particulièrement nécessaire quand le logiciel est destiné à un système embarqué,
à une machine autre que l’ordinateur.
b) Les approches courantes de capture et analyse des exigences
Dans la littérature, on identifie plusieurs approches à la capture et analyse des exigences.
On retrouve principalement l'approche axée sur les buts (goal-oriented approach en anglais),
l'approche axée sur les scénarii ( scenarios based-approach), l'approche axées sur les aspects
Page 36
(aspects-oriented approach), l'approche axée sur les modèles (model-driven approach),
l'approche axée sur les langages formels. Certains auteurs proposent aussi d'intégrer ces
différentes approches pour maximiser la qualité des exigences.
c) Quelques techniques de capture et analyse des exigences
Quand les sources d’exigences ont été identifiées, l’ingénieur logiciel peut alors commencer
la capture et l’analyse des exigences à partir de ces sources.
Les ingénieurs logiciels doivent être sensibilisés au fait que cette tâche est particulièrement
ardue en réalité. Par exemple, les utilisateurs peuvent éprouver des difficultés à décrire leurs
tâches, manquer à fournir certaines informations importantes, ou tout simplement refuser ou
être incapable de coopérer. Il est particulièrement important de comprendre que la capture et
l’analyse des exigences ne sont pas des activités passives et que, même si les demandeurs sont
disponibles et disposés à coopérer, l’ingénieur logiciel doit travailler d’arrache-pied à en tirer
les bonnes informations.
Le génie logiciel établit un certain nombre de techniques pouvant l’assister dans cet
exercice. Les plus courantes sont l’interview, l’observation, les réunions facilitées, les scénarios,
les cas d’utilisation et le prototypage. On ajoutera, à cela, les techniques de conception de
l'interface utilisateur développées par des chercheurs en Interaction Homme-Machine.
Chaque technique a ses limites dont l’ingénieur aura conscience pendant l’exercice de la
capture des exigences. Il doit déterminer les techniques les plus appropriées à chaque fois et
les combiner efficacement pour obtenir toutes les informations nécessaires à la suite du
processus.
c.1) L'interview
C’est la technique traditionnelle consistant à questionner tour à tour les intervenants.
L’ingénieur doit bien étudier son questionnaire et déterminer au préalable les informations qu’il
cherche à obtenir. Pendant l’exercice de l’interview, il évitera de s’écarter trop loin de cet
objectif. Mais surtout, il doit écouter et prendre des notes intelligibles. Après l’interview, il
doit faire valider ses notes par l’interrogé et s’assurer qu’il n’a pas mal compris ce qui lui a été
dit.
c.2) Les réunions facilitées
Le but de cette technique est d’obtenir du groupe des informations que les intervenants
n’ont pu donner individuellement par des interviews, de confronter les points de vue, de régler
les exigences conflictuelles. L’ingénieur doit faire attention à mener efficacement ses réunions
(la présence d’un facilitateur) de manière à éviter que seules certaines opinions priment ou que
de l’abondance des échanges, la communication soit ratée. c.3) L'observation
Les ingénieurs logiciels apprennent comment les utilisateurs exécutent leurs tâches en les
regardant faire dans leur environnement, voire en le faisant eux-mêmes.
c.4) Le scénario
Un scénario est un exemple réel de comment le système peut être utilisé. Il inclut : une
description de la situation de départ, une description de l’enchaînement normal des événements,
une description des cas d’erreurs possibles, une description des activités parallèles, une
description de l’état du système après exécution du scénario. Soit un exemple de scénario :
Gestion du dossier médical d'un patient dans un logiciel de gestion hospitalière

Situation de départ :

Page 37
 Le patient a déjà été enregistré par le réceptionniste. Le réceptionniste a déjà créé un

dossier dans le système et collecté les informations administratives le concernant (nom,

adresse, age, etc.).

Une infirmière est déjà connectée au système et veut compléter les données
médicales concernant le patient.
Déroulement normal :

L'infirmière recherche le patient par son nom.

S'il existe plusieurs patients portant le même nom de famille, l'infirmière utilise le
post-nom, le prénom et éventuellement la date de naissance.

Une fois le patient retrouvé, l'infirmière choisit l'option de menu

« Ajouter une historique médicale

».

L'infirmière va ensuite suivre une série de boîtes de dialogue et saisir les données
concernant la consultation, les examens, les antécédents, le diagnostic et la prescription.

Situations anormales :

Il peut arriver que le patient n'as pas encore été enregistré dans la base de données.

L'infirmière crée alors un nouveau dossier pour le patient et y enregistre

ses informations administratives avant de procéder à la saisie des données

médico-techniques.

Il peut aussi arriver que le patient ne fournit pas les antécédents.

L'infirmière saisit, en texte libre, les raisons de l'incapacité du patient à fournir

ces informations.

Activités parallèles : Les autres membres du personnel médical peuvent consulter le

dossier du

patient pendant que l'infirmière le met à jour ; ils ne pourront, cependant, pas
l'éditer.

Situation finale : Les informations saisies sont enregistrées dans la base de données,

Page 38
 l’identité de l’infirmière et les opérations exécutées sont journalisées pour des raisons
d'audit et sécurité.
c.5) Les cas d'utilisation
Les cas d’utilisation représentent une technique de description des exigences basée sur les
scénarios et formalisée dans le langage UML. Un cas d’utilisation décrit tous les scénarios
importants d’utilisation d’une fonctionnalité du système. L’ensemble de cas d’utilisation décrit
de manière exhaustive l’ensemble des scénarios d’utilisation du système.
Un cas d’utilisation identifie les acteurs du système et décrit l’interaction entre ces acteurs
et le système. Des diagrammes de cas d’utilisation et diagrammes de séquence sont utilisés pour
une représentation graphique. Le cours de conception des systèmes d’information au programme
d’informatique de gestion enseigne abondamment UML et la technique des cas d’utilisation.
c.6) Le prototypage
Les prototypes du logiciel à développer constituent un excellent moyen d’identifier les
exigences manquantes et clarifier celles qui ne le sont pas. On peut les utiliser conjointement
aux scénarios pour amener les utilisateurs à comprendre quelles sont les informations qu’ils
doivent fournir et dans quel contexte. Il existe plusieurs techniques de prototypage, allant des
maquettes des interfaces homme-machine sur papier jusqu’à la version bêta du logiciel, en
passant par des modèles opérationnels construits rapidement.
d) Capture des exigences logicielles
d.1) Le point de départ
Lors de l’initialisation du projet, le demandeur définit les exigences essentielles par rapport
au problème, les contraintes globales du projet et les fonctions et caractéristiques attendues
du logiciel à développer. On utilise essentiellement la technique d’interview.
L’essentiel de la communication peut se résumer comme suit :
1. Le demandeur exprime le problème. C’est ce qu’on appelle la demande de logiciel.
2. Le développeur enregistre la demande de logiciel du client si elle n’est pas déjà écrite.
3. Le développeur entretient les premiers échanges avec le demandeur pour identifier les
objectifs globaux et l’intérêt du projet. Quelques questions types à poser : • Qui
demande la réalisation de ce travail ? (Clients)
• Qui utilisera le logiciel ? (Utilisateurs)
• Qui d’autre est intéressé par la réalisation de ce logiciel ? (Autres intéressés)
• Quel sera votre intérêt économique ou social une fois le logiciel terminé (Objectifs
globaux et intérêt)
4. La série de questions suivantes visera à obtenir une compréhension du problème qu’on
cherche à résoudre en demandant le logiciel et sa perception (représentation mentale
de ce qu’il perçoit) de ce logiciel :
• Quel(s) problème(s) cherchez-vous à résoudre en demandant ce logiciel ?
• Pouvez-vous me décrire l’environnement professionnel dans lequel vous évoluez pour
en savoir un peu plus sur le problème ?
• Sur base de quoi pourrez-vous dire que le logiciel répond à ce(s) problème(s) ?
5. Les dernières questions visent à évaluer l’activité de communication elle-même :
• Êtes-vous la personne habilitée à répondre à ces questions ? Vos réponses sont-elles
l’avis officiel ?
• Mes questions vous ont-elles semblé pertinentes par rapport au problème et à vos
préoccupations ?
• Est-ce que je pose trop de questions ?
Page 39
 • Il y a-t-il quelqu’un d’autre qui pourrait me fournir des informations supplémentaires
?
• Pourrais-je vous demander autre chose par après ?
6. Le développeur et le demandeur planifient la prochaine rencontre avec l’ensemble des
acteurs : • Objectif de la réunion : comprendre les objectifs et les besoins des uns
et des autres ;
• Définir l’organisation de cette réunion : jour, heure, lieu, les invités. Les résultats
attendus de la première rencontre avec le demandeur sont :
1. La liste des demandeurs (client, utilisateurs, autres intéressés, experts).
2. La demande de logiciel.
3. La description synoptique du système, qui inclut l’identification du système, le but du
système, les grandes fonctionnalités du système, les objectifs du système, les
contraintes du système.
4. Le plan de la première réunion.
Nota bene. Plutôt que d’être créé à la demande d’un client, un logiciel peut aussi être créé
sur l’initiative d’un éditeur ou d’un individu après étude du marché. C’est d’ailleurs assez
fréquent dans les milieux académiques où les étudiants doivent produire des applications
logicielles à la fin du cycle de graduat ou de licence. Dans ce cas, l’éditeur ou l’individu, renseigné
sur le marché et le potentiel du produit, fournira les exigences logicielles. Ce qui a conséquence
de faire varier légèrement le processus. Selon les particularités du contexte du projet, il faudra
définir un processus adéquat et évaluer son efficacité. Par exemple, n pourra partir du Personal
Software Process comme base.
d.2) La capture des exigences logicielles proprement dite
Il s’agit alors d’intensifier la communication qui a débuté lors de l’initialisation du projet afin
de soutirer davantage d’information de toutes les sources disponibles. Toutes les techniques
sont applicables : l'interview, les scénarios, le prototypage, les réunions facilitées, etc.
Les informations obtenues lors de l’initialisation du projet doivent être mises à la disposition
des acteurs qui
les confronteront avec leurs versions des objectifs, des exigences et des contraintes.
Le canevas et les préalables d'une bonne réunion facilitée sont :
1. Les parties prenantes du projet sont présentes.
2. Le protocole de la réunion a été défini.
3. Le facilitateur de la réunion a été désigné.
4. Les rapporteurs de la réunion ont été désignés.
5. Le facilitateur doit conduire la réunion de manière à encourager les participants à
exprimer les objectifs, les fonctions et les contraintes le plus exhaustivement possible
, éviter des discussions et des contradictions (à faire lors de l’analyse des exigences).
6. Toutes les informations et toutes les décisions doivent être notées.
Les résultats attendus d'une réunion facilitée doivent inclure, entre autres :
• La liste des exigences (fonctions et contraintes de fonctionnement du logiciel)
exprimées par les parties prenantes ;
• Les scénarios d'utilisation ;
• etc.
Les analystes peuvent également passer des interviews poussées avec le client, les
utilisateurs et d'autres acteurs du projet afin de recenser le plus de besoins possibles.
Les ingénieurs du logiciel peuvent également développer des prototypes et obtenir le feed-
back des utilisateurs.
Page 40
e) La modélisation des exigences
On construit les modèles du domaine du problème et les modèles des exigences du logiciel.
Les modèles du domaine du problème sont essentiels à l’analyse des exigences, parce qu’ils
permettent de comprendre le problème lui-même, indépendamment du projet logiciel. Les
modèles des exigences décrivent les fonctions et contraintes à remplir par le logiciel et
comment interagira-t-il avec son environnement.
Par analyse du domaine, nous entendons l’identification, l’analyse et la spécification des
concepts, entités, classes d’objets interagissant dans ce domaine ainsi que leurs
caractéristiques, leurs comportements et les règles qui régissent leur organisation (structures,
relations et interactions).
Deux approches de modélisation du domaine et des exigences sont possibles : l’analyse
structurée et l’approche orientée objet. Dans l’un ou l’autre cas, plusieurs types de modèles
peuvent être développés, groupés en trois catégories, indépendamment de l’approche : les
modèles fonctionnels, les modèles structurels et les modèles comportementaux.
On peut construit des diagrammes SADT (un diagramme de contexte, des diagrammes de
flots de données), des diagrammes Merise (graphe de flux, diagramme du modèle conceptuel
des données, diagramme du modèle conceptuel des traitements, diagramme du modèle
organisationnel des traitements), des diagrammes UML 2 (cas d’utilisation, classes, activités,
états, séquences, communications, packages, ...).
f) La priorisation des exigences
Les exigences logicielles doivent aussi être évaluées et classifiées en termes de priorité. La
priorité définit l'importance ou la valeur attribuée à une exigence en fonction des objectifs du
logiciel et des intérêts des parties prenantes.
On peut définir le niveau de priorité d'une exigence sur une échelle numérique – de 1 (la
moins prioritaire) à 10 (la plus prioritaire) par exemple – ou une échelle nominale – essentielle,
hautement souhaitable, souhaitable, optionnelle ou avec un autre mécanisme.
III.2.2 La spécification des exigences
La spécification est le moyen utilisé pour communiquer et archiver les exigences. Elle se
matérialise dans un document appelé Software Requirements Specification, SRS en anglais. En
français, on traduirait Spécification des exigences logicielles. L’expression Spécification des
exigences logicielles désigne donc à la fois l’activité et le document produit lors de cette
activité.
a) Le document de spécification des exigences logicielles
D’un point de vue technique, le document de spécification des exigences est le document qui
décrit officiellement les fonctionnalités du logiciel à développer. Juridiquement, ce document
est à la base des engagements réciproques entre le client et le développeur.
Le document de spécification des exigences est utilisé par tous les acteurs du projet, chacun
pour ses besoins spécifiques :
• Le client l’utilise pour s’assurer que les exigences spécifiées sont conformes à ses
besoins et permettent d’atteindre ses objectifs.
• Les gestionnaires du projet l’utilisent pour planifier le processus de développement du
logiciel.
• Les développeurs l’utilisent pour déterminer ce qu’ils doivent développer dans le logiciel.
• Les testeurs l’utilisent pour définir les tests de validation du logiciel.
• Les mainteneurs l’utilisent pour comprendre l’architecture et le fonctionnement du
logiciel à maintenir.

Page 41
 Les informations présentes dans un document de spécification des exigences dépendent de
l’approche de développement adopté. Les systèmes développés par l’approche incrémentale ou
agile partent d’un document des exigences peu détaillé, alors que les systèmes développés dans
l’approche systématique disposent d’un document des exigences très fourni. Il existe, en
particulier, la norme IEEE 830-1998 qui normalise le contenu d’un document des exigences
logicielles. b) La norme IEEE 830-1998
La norme IEEE 830-1998 « Pratiques recommandées pour la spécification des exigences
logicielles (SEL) », en anglais Software Requirements Specification, SRS), est un guide destiné
à aider les clients et les fournisseurs de logiciels à communiquer le plus clairement possible les
buts, les besoins et les exigences d'un logiciel que les premiers commanditent aux derniers. Il
décrit les approches recommandées dans la spécification d'exigences de logiciels, le contenu
de toute spécification d'exigences logicielles (SEL) et quelles sont les caractéristiques d'une
SEL bien rédigée. Il présente également le plan de plusieurs exemples de SEL.
III.2.3 La validation des exigences
Le document de spécification des exigences peut faire l’objet de procédures de validation
et vérification. Les exigences peuvent être validées pour s’assurer que les ingénieurs logiciels
les ont bien comprises ; il est aussi important de s’assurer que le document des exigences est
conforme aux standards de l’entreprise ou de l’équipe qui développe le logiciel, qu’il est
compréhensible, consistent et complet. Le cas échéant, des corrections doivent y être
apportées par tous les acteurs du projet.
La validation des exigences est le processus d'assurance qualité qui consiste à examiner le
document des exigences afin de s’assurer qu’il définit le bon logiciel (the right software), c’est-
à-dire le logiciel que les utilisateurs attendent. La validation des exigences peut se faire par les
revues des exigences, le prototypage, la validation des modèles ou les tests d’acceptation.
a) Les revues des exigences
Le moyen le plus courant de validation des exigences est d’inspecter le document des
exigences. Un groupe de réviseurs ou relecteurs est chargé de revoir le document des exigences
dans le but d’identifier des erreurs, des conceptions erronées, le manque de clarté et des
déviations des pratiques standard. La composition du groupe est importante ; au moins un
représentant du client doit être inclus.
b) Le prototypage
Le prototype est aussi un moyen courant de validation des exigences parce qu’il permet de
voir si l’interprétation des besoins faite par les ingénieurs du logiciel correspond à la demande,
ensuite il permet de capturer de nouvelles exigences.
c) La validation des modèles
Il est aussi nécessaire de valider la qualité des modèles (concepts et diagrammes)
développés durant l’analyse des exigences. Par exemple, pour des modèles objets développés
avec UML, il est utile d’effectuer une analyse statique afin de vérifier qu’il existe des chemins
de communication entre objets qui, dans le domaine du problème, échangent des données. Si
l’analyse s’est faite au moyen des approches formelles, il est possible de dérouler une preuve
formelle des propriétés de la spécification.
d) Les tests d'acceptation
Une propriété essentielle des exigences logicielles est qu’on doive déterminer si elles sont
satisfaites par le produit fini. Les exigences qui ne peuvent être satisfaites sont alors
considérées comme de simples souhaits. Il est alors important de planifier comment la validation
sera faite. Dans la plupart des cas, on y parvient en définissant des critères d’acceptation et
en concevant des tests d’acceptation.
Page 42
III.2.4 La gestion des exigences
Le rôle de l’ingénierie des exigences est l’établir une base initiale des exigences du logiciel
à développer. La gestion des exigences se préoccupe de gérer les changements (modification,
adaptation, évolution, suppression) des exigences qui surviennent tout au long du projet et de
maintenir ces changements dans le respect des délais, des budgets et autres ressources et
caractéristiques du projet.
Tout changement doit s’accompagner d’une analyse d’impact de manière à déterminer les
effets que ce changement provoque sur le calendrier, le budget, les ressources, les attributs
de qualité, la technologie et d’autres facteurs. L’analyse d’impact permettra de déterminer si
le changement demandé est acceptable ou en dehors de la portée du projet.
III.3 L'approche agile à l'ingénierie des exigences
La plupart des méthodes agiles considèrent qu’élaborer un document de spécification des
exigences exhaustif est une perte de temps parce que les exigences changent très rapidement,
ce qui rend le document rapidement obsolète. Les méthodes comme XP adoptent une approche
incrémentale à l’ingénierie des exigences et expriment ces exigences sous forme de user
stories. Les exigences sont émergentes : on découvre comment satisfaire les besoins du client
au fur et à mesure de l’évolution du projet, les exigences existantes changent et de nouvelles
exigences sont découvertes.
Initialement, il était pensé que l’approche agile était adaptée uniquement à des projets
consistant à élaborer des systèmes non critiques et de petite envergure et qu’il était plus
indiqué d’adopter une approche plus traditionnelle à l'ingénierie des exigences concernant les
gros projets.
Aujourd'hui, on observe, dans l'industrie, de nombreuses tentatives d'adaptation des
techniques et pratiques agiles à de gros et très gros projets. En particulier, SaFe (Scaled Agile
Framework for Enterprise) est le framework le plus prometteur. Les deux ouvrages de Dean
Leffingwell, Scaling Software Agility: Bests Practices for Large Enterprises (Leffingwell,
2007) et Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and
the Enterprise (Leffingwell, 2011), représentent une contribution majeure par rapport au sujet
et aux pratiques professionnelles dans l'industrie.
III.3.1 Le modèle agile d'ingénierie des exigences logicielles
Dean Leffingwell (Leffingwell, 2011) développe un méta-modèle cohérent d’ingénierie des
exigences destiné aux approches agiles en proposant d’intégrer la notion de user story dans un
un cadre conceptuel plus vaste où on retrouve aussi les notions de fonctionnalités (features) et
exigences non fonctionnelles. Les user stories sont donc vues comme des exigences
fonctionnelles qui réalisent des fonctionnalités. Elles doivent ensuite être complétées des
exigences non fonctionnelles et contraintes de développement.
Le modèle Agile Software Requirements est un modèle de structuration, hiérarchisation et
développement des exigences logicielles sur trois niveaux : le niveau d'une équipe agile, le niveau
d'un programme de développement et le niveau de la gestion du portefeuille d'investissement.
a) Le backlog du produit
En termes d'ingénierie des exigences, le niveau Équipe définit les éléments ou artefacts des
exigences manipulés par une équipe agile. Il s'agit des éléments du backlog du produit : les user
stories, les tests d'acceptation des user stories, les problèmes et les tâches.

Page 43
 Figure 16: Les éléments d'un backlog de produit.

III.3.2 Les user stories, les features et les epics

a) Définition et notions de user story
Une user story est un court énoncé de besoin décrivant une fonction, un service ou une
contrainte qu'un logiciel doit réaliser afin de permettre à un utilisateur d'atteindre un objectif.
La notion de user story a été introduite par la méthode Extrem Programming (XP) ; c’est
aujourd’hui le concept des méthodes agiles qui remplace (ou qui s’ajoute à ?) la notion
traditionnelle d’exigence logicielle et la notion de cas d’utilisation. C’est donc le cheval de
bataille du développement agile au niveau d'une équipe.
Une user story (littéralement histoire utilisateur) décrit, en langue naturelle, un scénario
du métier en termes de QUI, QUOI et POURQUOI. Les users stories sont les spécifications
du projet présentées sous forme d’histoires utilisateurs qui décrivent les interactions de
l’utilisateur avec le système de façon plus ou moins détaillées. La description est
intentionnellement courte, traditionnellement inscrite sur un coupon, longue d’une ou deux
phrases. Une user story ne se préoccupe pas de couvrir tous les détails, elle constitue juste un
point de départ de la conversion entre le métier et le développeur, elle exprime l’intention avec
laquelle quelqu’un souhaite avoir une fonctionnalité dans le logiciel.
Techniquement, une user story représente une fonctionnalité à implémenter définie par
trois éléments :
1. Une courte description écrite de la user story ;
2. Les conversations informelles entre les membres de l’équipe autour de la user story ;
3. Les tests écrits permettant de documenter les détails et les critères d’acceptation de
la user story.
Une user story n’est pas un cas d’utilisation : les cas d’utilisation sont plus détaillés et
peuvent constituer la spécification détaillée des exigences.
b) Formulation d'une user story
La formule courante d'une user story est la suivante :

« En tant que <Rôle>, je peux <Action> afin de <Objectif> ».

où :
1. <Rôle> : représente le rôle joué par la personne ou l'autre système qui requiert une
fonction ou impose une contrainte.
2. <Action> : représente l'action qui doit le logiciel doit permettre d'exécuter.
Page 44
 3. <Objectif> : représente l'objet que la personne ou l'autre système veut atteindre.
L'atteinte de cet objectif produit de la valeur au niveau de l'organisation : satisfaction
d'un client, optimisation d'un processus, réduction d'un coût, augmentation de
bénéfices, etc.
Quelques exemples de user stories :
1. En tant que gérant du magasin, je peux consulter les statistiques de ventes
quotidiennes afin de me permettre d'évaluer la rentabilité de chaque produit que nous
commercialisons.

2. Moi, comme étudiant, je dois être en mesure d'imprimer ma grille de résultats

personnalisée de telle sorte que je puisse garder une trace de ma scolarité dans mes
archives personnelles.
Un formulaire d’enregistrement de user stories peut contenir plusieurs rubriques, les plus
importantes étant :
1. ID : le numéro d'identification unique de la user story ;
2. Rôle (En tant que) : Le rôle de la personne qui exprime la user story dans le métier (Le
QUI) ;
3. Action ou contenu (Je peux) : Ce que la personne veux pouvoir faire avec le logiciel ; le
scénario doit être exprimé en termes du métier (Le QUOI) ;
4. Objectif métier (Raison, Parce que) : L’objectif métier que la personne veut atteindre
en demandant la fonctionnalité (Le POURQUOI) ;
5. Importance ou poids : Importance ou poids estimé en story points ;
6. Critères d’acceptation : Détails, tests, …
c) Les critères d'acceptation d'une user story
Les tests d’acceptation d’une user story sont des tests fonctionnels permettant de vérifier
que le système implémente correctement la user story. Ces tests sont basés sur les critères
d’acceptation de la user story. La conception des tests d’acceptation consistera à vérifier que
le système satisfait aux critères d’acceptation ayant été définis pour chaque user story.
Un exemple de critères d'acceptation de la première user story de l'exemple précédent
serait :
1. Pour une période au cours de laquelle il y a eu vente, j'obtiens les statistiques de tous
les produits vendus, c'est-à-dire le code, la désignation, le chiffre de ventes et le
classement en termes de rentabilité.

2. Je peux regrouper ou filtrer les produits par catégorie.

3. Je peux filtrer les produits dont les chiffres de ventes dépassent un certain seuil.

4. Je peux trier la liste de produits dans l'ordre que je veux et selon la rubrique que je
veux.

5. Pour une période au cours de laquelle il n'y a pas eu vente, le système me signale qu'il n'y
a pas de statistique.

d) Les caractéristiques d'une bonne user story

Une bonne user story doit être INVEST :
1. Indépendante : Une user story se doit de n’avoir aucune dépendance envers les autres
stories, elle doit pouvoir être réalisée individuellement. Ce besoin découle du fait qu’à
tout moment on veut pouvoir réorganiser, reprioriser le carnet de produit. Si les stories
ont des dépendances, cette repriorisation est limitée.

Page 45
 2. Négociable : Toute story qui se trouve dans le carnet de produit, peut être réécrite,
repensée ou même supprimée à tout moment en raison de changements du marché, de
modification de l’orientation de besoins techniques ou tout autre motif valable provenant
de membre de l’équipe ou des sponsors.
3. De valeur (précieuse, valuable en anglais) : Toutes les stories se doivent de générer de
la valeur au niveau du métier de l’utilisateur final.
4. Estimable : Une user story doit pouvoir être évaluée en terme de complexité par l’équipe.
Si une user story ne peut être évaluée, elle ne sera jamais planifiée ni incluse dans un
carnet de sprint ou découpée en tâches. Habituellement elle ne peut l’être lorsqu’elle
manque d’informations de support, ou lorsque la description faite pas le propriétaire du
produit est insuffisante ou vague.
5. Petite (small en anglais) : Une user story doit être suffisamment petite pour permettre
d’être évaluée avec le plus de précision et certitude possible. Si l’équipe évalue la
complexité relativement élévée, cela démontre en général un niveau d’incertitude élevé
et cela implique qu’elle devrait être découpée en plusieurs stories.
6. Testable : Garder en tête qu’une story ne peut être considérée finie sans qu’elle ait été
testée avec succès. S’il n’est pas possible de tester la story due à un manque
d’information, elle ne devrait surtout pas être considerée pour être incluse dans un
sprint Backllog. Ceci est encore plus vrai pour les équipes intégrant les techniques XP et
particulierement le TDD (développement piloté par les Tests).
e) Le découpage d'une user story en tâches
Pour s’assurer que l’équipe comprend réellement son travail et qu’elle est en mesure de tenir
ses engagements, les user stories sont implémentées par des tâches. Par définition, une tâche
est une petite unité de travail nécessaire à la réalisation d’une user story. Le découpage des
user stories en tâches facilite davantage l’estimation et la coordination du travail individuel de
chaque membre de l’équipe agile.
Un exemple de tâches tirées de la première user story de l'exemple précédent serait :
1. Définir les tests d'acceptation.
2. Concevoir le formulaire de paramétrage du rapport des statistiques et le rapport des
statistiques.

3. Coder la logique applicative (routes et contrôleurs) de la user story.

4. Coder les tests d'acceptation.

5. Valider la user story.
6. Documenter la user story dans l'aide utilisateur.
f) L'expression des exigences non fonctionnelles
Les exigences non fonctionnelles et contraintes de développement devraient être exprimées
dans le style des user stories de manière à identifier la source de l’exigence et la valeur ajoutée
dans le métier des utilisateurs. Par exemple, au lieu de :
1. Tous les messages de notification doivent s'afficher en moins de 5 secondes.
On préférera :
1. En tant que vendeur, je veux que tous les messages de notifications s'affichent en
moins de 5 secondes, parce que les acheteurs sont impatients et j'en reçoit plusieurs à
tout moment.

Page 46
 Chapitre IV.
LA GESTION DE PROJETS LOGICIELS

Ce chapitre traitement des éléments fondamentaux de la gestion de projets logiciels. Le

programme officiel de deuxième année de licence (Bac+4) en informatique de gestion, toutes
options confondues, prévoit un cours sur la conduite de projets informatiques en général, les
projets logiciels inclus. Dans ce cours, nous mettons un accent particulier sur les aspects
techniques spécifiques aux projets logiciels.

Ce chapitre poursuit les objectifs spécifiques suivants :

1. Présenter les concepts de la gestion de projets de développement de logiciels.
2. Donner un aperçu exhaustif des activités des processus de gestion de projets de
développement de logiciels.
3. Présenter les techniques les plus courantes d'estimation de tâches (délais et coûts).

À l'issue du chapitre, l'étudiant devrait être en mesure de :

1. Définir et comprendre les concepts de l'ingénierie des exigences logicielles.
2. Lister et décrire les activités de gestion de projets de développement de logiciels ainsi
que les produits logiciels associés.
3. Mettre en œuvre les techniques les plus courantes d'estimation de tâches sur des
problèmes fictifs ou concrets de développement de logiciels.
IV.1 Quelques généralités
On admet généralement que la différence principale entre le génie logiciel et les autres
types de développement logiciel est que l’ingénierie est un processus managé. Cela signifie que
le développement logiciel a lieu dans une organisation et fait l’objet d’un calendrier, d’un budget
et de contraintes organisationnelles. Il s’ensuit que le management est très important pour le
génie logiciel. IV.1.1 Définitions et notions
a) Le projet logiciel
Richard E. Fairley (Fairley, 2009) définit un projet comme un groupe d’activités coordonnées
conduites dans un intervalle de temps spécifique dans le but d’atteindre des objectifs spécifiés.
Un projet peut être personnel ou conduit par une équipe ou encore une organisation entière.
Le Project Management Book of Knowlegde (PMBOK) publié par le Project Management
Institute définit un projet comme une entreprise temporaire consistant à créer un produit, un
service ou un résultat unique. La nature temporaire des projets indique qu’un projet a un début
et une fin. La fin est atteinte quand les objectifs du projet ont été atteints ou quand le projet
est interrompu parce que ses objectifs ne peuvent ou ne seront pas atteints, ou encore quand
le besoin à l’origine du projet n’existe plus.
Un projet logiciel est un projet visant la production d’un logiciel tout entier ou en partie.
Lorsqu’il est de grande envergure, un projet est souvent subdivisé en sous-projets.
b) La gestion de projets logiciels
Le corpus SWEBOK définit la gestion de projets logiciels comme l’application des activités
de management ( planification, coordination, surveillance, contrôle, prélèvement des mesures,
évaluation, compte-rendu) de manière à assurer un développement logiciel systématique,
discipliné et quantifié.
Le management de projets logiciels s’intéresse donc aux activités permettant de s’assurer
que le logiciel est livré dans le respect des délais et des budgets et en accord avec les exigences
de tous les acteurs impliqués. Ces activités de management sont requises parce que le
Page 47
développement de produits logiciels fait toujours l’objet de plusieurs contraintes de délais et
de budgets définies par l’organisation qui commandite ces produits.
Les activités de gestion de projets logiciels incluent (SWEBOK, 2013) :
• La planification du projet : Les gestionnaires de projets, seuls ou en collaboration avec
leurs équipes selon les approches, ont la responsabilité de planifier les projets, assigner
des tâches aux membres des équipes, estimer la durée, les coûts et les efforts de
réalisation des tâches et élaborer les divers plans et le calendrier du projet.
• Le compte-rendu : Les gestionnaires de projets ont généralement la responsabilité
rendre compte de l’évolution de projets aux clients et aux autres acteurs (par exemple,
les gestionnaires de l’organisation qui développe le logiciel).
• La gestion de risques : Les gestionnaires de projets ont la responsabilité d’évaluer les
risques susceptibles d’affecter le projet, surveiller ces risques et prendre les mesures
nécessaires quand des problèmes surviennent.
• La gestion des personnes (pour ne pas dire des ressources humaines) : Les gestionnaires
de projets ont la responsabilité de recruter des personnes compétences pour former
leurs équipes de travail et et créer des voies et moyens et un cadre de travail leur
permettant d’amener leurs équipes à la performance et à l’atteinte des objectifs.
• La rédaction de la proposition de projet : La première étape d’un projet logiciel peut
consister à soumettre une proposition afin de gagner un contrat de développement
logiciel ; il incombe aux gestionnaires de projets de rédiger cette proposition et de la
défendre.
Ce qui fait la particularité du management de projets logiciels par rapport à d’autres types
de projets, c’est certaines caractéristiques du produit logiciel en-soi (Pressman, 2010 ;
Sommerville, 2011) :
• Le logiciel est intangible : Le logiciel ne peut être vu ni touché. Les gestionnaires d’un
projet logiciel ne peuvent donc évaluer l’avancement du projet en regardant simplement
l’artefact en cours de construction.
• Chaque projet logiciel est unique en son genre : Les projets logiciels, en particulier les
gros projets, sont, d’une certaine manière, différent les uns des autres tel que même
les gestionnaires ayant accumulées de l’expérience dans les projets précédents.
• Les processus logiciels sont variables et spécifiques à chaque organisation : On pourrait
définir une infinité de processus de développement logiciel et, il n’est pas évident de
prédire quand un processus est approprié au problème à résoudre, à l’objectif à
atteindre ou au produit à développer.
IV.1.2 Les critères de succès de la gestion d'un projet logiciel
Partant des définitions précédentes, les critères à partir desquels on peut mesurer le succès
de la gestion d’un projet logiciel sont :
• Le logiciel est livré au client dans le respect des délais fixés ;
• Le logiciel est livré au client dans le respect des budgets alloués ;
• Le logiciel satisfait aux attentes du client ;
• Un meilleur climat possible de travail est maintenu au sein de toute l'équipe de
développement.
S’il n’est pas simple de satisfaire tous ces critères à la perfection, le souci d’un bon manager
de projets logiciels est de s’y rapprocher le plus possible.

Page 48
IV.1.3 Le spectre de la gestion de projets logiciels : les 4 P
Une gestion de projet logiciel efficace, qui vise la satisfaction des critères sus-énumérés,
se focalise sur les quatre « P » : les Personnes (People), le Produit (Product), le Processus
(Process) et le Projet (Project) (Pressman, 2010) . L’ordre d’énumération n’est pas arbitaire. Le
gestionnaire qui oublie que l’ingénierie du logiciel est d’abord un travail humain, une entreprise
réalisée par des personnes n’aura jamais de succès dans la gestion de son projet. Un gestionnaire
qui ne parvient pas à stimuler des échanges permettant de communiquer efficacement sur les
exigences du produit risque de développer une solution, peut-être élégante, mais inadaptée au
problème à résoudre. Le gestionnaire qui accorde peut d’attention au processus de
développement court le risque d’utiliser des méthodes, techniques et outils dans le vide, quel
que soit leur degré de sophistication. Le gestionnaire qui s’embarque dans son projet sans un
plan solide menace le succès de ce projet.
IV.1.4 Le workflow de gestion d'un projet logiciel de Fairley

Figure 17: Le workflow (flux de travail) de gestion d'un projet logiciel

(Fairley, 2009).
IV.2 Un aperçu général des activités de gestion de projets logiciels
Le dispositif SWEBOK structure les activités de management de projets logiciels en cinq
phases : (1) initialisation et définition de la portée, (2) planification, (3) promulgation, (4) revue
et évaluation, (5) clôture.
IV.2.1 L'initialisation et la définition de la portée d'un projet logiciel
Le point focus de cet ensemble d’activités est d’arriver à déterminer, de manière effective,
les exigences ( besoins et contraintes) du logiciel au moyen des techniques de captures des
exigences, ensuite tabler sur la faisabilité du projet sur plusieurs aspects. Une fois la faisabilité
établie, la tâche suivante est la spécification des procédures de validation et de modification
des exigences du logiciel.
a) La détermination et la négociation des exigences
Des techniques de capture (ex. : observation), d’analyse (ex. : modélisation des données,
modélisation des cas d’utilisation), de spécification et de validation (ex. : le prototypage) doivent
être sélectionnées et appliquées, tout en prenant en compte les perspectives des différents
acteurs du projet. Cela conduira à déterminer la portée, les objectifs et les contraintes du
projet ; ces éléments fixent clairement les limites du projet.
b) L'analyse de faisabilité

Page 49
 Les ingénieurs logiciels doivent s’assurer que des capacités et ressources techniques,
opérationnelles, financières et sociopolitiques sont disponibles. Cela inclut une main-d’œuvre
suffisante, une expertise confirmée, des installations appropriées, une infrastructure et un
support permettant de s’assurer que le projet peut être réalisé avec succès dans les limites du
temps imparti et du budget disponible. Il est possible d’élaboration une estimation provisoire
du travail à accomplir et des coûts en utilisant des méthodes appropriées ou en demandant l’avis
des experts.
c) La spécification du processus de revue et révision des exigences
Étant donné que les changements (modification, évolution) des exigences sont inévitables, il
est vital que les acteurs du projet s’accordent déjà sur les moyens à mettre en œuvre pour
revoir et réviser les exigences ; ils aboutiront à la définition de procédures concrètes. Cela
implique que les exigences et la portée du projet ne seront pas définies de manière définitive ;
des révisions doivent être possibles à certains points d’avancement du projet.
La prise en charge des changements des exigences et de la portée du projet s’accompagne
d’une analyse de traçabilité et d’une analyse de risques de manière à évaluer l’impact de tous
ces changements sur la réalisation du projet.
IV.2.2 La planification d'un projet logiciel
Le processus de planification d’un projet logiciel est itératif ; il tire les informations
essentielles des exigences et de la portée du projet définies par les acteurs, ainsi que l’étude
de faisabilité.
À ce point, les processus du cycle de vie du logiciel sont évalués et les plus appropriés sont
retenus en fonction des caractéristiques du projet (nature du projet, degré d’innovation,
complexité fonctionnelle, complexité technique, exigences de qualité, ...). Dans la mesure du
possible, le projet tout entier est planifié sous forme d’une décomposition hiérarchique des
tâches. On va ensuite déterminer les produits livrables associés à chaque tâche ; en fonction
des exigences, on spécifie chaque produit en déterminant les attributs de qualité et autres
caractéristiques.
Puis, on établit les estimations des efforts de développement, du calendrier et des coûts.
Ensuite, on alloue les ressources aux tâches de manière à optimiser la productivité personnelle
de chaque acteur du projet, tant au niveau individuel, au niveau des équipes qu’au niveau
organisationnel, optimiser l’utilisation des matériels et assurer l’adhésion au calendrier.
L’étape suivante est d’étudier et d’initialiser la gestion des risques qui caractérisent le
projet. Les processus de gestion de la qualité sont aussi déterminés et intégrés dans le
processus de planification. Pour chaque processus qualité, on détermine les procédures et les
responsabilités concernant l’assurance qualité, la vérification et validation, les revues, et les
audits.
a) La planification du processus de développement du logiciel
On commence par choisir le modèle de cycle de vie le plus approprié (ex. : cascade, spirale,
agile) et choisir les processus à adopter et déployer dans le cycle de vie. De manière générale,
il existe deux approches dans le choix d’un modèle de cycle de vie : un modèle piloté par un plan
(plan-driven model) et un modèle agile. Le modèle piloté par un plan voit un projet logiciel
comment une entreprise dans la réussite est conditionnée par l’utilisation d’une approche
systématique, des processus et des activités clairement prescrites. Un accent est aussi mis sur
la documentation nécessaire à la vérification et à la validation des produits logiciels. Un modèle
de cycle de vie agile est composé de processus légers qui utilisent des cycles itératifs courts
et qui impliquent activement l’utilisateur dans la définition des et l’analyse des exigences. Ce
type de modèle est surtout basé sur les connaissances tacites de membres de l’équipe, plutôt
Page 50
que sur une documentation abondante. Tous ces choix sont conditionnés par les caractéristiques
du projet.
Ensuite, on choisit les techniques et outils de planification du temps, d’ingénierie des
exigences, de conception, de construction, de maintenance, de gestion de la configuration, de
gestion de la qualité, etc.
Le projet est aussi décomposé en tâches, avec les inputs, outputs et conditions associés.
Cette décomposition aura un impact sur le calendrier global et l’organisation du projet.
b) La détermination des livrables
Le(s) produit(s) de chaque tâche (ex. : documents de conception architecturale, rapports
d’inspection des spécifications) est(sont) spécifié(s) et caractérisé(s). Les opportunités de
réutilisation de composants logiciels développés dans des projets précédents tout comme les
possibilités de réutiliser des logiciels du marché sont évaluées. De même, la commande et
l’utilisation des logiciels de tierces parties sont planifiées et les fournisseurs sélectionnés.
c) L'estimation des efforts, des délais et des coûts
En fonction du découpage de tâches, inputs et outputs,les efforts requis pour chaque tâche
sont estimés ; on pourrait recourir aux données des estimations et desexpériences passées si
elles existent, sinon d’autres modèles et techniques d’estimation pourraient être utilisées. Les
dépendances entre tâches sont établies et des tâches critiques sont identifiées et étudiées
aux techniques appropriées telles que l’analyse des chemins critiques. Le calendrier de
réalisation des tâches est établi au moyen de la méthode PERT (Project Evaluation and Review
Technique) ou autre. Les ressources requises (personnes, outils) sont estimées en termes de
coûts. Toutes ces estimations doivent être négociées entre tous les acteurs du projet et
définies de manière consensuelle.
d) L'allocation de ressources
Les équipements, les installations et les personnes sont affectées aux tâches planifiées et
les responsabilités sont bien établies. On utilisera, par exemple, un diagramme de Gantt. On
n’oubliera pas que cette activité est contrainte par la disponibilité des ressources et leur
utilisation optimale dans les circonstances précises de la tâche, mais aussi les problèmes liés au
personnel tels que la productivité d’un membre particulier de l’équipe ou toute l’équipe, la
dynamique d’équipe, la disponibilité des membres, etc. Toutes ces informations sont importantes
à réunir.
e) La gestion de risques
L’identification et l’analyse de risques (qu’est-ce qui va mal, comment et pourquoi, et quelles
en sont les conséquences), l’évaluation critique de ces risques, aussi bien que la mitigation et la
planification de la contingence (formulation d’une stratégie de gestion de risques) constituent
les tâches essentielles de la gestion de risques.
f) La gestion de la qualité
La qualité est définie en termes de caractéristiques et attributs de qualité, en privilégiant
les plus pertinents au projet en cours de réalisation.
g) La gestion du plan
Le plan du projet doit aussi être géré, c’est-à-dire surveillé, contrôlé, réajusté, etc.
IV.2.3 La promulgation d'un projet logiciel
Les plans du projet sont mis à la portée de tous les acteurs du projet et implémentés dès le
démarrage du projet.

Page 51
IV.2.4 La revue et l'évaluation d'un projet logiciel
À des points critiques du projet, on doit évaluer la réalisation du projet et prendre les
mesures nécessaires requises pour son aboutissement.
IV.3 Les moments forts de la planification de projets logiciels
La planification du projet est l’une des tâches essentielles du gestionnaire de projet tel que
nous l’avons établi dans la section précédente. En tant que gestionnaire de projet, vous avez la
responsabilité de découper le travail à faire en tâches et assigner ces tâches aux membres de
l’équipe du projet. Votre deuxième responsabilité est d’anticiper les problèmes susceptibles
d’advenir tout au long du projet et de préparer des solutions anticipées à ces problèmes. Le plan
du projet, qui est créé au tout début du projet, est utilisé pour communiquer aux membres de
l’équipe du projet et aux clients comment le travail sera effectué et comment sera évaluée
l’évolution du projet.
Dans tout projet de développement logiciel, la planification couvre tout le cycle de vie du
logiciel, de la proposition du projet au retrait du logiciel du marché. On identifie, tout de même,
trois moments forts où l’activité de planification est intense : lors de la proposition du projet,
lors du démarrage du projet et périodiquement tout au long du projet.
IV.3.1 La planification lors de la proposition d'un projet logiciel
La planification s’effectue, pour la première fois, lors de la proposition du projet, alors que
vous soumissionnez (vous faites une soumission) de développer et fournir un système logiciel à
une entreprise, ou quand vous êtes sollicité par une entreprise désireuse d’avoir un système
logiciel. À ce stage, vous avez besoin d’un plan à partir duquel vous déterminerez si vous disposez
des ressources nécessaires à l’accomplissement travail. Ce plan vous aidera également à
déterminer le prix à demander au client.
La planification lors de la phase de proposition de projet est inévitablement spéculative,
puisque vous ne disposez pas encore d’un jeu complet d’exigences du logiciel à développer.
Cependant, vous devez pouvoir répondre à la demande du client en vous basant sur la description
globale faite des fonctionnalités attendues du logiciel. De même, la proposition de projet de
vous adresserez au client doit inclure un plan de travail plus ou moins crédible. Elle doit aussi
s’accompagner d’une estimation provisoire des coûts. Àprès avoir gagné le contrat, vous pourrez
alors replanifier le projet et reestimer les coûts et les délais en prenant en compte les
changements survenus dans l’entre-temps.
IV.3.2 La planification au démarrage d'un projet logiciel
La planification s’effectuera aussi lors du démarrage du projet, alors que vous devez monter
une équipe, déterminer les critères de découpage du projet en incréments, tabler sur l’allocation
des ressources, etc. À ce stade, vous possédez davantage d’information comparativement à la
phase de proposition ; vous devez alors raffiner le plan initial et les estimations provisoires.
IV.3.3 La planification tout au long d'un projet logiciel
La planification s’effectuera aussi périodiquement tout au long du projet, quand vous aurez
à modifier le plan initial à la lumière de l’expérience et des informations issues du contrôle et
de l’évaluation de l’avancement du travail. Vous en aurez appris davantage sur le système sous
implémentation ainsi que sur les capacités de votre équipe de développement. Cette information
vous permettra d’améliorer vos estimations de la durée du travail. Plus tard, le découpage des
tâches et le calendrier pourraient faire l’objet de modifications si les exigences du logiciel
venaient à changer. Cela implique la modification du plan élaboré lors de la phase de démarrage,
si vous avez adopté une approche de projet orientée planification. Si, toutefois, vous avez

Page 52
adopté une approche agile, il sera naturel que les plans soient de court terme et voués à changer
au fur et à mesure que le logiciel évolue.

IV.4 La planification agile

IV.4.1 Généralités et notions

a) L'approche agile à la gestion de projets logiciels
Les méthodes agiles sont des approches itératives où le logiciel est développé et livré aux
clients en plusieurs incréments. Contrairement aux approches pilotées par un plan, les
fonctionnalités de ces incréments ne sont pas planifiées en avance, mais sont décidées pendant
le développement. Le choix des fonctionnalités à inclure dans un incrément dépend de la
progression du travail et des priorités du client. Cela s’explique par le fait les priorités et les
exigences du client changent, d’où il faut disposer d’un plan flexible et capable de prendre en
compte ces changements.
Les approches agiles courantes telles que Scrum et Extreme Programming planifient le
projet en deux phases :
1. La planification d'une release (édition en français) : Lors de cette phase, l’équipe décide
des fonctionnalités (user stories, features) dans une édition du système. La phase dure
entre 3 et 6 mois en fonction du projet et du produit. La planification initiale a lieu lors
du démarrage du projet. Les mises à jour ont lieu après chaque itération courte ou sprint.
2. La planification d'une itération ou d'un sprint : Cette phase est plus courte et
focalisée sur la planification des incréments futurs du système. Elle dure entre 2 et 4
semaines de travail pour l’équipe.
b) Le framework SAFE
Le framework SAFE définit trois niveaux de gestion de projets logiciels : les niveaux Équipe,
Programme et Portefeuille.
En termes de gestion de projets logiciels, le niveau Équipe décrit le mode de fonctionnement
d'une équipe agile de développement logiciel. Les pratiques managériales se résument au cadre
Scrum. En d'autres termes, l'équipe agile fonctionne et gère les exigences de son produit en
suivant les principes, les rôles et la démarche définis par la méthode Scrum.
IV.4.2 Vue d'ensemble du cadre de gestion de projets d'équipes agiles « Scrum »
Scrum est un cadre de développement et de maintenance à l’intérieur duquel les personnes
peuvent traiter (ou même résoudre) des problèmes changeants et complexes, tout en livrant de
manière productive et créative des produits de la plus haute valeur possible.
Scrum est un cadre de travail qui a été employé pour gérer le développement de produit
complexe depuis le début des années 1990. Scrum n’est pas une procédure ou une technique
pour construire des produits ; il s’agit plutôt d’un cadre à l’intérieur duquel vous pouvez utiliser
des procédures et des techniques variées. Scrum met en évidence l’efficacité relative de vos
pratiques de gestion et de développement de produit afin que vous puissiez les améliorer.
Scrum est un cadre de travail qui a été employé pour gérer le développement de produit
complexe depuis le début des années 1990. Scrum n’est pas une procédure ou une technique
pour construire des produits ; il s’agit plutôt d’un cadre à l’intérieur duquel vous pouvez utiliser
des procédures et des techniques variées. Scrum met en évidence l’efficacité relative de vos
pratiques de gestion et de développement de produit afin que vous puissiez les améliorer.
Les éléments essentiels de Scrum sont :
• Le sprint : Un sprint est une courte itération ayant une durée fixée.

Page 53
 • Les 4 types de réunions : la planification d’un sprint, la mêlée quotidienne, la revue d’un
sprint et la rétrospective.
• Les 3 documents ou artefacts : le carnet de produit, le carnet de sprint et l'incrément.
• Les 3 rôles : le Propriétaire du produit, le Scrum Master et l’Équipe de développement.
Le contenu de cette section du cours est une adaptation de la traduction française réalisée
à partir de la version originale du document de référence de Scrum publié par Ken Schwaber et
Jeff Sutherland, les co-auteurs de Scrum.
a) Le cadre Scrum
Le cadre Scrum inclut les équipes Scrum ainsi que leurs rôles, événements, artefacts et
règles associés. Chacun de ces éléments répond à un but spécifique et est essentiel à l’utilisation
et au succès de Scrum.
Les stratégies spécifiques pour l’utilisation du cadre Scrum varient. Les règles de Scrum
lient ensemble les rôles, les événements et les artefacts et régissent les relations et les
interactions entre eux.
b) La théorie de Scrum
Scrum est fondé sur la théorie de contrôle des processus empiriques. Cette théorie affirme
que la connaissance s’acquiert par l’expérience et favorise la prise de décision basée sur ce qui
est connu. Scrum utilise une approche itérative et incrémentale pour optimiser la prévisibilité
et le contrôle des risques.
Toute implémentation de contrôle de processus empirique s’appuie sur les trois piliers
suivants : la transparence, l’inspection et l’adaptation.
1. La transparence : Les aspects importants du processus doivent être visibles par ceux
qui sont responsables du résultat. La transparence requiert que ces aspects soient
définis par un standard commun afin que les observateurs partagent une compréhension
commune de ce qui est vu. Par exemple, Un langage commun se référant au processus
doit être partagé par tous les participants.
2. L'inspection : Les utilisateurs de Scrum doivent régulièrement passer en revue les
artefacts et l’état d’avancement par rapport aux objectifs afin de détecter les écarts
indésirables. La fréquence de ces revues ne doit cependant pas gêner les travaux de
l’équipe. Les revues les plus efficaces sont celles menées par des contrôleurs
expérimentés sur le site de travail de l’équipe.
3. L'adaptation : Si la personne qui contrôle détermine qu’un ou plusieurs aspects d’un
processus sortent des limites acceptables et que le produit résultant sera inacceptable,
le processus ou le matériel en cours de traitement doit être ajusté. Un ajustement doit
être effectué dès que possible afin de minimiser d’autres écarts. Scrum prescrit quatre
occasions formelles pour l’inspection et l’adaptation : planification de sprint, mêlée
quotidienne (daily sprint), revue de sprint (sprint review), rétrospective de sprint (
sprint retrospective).
c) L'équipe Scrum
L’équipe Scrum est constituée d’un propriétaire de produit, de l’équipe de développement et
d’un Scrum Master. Les équipes Scrum sont auto-organisées et pluridisciplinaires. Des équipes
auto-organisées choisissent la meilleure manière de réaliser leur travail, plutôt que d’être
dirigées par des personnes extérieures à l’équipe. Des équipes pluridisciplinaires ont toutes les
compétences nécessaires pour réaliser le travail sans dépendre de personnes ne faisant pas
partie de l’équipe. Le modèle d’équipe de Scrum est conçu pour optimiser la flexibilité, la
créativité et la productivité.

Page 54
 Les équipes Scrum livrent des produits de façon itérative et incrémentale, maximisant ainsi
les possibilités de rétroaction. Des livraisons incrémentales d’un produit « terminé » assurent
aussi qu’une version potentiellement utile du produit est toujours fonctionnelle et disponible.
Dans les conditions idéales, elle est disponible à plein temps et travaille au même endroit.
Elle a la responsabilité de sélectionner les exigences à réaliser dans un sprint et ainsi
d’atteindre le but du sprint. Elle est collectivement responsable de la réalisation de l’objectif
fixé et de démontrer le bon fonctionnement du nouvel incrément du produit à la fin d’un sprint.
c.1) Le propriétaire du produit
Le propriétaire de produit est chargé de maximiser la valeur du produit et du travail de
l’équipe de développement. Cela se concrétise d’une manière qui varie considérablement selon
les organisations, les équipes Scrum et les individus.
Le propriétaire de produit est la seule personne responsable de la gestion du carnet de
produit. La gestion du carnet de produit comprend : (1) exprimer clairement les items du carnet
de produit, (2) hiérarchiser les items du carnet de produit pour mieux atteindre les objectifs
et les missions, (3) s’assurer de la valeur du travail que l’équipe de développement réalise, (4)
s’assurer que le carnet de produit est visible, transparent et clair pour tous et qu’il décrit bien
le travail à venir pour l’équipe Scrum, (5) s’assurer que l’équipe de développement comprend
suffisamment les items du carnet de produit.
Le propriétaire de produit peut faire le travail ci-dessus ou le faire réaliser par l’équipe de
développement. Toutefois, le propriétaire de produit en demeure responsable.
Le propriétaire de produit est une personne, et non un comité. Le propriétaire de produit
peut représenter les objectifs d’un comité dans le carnet de produit, mais les membres du
comité qui veulent modifier la hiérarchie d’un item du carnet doivent en convaincre la personne
agissant comme propriétaire de produit.
Pour que le propriétaire de produit réussisse, toute l’organisation doit respecter ses
décisions. Ses décisions se traduisent par le contenu et par la hiérarchisation du carnet de
produit. Personne ne peut demander à l’équipe de développement de travailler sur un ensemble
d’items différents, et l’équipe de développement n’est pas autorisée à travailler sur les
demandes de quelqu’un d’autre.
Le propriétaire du produit est responsable de la création et de la définition des priorités
du carnet du produit. Tout le monde peut contribuer au carnet du produit, mais le propriétaire
du produit a toujours le dernier mot quant à ce qui est prioritaire ou ce qui ne l’est pas.
c.2) L'équipe de développement
L’équipe de développement est composée de professionnels qui livrent à chaque sprint un
incrément « terminé » et potentiellement livrable du produit. Seuls les membres de l’équipe de
développement réalisent l’incrément.
Les équipes de développement sont structurées et habilitées par l’organisation à organiser
et gérer leur propre travail. Les synergies qui en résultent permettent d’optimiser l’efficacité
globale des équipes de développement. Les équipes de développement ont les caractéristiques
suivantes :
• Elles sont auto-organisées. Personne (pas même le Scrum Master) ne peut dicter à
l’équipe comment traduire le carnet de produit en incréments de fonctionnalités
potentiellement livrables ;
• Elles sont pluridisciplinaires, ayant toutes les compétences nécessaires pour mettre en
œuvre
• un incrément du produit ;

Page 55
 • Scrum ne reconnaît aucun autre titre, pour les membres de l’équipe de développement,
que celui de développeur, indépendamment du travail réalisé par la personne ; il ne peut
y avoir aucune exception à cette règle ;
• Individuellement, les membres d’une équipe peuvent être spécialisés dans certaines
compétences ou dans certains domaines, mais la responsabilité appartient à l’équipe de
développement dans son ensemble ; et,
• Les équipes de développement ne contiennent pas de sous-équipes dédiées à un domaine
en particulier comme les tests ou l’analyse métier (fonctionnelle).
Une équipe de développement de taille optimale est assez petite pour demeurer agile et
assez grande pour effectuer du travail significatif. Moins de trois membres dans l’équipe de
développement diminue les interactions et entraîne des gains de productivité moindres. Une
équipe de développement trop petite peut rencontrer des contraintes de compétences pendant
le sprint, menant l’équipe à être incapable de terminer un incrément potentiellement livrable.
Plus de neuf membres exige trop de coordination. Les grandes équipes de développement
génèrent trop de complexité pour être gérées par un processus empirique. Les rôles de
propriétaire de produit et de Scrum Master ne sont pas inclus dans ce nombre, sauf s’ils
participent également à la réalisation des travaux du carnet de sprint.
c.3) Le Scrum Master
Le Scrum Master est responsable de la compréhension et de l’application de Scrum. Pour
cela il ou elle s’assure que l’équipe Scrum adhère aux valeurs, pratiques et règles de Scrum. Le
rôle de Scrum Master est celui de meneur au service de l’équipe (Servant Leader).
Le Scrum Master aide les personnes extérieures à l’équipe Scrum à comprendre lesquelles
de leurs interactions sont utiles et lesquelles ne le sont pas. Le Scrum Master apporte son aide
pour changer ces interactions afin de maximiser la valeur créée par l’équipe Scrum.
Le Scrum Master sert le propriétaire de produit de plusieurs façons, notamment : en
trouvant des techniques pour la gestion efficace du carnet de produit, en communiquant
clairement la vision, les objectifs et les items du carnet de produit à l’équipe de développement,
en enseignant à l’équipe de développement comment créer des items de carnet clairs et concis,
en comprenant la planification à long terme du produit dans un environnement empirique, en
comprenant et pratiquant l’agilité, en facilitant les évènements Scrum à la demande ou lorsque
c’est nécessaire.
Le Scrum Master sert l’équipe de développement de plusieurs façons, notamment : en aidant
l’équipe de développement à apprendre comment s’auto-organiser et développer sa
transversalité, en enseignant et en menant l’équipe de développement à livrer des produits de
haute valeur, en supprimant les obstacles nuisant au progrès de l’équipe de développement, en
facilitant des événements Scrum à la demande ou lorsque c’est nécessaire, en accompagnant
l’équipe de développement dans les environnements organisationnels dans lesquels Scrum n’est
pas encore complètement adopté et compris.
Le Scrum Master sert l’organisation de plusieurs façons, notamment : en menant et en
accompagnant l’organisation dans ses efforts d’adoption de Scrum, en planifiant des mises en
œuvres de Scrum au sein de l’organisation, en aidant les employés et les parties prenantes à
comprendre et à adopter Scrum ainsi que le développement empirique de produits, en
provoquant le changement qui est susceptible d’accroître la productivité de l’équipe Scrum, en
travaillant avec d’autres Scrum Master dans le but d’accroître l’efficacité de l’application de
Scrum au sein de l’organisation.

Page 56
IV.4.3 Les événements ou réunions Scrum
Des événements prescrits sont utilisés dans Scrum afin de créer de la régularité et de
minimiser la nécessité de réunions qui ne sont pas définies dans Scrum. Scrum utilise des
événements à durée déterminée. Chaque évènement a ainsi une durée maximale. Cela garantit
qu’une quantité appropriée de temps est utilisée à la planification sans mener à des pertes dans
le processus de planification.
En plus du sprint qui sert de contenant pour tous les autres événements, chaque événement
dans Scrum représente une occasion d’inspecter et d’adapter quelque chose. Ces événements
sont spécifiquement conçus pour permettre la transparence, l’inspection et l’adaptation.
Omettre d’inclure un de ces événements mène à une réduction de la transparence et une
occasion perdue d’inspection et d’adaptation.
a) Le sprint
Le cœur de Scrum est un sprint : un bloc de temps d’un mois ou moins durant lequel un
incrément du produit « terminé », utilisable et potentiellement livrable est réalisé. Les sprints
ont une durée constante durant l’effort de développement. On peut donc dire qu’un sprint est
une courte itération ayant une durée fixée. Un nouveau sprint démarre dès que le sprint
précédent est terminé.
Les sprints sont constitués d’une réunion de planification, de mêlées quotidiennes, de
périodes de développement, d’une revue de sprint et d’une rétrospective de sprint.
Pendant le sprint :
• aucun changement qui affecterait l’objectif du sprint n’est permis,
• la composition de l’équipe de développement et les objectifs de qualité restent
inchangés,
• le contenu du sprint peut être affiné et faire l’objet d’une renégociation entre le
propriétaire de produit et l’équipe de développement suite à de nouvelles connaissances.
Chaque sprint peut être vu comme un projet d’au maximum un mois. A l’instar des projets,
les sprints servent à réaliser quelque chose. Chaque sprint est composé d’une définition de ce
qui doit être construit, d’une planification souple indiquant comment le construire, du travail
fait pour le construire et du produit résultant.
La durée maximale des sprints est d’un mois calendaire. Si l’horizon d’un sprint est trop
éloigné, la définition de ce qui est construit peut changer, la complexité peut s’accroître et les
risques augmenter. Les sprints permettent d’obtenir une bonne prévisibilité en garantissant une
évaluation et une adaptation (au pire) mensuelle de l’état d’avancement par rapport à l’objectif.
Les sprints limitent également le risque financier à un mois calendaire.
Un sprint peut être annulé avant la fin de son bloc de temps. Seul le propriétaire de produit
possède le droit d’annuler le sprint, même si il ou elle peut le faire à la demande des parties
prenantes, de l’équipe de développement, ou de la personne agissant comme Scrum Master.
Un sprint devrait être annulé lorsque son but devient désuet. Cela pourrait se produire si
l’organisation changeait d’orientation ou si le marché ou les conditions technologiques venaient
à changer. Cependant, en raison de la courte durée des sprints, l’annulation d’un sprint est plutôt
rare.
Quand un sprint est annulé, tous les items de carnet de produit « terminés » sont passés en
revue. Si une partie du travail est potentiellement livrable, le propriétaire doit généralement
l’accepter. Tous les items incomplets du carnet de produit doivent être ré-estimés et remis
dans le carnet de produit. Le travail effectué sur ces derniers déprécie rapidement et doit être
fréquemment ré-estimé.

Page 57
 L’annulation d’un sprint consomme des ressources, puisque tout le monde doit se regrouper
dans une nouvelle rencontre de planification de sprint afin de démarrer un nouveau sprint.
L’annulation d’un sprint est souvent traumatisante pour l’équipe Scrum et n’est pas une pratique
fréquente.

b) La planification d'une release

Figure 18: Le processus de planification d'une release dans le cadre

Scrum.

Il y a trois approches pour déterminer la vitesse de développement initiale. Par ordre de

préférence, on a :
• Exécuter 2 ou 3 sprints et mesurer la vitesse moyenne ;
• Utiliser des données historiques pour estimer la vitesse moyenne ;
• Simuler la planification d’un sprint et estimer combien de fonctionnalités peuvent être
livrées en un sprint.
Après l’exécution de chaque sprint, l’expérience acquise permet d’affiner le plan initial de
la release. L’unité d’estimation des fonctionnalités du backlog est le Sorty Points.
c) La réunion de planification d'un sprint (Sprint planning meeting)
Les travaux à effectuer durant le sprint sont planifiés lors de la réunion de planification de
sprint. Ce plan est créé par la collaboration de toute l’équipe Scrum.
La réunion de planification de sprint est un bloc de temps de huit heures pour un sprint d’un
mois. Pour des sprints plus courts, la réunion est proportionnellement plus courte. Par exemple,
des sprints de deux semaines ont une réunion de planification de quatre heures.
La réunion de planification de sprint se compose de deux parties, chacune utilisant la moitié
du temps total alloué pour la planification. Les deux parties de la réunion de planification de
sprint répondent aux questions suivantes : Qu’est-ce qui sera livré dans l’incrément résultant
du prochain sprint ? Comment le travail nécessaire pour réaliser l’incrément sera-t-il accompli
?
c.1) 1ère partie : Qu'est-ce qui sera livré dans l'incrément résultant du prochain sprint ?
Dans cette partie, l’équipe de développement choisit les fonctionnalités qui seront livrées
au cours du sprint.
Le propriétaire de produit présente à l’équipe de développement les items hiérarchisés du
carnet de produit et toute l’équipe Scrum travaille alors ensemble sur la compréhension du
travail à effectuer dans le sprint.
Les éléments requis pour cette réunion sont le carnet de produit, le dernier incrément de
produit, la capacité estimée de l’équipe de développement pour le sprint, ainsi que sa
performance passée. Le choix du nombre d’items sélectionnés pour le sprint à partir du carnet
de produit relève entièrement de l’équipe de développement. Seule l’équipe de développement
est en mesure d’évaluer ce qu’elle peut accomplir durant le prochain sprint.
Suite à la planification des items du carnet de produit que l’équipe de développement livrera
durant le sprint, l’équipe Scrum élabore un objectif de sprint. L’objectif de sprint sera atteint
durant le sprint par la réalisation du carnet de produit. Cet objectif donne à l’équipe de
développement du sens à la réalisation de l’incrément.

Page 58
c.2) 2e partie : Comment le travail sélectionné sera-t-il accompli ?
Après avoir choisi le travail du sprint, l’équipe de développement décide comment elle va
réaliser, durant le sprint, un incrément de produit « terminé ». Les items sélectionnés du carnet
de produit pour ce sprint ainsi que le plan pour les livrer est appelé le carnet de sprint.
L’équipe de développement commence généralement par concevoir le système et le travail
nécessaire afin de convertir le carnet de produit en un incrément livrable. La taille ou l’effort
estimé du travail peut varier. Cependant, suffisamment de travail doit être prévu lors de la
réunion de planification de sprint pour que l’équipe de développement puisse anticiper ce qu’elle
pense pouvoir accomplir durant le sprint. Le travail prévu pour les premiers jours du sprint doit
être décomposé en tâches d’une journée ou moins avant la fin de la réunion. L’équipe de
développement s’auto-organise pour consigner les travaux dans le carnet de sprint, à la fois lors
de la réunion de planification de sprint et quand cela est nécessaire tout au long du sprint.
Le propriétaire de produit peut être présent lors de la deuxième partie de la réunion de
planification de sprint pour clarifier les items sélectionnés du carnet de produit et afin de
contribuer à trouver des compromis. Si l’équipe de développement détermine qu’elle a trop de
travail, ou bien qu’elle n’en a pas assez, elle peut renégocier avec le propriétaire de produit les
items du carnet de sprint. L’équipe de développement peut également inviter d’autres personnes
à la réunion afin de fournir des conseils techniques ou sur le domaine.
À la fin de la réunion de planification de sprint, l’équipe de développement devrait être en
mesure d’expliquer aux propriétaire de produit et Scrum Master comment elle entend travailler
en tant qu’équipe auto-organisée pour atteindre l’objectif de sprint et livrer l’incrément prévu.
c.3) Objectif de sprint
L’objectif de sprint donne à l’équipe de développement une certaine latitude vis à vis des
fonctionnalités à réaliser durant le sprint.
Tout au long du sprint, l’équipe de développement garde l’objectif en tête. Cet objectif guide
le travail de l’équipe, tant au niveau fonctionnel que technologique. Si l’équipe de développement
découvre pendant le sprint que le travail à faire pour atteindre cet objectif diffère du travail
envisagé, alors elle collabore avec le propriétaire de produit pour redéfinir le carnet de sprint.
L’objectif de sprint peut, par exemple, être un sous-objectif d’une stratégie plus globale de
livraison du produit.
d) La mêlée quotidienne (Daily scrum)
La mêlée quotidienne est une réunion limitée à un bloc de temps de 15 minutes et destinée à
permettre à l’équipe de développement de synchroniser ses activités et planifier les prochaines
24 heures. Pour ce faire, le travail réalisé depuis la dernière mêlée quotidienne est inspecté et
une prévision du travail qui pourra être réalisé avant la prochaine mêlée est énoncée.
La mêlée quotidienne a lieu tous les jours à la même heure et au même endroit afin de réduire
la complexité. Pendant la réunion chaque membre de l’équipe de développement décrit :
1. ce qu’il a réalisé depuis la dernière
réunion,
2. ce qu’il réalisera avant la prochaine
réunion,
3. les difficultés qu’il rencontre.
L’équipe de développement se sert de la mêlée quotidienne pour évaluer l’atteinte de
l’objectif du sprint ainsi qu’évaluer comment se fait la progression vers la finalisation du travail
du carnet de sprint. La mêlée quotidienne optimise la probabilité d’atteinte des objectifs du
sprint par l’équipe de développement. Celle-ci se réunit souvent juste après la mêlée quotidienne
pour mettre à jour la planification du travail restant dans le sprint. Tous les jours, l’équipe de

Page 59
développement doit être capable d’expliquer aux propriétaire de produit et Scrum Master
comment elle compte s’organiser, en tant qu’équipe auto-organisée, pour atteindre l’objectif et
réaliser les fonctionnalités attendues.
Le Scrum Master s’assure que la mêlée quotidienne a lieu mais c’est l’équipe de
développement qui est responsable du déroulement de la réunion. Le Scrum Master apprend à
l’équipe de développement comment limiter la mêlée quotidienne à un bloc de temps de 15
minutes.
Le Scrum Master veille à l’application de la règle stipulant que seuls les membres de l’équipe
de développement participent à la mêlée quotidienne. La mêlée quotidienne n’est pas une réunion
d’avancement et est destinée aux personnes en charge de transformer les items du carnet de
produit en fonctionnalités livrables.
Les mêlées quotidiennes améliorent la communication, réduisent le nombre de réunions,
identifient et suppriment les obstacles qui perturbent le développement, mettent en avant et
encouragent la prise de décision rapide et améliorent la compréhension du projet par l’équipe
de développement. Il s’agit d’une réunion d’inspection et d’adaptation primordiale.
d) La revue de sprint (Sprint review)
La rétrospective de sprint est une occasion pour l’équipe Scrum de s’inspecter et de créer
un plan d’améliorations qui sera mis en place au cours du sprint suivant.
La rétrospective de sprint survient après la revue de sprint et avant la prochaine réunion de
planification de sprint. Pour un sprint d’un mois, cette rencontre est limitée à un bloc de temps
de trois heures. La rétrospective des sprints plus courts a une durée proportionnellement plus
courte.
Le but de la rétrospective de sprint est :
• d’inspecter la manière dont le dernier sprint s’est déroulé en ce qui concerne les
personnes, les relations, les processus et les outils ;
• d’identifier et ordonner les éléments majeurs qui se sont bien déroulés et les
améliorations potentielles ;
• de créer un plan pour améliorer les processus de travail de l’équipe Scrum.
Le Scrum Master encourage l’équipe Scrum à améliorer, dans le cadre du processus Scrum,
son processus de développement et ses pratiques afin de les rendre plus efficaces et agréables
pour le prochain sprint. Lors de chaque rétrospective de sprint, l’équipe Scrum planifie des
moyens adéquats d’accroître la qualité du produit, en adaptant sa définition de « terminé ».
À la fin de la rétrospective de sprint, l’équipe Scrum devrait avoir identifié les améliorations
qu’elle mettra en œuvre durant le prochain sprint. La mise en œuvre de ces améliorations au
cours du prochain sprint est l’adaptation à l’inspection de l’équipe de développement elle- même.
Bien que des améliorations puissent être mises en œuvre à tout moment, la rétrospective de
sprint fournit un événement dédié et axé sur l’inspection et l’adaptation.
IV.4.4 Les artefacts produits par l'équipe Scrum
Les artefacts de Scrum représentent du travail ou de la valeur de diverses manières, de
telle sorte qu’ils fournissent de la transparence et des opportunités pour l’inspection et
l’adaptation. Les artefacts définis par Scrum sont spécifiquement élaborés pour maximiser la
transparence sur les informations essentielles requises pour garantir la réussite des équipes
Scrum à livrer un incrément « terminé ».
a) Le carnet de produit (Product backlog)
Le carnet de produit est une liste ordonnée de tout ce qui est pourrait être requis dans le
produit, et il est la source unique des besoins pour tous les changements à effectuer sur le

Page 60
produit. Le propriétaire de produit est responsable de ce carnet, de son contenu, de sa
publication ainsi que de l’ordonnancement des items qu’il contient.
Le carnet de produit n’est jamais terminé. Ses premières versions contiennent uniquement
les besoins identifiés initialement et les mieux compris. Le carnet de produit évolue au fur et à
mesure que le produit et l’environnement dans lequel il sera utilisé évoluent. Le carnet de produit
est dynamique ; il change constamment pour refléter ce que le produit requiert pour être
compétitif et utile. Tant que le produit existera, le carnet de produit correspondant existera.
Le carnet de produit liste toutes les fonctionnalités, besoins, améliorations et correctifs
qui correspondent aux changements qui doivent être appliqués au produit lors de livraisons
futures. Les items du carnet possèdent une description, un ordre et une estimation.
Le carnet de produit est fréquemment ordonné en fonction de la valeur, du risque, de la
priorité et de la nécessité de ses items. Les items les plus élevés dans l’ordre doivent être
traités immédiatement du point de vue des activités de développement. L’ordre le plus élevé
indique la considération la plus élevée, et également que l’item a le consensus le plus élevé quant
à sa valeur.
Les items les plus hauts dans le carnet sont également plus clairs et détaillés que les items
moins élevés. Des estimations plus précises sont élaborées grâce à une plus grande clarté et un
niveau de détail accru. Les items qui vont occuper les prochains sprints sont suffisamment
détaillés et décomposés de façon à ce que chacun puisse être « terminé » par l’équipe de
développement à l’intérieur d’un seul sprint. Ces items sont alors qualifiés de « prêt » ou «
actionnable » pour être sélectionnés lors de la rencontre de planification de sprint.
À mesure qu’un produit est utilisé, que sa valeur augmente et que l’on commence à recevoir
des retours sur son utilisation, le carnet de produit grossit et devient plus exhaustif. Les
besoins évoluent continuellement et n’arrêtent jamais de changer, ce qui fait du carnet de
produit un document vivant. Les changements au niveau des besoins utilisateurs, des conditions
du marché ou de la technologie peuvent impacter le carnet de produit.
Il arrive souvent que de multiples équipes Scrum travaillent ensemble sur le même produit.
Un seul carnet de produit est utilisé pour décrire le travail à venir pour un produit. On peut
alors ajouter une propriété aux items du carnet pour les regrouper.
La préparation du carnet de produit se fait en ajoutant les détails, estimés et ordre aux
items du carnet. Cette préparation est un processus continu dans lequel le propriétaire de
produit et l’équipe de développement collaborent pour définir les détails des items du carnet
de produit. Bien que les items soient révisés pendant une rencontre de préparation, ils peuvent
être mis à jour en tout temps par le propriétaire de produit, à son entière discrétion.
La préparation est une activité à temps partiel qui a lieu à l’intérieur du sprint, et qui
réunit le propriétaire de produit et l’équipe de développement. Souvent, l’équipe de
développement possède les connaissances nécessaires pour effectuer la préparation elle-
même. Le moment de la préparation et la méthode utilisée pour la réaliser sont décidés par
l’équipe de développement. La préparation ne prend pas plus de 10.
L’équipe de développement est responsable de tous les estimations. Le propriétaire de
produit peut influencer l’équipe en l’aidant dans sa compréhension et aux décisions
d’implémentation, mais les personnes qui effectuent le travail ont le mot final sur les
estimations.
À tout moment, le travail global restant pour atteindre l’objectif peut être calculé. Le
propriétaire de produit suit la progression de ce travail global restant au moins à chaque revue
de sprint. Cette personne compare cette quantité au travail restant lors des revues de sprint

Page 61
précédentes pour estimer le progrès vers la complétion du travail planifié dans le temps voulu
pour l’objectif. Cette information est rendue transparente pour toutes les parties prenantes.
Scrum ne prend pas en compte le temps passé à travailler sur les items du carnet de produit.
Le travail restant et la date sont les seules variables prises en compte.
Diverses mesures de progression, régression et autres pratiques de projection ont été
utilisées pour prévoir la progression. Elles ont prouvé leur utilité. Cependant, elles ne remplacent
pas l’importance de l’empirisme. Dans des environnements complexes, ce qui va se passer est
inconnu. Seul ce qui s’est passé peut être utilisé pour la prise de décision prospective.
b) Le carnet de sprint (Sprint backlog)
Le carnet de sprint est l’ensemble des items choisis pour le sprint en plus d’un plan pour les
réaliser dans le cadre d’un incrément de produit qui concrétisera l’objectif du sprint. Le carnet
est une prévision de ce que l’équipe de développement croit être en mesure de livrer dans le
prochain incrément de produit ainsi que le détail du travail qui devra être fait pour y arriver.
Le carnet de sprint défini le travail que l’équipe de développement devra effectuer pour que
les items du carnet de produit soient considérés comme « terminés ». Le carnet de sprint
permet de visualiser tout le travail nécessaire pour réaliser l’objectif du sprint.
Le carnet de sprint est un plan suffisamment détaillé pour que la progression de l’équipe soit
claire lors de la mêlée quotidienne. Le carnet de sprint est continuellement mis à jours par
l’équipe de développement. Il émerge durant le sprint. Cette émergence se produit lorsque
l’équipe exécute le plan et découvre ce qui est nécessaire pour atteindre l’objectif du sprint.
À mesure que du nouveau travail est découvert, l’équipe l’ajoute au carnet de sprint. Lorsque
le travail est effectué ou terminé, les estimés du travail restant sont mis à jours. Lorsque des
items du plan sont considérés comme n’étant plus nécessaires, ils sont retirés. Seul l’équipe de
développement peut changer le carnet de sprint pendant un sprint. Le carnet de sprint est une
vue en temps-réel et très visible du travail que l’équipe doit accomplir durant le sprint. L’équipe
de développement en est la seule propriétaire.
À n’importe quel moment d’un sprint, la quantité totale de travail restant dans le carnet de
sprint peut être additionnée. L’équipe de développement fait le suivi de cette quantité totale
de travail restant au moins à chaque Scrum journalier. L’équipe de développement fait le suivi
de ces totaux à tous les jours et évalue la probabilité que le but du sprint soit atteint. En faisant
le suivi du travail restant tout au long du sprint, l’équipe de développement peut gérer sa
progression.
Scrum ne considère pas le temps déjà passé à travailler sur des items du carnet de sprint.
Le travail restant et la date sont les seules variables dignes d’intérêt.
Différents graphiques de progression ont traditionnellement été utilisés pour effectuer des
prédictions d’avancement. Ces outils se sont révélés être utiles. Cependant, ils ne peuvent pas
remplacer le processus empirique. Dans des environnements complexes, le futur est incertain.
Seul ce qui s’est passé devrait être utilisé pour prendre des décisions concernant le futur.
c) L'incrément
L’incrément est la somme de tous les items du carnet de produit terminés pendant un sprint,
additionné de tous les items terminés des sprints précédents. A la fin d’un sprint, le nouvel
incrément doit être « terminé ». Ceci signifie qu’il doit être dans un état utilisable et être en
accord avec la définition du « terminé » tel qu’établi par l’équipe Scrum. Il doit être dans un
état utilisable, sans égard à la décision du ou de la propriétaire de produit de le rendre
disponible ou non.

Page 62
IV.4.5 Quelques limites de la planification agile
Une difficulté majeure dans la planification agile est qu’elle repose sur la disponibilité et
l’implication du client. Dans certains cas, cela peut être difficile à obtenir. Par exemple, dans
nos entreprises congolaises où le personnel ne sait que très peut de l’informatisation, il est
difficile de le mobiliser dans un projet. De même, des employés très occupés à travailler du
matin au soir, n’ont pas vraiment le temps de s’impliquer à ce point.
Sommerville (2011) conclut que les approches agiles sont adaptées à des équipes petites et
stables et à des projets de petite envergure. Néanmoins, Leffingw (2011) propose un cadre
conceptuel et méthodologique permettant d’appliquer des approches agiles dans des projets de
moyenne, grande et très grande envergures.

Page 63
 Chapitre V.
LA CONCEPTION DU LOGICIEL

Ce chapitre poursuit les objectifs suivants :

1. Définir les concepts de base et donner les principes fondamentaux de la conception du
logiciel ;
2. Présenter des outils et des techniques de la conception de l'architecture, de l'interface
utilisateur et des composants du logiciel.
3. Montrer la mise en œuvre de ces outils et techniques.

À l'issue du cours, l'étudiant devrait être en mesure de :

1. Définir et comprendre les concepts de base et comprendre les principes fondamentaux
de la conception du logiciel ;
2. Mettre en œuvre les outils et les techniques de base de la conception de l'architecture,
de l'interface utilisateur et des composants du logiciel.
V.1 Définition de concepts, notions et principes
Le glossaire IEEE 610.12-1990 définit la conception comme (1) le processus consistant à
définir l’architecture, les composants, les interfaces et d’autres caractéristiques d’un système
ou d’un composant et (2) le résultat même de ce processus. Vue comme un processus du cycle
de vie d'un logiciel, la conception est le processus de génie logiciel au cours duquel les exigences
logicielles sont analysées pour produire une description de la structure interne du logiciel, qui
servira de base à sa construction. Vue comme résultat du processus de conception, la conception
doit décrire l’architecture du logiciel, c’est-à-dire comment le logiciel est décomposé et
organisé en composants, et les interfaces entre ces composants. Elle doit mêmement décrire
chaque composant à un niveau de détails tel qu’il soit possible de le construire. De ce fait, on
admet généralement que la conception englobe deux activités intercalées dans le cycle de vie
entre l'ingénierie des exigences et la construction ( implémentation) du logiciel.
Le processus de conception du logiciel inclut deux activités : la conception de l'architecture,
appelée aussi architecturale, conception préliminaire, ou conception de haut niveau, ou encore
conception globale, et la conception des composants appelée aussi conception détaillée.
La conception du logiciel joue un rôle important dans le développement du logiciel : elle
permet aux ingénieurs du logiciel de produire des modèles variés à partir desquels on peut se
former une idée assez précise de la solution à implémenter. Ces modèles sont analysés et évalués
afin de déterminer si la solution conçue permet de satisfaire les exigences. Il est aussi possible
d’évaluer des solutions alternatives et plusieurs compromis. Enfin, on pourra utiliser les
différents modèles pour planifier les activités subséquentes de développement, autres que la
construction et le test.
V.1.1 Définition de concepts
Les concepts clés de la conception logicielle sont : le composant, l’interface, le module et
l'architecture. Tous les principes fondamentaux de la conception sont tournent autour de ces
concepts. Le glossaire IEEE 610.12-1990 en donne les définitions les plus couramment admises.
a) Le composant et le module
Un composant logiciel est une unité indépendante du logiciel, ayant des interfaces et des
dépendances bien définies et qui peut être réalisé et déployé indépendant. Un module est :
1. une unité de programme qui est discrète et identifiable par rapport à la compilation, à
la combinaison avec d’autres unités et au chargement ou

Page 64
 2. une partie logiquement séparable d’un programme.
Une interface est une frontière commune entre composants ou modules à travers laquelle
les échanges d’information peuvent avoir lieu. Elle spécifie les services offerts, les services
requis et les structures ou types de données échangés. Concrètement, au niveau modulaire un
service offert/rendu désigne une fonction ou une méthode de classe publique accessible par
d’autres modules. Ces fonctions/méthodes prennent en paramètres et retournent en résultat
des données de types également accessibles par d’autres modules. L’interface est l’ensemble
constitué de ces fonctions/méthodes publiques et types de données d’échange. Au niveau des
composants, l’interface d’un composant est l’ensemble des interfaces de ses modules.
En programmation procédurale, un module est généralement un jeu de fonctions et
procédures logiquement cohérentes. En C, on sépare l’interface dans un fichier d’entête .h et
l’implémentation dans un fichier source .c ou autre extension. On a, par exemple, le module «
math » des fonctions mathématiques et structures de données associées, le module « string »
des fonctions de traitement de chaînes de caractères et structures de données associées, etc.
En Pascal, un module est une unité .pas ; l’interface et l’implémentation sont incluses dans ce
même fichier.
Dans les langages à objets (C++, Java, PHP, C#, VB.Net, ...), un module correspond à une
classe dont l’interface et l’implémentation peuvent être ou non séparées en deux fichiers.
Par exemple, en C++, on a les fichiers d’interface .h, .hpp, .hxx et les fichiers
d’implémentation .cpp, .cxx ; en Java, on n’a que le fichier de code source .java, en C# le
fichier de code source .cs, en PHP le fichier de code source .php et en VB.Net le fichier de
code source .vb.
On notera que les termes composant, module et unité sont souvent utilisés de manière
interchangeable ou définis comme sous-éléments les uns des autres selon le contexte vue que
leurs relations ne sont pas normalisées. Ici, nous considérons qu’un logiciel est d’abord découpé
en composants, qui sont à leur tour découpés en modules ; les composants et modules sont, de
ce fait, des unités du logiciel.
Figure

19: Décomposition d'un logiciel en

composants et modules. b) L'architecture du logiciel
Le standard IEEE 1471 définit l’architecture d'un logiciel comme l’organisation
fondamentale d’un système incorporée dans ses composants, leurs interrelations, leurs relations
avec l’environnement et les principes qui guident toutes les tâches de conception et d’évolution
du logiciel. L’architecture logicielle définit donc la structure interne du logiciel ; c’est une
manière particulière de structurer et d’organiser les éléments internes d’un logiciel ou d’un
composant. Cependant, l’architecture omet tous les détails des composants qui ne sont pas
essentiels à la définition de leurs interactions avec les autres composants ; elle définit
uniquement les interfaces entre composants identifiés.

Page 65
V.1.2 Les principes fondamentaux de la conception du logiciel
Au sens général, un principe est une loi compréhensive et fondamentale, une considération
généralement admise. De manière spécifique, un principe de conception du logiciel est une notion
clé considérée comme fondamentales à plusieurs approches de conception.
Les principes fondamentaux de la conception du logiciel sont :
1. l’abstraction, le couplage et la cohésion,
2. la décomposition et la modularisation,
3. l’encapsulation et le masquage d’information,
4. la séparation entre l’interface et l’implémentation,
5. la suffisance, la complétude et l’état primitif ,
6. la séparation des préoccupations.
a) L'abstraction
L’abstraction est une vue d’un objet qui se focalise sur des informations pertinentes à une
finalité donnée et qui ignore les autres détails. C’est aussi processus de création d’une
abstraction telle que définie par le premier sens.
Dans le contexte de la conception logicielle, deux mécanismes clés d’abstraction sont le
paramétrage et la spécification.
La spécification conduit à trois types d’abstraction : l’abstraction procédurale, l’abstraction
de données et l’abstraction de contrôle (itération). L’abstraction de données est le processus
d’extraction des caractéristiques essentielles de données en définissant des types de données
ainsi que les caractéristiques fonctionnelles associées tout en ignorant les détails de
représentation. On appelle ces types types abstraits de données ; ils incluent les structures de
données composites, les classes d’objets et bien d’autres.
b) L'encapsulation/masquage d'information
L’encapsulation est une technique de développement qui consiste à isoler une fonction d’un
système ou un jeu de données d’un système ainsi que les opérations qui s’y rapportent dans un
module et à fournir une spécification précise de ce module.
Le masquage d’information est une technique de développement dans laquelle chaque
interface de module relève le moins de détails possible concernant le fonctionnement interne
du module et à empêche les modules environnants d’utiliser directement les informations et
fonctions internes au module qui ne sont pas incluses dans la spécification de son interface.
L’encapsulation/masquage d’information signifie grouper et empaqueter des éléments et les
détails internes d’une abstraction et les rendre inaccessibles. L’encapsulation va de pair avec
l’abstraction.
En programmation orientée objet, l’abstraction, l’encapsulation et le masquage d’information
sont mieux matérialisés grâce aux qualificateurs de visibilité public, protected, private, package
ou autres implémentés dans les langages tels que C++, Java, C#, PHP, VB.Net, etc.
c) La décomposition modulaire ou modularisation
Décomposer en modules signifie qu’un logiciel large est divisé en plusieurs parties plus
petites et indépendantes les unes des autres, chacune ayant un jeu de fonctionnalités et de
responsabilités précises. C’est le principe traditionnel de répartition des responsabilités.
d) La séparation des préoccupations
Le standard IEEE 1069-2009 définition une préoccupation comme un champ d’intérêt en
accord avec une conception logicielle, c’est-à-dire un aspect de la conception logicielle qui revêt
un intérêt particulier pour les concepteurs.
La séparation des préoccupations (separation of concerns en anglais) suggère que n’importe
quel problème complexe peut être plus facilement pris en charge s’il est subdivisé en éléments

Page 66
qu’il est possible de résoudre ou traiter indépendamment. Il en résulte plus de facilité et moins
de temps à résoudre le problème global. Ce principe est à l’origine de la stratégie traditionnelle
diviser pour régner.
e) Le couplage et la cohésion
Le couplage est défini comme une mesure de l’interdépendance entre les modules d’un
logiciel, alors que la cohésion est la mesure de la force d’association des éléments à l’intérieur
d’un module. Un slogan traditionnel est de toujours assurer un couplage faible et une cohésion
forte dans la conception d’un logiciel.
On distingue plusieurs types de cohésion : la cohésion par coïncidence, la cohésion
communicationnelle, la cohésion fonctionnelle, la cohésion logique, la cohésion procédurale, la
cohésion séquentielle et la cohésion temporelle.
1. La cohésion par coïncidence est une forme de cohésion dans laquelle les tâches
exécutées par un module logiciel n’ont pas de relation fonctionnelle avec entre elles.
2. La cohésion communicationnelle est un type de cohésion dans laquelle les tâches réalisées
par un module logiciel utilisent les mêmes données à l’input ou contribuent à la production
de mêmes données à l’output.
3. La cohésion fonctionnelle est un type de cohésion dans laquelle les tâches réalisées par
un module logiciel contribue toutes à l’exécution d’une seule fonction.
4. La cohésion logique est une forme de cohésion dans laquelle les tâches réalisées par un
module logiciel exécutent des fonctions logiquement similaires ; par exemple, le
traitement de différents types de données en input.
5. La cohésion procédurale est une forme de cohésion dans laquelle les tâches réalisées par
un module logiciel contribuent toutes à une procédure d’un programme donné ; c’est le
cas d’un processus d’itération ou de décision.
6. La cohésion séquentielle est un type de cohésion dans laquelle les outputs d’une tâche
réalisée par un module logiciel servent d’inputs à une autre tâche réalisée par le module.
7. La cohésion temporelle est un type de cohésion dans laquelle les tâches réalisées par un
module logiciel sont toutes requises à une étape particulière de l’exécution du
programme ; un exemple est celui d’un module contenant toutes les tâches d’initialisation
d’un programme.
De même, on distingue plusieurs types de couplage : couplage par environnement commun,
couplage de contenu, couplage de contrôle, couplage de données, couplage hybride et couplage
pathologique.
f) Séparation entre l'interface et l'implémentation
La séparation entre l’interface et l’implémentation d’un module ou d’un composant consiste à
le définir en spécifiant une interface publique connue des clients de ce module/composant qui
est séparé des détails d’implémentation. L’interface se limite à définir les services offerts par
le module au reste du logiciel, les services requis par le module des autres modules du logiciel
ainsi que les données échangées entre modules ; c’est le propre de l’implémentation de définir
comment fonctionnera le module ou le composant en interne afin de rendre ces services ou
produire ces données.
g) Suffisance, complétude et état primitif
Assurer la suffisance, la complétude et l’état primitif signifie qu’on doit s’assurer qu’un
composant logiciel ait toutes les caractéristiques importantes de l’abstraction qu’il réalise, mais
rien de plus.

Page 67
V.1.3 Les problèmes principaux de la pratique de la conception du logiciel
Les préoccupations majeures de la conception du logiciel dans la pratique se rapportent à la
concurrence, au contrôle et gestion des événements, à la persistance de données, à la
répartition des composants, à la gestion des erreurs et des exceptions et tolérance aux pannes,
à l'interaction et présentation et à la sécurité.
a) La concurrence
La concurrence est la possibilité d’exécuter, dans un logiciel, plusieurs processus applicatifs.
La préoccupation principale en termes de concurrence est de déterminer la meilleure façon de
décomposer le logiciel en processus, tâches et fils d’exécution (threads en anglais) sans porter
préjudice à l’efficacité globale, à l’atomicité, à la synchronisation et à l’ordonnancement.
b) Le contrôle et la gestion des événements
La préoccupation, ici, est de chercher comment organiser le flot de données et contrôle de
manière à prendre en charge les événements réactifs et temporels à travers divers mécanismes
tels que les gestionnaires d’événements d’interface graphique, l’invocation implicite ou les
fonctions de callback.
c) La persistance de données
Cette préoccupation s’intéresse aux possibilités de sauvegarde à long terme de données sans
complexifier l’accès à ces données par les programmes.
d) La répartition des composants
Cette préoccupation cherche à déterminer comment distribuer (répartir) le logiciel sur
plusieurs matériels et comment alors assurer la communication entre composants ainsi
distribués, comment utiliser les intergiciels ( middlewares) dans ces interactions.
e) La gestion des erreurs et des exceptions et la tolérance aux pannes
Cette préoccupation consiste à définir la meilleure approche permettant de prévenir et
tolérer les fautes à l’exécution d’un logiciel et prendre en charge les exceptions levées durant
son fonctionnement. f) L'interaction et la présentation
La majorité des logiciels conçus sont des systèmes interactifs, destinés à être utilisés par
des humains. Cette préoccupation chercher à déterminer comment structurer et organiser
efficacement les interactions hommemachine. Cette préoccupation est complémentaire à la
conception de l’interface utilisateur elle-même.
g) La sécurité
Cette préoccupation cherche à déterminer la meilleure approche permettant de prévenir
des opérations non autorisées sur les données sous la responsabilité du logiciel, comment tolérer
aux attaques et aux violations d’ordre sécuritaire en limitant les dommages, en assurant la
continuité des services, en optimisant les temps de réparation et rétablissement, etc. Le
contrôle des accès et le chiffrement sont des fondamentaux de toute stratégie de sécurité
logicielle.
V.2 Le processus de conception du logiciel

V.2.1 La conception de l'architecture du logiciel

Lorsqu’on doit définir l’architecture de son logiciel, on se posera une série de questions qui
permettront de prendre les bonnes décisions de conception architecturale. On se demandera,
notamment : Quelle approche fondamentale adopter pour structurer le logiciel en cours de
conception ? Y a-t-il une architecture générique susceptible d’être utilisée comme modèle pour
ce logiciel ? Y a-t-il des styles architecturaux utilisables dans le cas de ce logiciel ? Comment
le logiciel sera-t-il répartis sur les matériels (cœurs de processeurs en particulier) ? Comment
les macro composants seront-ils décomposés en micro composants ? Quelle stratégie sera
Page 68
utilisée pour contrôler le fonctionnement et l’interaction des composants du logiciel ? Quelle
organisation architecturale sera la plus adaptée à supporter les exigences non fonctionnelles
telles que la sécurité, les performances ou la disponibilité ? Comment la conception
architecturale sera-t-elle évaluée ? Comment l’architecture sera-t-elle modélisée et
documentée ?
a) Les caractéristiques d'une bonne architecture logicielle
Les caractéristiques d’une bonne architecture incluent les aptitudes telles que la modularité,
l’extensibilité, la résistance aux pannes, la simplicité, etc.
b) Les vues architecturales
P. Clements et al. (2010) définissent une vue comme la représentation d’un aspect partiel
d’une architecture d’un logiciel qui montre des propriétés spécifiques du système logiciel.
Il est impossible de représenter toutes les informations pertinentes concernant
l’architecture d’un logiciel au moyen d’un seul modèle, étant donné que chaque modèle ne montre
qu’une seule perspective du logiciel. Différentes facettes de haut niveau d’abstraction
devraient être décrites et documentées pour mieux visualiser l’architecture d’un logiciel de
plusieurs points de vue différents. Les facettes doivent montrer comment le système logiciel
est décomposé en composants et modules, comment les processus à l’exécution interagissent,
comment les différents composants sont répartis sur le réseau, etc.
Le modèle de vues architecturales le plus populaire est celui introduit par Philippe B.
Kruchten (Kruchten, 1995) et appelé The 4+1 View Model of Architecture.

Figure 20: Le modèle de vues architecturales 4+1 (Kruchten, 1995).

Les cinq vues se présentent comme suit :

• La vue logique montre les abstractions principales du système en termes d’entités ou
objets ou de classes d’objets ou de packages.
• La vue de processus montre comment, à l’exécution, le système est composé de processus
en interaction en termes de processus exécutés, threads (fils d’exécution), tâches,
parallélisme, synchronisation, ordonnancement, etc. Cette vue permet de formuler des
jugements au sujet des caractéristiques non fonctionnelles du système telles que la
performance ou la disponibilité.
• La vue de développement montre comment le logiciel est décomposé afin d’être réalisé,
c’est-à-dire quels sont ses composants, ses modules, éventuellement comment seront-ils
affectés aux équipes et aux développeurs.
• La vue physique montre le matériel et les processeurs sur lesquels s’exécutera le logiciel
et comment les composants du logiciel seront-ils déployés (répartis et installés) sur ce
matériel et exécutés par les différents processeurs.

Page 69
 • La vue de cas d'utilisation montre les besoins et les attentes des utilisateurs vis-à-vis
du logiciel. Cette vue est le ciment qui unit toutes les autres vues et pilote le
développement du logiciel.
c) Les styles architecturaux
P. Clements et al. (2010) définissent un style d’architecture comme une spécialisation des
types d’élément et de relation, ensemble avec un jeu de contraintes portant sur la manière de
les utiliser. On parle aussi de patron d’architecture ou de modèle d’architecture.
On peut voir un style architectural comme la description d’une architecture-type ayant été
testée sur plusieurs logiciels et éprouvée par le temps. Le style capture les concepts et
principes fondamentaux d’une certaine manière d’organiser les composants de son logiciel pour
atteindre un objectif spécifique et satisfaire les exigences d’un cas spécifique de logiciel. L’idée
derrière la notion de style architectural est de pouvoir capturer, partager et réutiliser des
connaissances au sujet de la meilleure façon admise de structurer et organiser les logiciels.
Plusieurs auteurs ont contribué à identifier les styles architecteraux les plus importants en
génie logiciel. On distingue les styles suivants :
• les structures générales telles que les modèles en couches, les modèles en pipe, les
modèles à filtres et les modèles blackboard,
• les styles de systèmes distribués tels que le client/serveur, le modèle 3-tiers, le broker,
• les styles de systèmes interactifs tels que le modèle Modèle-Vue-Contrôleur, le modèle
PrésentationAbstraction-Contrôle, les styles de systèmes adaptables tels que le micro
noyau, la réflexion et
• bien d’autres utilisés pour les systèmes en batch, les interpréteurs, les systèmes de
contrôle de processus, les systèmes à base de règles.
c.1) Les modèles d'architecture en couches
Les notions de séparation et d’indépendance sont fondamentales à la conception
architecturale, parce qu’elles permettent de confiner les changements dus à l’évolution du
système seulement dans des parties locales, sans affecter l’ensemble du système. Ces notions
sont à la base des modèles d’architecture en couches. C’est une approche générale de conception
architecturale qui se matérialisent en plusieurs styles variés. Les variétés de modèles en
couches se différencient en général par le nombre de couches ou par les règles d’interaction
intercouches.
c.2) L'architecture N-Tiers
Le patron d’architecture N-Tiers est un modèle en couches dans lequel chaque couche
communique seulement avec ses couches adjacentes (supérieure et inférieure) et le flux de
contrôle traverse le système de haut en bas ; les couches supérieures contrôlent les couches
inférieures, c’est-à-dire, que les couches supérieures sont toujours sources d’interaction
(clients) alors que les couches inférieures ne font que répondre à des requêtes (serveurs).

Page 70
 Figure 21: Vue conceptuelle du modèle d'architecture N-Tiers.

Soit un exemple générique d’implémentation du modèle N-tiers avec 4 couches dans une
application.

Figure 22: Un exemple générique d'implémentation du modèle

d'architecture N-Tiers.

c.3) L'architecture Modèle-Vue-Contrôleur (MVC)

Le patron architectural modèle-vue-contrôleur (MVC, de l’anglais model-view-controller),

tout comme les patrons modèle-vue-présentation ou présentation-abstraction-contrôle, est un
modèle en couches destiné à répondre aux besoins des applications interactives en séparant les
problématiques liées aux différents composants au sein de leur architecture respective.
Ce modèle regroupe les fonctions nécessaires en trois catégories :
• un modèle (modèle de données),
• une vue (présentation, dialogue utilisateur),
• un contrôleur (logique de contrôle, gestion des événements, synchronisation).
Le modèle MVC est issu de travaux de Trygve Reenskaug en 1978-79. Son but principal était
de proposer une solution générale aux problèmes d’utilisateurs manipulant des données
volumineuses et complexes.
L’organisation d’une interface graphique est délicate. L’architecture MVC ne prétend pas en
éliminer tous les problèmes, mais fournit une première approche pour le faire. L’idée est de bien

Page 71
séparer les données, la présentation et les traitements. Il en résulte les trois parties
énumérées plus haut : le modèle, la vue et le contrôleur.
Le modèle représente le cœur de l’application : traitements des données, interactions avec
la base de données, etc. Il décrit les données manipulées par l’application. Il regroupe la gestion
de ces données et est responsable de leur intégrité. La base de données sera l’un de ses
composants. Le modèle comporte des méthodes standards pour mettre à jour ces données
(insertion, suppression, changement de valeur). Il offre aussi des méthodes pour récupérer ces
données. Les résultats renvoyés par le modèle ne s’occupent pas de la présentation. Le modèle
ne contient aucun lien direct vers le contrôleur ou la vue. Sa communication avec la vue
s’effectue au travers du patron de conception Observateur.
Le modèle peut autoriser plusieurs vues partielles des données. Si par exemple le programme
manipule une base de données pour les emplois du temps, le modèle peut avoir des méthodes
pour avoir tous les cours d’une salle, tous les cours d’une personne ou tous les cours d’un groupe
de TD.
Ce avec quoi l’utilisateur interagit se nomme précisément la vue. Sa première tâche est de
présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toute action
de l’utilisateur (clic de souris, sélection d’un bouton radio, décochage d’une case, entrée de
texte, de mouvements, de voix, etc.). Ces différents événements sont envoyés au contrôleur.
La vue n’effectue pas de traitement, elle se contente d’afficher les résultats des traitements
effectués par le modèle et d’interagir avec l’utilisateur.
Plusieurs vues peuvent afficher des informations partielles ou non d’un même modèle. Par
exemple si une application de conversion de base a un entier comme unique donnée, ce même
entier peut être affiché de multiples façons (en texte dans différentes bases, bit par bit avec
des boutons à cocher, avec des curseurs). La vue peut aussi offrir à l’utilisateur la possibilité
de changer de vue.
Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à
jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l’utilisateur et
enclenche les actions à effectuer. Si une action nécessite un changement des données, le
contrôleur demande la modification des données au modèle, et ce dernier notifie la vue que les
données ont changé pour qu’elle se mette à jour. D’après le patron de conception
observateur/observable, la vue est un « observateur » du modèle qui est lui « observable ».
Certains événements de l’utilisateur ne concernent pas les données mais la vue. Dans ce cas, le
contrôleur demande à la vue de se modifier. Le contrôleur n’effectue aucun traitement, ne
modifie aucune donnée. Il analyse la requête du client et se contente d’appeler le modèle
adéquat et de renvoyer la vue correspondant à la demande.
Par exemple, dans le cas d’une base de données gérant les emplois du temps des professeurs
d’une école, une action de l’utilisateur peut être l’entrée (saisie) d’un nouveau cours. Le
contrôleur ajoute ce cours au modèle et demande sa prise en compte par la vue. Une action de
l’utilisateur peut aussi être de sélectionner une nouvelle personne pour visualiser tous ses cours.
Ceci ne modifie pas la base des cours mais nécessite simplement que la vue s’adapte et offre à
l’utilisateur une vision des cours de cette personne.
Quand un même objet contrôleur reçoit les événements de tous les composants, il lui faut
déterminer quelle est l’origine de chaque événement. Ce tri des événements peut s’avérer
fastidieux et peut conduire à un code peu élégant (un énorme switch ou beaucoup de if). C’est
pourquoi le contrôleur est souvent scindé en plusieurs parties dont chacune reçoit les
événements d’une partie des composants.

Page 72
 Figure 23: Vue conceptuelle du modèle MVC; adaptée de Sommerville
(2011).

En résumé, lorsqu’un client envoie une requête à l’application :

1. la requête envoyée depuis la vue est analysée par le contrôleur (par exemple un clic de
souris pour lancer un traitement de données) ;
2. le contrôleur demande au modèle approprié d’effectuer les traitements et notifie à la
vue que la requête est traitée (via par exemple un handler ou callback) ;
3. la vue notifiée fait une requête au modèle pour se mettre à jour (par exemple affiche le
résultat du traitement via le modèle).

Figure 24: Implémentation du modèle MVC dans une application web (Adaptée de
Sommervile, 2011).

Dans le modèle MVC, il est généralement admis que la vue puisse consulter directement le
modèle (lecture) sans passer par le contrôleur. Par contre, elle doit nécessairement passer par
le contrôleur pour effectuer une modification (écriture). Ici, le flux de contrôle est inversé par
rapport au modèle en couches, le contrôleur peut alors envoyer des requêtes à toutes les vues
de manière à ce qu’elles se mettent à jour.

Page 73
 Dans l’architecture trois tiers, si une vue modifie les données, toutes les vues concernées
par la modification doivent être mises à jour, d’où l’utilité de l’utilisation du MVC au niveau de
la couche de présentation. La couche de présentation permet donc d’établir des règles du type
« mettre à jour les vues concernant X si Y ou Z sont modifiés ». Mais ces règles deviennent
rapidement trop nombreuses et ingérables si les relations logiques sont trop élevées. Dans ce
cas, un simple rafraîchissement des vues à intervalle régulier permet de surmonter aisément ce
problème. Il s’agit d’ailleurs de la solution la plus répandue en architecture trois tiers,
l’utilisation du MVC étant moderne et encore marginale.
Une variante du modèle MVC très implémentée dans les frameworks de développement web
est le modèle dit MVC à contrôleur frontal. Dans ce modèle, l’application définit un contrôleur
particulier qui doit recevoir toutes les requêtes avant qu’un quelconque traitement ne leur ait
été appliquée dans l’application. L’application doit disposer d’un mécanisme permettant au
contrôleur d’intercepter toutes les requêtes issues des clients. L’objectif poursuivi est de
centraliser l’exécution des tâches techniques telles que le chargement des bibliothèques
tierces utilisées par l’application, la configuration des paramètres globaux de l’application, la
connexion à la base de données, l’authentification, le contrôle d’accès, le chargement d’un
gabarit d’interface web uniforme ou autre dans ce contrôleur frontal et focaliser
l’implémentation des autres contrôleurs sur la seule logique applicative. Le contrôleur frontal
doit alors inclure des fonctionnalités de routage des requêtes ou faire appel à un composant ou
module de routage de manière à acheminer correctement les requêtes aux contrôleurs
applicatifs censés traiter ces requêtes.

Figure 25: Le modèle d'architecture MVC à

contrôleur frontal.
Page 74
c.4) L'architecture à source de données partagée

La majorité de systèmes qui manipulent de grandes masses de données sont organisés autour
d’une source de données partagée et centralisée telle qu’une base de données ou un référentiel
de fichiers. Ce modèle architectural est alors adapté dans les applications où des données sont
générées par un composant et utilisées par d’autres composants. Les exemples les plus courants
qui adoptent ce style d’architecture incluent les systèmes de commande de contrôle, les
applications d’entreprise, les progiciels de gestion intégrés, les environnements de
développement intégrés, etc.

Figure 26: Exemple d'architecture à base de données partagée pour un logiciel de

gestion commerciale.

Figure 27: Exemple d'architecture à référentiel centralisé pour un environnement

de développement intégré.

Organiser des outils ou des composants autour d’une source de données centralisée est une
approche efficace permettant de partager une large quantité de données entre ces
outils/composants. Il faut, cependant, considérer que le modèle de données de la source doit
être en harmonie avec les modèles de données spécifiques à chaque outils/composants. Les
compromis seront inévitables dans la conception des outils/composants et de la source de
données.
c.5) Architecture client/serveur
Dans une architecture client/serveur, les fonctionnalités du système logiciel sont organisées
en services, chaque service étant délivré par un serveur différent. Les clients sont les
utilisateurs de ces services ; ils contactent les serveurs sur le réseau.
Les composants principaux du modèle architectural client/serveur incluent :
1. un ensemble de serveurs qui offrent des services à d’autres composants ;
2. un ensemble de clients qui font appel aux services offerts par les serveurs ;
3. un réseau à partir duquel les clients peuvent connecter les serveurs et accéder aux
services.
Page 75
 Sur les réseaux actuels, les clients et serveurs exploitent essentiellement les
fonctionnalités logicielles des protocoles TCP/IP pour pouvoir solliciter des services et
échanger des informations.

Figure 28: Modèle d'architecture Client/Serveur.

Dans cette composition, les clients et les serveurs sont conçues comme des logiciels
indépendants, avec leurs propres architectures pouvant être en couches ou basées sur un autre
style. Les clients et serveurs sont des applications réseau, c’est-à-dire des applications ayant,
en plus de leurs fonctionnalités propres, des fonctionnalités de communication réseau.
Un serveur peut être client d’un autre serveur, aboutissant alors à une architecture
client/serveur en couches. Dans le modèle ci-dessous, par exemple, le navigateur web du client
du magasin qui connecté à Internet et le navigateur du gérant connecté au réseau local
d’entreprise sont des clients du serveur de pages web. Le serveur de pages web est aussi un
client du serveur de services web.

Figure 29: Modèle d'architecture Client/Serveur en couches.

Pour des raisons de performance et d’impression des factures, on a voulu que les
fonctionnalités requises par le vendeur soient pas implémentées hors de l’application web, mais
qu’elles exploitent tout de même les services web d’entreprise. Ainsi, l’application du vendeur
est native (elle repose sur les API d’interface utilisateur propre au système d’exploitation hôte)
; elle est aussi client, directement client du serveur de services web.
Le serveur de pages web ainsi que le serveur de services web sont tous à la fois client du
serveur de bases de données relationnelles et du serveur des services d’annuaire.
Le principal avantage du modèle architectural client/serveur est que les serveurs peuvent
être répartis sur le réseau. Ainsi, les fonctionnalités générales telles que les partages de
fichiers, les services d’impression sont implémentées une seule fois et accessibles à tous les
clients, sans interférer avec des fonctionnalités spécifiques telles que des services web
d’entreprise.
Il y a aussi des inconvénients à souligner. Chaque serveur (y compris le service qu’il héberge)
Page 76
 est un point de défaillance qui, une fois hors de service, pénalise tous les clients et autres
serveurs qui en dépendent. D’autre part, on pourrait faire face à des problèmes de
performances logicielles si le réseau global accuse les mêmes problèmes dus à une mauvaise
conception ou une saturation du trafic.
c.6) L'architecture en pipe et filtre
Le style d’architecture en pipe et filtre est tel que chaque module ou fonctionnalités de
traitement, appelé ici filtre, reçoit en input les données intermédiaires produites par un autre
module en amont et produira des données en output qui serviront également d’input à un autre
module en aval. On parle alors de chaîne de traitement ou pipeline en faisant référence au fait
que les traitements sont enchaînés les uns à la suite des autres sur le même jeu de données et
que les modules sont mêmement appelés en chaîne. Le premier module de traitement reçoit les
données les plus brutes et le dernier module de traitement produit les données finales.

Figure 30: Modèle d'architecture en pipe et filtre.

On retrouve ce style d’architecture dans les logiciels de traitement d’images, les

traducteurs/interpréteurs de langages, les compilateurs, etc. qui appliquent une série de
traitements sur les mêmes données, respectivement les pixels-images et le code de
programmes.

Figure 31: Exemple d'architecture en pipe et filtre pour un

compilateur.
d) Les formalismes de conception architecturale
Plusieurs notations et langages sont utilisés dans la modélisation des produits de la
conception logicielle. Certaines sont utilisées spécifiquement pour décrire l’organisation
structurelle du logiciel, d’autres pour décrire son comportement. Certaines encore permettent
de modéliser les aspects architecturaux, d’autres les détails des composants, d’autres encore
pour les deux.
Les formalismes suivants servent à décrire textuellement ou graphiquement les aspects
structurels liés à l’architecture d’un logiciel : les langages de description d’architecture
(Architecture description languages, ADLs en anglais), les diagrammes de packages UML, les
diagrammes de composants UML, les diagrammes de déploiement UML, les langages de
description d’interfaces (Interfaces description languages, IDLs).
Il est aussi fréquent que l’architecture d’un logiciel soit esquissée simplement en utilisant
un diagramme de blocs plutôt qu’un formalisme très élaboré. C’est le cas de tous les modèles
d’architecture que nous avons présenté dans la section précédente. Dans un diagramme de blocs,

Page 77
les composants du logiciel sont représentés au moyen de blocs rectangulaires. Si un bloc est
contenu dans un autre, on le voit comme un sous-composants ou un module de ce dernier. Les
flèches orientées indiquent les flots orientés de données ou de contrôle entre composants. Il
appartient à l’architecte du logiciel de choisir le formalisme approprié selon le degré de
sémantique du modèle d’architecture souhaitée.
e) Les familles de programmes, les frameworks et la réutilisabilité en conception
architecturale
Une approche possible qui permet la réutilisation de conceptions et composants logiciel est
de concevoir une famille d’applications logiciels regroupées dans une gamme telles que les suites
LibreOffice, Microsoft Office, Adobe CS, etc. L’architecture d’une telle suite identifie des
éléments communs à l’ensemble des applications et permet mêmement de personnaliser ces
éléments pour chaque application.
En programmation orientée objet en particulier, une notion clé au centre de la réutilisation
de produits logiciels est la notion de framework. Un framework est un sous-système logiciel
partiellement complet qui peut être étendu par instanciation de modules et composants
existants ou par ajout de plug-ins (greffons). Le framework contient un ensemble de
bibliothèques de modules et composants prêt-à-utiliser qu’il suffit d’intégrer à son propre
logiciel ; des frameworks plus élaborés proposent eux-mêmes une architecture logicielle prêt-
à-utiliser, restant alors à l’architecte et aux ingénieurs logiciels de déterminer comment
intégrer les composants et modules qu’ils développent dans l’ensemble.
V.2.2 La conception de l'interface utilisateur
a) Quelques concepts et notions de l'Interaction Homme-Machine
L’interaction homme-ordinateur est un domaine de recherche et d’ingénierie à la confluence
des sciences cognitives et des techniques informatiques. Pour les ergonomes et psychologues,
l’interaction homme-ordinateur désigne l’ensemble des phénomènes cognitifs et physiques qui
participent à la réalisation de tâches informatisées. Chez les informaticiens, concernés par la
technologie de l’interaction, on parle d’interface homme-ordinateur ou encore, par abus de
langage, d’interface homme-machine (Coutaz, 1988). Le terme interface homme-machine
désigne un concept plus général et inclut l’interface des systèmes mécaniques, des véhicules et
des installations industrielles. On parlera alors d’« interface utilisateur » dans le contexte de
systèmes informatiques et appareils électroniques personnels. En ce qui nous concerne, nous
garderons, tout de même, la locution « homme-machine » pour des raisons de convenance vu
qu’elle est répandue dans le milieu des informaticiens.
Une interface homme-machine est un assemblage de composants logiciels et matériels qui
permet l’accomplissement de tâches avec le concours d’un ordinateur (Coutaz, 1988). On peut
la scinder en interface matérielle, la composante matérielle, et interface logicielle, la
composante logicielle. Dans notre étude, nous nous intéressons à l’interface logicielle qui est
l’apanage du génie logiciel.
La conception de l’interface utilisateur est une partie essentielle du processus de conception
d’un logiciel. Cette interface doit être conçue de manière à se conformer aux compétences, à
l’expérience, aux attentes et au contexte de travail de les utilisateurs.
b) La méthode de conception de l'interface utilisateur
La méthode de conception de l’interface utilisateur la plus en vogue est la conception centrée
sur l’utilisateur. La conception centrée sur l’utilisateur ou conception orientée utilisateur (UCD,
User-Centered Design en anglais) est une philosophie et une démarche de conception où les
besoins, les attentes et les caractéristiques propres des utilisateurs finaux sont pris en compte
à chaque étape du processus de développement d’un produit pour Jakob Nielsen cité par
Page 78
Wikipédia. Cette démarche se distingue fortement d’autres démarches de conception en
cherchant à adapter l’interface utilisateur à l’utilisateur final plutôt que de lui imposer un mode
d’utilisation choisi par les concepteurs. Elle repose sur le principe que les utilisateurs finaux
sont les mieux placés pour évaluer et utiliser le produit (Balbo, 1994 ; Wikipédia, 2013).
La norme ISO 9241-210 définit 5 critères d’application et de mise en œuvre de la démarche
:
• La prise en compte en amont des utilisateurs, de leurs tâches et de leur environnement
;
• La participation active des utilisateurs, garantissant la fidélité des besoins et des
exigences liées à leurs tâches ;
• La répartition appropriée des fonctions entre les utilisateurs et la technologie ;
• L’itération des solutions de conception, jusqu’à satisfaction des besoins et des exigences
exprimés par les utilisateurs ;
• L’intervention d’une équipe de conception multidisciplinaire, visant une expérience
utilisateur optimale.
Pour Deborah Mayhew et Jean-François Nogier cités par Wikipédia, la démarche de
conception centrée sur l’utilisateur consiste à mettre en place un processus itératif comprenant
habituellement 3 phases : la phase d'analyse, la phase de conception et la phase d'évaluation.
b.1) La phase d'analyse
Cette première étape vise à préciser les attentes et les besoins des utilisateurs finaux. Elle
permet de prendre connaissance de la tâche réelle des utilisateurs et d’analyser le contexte
dans lequel ils effectuent, ou vont effectuer, cette tâche. La phase d’analyse permet de
préciser l’utilité recherchée par les utilisateurs de l’application. Les méthodes d’observation
peuvent comprendre l’utilisation de questionnaires, de grilles d’observation heuristiques, de
focus group. Il est préférable d’ordonner ces besoins et exigences selon leur importance vis-à-
vis du produit à développer, et des éventuelles contraintes de faisabilité technique.
b.2) La phase de conception
Sur la base des éléments recueillis dans la phase d’analyse, une première maquette ou
prototype du produit est conçu. Cette maquette résulte, d’une part de l’analyse de la tâche des
utilisateurs et des spécificités du contexte de travail, et d’autre part des principes et
recommandations ergonomiques. Elle peut reposer également sur des standards de conception.
Cette première maquette évoluera ensuite en fonction des retours de la phase suivante
d’évaluation. Chaque itération permet d’enrichir et finaliser la maquette.
b.3) La phase d'évaluation
La phase d’évaluation consiste à mesurer l’utilisabilité du produit, autrement dit de valider
la satisfaction des utilisateurs dans la réalisation des tâches évaluées. Parmi les différentes
méthodes d’évaluation possibles, la principale est le test utilisateur. Celui-ci consiste à placer
l’utilisateur en situation d’utilisation réelle du produit et à observer les difficultés rencontrées.
L’évaluation permet d’identifier les points à améliorer sur la maquette et donc de préparer la
version suivante qui sera à nouveau testée et ainsi de suite. L’expérience montre que 2 à 3
itérations suffisent en général pour finaliser la conception de l’interface.
On utilise habituellement des prototypes d’interface pour définir l’organisation, les
fonctionnalités et l’apparence de l’interface utilisateur.
V.2.3 La conception des composants
a) Les formalismes de la conception de composants

Page 79
 Plusieurs notations et langages permettent habituellement de représenter les modèles de
conception des composants logiciels. On les regroupe généralement en deux vues : les
formalismes permettant de décrire la structure, soit vue statique et les formalismes
permettant de décrire les comportements, soit la vue dynamique.
a.1) Les formalismes de description de structures et de la vue statique
Ces notations décrivent et représentent les aspects structurels du logiciel, c’est-à-dire les
composants principaux ainsi que la manière dont ils sont interconnectés et répartis
géographiquement (vue statique) : les diagrammes de classes UML, les diagrammes d’objets
UML, les cartes de répartition de responsabilité de classe ( Class responsabilité collaborator
cards, CRCs), les diagrammes entités-associations (Entity-relationship diagrams, ERDs), les
diagrammes de structure de Jackson, les graphes de structure (Structure charts), etc.
a.2) Les formalismes de description de comportements et de la vue dynamique
Les notations suivantes sont utilisées pour décrire le comportement dynamique de logiciel
entier ou de ses composants : les diagrammes d’activité UML, les diagrammes de communication
UML, les diagrammes de flots de données (Data flow diagrams, DFDs), les diagrammes et tables
de décision, le flowcharts et flowcharts structurés, les diagrammes de séquence UML, les
diagrammes d’état-transition UML, les langages de spécification formelle, le pseudo-code et les
langages de conception de programmes (Program design languages, PDLs), etc.
b) Quelques stratégies et méthodes de conception de composants
Il existe des stratégies générales variées qui aident à guider le processus de conception.
Contrairement aux stratégies générales, les méthodes sont plus spécifiques dans le sens qu’elle
suggèrent et fournissent généralement un ensemble de notations avec lesquelles les combiner,
la description d’un processus à suivre et un ensemble de directives pratiques.
b.1) Les stratégies générales de conception du logiciel

Quelques stratégies générales de conception logicielle populaires incluent les approches

descendantes (diviser pour règner, la décomposition hiérarchique), les approches ascendantes,
les stratégies à base d’heuristiques l’utilisation de patrons, les approches itératives et
incrémentales, etc.
b.2) La conception orientée fonctions ou conception structurée

La conception structurée est l’une des méthodes classiques de conception logicielle, où la

décomposition est centrée sur l’identification de grandes fonctions du logiciel qui seront par la
suite raffinées dans une approche descendante. La conception structurée fait suite à l’analyse
structurée ; elle produira des diagrammes de flots de données détaillés ainsi que les
descriptions de processus associés. Grâce à des stratégies telles que l’analyse de
transformations, l’analyse de transaction ou les heuristiques, les diagrammes de flots de
données seront ensuite transformés en architecture logicielle généralement représentée par
un graphe de structure.
b.3) La conception centrée sur les structures de données

La conception centrée sur les structures de données commence par les structures de
données manipulées par un programme plutôt que par les fonctions qu’il exécute. L’ingénieur
logiciel décrit les structures de données en input et en output, en utilisant par exemple les
diagrammes de structures de Jackson et développe ensuite la structure de contrôle du
programme sur base de ces diagrammes de structures de données.
b.4) La conception orientée objets
De nombreuses méthodes à l’état actuel de l’art sont basées sur l’orienté objets. L’approche
a évolué des pratiques de conception orientée objets séminales des années 1980s centrées sur
l’héritage et le polymorphisme aux pratiques actuelles où la conception est orientée composant,
Page 80
où les méta-données sont manipulables dans les programmes à travers des mécanismes tels que
la réflexion et les annotations. Initialement enracinée sur le concept d’abstraction de données,
aujourd’hui la conception orientée objet est pilotée par la notion de responsabilité.
b.5) La conception centrée sur les composants
La conception centrée sur les composants aborde les problèmes liés à la fourniture, au
développement et à l’intégration de composants de manière à accroître la réutilisation.
b.6) L'approche agile
Les méthodes agiles proposent d’implémenter rapidement une base incrémentale en
minimisant la rigueur de l’ingénierie des exigences et la conception dans le sens des approches
systématiques. On fera le moins de spécification et de conception possibles.
b.7) La conception orientée aspect
La conception orientée aspect est une méthode dans laquelle on conçoit le logiciel en utilisant
les aspects pour implémenter les préoccupations transversales identifiées dans le processus
d’ingénierie des exigences.
b.8) La conception orientée service
L’orienté service est une manière de développer du logiciel distribué généralement
implémenté au moyen des services web. Au centre d’un tel logiciel se trouve une architecture
orientée service.
c) La conception orientée objet avec UML
Un système logiciel orienté objet est fait d’objets en interactions qui maintiennent leur
propre état local ( valeurs des attributs internes) et fournissent des opérations susceptibles
d’être exécutées sur cet état. La représentation de cet état est privé et n’est pas directement
accessible de l’extérieur de l’objet. Le processus de conception orientée objet consiste à
concevoir les classes d’objets et les relations entre ces classes. Les classes définissent les
objets qui seront à l’intérieur du logiciel ainsi que leurs interactions. Quand la conception est
implémentée en programme exécutable, les objets sont créés dynamiquement à partir de ces
définitions de classes.
Les systèmes orientés objet sont, en général, plus aisés à maintenir que les systèmes
développés par l’approche fonctionnelle (approche structurées). Parce que les objets
encapsulent en eux leurs propres données et les opérations permettant de manipuler ces
données. Il est, de ce fait, plus facile de comprendre leur logique de fonctionnement en tant
qu’entités autonomes et modifier plus aisément cette logique. De même, modifier
l’implémentation d’une classe d’objets n’affectera pas d’autres objets du système par le principe
de l’encapsulation. De trois, les objets à l’intérieur d’un logiciel orienté objet modélisent des
choses, des objets, des concepts, des rôles du domaine réel du problème ; il a, donc, une
correspondance claire entre ces entités du monde réelle et les objets à partir desquels le
système les manipule. Cela contribue énormément à la facilité de compréhension et de
maintenance du système.
Plusieurs auteurs admettent que les étapes essentielles dans la conception orientée objet
sont (Sommerville, 2011) :
1. Comprendre et définir le contexte du système ainsi que ses interactions avec d’autres
systèmes de son environnement et développer les cas d’utilisation. Ces tâches sont
réalisées lors de l’ingénierie des exigences.
2. Concevoir l’architecture du système.
3. Identifier les objets principaux du système.
4. Développer les modèles de conception.
5. Spécifier les interfaces.
Page 81
 UML n’est ni une méthode d’analyse, ni une méthode de conception. Cependant, l’ensemble
des méthodes élaborées autour de ce langage partagent des principes communs et une démarche
générale. Les étapes essentielles de conception objet avec UML incluent :
1. Élaborer le modèle de classes du contexte statique en même temps que le modèle de
communication du contexte dynamique du système.
2. Élaborer modèle de cas d’utilisation ainsi que les modèles de séquence, de communication
et/ou d’activité de spécification des cas d’utilisation.
3. Élaborer le modèle de classes du domaine et, éventuellement, le modèle d’état-transition
permettant de spécifier l’activité interne des objets du domaine ayant un comportement
remarquable.
4. Élaborer le modèle de packages du domaine permettant d’organiser les classes du
domaine en catégories logiques, cohérente et hautement réutilisables.
5. Planifier le développement du logiciel.
6. Concevoir l’architecture du logiciel.
7. En référence au modèle d’architecture conçu ou du système architectural choisi,
répartir les classes dans les différents composants et micro composants du logiciel. Les
classes du domaine seront complétées des classes techniques telles les éléments
d’interface homme-machine, les éléments d’interaction logicielsystèmes, logiciel-sources
de données, les utilitaires applicatifs, etc. L’ensemble des classes font les classes de
conception.
8. Sur base de la logique d’interaction entre composants imposée par les choix
architecturaux, concevoir les interactions entre objets permettant de réaliser les
scénarios des cas d’utilisation. On utilise essentiellement les diagrammes d’interaction
détaillés (séquence, communication, interaction globale).
9. Enrichir les classes de conception avec les informations issues des diagrammes
d’interaction détaillés.
10. Enrichir et finaliser les classes de conception en spécifiant les types de attributs et
autres caractéristiques qui s’y rapportent, les signatures des méthodes, en y appliquant
les patrons de conception, etc. Ces étapes peuvent avoir lieu avant ou en même temps
que l’implémentation, les tests unitaires et les tests d’intégration. De même, toutes les
étapes listées ici ne sont pas obligatoires ni suffisantes dans tous les cas.
d) Les motifs de conceptions
Ivar Jackson et J. Rumbaugh (1999) définissent un motif ou patron de conception (design
pattern en anglais) comme une solution commune à un problème commun dans un contexte donné.
Pour Rajib Mall (Mall, 2009), un patron de conception est un arrangement caractéristique de
modules, reconnu comme bonne pratique en réponse à un problème de conception d’un logiciel. Il
décrit une solution standard, utilisable dans la conception de différents logiciels.
Les patrons de conception tirent leur origine des travaux de l’architecte en bâtiments
Christopher Alexander dans les années 70, dont son livre A Pattern Language définissant un
ensemble de patrons d’architecture.
Alors que les patrons architecteraux peuvent être vus comme des modèles d’organisation de
logiciels à un haut niveau d’abstraction, d’autres patrons peuvent être utilisés pour décrire les
détails du logiciel à un niveau plus bas ou local. Pour sa part, Bruce Eckel considère que les
patrons de conception consiste en une pratique de développement logiciel dans laquelle on
cherche à isoler les parties changeantes du logiciel de celles qui restent inchangées.
C’est Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides appelés The Gang of 4,
le groupe des 4 qui ont identifié et décrit pour la première fois un ensemble de vingt-trois

Page 82
patrons de conception qui sont aujourd’hui implémentés dans l’ensemble des langages de
programmation populaire et qu’on retrouve au coeur de la plupart des logiciels contemporains.
D’autres patrons ont été proposés, dérivés ou non des douze séminaux.
Les vingt-trois patrons de conception du Gang of 4 sont classifiés en trois catégories : les
patrons de création, les patrons de structuration et les patrons de comportement. Les patrons
de création ou patrons créationnels ou encore patrons de construction déterminent les
meilleures façons de créer (instancier) et configurer des objets dans un logiciel. En général, ils
définissent comment créer de nouveaux objets tout en isolant les détails de cette création pour
que le reste du code ne dépende pas du type de ces objets et, donc, qu’il ne change pas avec le
type d’objets créés. Les patrons de création incluent le singleton, la fabrique (factory method),
la fabrique abstraite ( abstract factory) et le monteur (builder ).
Les patrons de structure ou patrons structuraux définissent comment organiser les objets
dans un logiciel de manière à satisfaire certaines contraintes. Il s’agit d’organiser les objets
pour que les relations qu’ils entretiennent les uns avec les autres dans le programme restent
inchangées quand certains changements surviennent dans le système. Les patrons structuraux
incluent l’adaptateur (adapter), le pont (bridge), l’objet composite (composite), le décorateur
(decorator), la façade (facade), le poids-mouche ou poids-plume (flyweight) et le proxy (proxy).
Les partrons de comportement ou patrons comportementaux permettent de gérer varier les
comportements des objets dans le logiciel sans pour autant modifier le code du logiciel. Ils
inclut l’observateur et le visiteur. Les patrons de comportement incluent la chaîne de
responsabilité (chain of responsability), la commande (command), l’interpréteur (interpreter),
l’itérateur (iterator), le médiateur (mediator), le mémento (memento), l’observateur (
observer), l’état (state), la stratégie (strategy), le patron de méthode (template method), le
visiteur (visitor), la fonction de rappel (callback).
À ces vingt-trois s’ajoutent d’autres patrons, notamment l’inversion de contrôle au niveau
architectural, qui est implémenté au moyen du mécanisme de l’injection de dépendances.

Page 83
 Chapitre VI.
LA CONSTRUCTION ET LE TEST DU LOGICIEL

Ce chapitre poursuit les objectifs suivants :

1. Donner les concepts et les principes fondamentaux de la construction et du test du
logiciel ;
2. Donner un aperçu des techniques de test du logiciel ;
3. Montrer la mise en œuvre de quelques techniques de test couramment utilisées.

À l'issue du chapitre, l'étudiant devrait être en mesure de :

1. Définir et comprendre les concepts de la construction et du test du logiciel ;
2. Énumérer et classifier les techniques de test du logiciel ;
3. Mettre en œuvre les techniques de test les plus couramment utilisées.
VI.1 Quelques considérations générales sur la construction et le test du logiciel

VI.1.1 Définition de concepts, notions et principes

a) La construction du logiciel
a.1) Définition et notions

L'expression construction du logiciel fait référence à la création détaillée d’un logiciel

opérationnel et significatif en combinant le codage, la vérification, les tests unitaires, les tests
d’intégration et le débogage.
Bien que la plus grande part de la conception peut être finalisée avant la construction, il est,
aujourd’hui, fréquent de concevoir en même temps que la construction. D’où, la conception
logicielle est intimement liée à la construction. De même, à travers la construction, les
ingénieurs logiciels réalisent mêmement les tests unitaires et les tests d’intégration. D’où, la
construction est également intimement liée au test. De trois, la construction logicielle génère
le plus grand nombre de produits logiciels (fichiers de code source, éléments de contenu, cas
de test, etc.) qui nécessitent d’être gérés convenablement. D’où la constructeur est, une fois
de plus, intimement liée à la gestion de configuration logicielle.
a.2) Quelques principes fondamentaux de la construction du logiciel

Les principes fondamentaux de la construction logicielle incluent : la réduction (minimisation)

de la complexité, l’anticipation du changement, la construction pour la vérification, la
réutilisation, l’application de standards.
b) Le test du logiciel
b.1) Définition de concepts relatifs au test du logiciel
La norme IEEE 829-1998 relative à la documentation du test, revue à l’aide du glossaire de
l’International Software Testing Qualifications Board (ISTQB) définit un test comme un
ensemble de cas à tester (état de l’objet à tester avant exécution du test, actions ou données
en entrée, valeurs ou observations attendues, et état de l’objet après exécution),
éventuellement accompagné d’une procédure d’exécution (séquence d’actions à exécuter). Il est
lié à un objectif.
Dans leur ouvrage sur l’assurance qualité, Claude Laporte et Alain April établissent qu’un
test ressemble à une expérience scientifique. Il examine une hypothèse exprimée en fonction
de trois éléments : les données en entrée, l’objet à tester et les observations attendues. Cet
examen est effectué sous conditions contrôlées pour pouvoir tirer des conclusions. Un bon test
respecte également l’exigence de répétabilité.

Page 84
 Ensuite, la terminologie essentielle du test logiciel inclut aussi des termes qui font souvent
l’objet de confusion dans l’expression courante des acteurs impliqués dans le développement
logiciel.
Il s’agit de défaut, défaillance, anomalie, erreur et faute. Voici les définitions les plus
couramment partagées par l’ISTQB, l’IEEE et bien d’autres.
• Un défaut est une imperfection dans un composant ou le système logiciel entier qui peut
en perturber le fonctionnement. Ce défaut est révélé par une défaillance (failure en
anglais) s’il est exécuté.
• Une défaillance est une déviation par rapport au comportement ou résultat attendu. Il
apparaît donc que l’exécution du produit n’est pas la seule façon de détecter des défauts.
Cela laisse aussi entrevoir qu’un code peut être syntaxiquement et sémantiquement
correct et pourtant présenter un défaut qui ne sera manifesté que lors d’un test de
performance par exemple. Dans un tel cas, l’origine du défaut pourrait être une erreur
d’architecture ou de configuration.
• Le terme anomalie est aussi souvent utilisé. C’est un terme générique qui fait référence
autant à un défaut qu’à une défaillance.
• La norme BS 7925-16 définit le terme faute (fault) comme la matérialisation d’une
erreur, c’est-à-dire une action humaine produisant un résultat incorrect, une « faute »
de frappe ou une erreur de raisonnement par exemple.
Dans la plupart des outils de test, on rencontre aussi les notions de cas de test et de suite
ou jeu de tests.
• Un cas de test (test case) est un ensemble de conditions ou variables à partir desquelles
un testeur déterminera si une unité du système logiciel ou le système logiciel entier
fonctionne comme prévu. Lorsque cela est vérifié, on dit que l’unité logicielle a passé le
test, sinon elle l’a échoué.
• Le mécanisme permettant de déterminer si une unité logicielle ou le logiciel tout entier
a passé un test est appelé oracle de test. Dans la pratique, un oracle de test peut être
une exigence, un cas d’utilisation, ou une heuristique.
• Lorsqu’un cas de test est rédigé sous forme de script automatisé, on l’appelle script de
test.
• Une suite de test (test suite) est un ensemble de plusieurs cas de tests, éventuellement
exécutés ensemble manuellement ou automatiquement ; ils sont ainsi regroupés d’après
un critère de similarité choisi.
• Lorsque les exigences du logiciel sont formelles, on élaborera des cas de test formels,
sinon des cas de test informels.
b.2) Les objectifs du test du logiciel
Le test du logiciel poursuit deux objectifs fondamentaux :
• Montrer que le logiciel fait exactement ce pour quoi il a été créé ; techniquement parlant,
le test permet de démontrer aux développeurs et au client que le logiciel satisfait à ses
exigences (test de validation).
• Découvrir des défections avant que le logiciel ne soit mis en service ; en termes
techniques, le test permet de découvrir des situations dans lesquelles le comportement
du logiciel est incorrect, indésirable et non conforme à sa spécification (test de
défection).
Un test logiciel n’a pas pour finalité d’identifier la cause des erreurs, de les rectifier, ou de
prouver la correction de l’objet testé ; il vise simplement à mettre en évidence des défauts de
l’objet testé.
Page 85
b.3) Le test du logiciel et l'assurance qualité
En détectant des défauts résiduels sur le logiciel, le test contribue à l’amélioration de sa
qualité ; d’où le test logiciel fait partie du processus de vérification et validation dans lequel il
est pratiqué en complément aux activités d’assurance qualité les inspections.
Le test et les inspections sont des activités de vérification complémentaires, et non
opposées. Alors que les inspections consistent à analyser les représentations statiques du
système telles que les spécifications, les modèles, les schémas ou le code (vérification statique),
le test consiste à observer le comportement du système en exécution ( vérification dynamique
).

Figure 32: Le test et les inspections

(Sommerville, 2011).

c) Les niveaux de test du logiciel

Différents types de test permettent de détecter différents types de défauts. Des

méthodes de spécification de test ont été élaborées pour permettre une plus grande rigueur
dans cette activité de définition. La norme britannique BS 7925-24, Standard for Software
Component Testing en donne des exemples.
Le test logiciel est habituellement réalisé à plusieurs niveaux tout au long du processus de
développement et du processus de maintenance. Un niveau de test est un groupe d’activités de
tests qui sont organisées et gérées ensemble. Un test peut être classifié de tel ou tel niveau
selon la cible du test, c’est-à-dire l’objet même qui est testé, ou selon objectif du test qui
définit l’intention du test.
c.1) Selon la cible du test
La cible d’un test logiciel peut être un seul module, un groupe de modules liés
structurellement, fonctionnellement, etc. ou le système logiciel entier. On parle alors de trois
types ou niveaux de test selon la cible : le test unitaire, le test d’intégration et le test système.
• Le test unitaire : Le test unitaire consiste à vérifier le fonctionnement isolé d’éléments
du logiciel testables séparément. En fonction du contexte, ces éléments peuvent être
des sous-programmes, des fonctions, des classes, ou des composants constitués d’unités
très cohésives. Typiquement, lors du test unitaire, on a accès au code source sous test
et on fait recours aux outils de débogage. Typiquement, c’est le programmeur qui a
rédigé le code source qui conduit le test unitaire, même si ce n’est pas toujours le cas.
• Le test d'intégration : Le test d’intégration est le processus consistant à vérifier les
interactions entre composants du logiciel.
• Le test système : Le test système consiste à tester le comportement du système
logiciel tout entier. En principe, si les tests unitaires et les tests d’intégration ont été
effectifs, la plupart des défections dans le logiciel auront déjà été identifiées et prises
Page 86
 en charge. Le test système est souvent pratiqué pour évaluer des exigences non
fonctionnelles telles que la sécurité, la performance, la fiabilité, etc. Il permet aussi de
tester les interactions entre le système et les autres systèmes environnants à travers
ses interfaces externes.
c.2) Selon les objectifs du test
Selon les objectifs du test, on distingue le test de conformité, le test d’exactitude et le
test fonctionnel. On peut aussi ajouter les tests visant à évaluer certaines propriétés du
logiciel : le test de performance, le test de fiabilité, le test d’utilisabilité, le test de
vulnérabilité, le test d’acceptation, etc.
• Le test d'acceptation ou test de qualification : Le test d’acceptation/qualification est
le test visant à déterminer si le système satisfait les critères d’acceptation
préalablement fixés, généralement en comparant les comportements du système aux
exigences des clients. Les clients ou leur représentant sont chargés d’effectuer ce test
; dans le cas d’un produit générique, le responsable du produit s’en charge. Le test n’exige
pas la présence des développeurs du système.
• Le test d'installation : Le test d’installation peut être vu comme un test système
effectué dans l’environnement de destination avec sa configuration matérielle et ses
contraintes opérationnelles. On vérifier si le système fonctionne correctement dans cet
environnement et si les procédures d’installation sont adaptées. Le test d’installation
survient après les tests d’acceptation.
• Le test Alpha et le test Bêta : Avant que le logiciel ne soit publié, on le confie à un
groupe restreint d’utilisateurs potentiels pour essai sur le site de développement ; c’est
le test Alpha. Ou bien, on le confie à un groupe plus large, en dehors du site de
développement ; c’est le test Beta. On reconnaîtra, par exemple, les test Bêta que les
utilisateurs réalisent sur les versions gratuites d’antivirus populaires téléchargés à
partir d’Internet. Dans les deux cas, les utilisateurs ayant testé le logiciel signalent les
problèmes rencontrés en envoyant des rapports de test. Généralement, le logiciel en
version Bêta est configuré pour constituer et/ou envoyer le rapport de test
automatiquement ou après avoir obtenu l’accord de l’utilisateur.
• Le test de régression : Un test de régression, appelé aussi test de non régression est
un test appliqué sur un module/composant déjà testé mais qui a été modifié ; il vise à
vérifier si les modifications apportées au module/composant n’ont pas occasionné des
effets inattendus et que le module/composant continue à satisfaire les exigences
spécifiées. Dans la pratique, on réexécute les tests déjà passés par le module/composant
afin de s’assurer que les résultats obtenus préalablement restent valables. Le test de
régression revêt un autre rôle dans le développement incrémental. Étant donné que le
logiciel est livré incrément par incrément, et que l’ensemble des incréments ainsi livrés
viennent d’ajouter au noyau applicatif existant, le test de régression permet de vérifier
que le comportement du logiciel ne change pas suite à ces ajouts, sauf, bien sûr, la prise
en compte de nouvelles fonctionnalités. Le test de régression peut être conduit au niveau
unitaire, au niveau d’intégration et au niveau système ; il peut être aussi au niveau
fonctionnel et au niveau non fonctionnel.
• Le test de performance : Le test de performance permet de vérifier que le logiciel
satisfait les exigences de performance spécifiées et, en même temps, d’évaluer les
caractéristiques de performance mesurées.
• Le test de sécurité : Le test de sécurité permet de vérifier que le logiciel est protégé
des attaques externes en terme de confidentialité, d’intégrité et de disponibilité des

Page 87
 données manipulées par le logiciel. Ce test inclut aussi le test appelé test négatif et qui
consiste à vérifier que le logiciel n’est pas utilisé à tort.
• Le test de stress : Le test de stress soumet le logiciel à une charge maximale au-
dessous de ses capacités maximales telles que définies par les spécifications et la
conception, dans le but d’observer le comportement du logiciel dans ces conditions
limites. Les capacités limites peuvent inclure la quantité de données traitées, le nombre
d’utilisateurs simultanés, la mémoire vive disponible, etc. bref, l’augmentation des
sollicitations et/ou la diminution de ressources.
• Le test de récupération : Le test de récupération vise à vérifier les capacités de
redémarrage et récupération du logiciel après un crash ou une autre forme de désastre
tant au niveau du logiciel lui-même qu’au niveau du système hôte.
• Le test d'interface : Dans des systèmes complexes, des défections sont souvent
fréquentes au niveau de l’interface. Le test d’interface vise à vérifier si les composants
s’interfacent correctement de manière à assurer un échange approprié de données et
des informations de contrôle. Généralement, les tests d’interface sont générés à partir
de la spécification de l’interface entre composants. Un objectif spécifique de ces tests
est de simuler l’utilisation des APIs dans des applications utilisateur.
• Le test de configuration : Au cas où le logiciel est construit pour servir différents
utilisateurs, le test de configuration permet de vérifier le fonctionnement du logiciel
sous différentes configurations spécifiques.
• Le test d'utilisabilité et le test d'interaction homme-machine : La tâche principale du
test d’utilisabilité et interaction homme-machine consiste à évaluer à quel point est-il
aisé pour les utilisateurs finals d’apprendre et d’utiliser le logiciel. En général, il peut
consister à tester les fonctions du logiciel qui prennent en charge les tâches de
l’utilisateur, la documentation qui aide les utilisateurs et l’habileté du logiciel à récupérer
des erreurs utilisateur.
VI.2 Aperçu de techniques de test
Un des buts du test est de détecter le plus de défauts possibles. Pour cela, plusieurs
techniques ont été développées. De manière générale, on classifie les techniques en deux
catégories : les techniques à boîte blanche ou tests structuraux si les tests sont basés sur le
fonctionnement interne du logiciel, c’est-à-dire sa conception et son code, et les techniques à
boîte noire ou tests fonctionnels si les tests concernent le comportement externe du logiciel,
c’est-à-dire son comportement extérieur face aux données à l’input et à l’output. Contrairement
aux tests fonctionnels, où le logiciel ou module peut être testé sans connaissance de ses
structures internes, les tests structurels exigent que le testeur ait accès aux détails de la
structure du logiciel ou du module.
VI.2.1 Les techniques basées sur l'expérience et l'intuition de l'ingénieur a) Les techniques
Ad hoc
Les tests ad hoc sont dérivés en fonction des compétences, de l’intuition et de l’expérience
personnelles de l’ingénieur.
b) Le test exploratoire
Dans son livre Exploratory Software Testing (Whittaker, 2010), James A. Whittaker
définit le test exploratoire comme suit : Le test exploratoire consiste en un ensemble de
techniques, de test manuel, qui vise à investiguer le logiciel sur la base des fonctionnalités
attendues et de différentes heuristiques de test (valeurs aux limites, messages d’erreurs, tour
guidé et adaptation du parcours de test aux résultats obtenus, …). Les limites du test
exploratoire proviennent de son coût et le destine prioritairement aux fonctionnalités nouvelles.

Page 88
Cette technique est très en vogue dans les méthodes agiles où, de manière générale, les tests
fonctionnels constituent le point clé permettant de maintenir un bon alignement entre les
besoins métiers et les développements itératifs.
VI.2.2 Les techniques basées sur le domaine des inputs
a) Le test de partitionnement d'équivalence
C’est Ilene Burnstein qui, dans son livre Practical Software Testing (Burnstein, 2003),
définit cette technique de test.
Le partitionnement d’équivalence, également appelé partitionnement de classe d’équivalence
est une technique de test qui divise le domaine des inputs d’une unité logicielle en partitions de
données équivalentes à partir desquelles les cas de test sont dérivés. En principe, les cas de
test sont conçus de manière à couvrir chaque partition au moins une fois. Cette technique essaie
de définir des cas de test permettant de découvrir des classes d’erreurs, et ainsi réduire le
nombre total de cas de test à développer. Un nombre réduit de cas de test entraîne une
réduction du temps de test.
b) Le test par paires (Pairewise testing)
C’est une technique combinatoire de test qui, pour toute paire des paramètres en input d’un
algorithme, d’une fonction, d’une méthode de classe, teste toutes les combinaisons discrètes
possibles ou un vecteur de test judicieusement choisi parmi ces combinaisons.
VI.2.3 Les techniques basées sur le code source
a) Le test basé sur le flux de contrôle
Le test basé sur le flux de contrôle vise à couvrir toutes les instructions et tous les blocs
d’instructions dans un programme ou une fonction.
b) Le test basé sur le flux de données
Le test basé sur le flot de données est une forme de test à boîte blanche qui se focalise sur
les variables/objets utilisés dans un programme ou une fonction ou une méthode de classe. Les
variables sont définies et utilisées à différents point du programme ou de la méthode ; le test
basé sur le flot de données permet au testeur de représenter graphiquement les valeurs
changeantes de variables dans le programme au moyen d’un graphe de programme.
Il existe deux formes principales de test basé sur les flots de données : le test
définition/utilisation et le test tranches ou segments de programme.

VI.2.4 Les techniques basées sur la nature du logiciel

L’ensemble de techniques citées, jusque-là, s’appliquent à tout type de logiciel. Mais en plus
de celles-là, il existe des techniques spécifiques à la nature de l’application même. On citera,
par exemple, les techniques spécifiques de test de logiciels orientés objets, de logiciels
structurés, de logiciels assemblés à partir de composants, d’applications web, de programmes
concurrents, de logiciels orientés protocoles, de systèmes temps réels, de systèmes critiques,
de logiciels orientés service, de logiciels open source, de systèmes embarqués, etc.
VI.2.5 Autres techniques
Il existe beaucoup d’autres techniques de test du logiciel incluant les techniques basés sur
les erreurs courantes, les techniques basées sur un modèle telles que les tables de décision, les
machines à états finis, les spécifications formelles, les modèles de workflows, les techniques
basées sur l’utilisation, etc.

Page 89
 Il est aussi possible et intéressant de combiner plusieurs approches et techniques de test
logiciel de manière à évaluer les différents aspects du fonctionnement ou de la structure du
logiciel et de ses unités.
VI.3 Le processus de test du logiciel
Les concepts, stratégies, techniques et mesures du test logiciel doivent être intégrés dans
un processus bien défini et contrôlé. Ce processus est défini de manière à prendre en charge
les activités de test et à guider les testeurs de telle sorte que les objectifs du test soient
atteints.
Les activités du processus de test logiciel généralement admises sont : la planification du
test, la génération des cas de test, la construction de l’environnement de test, l’exécution du
test, l’évaluation des résultats du test, le compte-rendu des problèmes et la détection des
défections.
Sommervile (2011) propose le processus de test suivant :

Figure 33: Un exemple de processus de test du logiciel (Sommerville,

2011).

Page 90
BIBLIOGRAPHIE

1. Abdelhak-Djamel Seriai (Dir.), Évolution et maintenance des systèmes logiciels,

Lavoisier, 2014.
2. A. Bijlsma, B. J. Heerendr, E. E ; Roubtsovair and S. Stuurman, Software Architecture,
Free Technology Academy.
3. B. Curtis, W. Hefley and S. Miller, People Capability Maturity Model, Addison-Wesley,
2001.
4. Dean Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises,
Boston: AddisonWesley, 2007.
5. Mickey Gousset, Brian Keller, Ajoy Krishnamoorthy and Martin Woodward, Professional
Application Lifecycle Management with Visual Studio 2010, Wiley Publishing Inc., 2010.
6. Stephen R. Schach, Object-Oriented and Classical Software Engineering, New York:
McGraw-Hill, 8th ed, 2011.
7. Roger S. Pressman, Software Engineering: A Pratictioner's Approach, New York:
McGraw-Hill, 7th ed., 2010.
8. Julius Marcelin Nkenkifack, Ingénierie des Systèmes Logiciels, Notes de cours inédites,
Master II en Informatique Appliquée aux Systèmes d'Information Géographique,
University de Douala, 2012/2013.
9. Philippe Palanque, De l'analyse des tâches à l'ingénierie des modèles de tâches, Mars
1999.
10. Fabio Paternò, Tools and Methods based on Task Models, 1999.
11. Fabio Paternò, Model-based Design and Evaluation of Interactive Application, Springer
Verlag, 2000.
12. Roger S. Pressman, Software Engineering : A Practitioner's Approach, McGraw-Hill, 7th
edition, 2010.
13. IEEE, Recommended Practice for Software Requirements Specifications (IEEE Std
830-1998, Revision of IEEE Std 830-1993), June 1998.
14. IEEE, A Guide ot the Software Engineering Body of Knowledge (SWEBOK), 2004
version, 2004.

Page 91