Chapitre 2 Cycle de Vie Du Développement Logiciel

Développeur d’Applications Web & Mobile
Atelier de génie logiciel

Chapitre 2 : Cycle de vie du développement
logiciel
Prof. Mohamed Hamidi AU :2023/2024

Introduction
Le Cycle de vie du développement d’un logiciel est un ensemble d’étapes de la

réalisation, de l’énoncé des besoins à la maintenance au retrait du logiciel sur le
marché informatique. De façon générale, on peut dire que le cycle de vie du
logiciel est la période de temps s’étalant du début à la fin du processus du logiciel.
Il commence donc avec a proposition ou la décision de développer un logiciel et se
termine avec sa mise hors service.
2
Développeur d’Applications Web & Mobile M. Hamidi
1. Étapes du cycle de vie du développement d’un logiciel
Le développement de logiciel impose d’effectuer un certain nombre d’étapes. Il existe de
nombreux modèles de cycle de vie du développement d’un logiciel, les plus courants
comportent les phases suivantes :
• La communication
• La collection des exigences
• L’étude du préalable (faisabilité ou opportunité)
• Définition et analyse de besoins (Spécification)
• La conception du logiciel
• Le codage
• Les tests
• L’intégration
• L’installation
• La maintenance
• La disposition
3
1.1 Communication
C’est la première étape du cycle de vie de développement logiciel où l’utilisateur

initie la demande du produit logiciel souhaité. Ce dernier contact le service du «
provider » et essaie de négocier les termes du contrat. Il soumet alors sa demande
à l’entreprise du fournisseur des services par écrit.
4
1.2. La collection des exigences
Cette étape permet à l'équipe de développement de faire progresser le projet

informatique jusqu'à ce qu'il devienne visible. À ce stade, l'équipe de
développement collabore avec des partenaires pour discuter des problèmes
spécifiques du domaine et fournir autant d'informations que possible sur les
différentes exigences. À ce niveau, les exigences sont examinées et classées en
fonction des besoins des utilisateurs, distinguant entre les exigences du système et
les exigences fonctionnelles. Les exigences sont rassemblées en utilisant diverses
pratiques, notamment :
• Analyse du système ou du logiciel existant ou obsolète
• Entretiens avec les utilisateurs et les développeurs
• Consultation de diverses bases de données
• Collecte de réponses au moyen de questionnaires
5
1.3. Etude des préalable
Le développement est précédé d’une étude d’opportunité ou étude préalable.

Cette phase a comme objectif de répondre aux questions suivantes : Pourquoi
développer le logiciel ? Comment procéder pour faire ce développement ? Quels
moyens faut-il mettre en œuvre ?
Elle comprend à la fois des aspects techniques et de gestion. Parmi les tâches
techniques, groupées sous le terme étude préalable, on peut citer :
• Dresser un état de l’existant et faire une analyse de ses forces et faiblesses ;
• Identifier les idées ou besoins de l’utilisateur ;
• Formuler des solutions potentielles ;
• Faire des études de faisabilité ;
• Planifier la transition entre l’ancien logiciel et le nouveau, s’il y a lieu ;
• Affiner ou finaliser l’énoncé des besoins de l’utilisateur.
6
1.4. Définition et analyse des besoins
Pendant la phase d'analyse, aussi connue sous le nom de phase de spécification,

on examine les besoins de l'utilisateur ou du système global et on établit les
fonctionnalités que le logiciel devra offrir. Les résultats de cette phase sont
documentés dans un rapport appelé "cahier des charges logiciel" ou "spécification
logicielle", en anglais "software requirements", "software specification" ou
"requirements specification". Il est crucial que cette spécification se limite à définir
les caractéristiques fondamentales du logiciel, afin de laisser place aux décisions de
conception (il ne faut pas prendre de décisions d'implémentation à ce stade). Une
spécification comprend les éléments suivants :
7
• description de l’environnement du logiciel ;

• spécification fonctionnelle (functional specification), qui définit toutes les
fonctions que le logiciel doit offrir ;
• comportement en cas d’erreurs, c’est-à-dire dans les cas où le logiciel ne peut pas
accomplir une fonction ;
• performances requises (performance requirements), par exemple : temps de
réponse, encombrement en mémoire, sécurité de fonctionnement ;
• les interfaces avec l’utilisateur (user interface), en particulier le dialogue sur
terminal, la présentation des écrans, la disposition des états imprimés, etc.
• interfaces avec d’autres logiciels et le matériel ;
• contraintes de réalisation, telles que l’environnement de développement, le
langage de programmation à utiliser, les procédures et normes à suivre, etc.
8
Il est judicieux de préparer pendant la phase d’analyse les procédures qui seront
mises en œuvre pour vérifier que le logiciel, une fois construit, est conforme à la
spécification, que nous l’appellerons test de réception (acceptance test). Durant la
phase d’analyse, on produit également une version provisoire des manuels
d’utilisation et d’exploitation du logiciel. Les Points clés :
• Pour les gros systèmes, il est difficile de formuler une spécification définitive. C’est
pourquoi on supposera que les besoins initiaux du système sont incomplets et
inconsistants.
• La définition des besoins et la spécification des besoins constituent des moyens

de description à différents niveaux de détails, s’adressant à différents lecteurs.
9
• La définition des besoins est un énoncé, en langue naturelle, des services que le
système est sensé fournir à l’utilisateur. Il doit être écrit de manière à être
compréhensible par les décideurs côté client et côté contractant, ainsi que par les
utilisateurs et acheteurs potentiels du système.
• La spécification des besoins est un document structuré qui énonce les services de
manière plus détaillée. Ce document doit être suffisamment précis pour servir de
base contractuelle entre le client et le fournisseur du logiciel. On peut utiliser des
techniques de spécification formelle pour rédiger un tel document, mais cela
dépendra du bagage technique du client.
10
• Il est difficile de détecter les inconsistances ou l’incomplétude d’une spécification

lorsqu’elle est décrite dans un langage naturel non structuré. On doit toujours
imposer une structuration du langage lors de la définition des besoins.
• Les besoins changent inévitablement. Le cahier des charges doit donc être conçu
de manière à être facilement modifiable
11
1.5. Conception du logiciel
La phase d’analyse est suivie de la phase de conception, généralement décomposée

en deux phases successives :
• Conception générale ou conception architecturale

• Conception détaillée
12
Conception générale ou conception architecturale (preliminary design ou

architectural design) : Si nécessaire, il faut commencer par l’ébauche de plusieurs
variantes de solutions et choisir celle qui offre le meilleur rapport entre coûts et
avantages. Il faut ensuite figer la solution retenue, la décrire et la détailler.
En particulier, il faut décrire l’architecture de la solution, c’est-à-dire son organisation
en entités, les interfaces de ces entités et les interactions entre ces entités.
Ce processus de structuration doit être poursuivi jusqu’à ce que tous les éléments du
document de spécification aient été pris en compte. Le résultat de cette démarche
est « un document de conception générale ».
Durant la phase de conception générale, il faut également préparer la phase
d’intégration. A cet effet, il faut élaborer un plan d’intégration, y compris un plan de
test d’intégration.
13
Conception détaillée (detailed design) : La conception détaillée affine la conception

générale. Elle commence par décomposer les entités découvertes lors de la
conception générale en entités plus élémentaires.
Cette décomposition doit être poursuivie jusqu’au niveau où les entités sont faciles à
implémenter et à tester, c’est-à-dire correspondent à des composants logiciels
élémentaires.
Ce niveau dépend fortement du langage de programmation retenu pour
l’implémentation. Il faut ensuite décrire chaque composant logiciel en détail : son
interface, les algorithmes utilisés, le traitement des erreurs, ses performances, etc.
14
L’ensemble de ces descriptions constitue le document de conception détaillée.

Pendant la conception détaillée, il faut également préparer la vérification des
composants logiciels élémentaires qui fera l’objet de la phase des tests unitaires. Le
résultat est consigné dans un document appelé plan de tests unitaires. Si nécessaire,
il faut de plus compléter le plan d’intégration, car de nouvelles entités ont pu être
introduites pendant la conception détaillée.
15
1.6. Codage
Après avoir achevé la phase de conception détaillée, on peut progresser vers la phase
de codage, parfois désignée comme la phase de construction ou d'implémentation.
Au cours de cette étape, la conception détaillée est concrétisée à travers la rédaction
du code source dans un langage de programmation donné.
16
1.7. Tests
La phase d'implémentation est ensuite suivie par la phase de test. Au cours de cette
étape, les éléments du logiciel sont examinés, intégrés, et l'ensemble du logiciel est
évalué pour vérifier s'il répond aux spécifications établies lors de la phase d'analyse.
Souvent, cette phase est subdivisée en plusieurs étapes distinctes.
17
1.7. Tests
Les tests unitaires ont pour objectif de vérifier que chaque petite unité de code
(généralement une fonction ou une méthode) fonctionne correctement, en isolant
cette unité du reste du système. Ils permettent de s'assurer que chaque composant
individuel du logiciel produit les résultats attendus.
Framework de tests : Pour écrire et exécuter des tests unitaires de manière efficace,
les développeurs utilisent généralement des frameworks de tests, tels que JUnit pour
Java, NUnit pour .NET, pytest pour Python, etc. Ces frameworks facilitent la création,
l'exécution et la gestion des tests unitaires.
18
1.8. Intégration
Une fois que la phase de test de tous les composants a été menée à bien, on peut
passer à l'assemblage de ces composants, une étape réalisée au cours de la phase
d'intégration. Durant cette phase, on vérifie également la cohérence et le bon
fonctionnement des composants assemblés, ce que l'on appelle le test d'intégration.
Les actions suivantes peuvent donc être distinguées :
• construire par assemblage un composant à partir de composants plus petits ;
• exécuter les tests pour le composant assemblé et enregistrer les résultats ;
• comparer les résultats obtenus aux résultats attendus ;
• si le composant n’est pas conforme, engager la procédure de modification ;
• si le composant est conforme, rédiger les comptes-rendus du test d’intégration et
archiver sur support informatique les sources, objets compilés, images
exécutables, les jeux de tests et leurs résultats.
19
1.9. Installation
Une fois que le logiciel a été intégré, on peut le déployer dans son environnement de
production ou dans un environnement de simulation similaire, puis le soumettre à
des tests pour vérifier s'il fonctionne conformément aux exigences définies dans la
spécification élaborée lors de la phase d'analyse.
20
1.9. Maintenance
Après l'installation, la phase d'exploitation et de maintenance entre en jeu. Le logiciel

est désormais utilisé dans son environnement opérationnel, où son comportement
est surveillé, et des modifications sont apportées si nécessaire. Cette dernière
activité est appelée la maintenance du logiciel, qui peut inclure la correction de
défauts, l'amélioration des performances, l'ajustement du logiciel à de nouveaux
environnements ou à des besoins modifiés.
21
1.9. Maintenance
On peut distinguer trois principales formes de maintenance logicielle :

• Maintenance Corrective: Cette forme de maintenance vise à corriger les erreurs,
les bugs et les problèmes identifiés dans le logiciel en production. Il s'agit de
rétablir le bon fonctionnement du logiciel.
• Maintenance Perfective: La maintenance perfective a pour objectif d'améliorer

les performances, l'efficacité et la convivialité du logiciel sans introduire de
nouvelles fonctionnalités majeures. Elle cherche à optimiser l'existant.
• Maintenance Adaptative: La maintenance adaptative intervient lorsque le logiciel

doit être ajusté pour s'adapter à un nouvel environnement, à des normes ou à des
besoins changeants. Elle peut également concerner des modifications
importantes pour répondre à de nouveaux besoins.
22
1.10. Disposition
Le temps joue un rôle crucial dans le développement des produits logiciels. Il est
essentiel de surveiller le logiciel, car sa performance peut se dégrader avec le temps.
Il peut devenir complètement obsolète ou nécessiter une mise à jour importante.
Cette phase de gestion comprend des activités telles que l'archivage des données, la
gestion des composants logiciels, la fermeture du système, la planification des
activités et la terminaison du système, y compris le moment approprié pour mettre
fin au logiciel. Cette phase est liée à la gestion des versions du logiciel
23

Chapitre 2 Cycle de Vie Du Développement Logiciel

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 2 Cycle de Vie Du Développement Logiciel

Transféré par

Droits d'auteur :

Formats disponibles

Développeur d’Applications Web & Mobile

Atelier de génie logiciel

Prof. Mohamed Hamidi AU :2023/2024

Le Cycle de vie du développement d’un logiciel est un ensemble d’étapes de la

C’est la première étape du cycle de vie de développement logiciel où l’utilisateur

Cette étape permet à l'équipe de développement de faire progresser le projet

Le développement est précédé d’une étude d’opportunité ou étude préalable.

Pendant la phase d'analyse, aussi connue sous le nom de phase de spécification,

• description de l’environnement du logiciel ;

• La définition des besoins et la spécification des besoins constituent des moyens

• Il est difficile de détecter les inconsistances ou l’incomplétude d’une spécification

La phase d’analyse est suivie de la phase de conception, généralement décomposée

• Conception générale ou conception architecturale

Conception générale ou conception architecturale (preliminary design ou

Conception détaillée (detailed design) : La conception détaillée affine la conception

L’ensemble de ces descriptions constitue le document de conception détaillée.

Après l'installation, la phase d'exploitation et de maintenance entre en jeu. Le logiciel

On peut distinguer trois principales formes de maintenance logicielle :

• Maintenance Perfective: La maintenance perfective a pour objectif d'améliorer

• Maintenance Adaptative: La maintenance adaptative intervient lorsque le logiciel

Vous aimerez peut-être aussi