Le document décrit les étapes du cycle de vie d'un logiciel, incluant l'analyse des besoins, la conception, le codage, les tests, le déploiement et la maintenance. Différents modèles de cycle de vie tels que le modèle en cascade, le modèle en V, le modèle incrémental et le modèle en spirale sont présentés, chacun ayant ses avantages et inconvénients. La maintenance est également abordée, soulignant l'importance d'adapter le logiciel post-livraison selon les besoins des utilisateurs.

1. Chapitre 2. Cycles de vie d’un
logiciel
Préparé par :
Jalila BEN GHORBEL
Et
Rabia AZIZA

2. Plan
 Les étapes principales de création d’un logiciel
 Les cycles de vies

3. Les étapes principales de
création d’un logiciel

4. Les étapes principales de création
d’un logiciel
Analyse des
Conception
besoins
Codage Test
Déploiement Maintenance

5. Analyse des besoins
 Appelée aussi Spécification des besoins
 Ce que peut contenir cette phase :
 Mise du logiciel dans son contexte : type de produit,
nouveau/altéré, etc.
 Étude de l’existant :
 Étude des produits similaires dans le marché (national ET
international)
 Critiquer les produits concurrents (points positifs et
négatifs)
 Étude du processus/logiciels existants à l’entreprise
 Comment fonctionnait l’entreprise avant le produit à créer
?
 la description du fonctionnement du processus de
l’entreprise peut aider à la conception du produit (étape
suivante)

6. Analyse des besoins
 Ce que peut contenir cette phase :
 Description des besoins et conditions qui doivent être
respectées
 Besoins fonctionnels : les fonctionnalités que le produit doit
automatiser
 Exemple : lister les produits, calculer le panier, trier, etc.
 Besoins non fonctionnels :
 Besoins de performance (disponibilité, rapidité de calcul,
rapidité de réponse, taille en mémoire, sécurité, ergonomie,
etc.)
 Besoins logiciels : si l’entreprise exige l’utilisation d’un outil
logiciel
 Peu contenir un cahier des charges
 Dans les grands projets, le cahier des charges est signé
 Phase difficile car le client et les informaticiens
(développeurs, analystes, concepteurs, etc.) ne
parlent pas le même langage

7. Conception
 La conception utilise les spécifications pour
décider des solutions proposées
 La conception peut contenir :
 Description des fonctionnalités de l’application (le
déroulement des processus)
 Les fonctionnalités précisées lors de la spécification des
besoins sont les objectifs à réaliser (de point de vue
fonctionnel). La conception décrit COMMENT arriver à
effectuer ces fonctionnalités
 Exemple : la fonctionnalité ‘Lister les produits’ : on doit se
connecter à la BD, sélectionner les produits à lister,
organiser la liste (trie ou autre), transférer cette liste à
l’interface finale, parcourir cette liste élément par élément et
afficher sous forme d’un tableau le nom du produit, sa
catégorie, son prix, sa remise, sa disponibilité, etc.

8. Conception
 La conception peut contenir :
 Conception architecturale : L’architecture logicielle de
l’application
 On peut trouver différents types d’architecture :
 Architecture en couches
 Architecture centrée sur les données
 Architecture orientée objets
 Architecture orientée agents
 Architecture orientée composants
 Architecture orientée services
 Etc.

9. Conception
 La conception peut contenir :
 Conception architecturale :
 Exemples : Architecture par couches
Couche de présentation
Couche métier
Couche d’accès aux données
Base(s) de
données

10. Conception
 La conception peut contenir :
 Conception architecturale :
 Exemples : Architecture orientée objets (d’une application
web) Couche de présentation
(interfaces utilisateur)
Html/... Reporting Pdf
Couche de contrôle
Couche métier
Entités Gestion
Couche d’accès aux données
Data transfer object Data acces object
(DTO) (DAO)
Base(s) de
données

11. Conception
 La conception peut contenir :
 Conception architecturale :
 Exemples : Architecture orientée composants

12. Conception
 La conception peut contenir :
 Conception des interfaces
 Plan de navigation
 Charte graphique
 Conception des données
 Type de la base de données : BDR (relationnelle), DWH
(entrepôt de données), BDXML, BDOO (orientée objet), etc.
 La structure de la base : quelles entités composent la base de
données et quelles sont les relations entre elles
 Conception de l’architecture matérielle
 Les composants matériels de l’architecture et la relation entre
ces composants

13. Conception
 La conception peut contenir :
 Conception de l’architecture matérielle
 Exemple : Architecture 3 tiers

14. Conception
 La conception peut contenir :
 Conception de l’architecture matérielle
 Exemple :

15. Codage
 Le codage transforme les solutions proposées lors
de la conception en un code opérationnel
 Les techniques de codage dépendent
intrinsèquement du langage de programmation
utilisé et du paradigme
 On peut arriver à cette phase sans connaitre
d’avance quels outils / langages de programmation
on va utiliser
 Le codage doit être bien conforme à la conception

16. Test
 Phase de test et de validation
 Les tests déterminent
 Les bugs techniques : erreurs dans le code ou
comportement anormal d’un processus
 Les bugs fonctionnels : si le logiciel fait ce qu’on attend de
lui par rapport aux spécifications
 La qualité du logiciel
 Plusieurs types de test :
 Les tests unitaires : orientés code
 Les tests d’acceptation vérifient les attentes d’un produit
logiciel
 Etc.
 On peut utiliser des logiciels de tests, des techniques,
des benchmarks, des fiches de tests

17. Déploiement
 Appelée aussi ‘phase de livraison’ ou ‘phase de
mise en exploitation’
 La phase de déploiement regroupe toutes les
activités qui mènent à l’installation et mise en
marche de l’application développée
 Installation des serveurs : serveur web, serveur
d’application, serveur de données, serveur FTP,
serveur d’authentification, etc.
 Setup et configuration des composants du logiciel
développé
 Tests de déploiement : pour se rassurer de la bonne
connectivité et exécution du système

18. Maintenance
 La maintenance consiste à modifier le produit après
sa livraison au client
 La maintenance peut avoir un but
 Correctif : rectifier les anomalies et corriger les erreurs
du système
 Évolutif : modifier le système pour rajouter des
fonctionnalités ou prendre en compte les demandes
d'évolution des utilisateurs
 Le degré de maintenance dépend de la qualité de la
conception

19. Les cycles de vie d’un logiciel

20. Cycle de vie
 Un projet réalisation d’un système d’information est
composé d’étapes
 Le découpage d’un projet en étapes et
l’organisation de ces étapes varie selon le modèle
utilisé
 On appel cycle de vie d’un logiciel l’ensemble des
étapes à suivre lors de la création du logiciel ainsi
que leur enchaînement

21. Cycle de vie
 Il existe deux types de méthodes :
Méthodes Méthodologies
classiques Agiles
 Modèle en cascade
 Modèle en V
 Modèle incrémental
 Modèle en spirale

22. Cycles de vie classiques
Modèle en Cascade
Spécification
Validation
Conception
générale
Vérification
Conception
détaillée
Vérification
Codage
Tests unitaires
Intégration
Tests d’intégration
Mise en
production
Validation
Maintenance

23. Cycles de vie classiques
Modèle en Cascade
Avantages Inconvénients
• Facile à utiliser et à • Sensibilité aux nouveaux
comprendre besoins : refaire tout le
• Structure simple pour une procédé
équipe inexpérimentée • Une phase ne peut
• Fonctionne bien quand la démarrer que si l’étape
qualité est beaucoup plus précédente est finie
importante que les couts et • Le produit n’est visible qu’à
le temps la fin
• Les risques se décalent
vers la fin
• Très faible implication du
client

24. Cycles de vie classiques
Modèle en V
Expression des Validation des
besoins besoins
Spécification Validation
fonctionnelle fonctionnelle
Modélisation Validation des
conceptuelle concepts
Tests par
Conception
modules et Tests
(modules)
du système
Codage

25. Cycles de vie classiques
Modèle en V
Avantages Inconvénients
• Met l’accent sur les • Ne gère pas les
tests et la activités parallèles
validation et donc • Ne gère pas les
accroît la qualité changements des
• Chaque livrable spécifications
doit être testable • Ne contient pas
• Facile à utiliser et d’activités
planifier d’analyse de risque

26. Cycles de vie classiques
Modèle Incrémental
 Chaque incrément est une construction partiel le
du logiciel
 Trie les spécifications par priorités
 Chaque incrément implémente un ou plusieurs
spécifications jusqu’à ce que la totalité du produit
soit finie
Spécification Conception Codage Tests Incrément 1
Spécification Conception Codage Tests Incrément 2
Spécification Conception Codage Tests Incrément N
.............

27. Cycles de vie classiques
Modèle Incrémental
Avantages Inconvénients
• Développement de • Exige une bonne
fonctionnalités à risque planification et une
en premier bonne conception
• Chaque incrément donne • Exige une vision sur le
un produit fonctionnel produit fini pour pouvoir
• Le client intervient à la fin bien le diviser en
de chaque incrément incréments
• Utiliser l’approche « • Le coût total du système
diviser pour régner » peut être cher
• Le client entre en relation
avec le produit très tôt

28. Cycles de vie classiques
Modèle en Spirale

29. Cycles de vie classiques
Modèle en Spirale
Avantages Inconvénients
• Inclut l’analyse de risque • L’évaluation des risques
et le prototypage peut prendre beaucoup de
• Fonctions critiques temps
développées en premier • Le modèle est très
• Feedback rapide du cl ient complexe
• Une évaluation continue
du procédé
• Chaque cycle est
composé des même
activités que du modèle
en cascade