L’art de produire des logiciels de qualité sans dépassement de délai

Notes de Génie Logiciel

UATM Gasa Formation SIL3 2023-2024

Maxime AYI
 Notes de Génie Logiciel

Maxime AYI UATM Gasa Formation / SIL3 1

 Notes de Génie Logiciel

Table des matières

1 Introduction....................................................................................................................................3
1.1 Qu'est-ce qu'un logiciel ?.......................................................................................................3
1.2 Qu'est-ce que Le génie logiciel ?............................................................................................4
1.3 Qualité logiciel.......................................................................................................................4
2 Les activités (taches) du processus de développement logiciel....................................................5
2.1 La Spécification......................................................................................................................5
2.2 La conception (design)...........................................................................................................7
2.2.1 La conception de haut niveau (High‐level design)..........................................................7
2.2.2 La conception de bas niveau (Low‐level design)...........................................................10
2.3 Codage..................................................................................................................................11
2.4 Le test...................................................................................................................................12
2.4.1 Niveaux de test.............................................................................................................12
2.4.2 Le déroulement d’un test.............................................................................................13
2.4.3 Les techniques de test..................................................................................................13
2.5 Le déploiement....................................................................................................................14
2.5.1 Le plan de déploiement................................................................................................14
2.5.2 Stratégies de déploiement............................................................................................14
2.6 Maintenance........................................................................................................................15
3 Modèles de projet logiciel...........................................................................................................15
3.1 Modèle en cascade (Waterfall Model).................................................................................16
3.2 Modèle en V.........................................................................................................................17
3.3 Modèle en Spiral...................................................................................................................18
3.3.1 Définition......................................................................................................................18
3.3.2 Particularité..................................................................................................................18
4 Scrum...........................................................................................................................................19
4.1.1 L’agilité.........................................................................................................................19
4.1.2 Pratiques Agiles............................................................................................................20

Maxime AYI UATM Gasa Formation / SIL3 2

 Notes de Génie Logiciel

1 Introduction
1.1 Qu'est-ce qu'un logiciel ?
Un logiciel est un ensemble de programmes informatiques (du code) mais également un certain
nombre de documents se rapportant à ces programmes et nécessaires à leur installation, utilisation,
développement et maintenance : spécifications, schémas conceptuels, jeux de tests, mode
d'emploi, ... https://perso.liris.cnrs.fr/christine.solnon/agl.html

Exemple de logiciel : Application sur téléphone, site web, jeux vidéo, programme s’exécutant dans
un microcontrôleur embarqué dans une voiture, un train ou un avion

Quels sont les participants à la production de logiciel (différents rôles) ? :

 Le développeur ou Maître d’œuvre : celui qui va écrire le code source du logiciel et le rendre
exécutable
Dans un contrat informatique ou un projet informatique, c’est la personne (généralement un
éditeur de logiciels ou une SSII) qui est chargée de la réalisation de la solution informatique,
objet du contrat conclu avec maître d'ouvrage.
https://www.baumann-avocats.com/definition/moe.php
 Le propriétaire ou Maître d’ouvrage : va payer le développeur et va fournir le logiciel aux
utilisateurs (gratuitement ou contre de l’argent)
C’est, dans un contrat informatique ou un projet informatique, la personne qui est à l'origine
du projet. Le MOA (propriétaire) est donc l'entité juridique, qui confie la réalisation du projet
informatique à un ou plusieurs prestataires informatiques (développeurs).
https://www.baumann-avocats.com/definition/moa.php
 L’utilisateur : celui qui va exploiter le logiciel

Quelques caractéristiques économiques des logiciels :

 Le volume ou la taille : généralement exprimé en nombre de lignes de code source ou

d’instruction (ls ou kls pour milliers de lignes sources)
 Le coût : l’unité de coût des logiciels s’exprime traditionnellement en hommes-mois (hm) ou
en hommes-ans (ha). Exemple : l’emploi de 3 ingénieurs sur une durée de 18 mois
correspond à un coût de 54 hm ou 4,5 ha
 La productivité : d’un développement s’exprime en ls par hm

Maxime AYI UATM Gasa Formation / SIL3 3

 Notes de Génie Logiciel

1.2 Qu'est-ce que Le génie logiciel ?

`Le génie logiciel, l'ingénierie logicielle ou l'ingénierie du logiciel (en 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 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. https://fr.wikipedia.org/wiki/G
%C3%A9nie_logiciel

1.3 Qualité logiciel

Si le génie logiciel est l'art de produire de bons logiciels, il est nécessaire de fixer les critères de
qualité d'un logiciel. Les six groupes d'indicateurs de qualité des logiciels selon la norme ISO 9126 :
https://fr.wikipedia.org/wiki/Qualit%C3%A9_logicielle#:~:text=La%20norme%20ISO
%209126%20(remplac%C3%A9e,explicites%20ou%20implicites%20des%20usagers

 La capacité fonctionnelle. C’est-à-dire la capacité qu'ont les fonctionnalités d'un logiciel à

répondre aux exigences et besoins explicites ou implicites des usagers. En font partie la
précision, l'interopérabilité, la conformité aux normes et la sécurité ;
 La facilité d'utilisation, qui porte sur l'effort nécessaire pour apprendre à manipuler le
logiciel. En font partie la facilité de compréhension, d'apprentissage et d'exploitation et la
robustesse - une utilisation incorrecte n'entraîne pas de dysfonctionnement ;
 La fiabilité, c'est-à-dire la capacité d'un logiciel de rendre des résultats corrects quelles que
soient les conditions d'exploitation. En font partie la tolérance aux pannes - la capacité d'un
logiciel de fonctionner même en étant handicapé par la panne d'un composant (logiciel ou
matériel) ;
 La performance, c'est-à-dire le rapport entre la quantité de ressources utilisées (moyens
matériels, temps, personnel), et la quantité de résultats délivrés. En font partie le temps de
réponse, le débit et la montée en charge - capacité à maintenir la performance même en cas
d'utilisation intensive ;
 La maintenabilité, qui mesure l'effort nécessaire à corriger ou transformer le logiciel. En font
partie l'extensibilité, c'est-à-dire le peu d'effort nécessaire pour y ajouter de nouvelles
fonctions ;
 La portabilité, c'est-à-dire l'aptitude d'un logiciel à fonctionner dans un environnement
matériel ou logiciel différent de son environnement initial. En font partie la facilité
d'installation et de configuration dans le nouvel environnement.

Maxime AYI UATM Gasa Formation / SIL3 4

 Notes de Génie Logiciel

2 Les activités (taches) du processus de développement logiciel

2.1 La Spécification
Cette activité consiste à identifier, lister, prioritiser et catégoriser les exigences et fonctionnalités
que doivent fournir le logiciel en cours de développement. Il s’agit d’identifier ce que le logiciel
devrait faire et comment il devrait fonctionner. Si cette tâche est male exécutée, le logiciel produit ne
répondra pas aux besoins des utilisateurs.

Pour être utiles, les exigences doivent remplir des conditions. Elles doivent être :

- Claires : c’est-à-dire concrète et rédiger dans un langage accessible à tous, sans jargons
inexpliqués.
- Non ambiguës : lors de l’écriture des exigences, s’assurer que les formulations ne pourraient
pas être males interprétées.
- Cohérentes : en effet, les exigences ne doivent pas se contredire et être réalisables
- Prioritisées : Pour implémenter les fonctionnalités les plus importantes d’abord, il faut
assigner des priorités aux exigences. L’acronyme MOSCOW représente une méthode de
prioritisassions. Les consonnes de ce mot correspondent à :
o Must : fonctionnalités jugées nécessaires au succès du projet. Elles doivent être
inclues dans la version courante du logiciel
o Should : fonctionnalités importantes à inclure dès que possible
o Could : fonctionnalités qui pourraient être omises et intégrées dans les versions
suivantes du logiciel. Tout dépendra du temps disponible
o Won’t : fonctionnalités optionnelles, pour lesquelles l’utilisateur est d’accord de
l’intégration dans d’autres versions du logiciel.
- Testable : les exigences doivent être précises et vérifiables

Une application donnée dispose de plusieurs exigences qui peuvent être regroupées dans différentes
catégories. Mise à part le premier bénéfice de la catégorisation qui est le classement des exigences,
le second et principal avantage de la catégorisation est leur utilisation en vue de vérifier que tous les
types d’exigences ont été rédigées. Ainsi, lors de la rédaction des exigences, on peut identifier des
exigences manquantes en passant en revue les catégories. L’acronyme anglais FURPS+ représente
une méthode de catégorisation. Voici les catégories qu’il définit :

- Functionality : Cette catégorie regroupe les exigences qui décrivent les fonctionnalités
générales du logiciel (ce que fait le logiciel, ses interfaces avec d’autres applications, la
sécurité, …).
- Usability : Ces exigences décrivent ce à quoi devrait ressembler le logiciel. Ce sont les
fonctionnalités orientées utilisateurs comme : l’apparence générale de l’application, sa
facilité d’utilisation, les méthodes de navigation, et sa responsivité.
- Reliability : Inclut les exigences traitant de la fiabilité du logiciel. Par exemple, quand le
système devrait être disponible (12 heures par jour de 7h00 à 19h00), à quelle fréquence le
système peut faillir (3 fois par an, et pas plus d'une heure à chaque fois), et sa précision
(marge d’erreur sur un calcul).
- Performance : Ces exigences parlent de l’efficacité et de la performance du système (vitesse
de l’application, consommation mémoire, utilisation du disque, et capacité de la base de
données)
- Supportability : Ces exigences traitent de la facilité à maintenir l’application, à la tester, et à
la configurer (paramétrage pour y intégrer de la souplesse).

Maxime AYI UATM Gasa Formation / SIL3 5

 Notes de Génie Logiciel

- Design constraints : Ce sont des contraintes sur la conception et le design du system qui sont
motivées par d'autres facteurs tels que la plate-forme matérielle, la plate-forme logicielle, les
caractéristiques du réseau ou la base de données. Par exemple, pour des raisons de fiabilité,
on peut exiger que le projet utilise une base de données miroir qui stocke chaque transaction
effectuée, pour qu’en cas de panne de la base de données principale, on ait accès aux
données.
- Implementation requirements : Ce sont des exigences sur la manière dont le logiciel est
construit. Par exemple, le respect de la norme ISO 9000, …
- Interface requirements : Ce sont les exigences liées à l’interfaçage avec les autres systèmes.
Elles indiquent quels autres systèmes échangeront des données avec celui qui est construit.
Elles décrivent des choses comme les types d'interactions qui auront lieu, quand elles se
produiront et le format des données qui seront échangées.
- Physical requirements : Ce sont des exigences physiques qui sont des contraintes sur le
matériel et les périphériques physiques que le système utilisera. Par exemple, ils peuvent
nécessiter une quantité minimale de puissance de traitement, une puissance électrique
maximale, une portabilité aisée (comme une tablette ou un smartphone), écrans tactiles ou
des caractéristiques environnementales (doit fonctionner dans des conditions de chaleurs
extrêmes).

https://businessanalysttraininghyderabad.wordpress.com/2014/08/05/what-is-furps/

Maxime AYI UATM Gasa Formation / SIL3 6

 Notes de Génie Logiciel

2.2 La conception (design)

On peut considérer le développement de logiciels comme un processus qui découpe le système en
éléments de plus en plus petits, jusqu'à ce que les morceaux soient suffisamment petits pour être
implémentés.

De ce point de vue, la conception de haut niveau est la première étape du processus de hachage. Le
but est de diviser le système en morceaux suffisamment autonomes pour être donnés à des équipes
différentes pour implémentation.

La seconde étape du processus de hachage est la conception bas niveau. Elle consiste à affiner les
éléments conçus lors de la conception haut niveau, afin d’avoir une image détaillée du code à écrire
lors de l’implémentation.

Ceci dit la frontière en la conception de haut et bas niveau, n’est pas étanche.

2.2.1 La conception de haut niveau (High‐level design)

Ce qu’on devrait spécifier dans la conception de haut niveau varie quelque peu selon la nature du
projet. Cependant, il existe des constances. Elles sont décrites dans les sections suivantes.

2.2.1.1 Sécurité
Le plus évident signe de la sécurité d’une application est l’écran de login. Mais la conception de haut
niveau doit identifier et répondre aux autres besoins en termes de sécurité qui sont par exemple :

- La sécurité du système d’exploitation : incluant les paramètres d’accès à l’ordinateur (temps

d’expiration du mot de passe, les critères que doivent respecter le mot de passe, …
- La sécurité de l’application : qui consiste à offrir le bon niveau d’accès aux parties de
l’application, à chaque utilisateur.
- La sécurité des données : qui consiste à s’assurer que les informations de la carte de crédit
des utilisateurs ne soient pas hackées.
- La sécurité réseau : même si l’application et les données sont sécurisées, les criminels
peuvent voler les données par le réseau.
- La sécurité physique : qui couvre certains dangers physiques comme la vole du téléphone ou
du laptop sur lequel tourne l’application.

2.2.1.2 Matériels
Ici, on spécifie le matériel nécessaire à l’exécution de l’application. Il s’agit non seulement des
ordinateurs (mainframes, ordinateurs de bureau, ordinateurs portables, tablettes et téléphones),
mais aussi d’autres matériels comme :

- Les imprimantes
- Les composants réseaux (routeurs, modems, câbles, …)
- Les serveurs (de bases de données, web, et d’application)
- Les instruments spéciaux (microscopes, module GPS, …)
- Les matériels Audios et vidéos (webcams, casques et VOIP)

2.2.1.3 Interface utilisateur

Lors de la conception de haut niveau, on esquisse l'interface utilisateur, au moins grossièrement. Par
exemple, on peut indiquer les principaux modes de navigation dans l'application (spécifier les
formulaires ou les fenêtres que l'application va inclure).

Les détails des interfaces seront définis lors de la conception bas niveau.

Maxime AYI UATM Gasa Formation / SIL3 7

 Notes de Génie Logiciel

2.2.1.4 Interfaces internes

Lorsqu’on découpe le programme en morceaux, on doit spécifier comment les morceaux vont
interagir. C’est ce qui est fait dans cette section. Ça permet aux équipes qui ont la responsabilité du
développement des morceaux, de travailler séparément sans avoir besoin d'une coordination
constante.

2.2.1.5 Interfaces externes

De nombreuses applications doivent interagir avec des systèmes externes (exemple API REST). D'une
certaine manière, les interfaces externes sont souvent plus faciles à spécifier que les interfaces
internes car on n’a généralement pas un contrôle sur les deux extrémités de l'interface. Si
l’application doit interagir avec un système, alors ce système a déjà des exigences d'interface qu’on
doit respecter. Inversement, si on souhaite que les futurs systèmes s'interfacent avec le notre, on
peut probablement spécifier n'importe quelle interface qui a du sens pour nous.

2.2.1.6 Architecture
L'architecture d'une application décrit comment ses éléments s'emboîtent au niveau le plus élevé.
Les développeurs choisissent parmi les nombreux types d'architectures qui existent, celle qui
convient le mieux, au problème posé. Voici certaines des architectures les plus courantes :

- Monolithique : Dans une architecture monolithique, un seul programme fait tout. Il affiche
l'interface utilisateur, accède aux données, traite les commandes des clients, imprime les
factures, et fait tout autre chose que devrait faire l'application. Cette architecture présente
des inconvénients importants. En particulier, les pièces du système sont liées étroitement
ensemble, de sorte qu'il ne donne pas beaucoup de flexibilité. Cependant, les architectures
monolithiques présentent certains avantages. Parce que tout est intégré dans un seul
programme, il n'y a pas besoin de communication compliquée à travers les réseaux. Aussi,
elle est utile pour de petites applications développées par un seul programmeur, ou une
seule équipe.
- Client/serveur et multi-tier : Une architecture client/serveur sépare les éléments du système
qui doivent utiliser une fonction particulière (clients) des parties du système qui fournissent
ces fonctions (les serveurs). Cette dissociation permet aux développeurs de travailler sur
l'application séparément. Exemple : architectures à 2, 3 ou plusieurs niveaux (2-tier, 3-tier,
etc. ...)
- Architecture orientée services (ou SOA, Service-Oriented Architecture) : elle peut être
définie comme une façon de bâtir une application logicielle en assemblant plusieurs
composantes logicielles autonomes. Un système logiciel bâti suivant ce modèle est
essentiellement une collection de services qui communiquent entre eux. La communication
peut impliquer une simple transmission de données entre deux services ou la coordination
d'une activité par plusieurs services. Un service SOA est une unité discrète de fonctionnalités
accessibles à distance, exploitée et mise à jour de manière indépendante. Autrement dit,
c’est une composante d’un système informatisé qui met à disposition de ses consommateurs
un accès centralisé à une ou plusieurs fonctions d’affaires. Les consommateurs peuvent être
des acteurs humains, du matériel ou des logiciels qui interviennent dans le processus
d’affaires que supporte ce service. https://www.lesmicroservices.com/2020/05/limites-soa-

Maxime AYI UATM Gasa Formation / SIL3 8

 Notes de Génie Logiciel

esb.html

Ainsi, l’application est conçue avec des capacités de partage, généralement à l’aide d’une API
bien définie. Un aspect important de l’architecture SOA est l’utilisation d’ESB (Entreprise
Service Bus) qui est une famille de produit conçue pour servir d’intermédiaire entre le client
et les services, et entre les services eux-mêmes. Ainsi, lors de la création d’un nouveau
service ayant besoin des données d’un autre service préexistant dans une entreprise, on n’a
pas besoin de toucher à l’ancien code, on a qu’a s’abonner à ce service pour échanger.
Pour plus d’informations lire : https://www.ibm.com/fr-fr/cloud/learn/soa
- Architecture Distribuée : Dans une architecture distribuée, différentes parties de
l'application s'exécutent sur différents processeurs et peuvent tourner en même temps. Les
processeurs peuvent se trouver sur différents ordinateurs dispersés sur le réseau, ou il peut
s'agir de cœurs différents sur un même ordinateur. Les architectures orientées services et
multi-tiers sont souvent distribuées, avec différentes parties du système s'exécutant sur
différents ordinateurs. En général, les applications distribuées peuvent être extrêmement
confuses et difficiles à déboguer.

NB : Une application n'a pas besoin de s'en tenir à une seule architecture. Différentes parties de
l'application peuvent utiliser différentes approches de conception.

Maxime AYI UATM Gasa Formation / SIL3 9

 Notes de Génie Logiciel

2.2.1.7 Les Rapports (états)

Il s’agit ici de définir les rapports qui vont être générés par l’application. Les détails de ces rapports
seront précisés lors de la conception bas niveau.

Voici quelques exemples de rapports pouvant être générés pour diverses applications :

- Liste des clients qui doivent

- Liste des produits qui se vendent le mieux
- Quels employés vendent le plus
- Sur quelles parties d’un jeux les joueurs passent le plus de temps
- …

2.2.1.8 Les autres sorties

En plus des rapports normaux, on doit envisager d'autres types de sorties que l'application pourrait
créer. L'application peut générer des impressions (de rapports et autres), des pages Web, des fichiers
de données, fichiers image, audio (vers des haut-parleurs ou des fichiers audio), vidéo, des e-mails ou
des SMS.

2.2.1.9 La base de données

La conception de bases de données est une partie importante de la plupart des applications. La
première partie de la conception de la base de données consiste à décider du type de base de
données dont le programme aura besoin. On doit préciser si l’application stockera les données dans
des fichiers textes, des fichiers XML, une base de données relationnelle etc …

Si notre choix se porte sur la base de données relationnelles, il faudra préciser quelle base de
données sera utilisée (Oracle, MySQL, Access, …), les tables qui la constitueront et leurs relations. Les
détails (champs, clés primaires, …) seront définis lors de la conception bas niveau.

NB : Les différents diagrammes UML seront utilisés pour modéliser les différents aspects de
l’application

2.2.2 La conception de bas niveau (Low‐level design)

La conception de haut niveau peint les grands traits (structure) d'une application. Elle identifie
l'environnement général (matériel, système d'exploitation, réseau, etc.), l'architecture
(monolithique, client/serveur et orienté service). Elle identifie les principaux composants du système
tels que les modules de génération de rapports, les bases de données et les classes de niveau
supérieur. Elle devrait également esquisser comment les éléments du système vont interagir.

La conception de bas niveau quant à elle, fournit des détails supplémentaires et nécessaires, avant
que les développeurs n’écrivent le code. Elle donne des indications plus précises sur la façon dont les
parties du système fonctionneront seules et ensemble. Elle affine la définition de la base de données,
les classes principales et les interfaces internes et externes.

Ceci dit, la frontière entre la conception de haut niveau et de bas niveau est souvent assez floue.

2.3 Codage
La phase de codage a pour objectif d’écrire le code source correspondant au design précédemment
conçu. Elle transforme des solutions proposées lors de la conception en un code opérationnel.

Maxime AYI UATM Gasa Formation / SIL3 10

 Notes de Génie Logiciel

L’application prends ainsi vie. Pour réussir sa mission, le développeur a besoin de certains outils
comme :

- Un ordinateur performant pour programmer (assez rapide)

- Une connexion internet pour rechercher des solutions aux problèmes
- Un environnement de développement adapté (IDE), avec compilateur, débugger, …
- Un logiciel de gestion de code source ou gestionnaire de code source : Un bon système de
gestion du code source permet de revenir sur les versions antérieures du logiciel et voir
exactement quelles modifications ont été apportées et quand. Si un programme cesse de
fonctionner, on peut extraire les anciennes versions du code pour voir ce qui a changé, et le
corriger. Les programmes de contrôle de code source empêchent également les
développeurs de se marcher sur les pieds en voulant modifier le même code en même temps
- Un outil de profilage de logiciel : permet d’analyser l’exécution d’une application, afin de
connaitre son comportement (liste des fonctions appelées et le temps passé dans chacune
d'elles ; l'utilisation processeur ; l'utilisation mémoire). Exemples de logiciels de profilage du
code source : Valgrind, gprof

Une fois les outils en place, le codage proprement dit démarre. Elle consiste à écrire le code
réalisant les taches identifiées lors de la phase de conception. Mais Pour les problèmes plus
compliqués, il y a une activité préalable qui consiste à rechercher des algorithmes possibles pour
résoudre le problème. Par exemple, un algorithme pour :

- Crypter et décrypter des données

- Trier des données
- Rechercher rapidement des éléments dans une base de données,
- …

C’est seulement après, que le développeur écrit le code correspondant, en faisant attention à bien le
commenter.

Maxime AYI UATM Gasa Formation / SIL3 11

 Notes de Génie Logiciel

2.4 Le test
L’objectif principal de la phase de test est d'étudier le code pour voir s'il répond aux exigences
(spécifications) et s'il fonctionne correctement en toutes circonstances (c’est-à-dire que le
programme fonctionne correctement avec n'importe quel ensemble d'entrées). Au cours de cette
activité, on identifie les comportements problématiques du logiciel (bugs), et on les corrige afin
d’améliorer sa qualité.

Il faut signaler qu’un logiciel à toujours des bugs et que si on veut livrer l’application à temps, on ne
pourra jamais finir de tous les éliminer. Il faut par contre essayer de corriger au maximum, ceux qui
irriteront le plus les utilisateurs.

Pour identifier un maximum de bug, le plus tôt possible, il existe plusieurs niveaux de test décits ci-
après.

2.4.1 Niveaux de test

- Les tests unitaires : permettent de vérifier que des bouts de code (fonctions, méthodes, …)
fonctionnent correctement. Des petits programmes peuvent être écrits pour tester ces
fonctions ou méthodes.
- Les tests d'intégration vérifient que la nouvelle méthode ou fonction fonctionne bien avec
les autres. Ils vérifient que le code existant appelle correctement la nouvelle méthode et que
la nouvelle méthode peut appeler d'autres méthodes correctement. Il est recommandé aussi
de passer un peu de temps à vérifier que le nouveau code n'a pas gâché tout ce qui semble
sans rapport avec lui.
- Les tests de validation permettent de vérifier si toutes les exigences client, décrites dans le
document de spécification du logiciel, sont respectées. Ces tests de validation se
décomposent généralement en plusieurs phases :
o Validation fonctionnelle : les tests fonctionnels assurent que les différents modules
ou composants implémentent correctement les exigences client.
o Validation solution : les tests solution assurent que les exigences client sont
respectées d'un point de vue cas d'utilisation (use cases). Chaque grand cas
d'utilisation est validé isolément, puis tous les cas d'utilisation sont validés ensemble.
L'intérêt de ces tests est de valider la stabilité d'une solution par rapport aux
différents modules qui la composent, en soumettant cette solution à un ensemble
d'actions représentatif de ce qui sera fait en production ;
o Validation performance et robustesse : les tests de performance vérifient la
conformité de la solution par rapport à ses exigences de performance, alors que les
tests de robustesse vont essayer de mettre en évidence des éventuels problèmes de
stabilité et de fiabilité dans le temps (fuite mémoire, résistance au pic de charge,
augmentation de la volumétrie des données, etc.).
- Tests d'acceptation (Acceptance Testing) : L'objectif des tests d'acceptation est de
déterminer si l'application finie répond aux attentes des clients. Normalement, un utilisateur
ou un autre représentant du client s'assoit avec l'application et passe en revue tous les cas
d'utilisation que vous avez identifiés lors de la phase de collecte des exigences pour s'assurer
que tout fonctionne comme convenu

NB : La différence entre les tests d’acceptation et les tests de validation, est que la première est
exécutée par la MOA, alors que la seconde est exécutée par la MOE.

Maxime AYI UATM Gasa Formation / SIL3 12

 Notes de Génie Logiciel

2.4.2 Le déroulement d’un test

Etapes d’un test : 1-Mettre l’objet à tester dans l’état initial
2-Lui faire exécuter des traitements (Actions), pour atteindre l’état souhaité
3-Verifier le résultat obtenu (RO)
Si RO (Résultat Obtenu) diffèrent de RA (Résultat Attendu), alors anomalie

Définir (écrire) un test nécessite :

- De préciser l’état initiale de l’objet à tester

- De préciser la suite des traitements (actions) pour arriver dans l’état à tester
- De préciser le résultat attendu

2.4.3 Les techniques de test

Mais quelles sont les techniques de test les plus utilisées ?

- Tests exhaustifs : Dans certains cas, on pourra peut-être tester une méthode avec toutes les
entrées possibles. Example méthode avec 2 entrées baouléennes "oui" et "non". Même si ce
type de test exhaustif prouve de manière concluante qu'une méthode fonctionne
correctement dans toutes les circonstances, la plupart du temps, les méthodes demandent
trop de combinaisons de paramètres d'entrée pour qu'on puisse toutes les essayer.
- Test boîte noire (black box) : Avec cette technique, on prétend que la méthode, fonction ou
composant logiciel est une boîte noire à l'intérieur de laquelle on ne peut pas jeter un coup
d'œil. On sait ce qu'elle est censée faire, mais on a aucune idée de comment cela fonctionne.
On applique ensuite toutes sortes d'entrées sur la méthode pour vérifier son comportement.
o Même si on ne sait pas comment fonctionne la méthode, on peut essayer de deviner
des valeurs qui pourraient la perturber. En règle générale, celles-ci impliquent des
valeurs spéciales telles que 0 pour les nombres et vide pour les chaînes. Ils peuvent
aussi inclure les valeurs les plus grandes et les plus petites possibles. Pour les
chaînes, ça pourrait signifier une chaîne entièrement vide ou tous les caractères ∼.
o Enfin, regardez les valeurs limites. Si une méthode attend un paramètre à virgule
flottante compris entre 0,0 et 1.0, assurez-vous qu'il peut gérer ces deux valeurs.
- Tests boîte blanche (white box) : Avec cette technique, on peut connaître le fonctionnement
de la méthode, fonction, ou composant logiciel. On conçoit alors les tests pour essayer de
faire planter l'objet tester (méthode, fonction, … ).
- Tests boîte grise (gray box) : c'est une combinaison de tests boîte blanche et boîte noire. On
connaît certains éléments internes de la méthode testée. Cette connaissance partielle
permet de concevoir des tests spécifiques pour la vérifier.

Maxime AYI UATM Gasa Formation / SIL3 13

 Notes de Génie Logiciel

2.5 Le déploiement
La phase de déploiement a pour objectif de déplacer le logiciel développé de l’environnement de
développement vers un environnement de production, de manière à ce que les utilisateurs puissent y
accéder.

Appelé aussi “phase de livraison” et “phase de mise en exploitation” : La phase de déploiement

regroupe toutes les activités qui mènent à l’installation et la mise en marche de l’application
développée (installation des serveurs, setup et configuration des composants du logiciel développés
et le test de déploiement).

Il est recommandé d’élaborer un plan de déploiement anticipant les problèmes qui pourraient se
poser, et de mettre en œuvre une stratégie de déploiement permettant de limiter les risques.

2.5.1 Le plan de déploiement

Un plan de déploiement doit inclure les étapes nécessaires au déploiement, les endroits possibles où
les choses pourraient mal tourner et des solutions de contournement.

Ainsi la planification du déploiement commence par, un listing des étapes à suivre. Il s'agit, de décrire
en détail comment chaque étape est censée fonctionner. Ensuite, pour chaque étape, lister les
façons dont cette étape pourrait échouer. Décrire ensuite les mesures qu'on prendra si l'un de ces
échecs se produisait. Décrire les solutions de contournement ou les approches alternatives qu'on
pourrait utiliser.

Souvent, l'action qui détermine le point de non-retour consiste à migrer les utilisateurs vers le
nouveau système. On peut configurer des réseaux, installer de nouvelles imprimantes et des
ordinateurs, etc.…, mais tant que personnes utilisent la nouvelle application, il est relativement facile
de revenir en arrière. Comment faire migrer intelligemment les utilisateurs vers le nouveau
système ?

2.5.2 Stratégies de déploiement

Il existe 4 stratégies :

- Déploiement par étapes (staged deployment): il s’agit de créer une zone entièrement
fonctionnelle où on pourra résoudre tous les problèmes avant la migration réelle. Une fois
que l'installation fonctionne correctement, des utilisateurs choisis testent la nouvelle
application dans un environnement plus réaliste que celui utilisé par les développeurs. Ils
signalent les problèmes que les autres utilisateurs remarqueraient. Et lorsque tous les
nouveaux bugs sont corrigés, on peut dans la nuit déployer sur le PC de tous les utilisateurs.
- Transfert graduel (gradual cutover) : on installe la nouvelle application pour certains
utilisateurs pendant que d'autres utilisateurs continuent travailler avec leur système
préexistant. On intègre progressivement tous les autres utilisateurs. L'avantage de cette
approche est qu’on ne détruit pas la productivité de chaque utilisateur si quelque chose se
passe mal.
- Déploiement incrémentiel (incremental deployment) : on livre aux utilisateurs, les
fonctionnalités de l’application une à une. D’abord une première, puis lorsqu’ils y sont
habitués, une seconde. Ainsi de suite. Cette méthode ne fonctionne pas bien avec les
grandes applications monolithiques car on ne peut généralement pas installer seulement une
partie du système.

Maxime AYI UATM Gasa Formation / SIL3 14

 Notes de Génie Logiciel

- Tests parallèles (parallel testing) : Selon la complexité du nouveau système, on peut

l'exécuter en parallèle pendant un certain temps pour faire ressortir les bugs. Par exemple,
s’il y a suffisamment d'utilisateurs, une petite partie d'entre eux pourrait utiliser le nouveau
système en parallèle avec l'ancien. Ils utiliseraient le nouveau système pour faire leur travail
comme si le nouveau système était entièrement déployé. Pendant ce temps, un autre groupe
d'utilisateurs continuerait à utiliser l'ancien système. L'ancien système est celui qui compte
réellement. Le nouveau n'est utilisé que pour voir ce qui se passerait s'il était déjà installé.
Après quelques jours, semaines ou peu importe le temps qu'il faudra pour qu’on ait
suffisamment confiance dans le nouveau système, on commencera à migrer les autres
utilisateurs vers le nouveau système. On peut faciliter le processus en utilisant le
Déploiement par étapes ou graduel

2.6 Maintenance
La phase de maintenance : a pour objectif de corriger les bugs et problèmes identifiés durant
l’utilisation du logiciel (après le déploiement). Elle intègre aussi les évolutions de fonctionnalité.

Les tâches de maintenance peuvent être divisées en quatre catégories :

- Les tâches de perfectionnement qui améliorent, modifient ou ajoutent des fonctionnalités à

un projet.
- Les tâches d’adaptation qui modifient une application pour qu'elle fonctionne avec des
changements dans l'environnement tel qu'une nouvelle version du système d'exploitation ou
des modifications d'interfaces externes.
- Les tâches correctives sont des corrections de bugs.
- Les tâches préventives (refactoring) modifient le code pour faciliter sa maintenance dans
avenir.

NB : Pour effectuer les tâches de maintenance avec succès, vous aurait besoin de suivre à nouveau,
les étapes du développement logiciel : recueil des exigences, conception de haut niveau, conception
de bas niveau, codage, tests et déploiement. (En fait, vous pouvez souvent abréger certaines de ces
étapes. Par exemple vous n'aurez probablement pas besoin d'une conception approfondie de de
haut niveau pour corriger un bug d'une seule ligne.)

3 Modèles de projet logiciel

Il existe plusieurs modèles de développement de logiciels qui intègrent les taches vues
précédemment, et qui visent à produire des logiciels de qualité dans les temps et budgets impartis.

Une façon de catégoriser les modèles de développement est la manière dont ils gèrent les exigences.
Il y des modèles prédictifs et des modèles adaptatifs.

Dans un modèle prédictif de développement, on prévoit à l'avance ce qui doit être fait, puis on le
fait. On utilise les exigences pour concevoir le système et on utilise la conception comme modèle
pour écrire le code. On teste le code, et on demande aux clients de vérifier que le logiciel fait
vraiment ce que la spécification dit qu'il devrait, puis on sabre le champagne.

Maxime AYI UATM Gasa Formation / SIL3 15

 Notes de Génie Logiciel

Malheureusement, il est souvent difficile de prédire exactement ce qu'une application doit faire et
comment on devrait la construire. En effet, les besoins clients peuvent changer au cours du projet,
ou on peut ne pas être familier d’une technique de programmation et notre conception ne marchera
pas du premier coup.

Un modèle adaptatif vous permet de modifier les objectifs du projet si nécessaire au cours du
développement. Au lieu de choisir un design au départ et de s'acharner dessus même quand la
conception n'est plus pertinente, un modèle adaptatif vous permet de réévaluer et de décider
périodiquement si vous devez changer de direction.

L’inspecteur de police dans les séries, est une belle analogie du modèle adaptatif. Cela commence
par un meurtre. Son objectif est de trouver le tueur. Il sait certaines des choses qu’il doit faire
(interroger des témoins, vérifiez les enregistrements de téléphone portable, ...), mais il ne sait pas
exactement où l'affaire va le mener. Il suit le premier indice, qui le mène à un deuxième, puis à un
troisième, et ainsi de suite. Chaque fois qu’il trouve un nouvel indice, il met à jour la direction de
l'enquête.

On pourrait penser qu'un modèle adaptatif est toujours préférable à un modèle prédictif, mais il y a
des cas dans lequel un modèle prédictif fonctionne assez bien. Par exemple, les modèles prédictifs
fonctionnent bien lorsque le projet est relativement petit ; on sait exactement ce qu'on doit faire, et
le délai est suffisamment court pour que les exigences ne changent pas au cours du développement.

Dans la suite de ce cours nous verront plusieurs modèles prédictifs (Modèle en cascade, Modèle en
V) et plusieurs modèles adaptatifs (Modèles en spiral, Modèle Agile : Srum)

3.1 Modèle en cascade (Waterfall Model)

C’est modèle prédictif qui suppose qu’on termine chaque étape (spec, design, codage, …)
complètement et minutieusement avant de passer à l'étape suivante.

Maxime AYI UATM Gasa Formation / SIL3 16

 Notes de Génie Logiciel

Le modèle en cascade peut fonctionner raisonnablement bien si toutes les hypothèses suivantes sont
satisfaites :

- Les exigences sont précisément connues à l'avance.

- Les exigences ne comprennent aucun élément à haut risque non résolu.
- Les exigences ne changeront pas beaucoup pendant le développement.
- L'équipe a une expérience antérieure avec des projets similaires afin de savoir ce qu'implique
une telle réalisation.
- Il y a suffisamment de temps pour tout faire séquentiellement.

3.2 Modèle en V
Le modèle en V est essentiellement un modèle en cascade qui a été plié en forme de V au niveau du
codage.

Les tâches sur le côté gauche du modèle en V, décomposent l'application de son niveau conceptuel le
plus élevé en morceaux implémentables, c'est la décomposition.

Les tâches sur le côté droit du modèle en V, partent des morceaux finis d'application et tendent vers
des niveaux de plus en plus élevés d’abstraction. Au niveau le plus bas, les tests vérifient que le code
fonctionne. Au niveau suivant, la vérification confirme que l'application satisfait aux exigences, et la
validation confirme que l'application répond aux besoins des clients. Cette démarche de remontée
jusqu'au sommet conceptuel de l'application est appelée intégration. Chacune des tâches de gauche
correspond à une tâche de droite avec un niveau d'abstraction similaire.

Ce modèle améliore le modèle en cascade. En effet, au lieu d’attendre la 4ieme phase pour rédiger
les tests, on le fait au fur et à mesure de l’évolution de la spécification, au codage, en passant par la
conception. Chacune de ces phases à un ensemble de test qui lui correspond. Ainsi, un problème
détecté lors des tests unitaires sera résolu au niveau du code ; alors qu’un problème identifié lors des
tests d’intégration sera résolu au niveau de la conception du composant incriminé. Idem pour les
tests de validation.

On comprend donc que ce découpage des tests permet non seulement de détecter au plus vite les
bugs, et mais aussi de réduire les couts.

Maxime AYI UATM Gasa Formation / SIL3 17

 Notes de Génie Logiciel

3.3 Modèle en Spiral

3.3.1 Définition
Cycle en spirale (spiral model) : est un modèle de Cycle de développement logiciel qui
reprend les différentes étapes du cycle en cascade. Par l'implémentation de versions
successives, le cycle recommence en proposant un produit de plus en plus complet et sûr.

3.3.2 Particularité
Ce modèle est très orienté gestion des risques. De manière itérative, 1-on définit un premier objectif,
2-on identifie et résout les risques liés à celui-ci, puis 3-on développe et teste la solution retenue, et
enfin 4-on planifie l’itération suivante. Plus on évolue, plus on implémente des fonctionnalités et plus
grand est le projet. L’objectif de chaque itération, c’est de décider si on poursuit ou pas le
développement : Go or No Go

Ce modèle est adapté aux réalisations expérimentales, dont on se doute de la faisabilité sans en être
sûr à 100%.

Exemple : Par exemple, lors d’une première itération du cycle en spiral, on construit les spécifications
de l’application. L'équipe examine les alternatives, identifie les risques les plus importants (peut-être
les exigences de performance ne sont pas claires), résout les risques et construit un ensemble de
spécifications prototypes. Les membres de l'équipe analysent ensuite les exigences et vérifient
qu'elles sont correctes. À ce stade, les exigences vérifiées deviennent les exigences réelles.

On procède de la même façon pour les autres phases du cycle de développement.

Maxime AYI UATM Gasa Formation / SIL3 18

 Notes de Génie Logiciel

4 Scrum
Scrum est un modèle de développement logiciel conforme aux principes agile. Dans un premier
temps, nous allons rappeler les éléments clés de l’agilité, puis nous allons introduire le modèle de
développement logiciel Scrum, qui se réfère à lui.

Mais avant, il faut noter ceci : si en résumant le génie logiciel à son niveau le plus fondamental, on dit
que ses objectifs sont simplement de produire des logiciels utiles le plus rapidement possible, alors
on peut dire que tous les modèles de développement logiciel décrits jusqu'à présent se concentrent
sur le premier de ces objectifs (produire des applications utiles. Ils essaient d'assurer que le résultat
soit conforme aux spécifications et que les spécifications spécifient en fait quelque chose d'utile).
Ainsi, Ces modèles ne se concentrent pas sur l’accélération de la vitesse de développement.

Les modèles comme Scrum, intègrent certaines des meilleures caractéristiques des modèles décrits
précédemment, ainsi que de nouvelles fonctionnalités qui aident les développeurs à produire
rapidement des livrables utiles à l'utilisateur final.

4.1.1 L’agilité
L’agilité est une philosophie, un ensemble de principes applicables qui permettent une certaine
rapidité et flexibilité dans le développement. Les modèles répondant aux principes agiles, permettent
de s’adapter aux évolutions constantes des problèmes que résolvent le logiciel en cours de
développement.

Ainsi les modèles agiles respectent entre autres les 4 valeurs suivantes :

 Les personnes et leurs interactions sont plus importantes que les process et les outils : Les
équipes ont la possibilité de décider des outils et processus à utiliser. S’il y a un arbitrage à
faire, ce sera toujours en faveur de ce que les individus auront préférés et non de ce qu’une
procédure aura demandée
 Un logiciel qui fonctionne prime sur de la documentation : l’objectif est d’arriver très vite à
un produit fini et opérationnel, sans trop passer du temps sur la documentation. Il y a
toujours de la doc à faire mais on ne passe pas trop de temps à la peaufiner.
 La collaboration avec les clients est préférable à la négociation contractuelle : Le contrat
n’est pas abandonné, mais on préfère collaborer à arriver rapidement au résultat plutôt que
de renégocier le contrat à chaque fois.
 La réactivité (réponse) au changement passe avant le suivi d’un plan : Si un problème
survient au cours du développement, il faut réagir vite plutôt que de se demander ce que le
plan à ou n’a pas prévu.

Agile énonce aussi les 12 principes suivants :

 Satisfaire le client en livrant tôt et régulièrement des logiciels utiles, qui offrent une véritable
valeur ajoutée
 Accepter les changements, même tard dans le développement
 Livrer fréquemment une application qui fonctionne
 Collaborer quotidiennement entre clients et développeurs
 Bâtir le projet autour de personnes motivées en leur fournissant environnement et support,
et en leur faisant confiance
 Communiquer par des conversations en face à face
 Mesurer la progression avec le logiciel qui fonctionne
 Garder un rythme de travail durable

Maxime AYI UATM Gasa Formation / SIL3 19

 Notes de Génie Logiciel

 Rechercher l’excellence technique et la qualité de la conception

 Laisser l’équipe s’auto organiser
 Rechercher la simplicité
 A intervalles réguliers, réfléchir aux moyens de devenir plus efficace

4.1.2 Pratiques Agiles

Scrum se caractérise par une équipe polyvalente (développeurs, testeurs, propriétaire, scrum master
(animateur), architecte…) et réduite de 3 à 9 personnes maxi, qui développent le projet par itération
successives appelées Sprints de 1 à 4 semaines maxi. A la fin de chaque sprint, le produit développé
est présenté au client, et ses remarques sont pris en compte dans les sprints suivants (intégration au
product backlog). Avant le démarrage de chaque projet, on liste les fonctionnalités de l’application
dans un document qui porte le nom de Backlog du produit logiciel. Chaque fonctionnalité se voit
attribuer une priorité et un cout de réalisation. Avant le démarrage du sprint, on choisit les
fonctionnalités qui sont retenues pour être développé ; Ce sous ensemble constitue le Backlog du
sprint (sprint backlog), dont on suit l’évolution quotidiennement au cours des Daly scrum meeting.

Il faut signaler que les développeurs sont conscients du fait que les besoins utilisateurs peuvent
évoluer et qu’ils peuvent développer des fonctionnalités qui deviendront inutiles.

Le principal avantage de cette méthode est la réactivité à la demande des utilisateurs, et la

réduction de la documentation.

C’est un modèle itératif et incrémentale à la fois :

 Incrémentale : Le logiciel est construit morceau par morceau au cours des sprints. Chaque
nouvelle partie venant s’ajouter à l’existant.
 Itératif : développement par incréments de produit réalisé à l’issue de d’itérations (sprints)
qui constituent des périodes de temps dans lesquelles sont effectuées des activités qui
seront répétées dans les itérations suivantes (spécification, conception, codage, test)

Maxime AYI UATM Gasa Formation / SIL3 20