IGL - Cours 2 - Cycles de Vie

COURS IGL
COURS 2
CYCLES DE VIE DE Cours 2 :
LOGICIELS Cycles de vie

de logiciels
Mostefai Mohammed Amine – m_mostefai@esi.dz

Batata Sofiane – s_batata@esi.dz 1
Cours 2 – Cycle de vie de OBJECTIFS DU COURS
logiciels
Objectifs du cours
 Découvrir les principales activités de développement de

logiciels
Cours IGL, Copyright © 2011, ESI

 Connaître les cycles de vie (SDLC) et leur motivation
 Connaître les SDLC classiques et les méthodes agiles
 Pourvoir choisir un SDLC sur la base des données
concernant un projet de développement
 Prise de contact avec la méthodologie UP
 Découvrir les outils de support (CASE)
2
Section 1 :
Section 2 : Cycle
Activités de INTRODUCTION
de vie AU GÉNIE
développement LOGICIEL
Cours 2
Section 3 : Cycles de vie
Modèles de Section 4 : de logiciels
procédés Méthodes Agiles
classiques
Section 6 : Outils
Section 5 :
de support
Méthodologie UP 3
(CASE)

COURS IGL
Cycles de vie
de logiciels
Section 1 : Activités de
développement

Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION
Etapes de développement
 Tout logiciel passe par plusieurs étapes pour être

développé

 Ces étapes peuvent être résumées dans les étapes ci-
dessous :
Définition Développement Support
5
Définition
 Définir les besoins :

 Que doit faire le logiciel

 De quelle façon
 Et sous quelles conditions
6
Développement
Transformation des données collectées pendant l’étape de

définition en plusieurs produits :

 Logiciel fonctionnel
 Code source
 Produits connexes
7
Support
Correction

Prévention Changements Adaptation
Amélioration
8
Support
 Correction : réparation des fonctions qui ne marchent pas

ou qui ne marchent pas comme souhaité.

 Adaptation : adaptation de fonctions aux évolutions
technologiques actuelles.
 Amélioration : en terme de performance, ergonomie, …
 Prévention : Rendre le logiciel plus facile à la
maintenance
9
Activités
 Chaque projet de développement est composé de

plusieurs activités

 Chaque activité est conduite et réalisée par plusieurs
acteurs
 Une activité a des entrées et des sorties. Les livrables
font partie des sorties des activités,
 Les livrables sont des produits ou des documents
produits par une activités et utilisé par les activités qui
en dépendent
 Par exemple : document, planning, code source sont tous
des livrables
10
Principales activités
 Tous les projets de développement ont des activités

communes

Analyse de
Conception
besoins
Codage Tests
Maintenance
11
Analyse de besoins
 Conditions qui doivent être respectées par un nouveau

produit ou un produit altéré

 Aussi appelé spécifications
 Dans les grands projets (par exemple projets nationaux),
c’est composé d’un cahier de charges
 Cette phase est difficile car le client et les développeurs
ne parlent pas le même langage
 Le livrable de cette phase est un document de
spécification
12
Conception
 La conception utilise les spécifications pour décider les

solutions relatives au différents problèmes de
développement

 La conception décide aussi d’un planning de la solution
 La conception décide de l’architecture de la solution
 Si le produit est centré sur l’utilisateur, la conception
propose une ébauche de l’interface utilisateur
13
Codage
 Le codage est une activité très importante du GL

 Le codage transforme les solutions proposées lors de la

conception en un code opérationnel
 La conception et le codage peuvent toutes les deux
produire du code source, mais c’est l’étape de codage qui
rend ce code opérationnel.
 Les techniques de codage dépendent intrinsèquement du
langage de programmation utilisé et du paradigme.
14
Tests
 Les tests déterminent la qualité du logiciel

 Les tests déterminent si le logiciel fait ce qu’on attend de

lui par rapport aux spécifications
 Plusieurs types de test dont deux principaux : tests
unitaires et tests d’acceptation
 Les tests unitaires sont orientés code. Ils se rédigent
durant l’activité de codage et se revérifient pendant la
phase de test
 Les tests d’acceptation vérifient les attentes d’un produit
logiciel
15
Maintenance
 La maintenance consiste à modifier le produit (le

logiciel) après sa livraison au client

 Son but est correctif ou évolutif
 La maintenance a deux facettes : organisationnelle et
technique
 L’aspect organisationnel concerne l’organisation des
équipes pour une réactivité face aux changements
 L’aspect technique concerne une maintenance sans
impact négatif sur le produit
 Le degré de maintenance dépend de la qualité de la
conception
16
COURS IGL
Cycles de vie
de logiciels
Débat (10 Mns)
17

COURS IGL
Cycles de vie
de logiciels
Section 2 : Cycle de vie de
logiciels
18

Cours 2 – Cycle de vie de S E C T I O N 2 – C YC L E S
logiciels DE VIE DE LOGICIELS
Procédé Logiciel
 Un procédé logiciel (software process) est un ensemble

d’activités conduisant à la production d’un logiciel

 Ils sont aussi appelés cycle de vie d’un logiciel (SDLC)
 Un procédé définit les étapes qui le composent ainsi que
leur enchaînement
 Les Cycles de vie de logiciels sont complexes et
dépendent fortement des acteurs qui dirigent les
activités
 Les activités des procédés ne peuvent être automatisées
mais il y a des outils de support, appelés outils CASE
(Computer-Aided Software Engineering)
19
Modèles de procédés
 Un modèle de procédé est une abstraction d’un procédé

 Un modèle décrit le procédé selon une certaine

perspective
 Un procédé logiciel est une application d’un modèle pour
un projet spécifique, qui peut inclure une certaine
adaptation
20
Modèles de procédés – Pourquoi ?
 Pour maîtriser les gros projets

 Pour découper le projet et affecter correctement les

tâches
 Pour anticiper et gérer les risques
21
 Il existe deux types de modèles de procédés :

Méthodes
classiques
Méthodologie
agiles
22
Caractéristiques
Méthodes classiques • Modèles stricts

• Etapes très clairement définies
• Documentation très fournie
• Fonctionne bien avec les gros projets et les projets
gouvernementaux
Méthodologies agiles • Modèles incrémentaux et itératifs

• Petites et fréquentes livraisons
• Accent sur le code et moins sur la documentation
• Convient aux projets de petite et moyenne taille
23
Choix d’un modèle
 Aucun modèle n’est meilleur que l’autre

 Le choix se fait selon certains critères tels que la nature

du projet, sa taille, la nature du client et les compétences
de l’équipe
24
COURS IGL
Section 2 : Débat (5 mn) Cycles de
• Qu’est-ce qu’un gros projet ? Vie des
• Comment mesure-t-on un gros projet ? Logiciels
• Pourquoi un modèle de procédé est -il
essentiel pour conduire un projet de
développement ?
25

COURS IGL
Cycles de vie
de logiciels
Section 3 : Cycles de vie
classiques
26

Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES
Modèle en cascade
 L’un des premiers modèles proposés, inspiré du modèle

de Royce (1970)

 Aussi appelé modèle linéaire
 Le résultat de chaque phase est un ensemble de livrables,
 Une phase ne peut démarrer que si la précédente est finie
 Le modèle académique par excellence
27
Modèle en cascade

28
Modèle en cascade
Avantages :
 Facile à utiliser et à comprendre

 Un procédé structuré pour une équipe inexpérimentée
 Idéal pour la gestion et le suivi de projets
 Fonctionne très bien quand la qualité est plus importante
que les coûts et les délais
29
Modèle en cascade
Inconvénients :
 Les besoins des clients sont très rarement stables et

clairement définis
 Sensibilité aux nouveaux besoins : refaire tout le procédé
 Une phase ne peut démarrer que si l’étape précédente est
finie
 Le produit n’est visible qu’à la fin
 Les risques se décalent vers la fin
 Très faible implication du client
30
Modèle en cascade
Quand l’utiliser ?
 Quand les besoins sont connus et stables

 Quand la technologie à utiliser est maîtrisée
 Lors de la création d’une nouvelle version d’un produit
existant
 Lors du portage d’un produit sur une autre plateforme
31
Modèle en V
 Variante du modèle en cascade qui fait l’accent sur la

vérification et la validation

 Le test du produit se fait en parallèle par rapport aux
autres activités
32
Modèle en V

33
Modèle en V
Avantages :
 Met l’accent sur lest tests et la validation et par

conséquent, ça accroît la qualité du logiciel
 Chaque livrable doit être testable
 Facile à planifier dans une gestion de projets
 Facile à utiliser
34
Modèle en V
Inconvénients :
 Ne gère pas les activités parallèles

 Ne gère pas explicitement les changements des
spécifications
 Ne contient pas d’activités d’analyse de risque
35
Modèle en V
Quand l’utiliser:
 Quand le produit à développer à de très hautes exigences

de qualité
 Quand les besoins sont connus à l’avance
 Les technologies à utiliser sont connues à l’avance
36
Prototypage
 Le projet se fait sur plusieurs itérations

 Les développeurs construisent un prototype selon les

attentes du client
 Le prototype est évalué par le client
 Le client donne son feedback
 Les développeurs adaptent le prototype selon les besoins
du client
 Quand le prototype satisfait le client, le code est
normalisé selon les standards et les bonnes pratiques
37
Prototypage
Ecouter le

client
Développer
Evaluer le
le
prototype
prototype
38
Prototypage
Avantages
 Implication active du client

 Le développeur apprend directement du client
 S’adapte rapidement aux changements des besoins
 Progrès constant et visible
 Une grande interaction avec le produit
39
Inconvénients
Inconvénients
 Le prototypage implique un code faiblement structuré

 Degré très faible de maintenabilité
 Le processus peut ne jamais s’arrêter
 Très difficile d’établir un planning
40
Inconvénients
 Quand les besoins sont instables et/ou nécessitent des

clarifications
 Peut être utilisé avec le modèle en cascade pour la
clarification des besoins
 Quand des livraisons rapides sont exigées
41
Modèle Incrémental
 Chaque incrément est une construction partielle du

logiciel

 Trie les spécifications par priorités et les regroupent
dans des groupes de spécifications
 Chaque incrément implémente un ou plusieurs groupes
jusqu’à ce que la totalité du produit soit finie
42
Spécifications Conception Implémentation Tests Incrément 1

Spécifications Conception Implémentation Tests Incrément 2
Spécifications Conception Implémentation Tests Incrément N
43
Avantages
 Développement de fonctionnalités à risque en premier

 Chaque incrément donne un produit fonctionnel
 Le client intervient à la fin de chaque incrément
 Utiliser l’approche « diviser pour régner »
 Le client entre en relation avec le produit très tôt
44
Inconvénients
 Exige une bonne planification et une bonne conception

 Exige une vision sur le produit fini pour pouvoir le
diviser en incréments
 Le coût total du système peut être cher
45
 Quand la plupart des spécifications sont connues à

l’avances et vont être sujettes à de faibles évolutions
 Quand on veut rapidement un produit fonctionnel
 Pour des projets de longues durées
 Pour des projets impliquant de nouvelles technologies
46
Modèle en spirale
 Modèle itératif
 Des incréments sous forme de cycle

 À la fin de chaque cycle on détermine les objectifs du
cycle suivant
 Chaque cycle est composé des même activités que du
modèle en cascade
 Inclut l’analyse de risque et le prototypage
47
Modèle en spirale

48
Modèle en spirale
Détermination des objectifs

 En terme de fonctionnalité, de performance, de coût,...etc.

 Déterminer les alternatives : développer, réutiliser,
acheter, sous-traiter…etc.
 Contraintes : coûts, plannings, … etc.
49
Modèle en spirale
Identification et évaluation de risques

 Etudier les alternatives de développement

 Identification des risques : technologie non maîtrisées,
équipe peu expérimentée, planning trop serré, …etc.
 Evaluation des risques : voir si les risques peuvent
impacter le projet et à quel degré
50
Modèle en spirale
Développement et test
 Contient pratiquement la plupart des activités :

conception, codage, test, … etc.
Planification de la prochaine itération

 Un planning de l’itération
 Un plan de tests
51
Modèle en spirale
Avantages
 Identification rapide des risques

 Impacts minimaux des risques sur le projet
 Fonctions critiques développées en premier
 Feedback rapide du client
 Une évaluation continue du procédé
52
Modèle en spirale
Inconvénients
 L’évaluation des risques peut prendre beaucoup de temps

 Le modèle est très complexe
 La spirale peut s’éterniser
 Les développeurs doivent être réaffectés pendant les
phases de non-développement
 Les objectifs ne sont pas souvent faciles à formuler
53
Modèle en spirale
Quand est-ce que l’utiliser ?

 Quand le prototypage est exigé

 Quand le risque du projet est considérable
 Quand les spécifications ne sont pas stables
 Pour les nouveaux produits
 Quand le projet implique de la recherche et de
l’investigation
54
Section 3 : Débat (15 Mn) COURS IGL
Cycles de vie
• Quel est le modèle le plus simple et le de logiciels
plus complexe ?
• Quels sont les critères qui définiront
quel modèle choisir ?
• Quelle est la chose la plus difficile pour
un modèle incrémental ou itératif ?
55

COURS IGL
Cycles de vie
de logiciels
Section 4 : Méthodologies
Agiles
56

logiciels MÉTHODES AGILES
Apparition
 Au milieu des années 90, un groupe d’expert en Cycles de

vie de logiciels voulaient proposer de nouveaux modèles

 Les nouveaux modèles sont plus « légers » : moins de
documentation et moins de contrôle sur le procédé
 Ces modèles s’adresse à des projets de petite ou moyenne
taille avec une équipe réduite
 Ces modèles permettent de s’ajuster rapidement aux
changements des spécifications tout en garantissant des
livraisons fréquentes
 Ces modèles sont qualifiés de « modèles agiles »
57
Principes agiles
Individus et Logiciel
interactions au fonctionnel au lieu

lieu de processus de documentation
et outils massive
Collaboration du Réagir au
client au lieu de changements au
négociation de lieu de suivre le
contrats plan
58
Principes
INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET

OUTILS

 Les collaborateurs sont la clé du succès
 Les « seniors » échoueront s’ils ne collaborent pas en tant
qu’équipe
 Un bon collaborateur n’est pas un forcément un bon
programmeur. C’est quelqu’un qui travaille bien en équipe
 Une surabondance d’outils est aussi mauvaise que le manque
d’outils
 Démarrer petit et investir peu au démarrage
 Construire l’équipe c’est plus important que construire
l’environnement
59
Principes
LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION

MASSIVE

 Un code sans documentation est un désastre
 Trop de documents est pire que pas de documents
 Difficulté à produire et à synchroniser avec le code
 Souvent les documents sont des « mensonges » formels
 Le code ne ment jamais sur lui-même
 Produire toujours des documents aussi courts que
possible
60
Principes
COLLABORATION DU CLIENT AU LIEU DE LA

NÉGOCIATION DE CONTRATS

 Très difficile de décrire la totalité du logiciel depuis le
début
 Les projets réussis impliquent les clients d’une manière
fréquente et régulière
 Le client doit avoir un contact direct avec l’équipe de
développement
61
Principes
RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN

 Un logiciel ne peut pas être planifié très loin dans le futur

 Tout change : technologie, environnement et surtout les
besoins
 Les chefs de projets classiques fonctionnent sur la base de
GANTT, PERT et le système de tâches
 Avec le temps, les diagrammes se dégradent car des tâches
s’ajoutent et d’autres deviennent non nécessaires
 Une meilleure stratégie est de planifier très court (02
semaines à 01 mois)
 Plannings détaillés pour la semaine à venir, rigoureux pour les
trois mois et très vagues au-delà
62
Principes
LES DOUZE PRINCIPES AGILES

1. Toujours satisfaire le client à travers des livraisons rapides

et continues
2. Bien accueillir tous les changements même les tardifs
3. Livrer fréquemment un système fonctionnel
4. Les clients et les développeurs doivent collaborer
5. Conduire le projet autour d’équipes motivées
6. La meilleure méthode de faire circuler l’information c’est le
contact direct entre collaborateurs
7. La première mesure d’avancement c’est un logiciel
fonctionnel
63
Principes
LES DOUZE PRINCIPES AGILES

8. Le développement doit être durable et à un rythme constant

9. La bonne conception et l’excellence technique augmentent
l’agilité
10. Simplifier au maximum
11. Les meilleurs architectures, besoins et conceptions
proviennent d’équipes qui s’organisent d’elles-mêmes
12. L’équipe s’améliore d’une manière autonome et régulière
64
Principales méthodologies agiles
Adaptive
Feature Driven
Software
Development Crystal Clear

Development
(FDD)
(ASD)
Dynamic
Rapid Application
Software
Development Scrum
Development
(RAD)
Method (DSDM)
Extreme
Programming
(XP)
65
Méthodologie XP
 eXtreme Programming
 Créée en 1995 Kent Beck and Ward Cunningham

 XP est un moyen léger, efficace, à bas risques, flexible,
scientifique et amusant de développer des logiciels
 Destinée à des équipes de moyenne taille avec des
spécifications incomplets et / ou vagues
 Le codage est le noyau de XP
66
Méthodologie XP - Fondamentaux
Implication Test unitaire

massive du client continu (TDD)
Itérations
Programmation courtes et
par paires livraisons
fréquentes
67
Méthodologie XP – Principales activités
Tests
Codage

(pendant le
(noyau de XP)
codage)
Ecoute (le Conception

client ou le (encore basée
partenaire) sur le codage)
68
Méthodologie XP – Les 12 pratiques
1- LE JEU DE PLANNING :
 Le client et les développeurs décident quoi mettre dans la

prochaine livraison en triant les spécifications par priorité
 L’estimation est la responsabilité du développeur, pas du chef
de projet ni du client
2 – DE PETITES ET FRÉQUENTES LIVRAISONS :
D’abord livrer un système minimaliste puis le faire évoluer à
travers des versions à des délais très courts
69
3- LES MÉTAPHORES
 Exprimer de manière naturelle et très simples des fonctions

du système
 Le client et les développeurs doivent s’accorder sur les
métaphores
4 – CONCEPTION SIMPLE
Le système doit être conçu de la manière la plus simple possible
5 – TESTS
Les développeurs rédigent les tests unitaires d’une manière
continue, Le client rédige les tests d’acceptation des
fonctionnalités,
70
6 – REFACTORING
Les développeurs améliorent continuellement le code tout en

veillant à le garder fonctionnel
7 – PROGRAMMATION PAR PAIRES
La totalité du code est écrite par deux programmeurs sur une
seule machine. L’un est appelé conducteur (driver) et l’autre
navigateur. Les rôles s’inversent régulièrement.
8 - PROPRIÉTÉ COLLECTIVE
N’importe qui peut changer le code n’importe où dans le
système à n’importe quel moment
9 - 40 HEURES LA SEMAINE
Le travail ne doit pas dépasser 40 heures par semaine
71
10 – intégration continue
Construire le système à chaque fois qu’une tâche est terminée.

11 – Le client est sur site
Le client est tout le temps présent avec l’équipe pour participer
et répondre aux questions
12 – Les standards de codage
À cause de la propriété collective, des standards (une charte de
codage) doivent être établis et adhérés par l’équipe de
développement
72
Méthodologie XP – Avantages
 Implication active du client

 Forte réactivité des développeurs

 Responsabilisation et solidarité de l’équipe
 Appel aux meilleurs pratiques de développement
 Souplesse extrême
73
Méthodologie XP – Inconvénients
 Demande une certaine maturité des développeurs

 La programmation par paires n’est toujours pas applicable

 Difficulté de planifier et de budgétiser un projet
 Stress dû aux devoir de l’intégration continue et des livraisons
fréquentes
 La faible documentation peut nuire en cas de départ des
développeurs
74
Méthodologie Scrum
 Inspiré par une approche développée en 1986 par H. Takeuchii

et II.. Nonaka, le terme « Scrum » utilisé dans « Wiicked
Problems, Rightteous Solutions » par DeGrace et Stahl en 1991

 Utilisé comme méthodologie dans le livre : « Agile Software
Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en
2001
75
Méthodologie Scrum - Principes
Simple Empirique
• Peut être combiné avec • Itérations courtes (sprints)
d’autres méthodes • Feedback continu

• Compatible avec les best
practices
Techniques simples Equipes

• Sprints de 2 à 4 semaines • Auto-organisation
• Besoins capturés en tant que • Multi-compétences
user stories
Optimisation
• Détection rapide des
anomalies
• Organisation simple
• Requiert l’ouverture et la
visibilité
76

77

Processus Backlog
• Sprint • Product Backlog
• Sprint Backlog

Equipe Réunions
• Srum Master • Scrum quotidien
• Product Owner • Planning
• Team • Revue
• Users and stakeholders • Rétrospective
Suivi
• Rapports
• Vélocité
78
Méthodologie Scrum - Avantages
 Méthode très simple et très efficace

 Adoptée par les géants du marché : Microsoft, Google, Nokia..

 Orientée projet contrairement à XP qui est orientée
développement
 Peut inclure d’autres activité venant d’autres méthodologies
(surtout XP)
79
Méthodologie Scrum - Inconvénients
 N’est pas 100% spécifique au GL

 Difficulté de budgétiser un projet

80
Section 4 : Débat (10 mns) COURS IGL
• Quelles sont les différences entre une
méthode agile et une méthode classique ? Cycles de vie
de logiciels
• Quels sont les points forts des méthodes
agiles ?
• Quels en sont les points faibles ?
• Quelle est la différence entre Scrum et XP ?
• Est-ce que Scrum et XP peuvent -elles être
combinées ?
81

COURS IGL
Cycles de vie
de logiciels
Section 5 : Processus Unifié
(Unified Process / UP)
82

logiciels MÉTHODOLOGIE UP
UP
 UP est un modèle de procédé très populaire

 UP est incrémental et itératif

 UP a plusieurs implémentation et / ou variation dont la plus
célèbre est RUP (Rational Unified Process)
83
UP – Implémentations
Agile Unified
Basic Unified
RUP (Rational Process (AUP)
Process (BUP)

Unified Process) par Scott W.
par IBM
Ambler
Enterprise Essential Unified

Open Unified
Unified Process Process (EssUP),
Process (OpenUP)
(EUP), une une légère
par Eclipse
extension de RUP variation
Oracle Unified
Method (OUM),
84
UP – Principes
Processus Basé sur les

itératif et cas
incrémental d’utilisation
Centré sur Accent sur

l’architecture les risques
85
UP - Principes
PROCESSUS ITÉRATIF ET INCRÉMENTAL

 UP est composé de quatre phase : l’analyse de besoins

(inception), l’élaboration, la construction et la transition
 Chaque phase peut être décomposée en plusieurs itérations
 Chaque itération produit un incrément du produit
86
UP - Principes
PROCESSUS BASÉ SUR LES CAS D’UTILISATION

 Les cas d’utilisation formalisent les spécifications

fonctionnelle du produit
 Chaque itérations prend un ensemble de cas d’utilisation et les
traite selon plusieurs workflows : modélisation métier, analyse
de besoins, analyse et conception, implémentation, tests et
déploiement
87
UP - Principes
PROCESSUS CENTRÉ SUR L’ARCHITECTURE

 UP supporte plusieurs architectures logicielles

 La phase d’élaboration fournit l’architecture de l’exécutable
 Cette architecture est une implémentation partielle qui sert de
fondation aux développements futurs
88
UP - Principes
PROCESSUS QUI MET L’ACCENT SUR LES RISQUES


 Traitement des risques dans les premières phases du projet
89
UP – Cycle de vie
 UP est composé de quatre phases principales : analyse de

besoins (inception), élaboration, construction et transition

90
UP – Cycle de vie
 UP est un processus bidimensionnel

 La phase horizontale représente le temps et les étapes

 La phase verticale représente les activités
91
UP – Cycle de vie

92
UP – Cycle de vie
PHASE D’ANALYSE DE BESOINS (INCEPTION)

 La plus petite phase et la plus courte

 Etablit une vision globale du projet
 Essaye d’identifier les principaux cas d’utilisations
 Propose une ou plusieurs architectures du système
 Identifie les risques
 Etablit un planning préliminaire
 Peut annuler le projet si l’étape prend trop de temps
93
UP – Cycle de vie
PHASE D’ÉLABORATION
 Capturer la majorité des cas d’utilisation

 Valider l’architecture du système
 Eliminer les facteurs de risque
 Peut décider de ne pas aller au-delà
 Livrable : prototype exécutable d’architecture
 Livrable : un planning détaillé et précis sur la phase de
construction
94
UP – Cycle de vie
PHASE DE CONSTRUCTION
 La phase la plus longue du projet

 Le reste du système est développé durant cette phase
 Chaque itération produit un incrément vers le système final
95
UP – Cycle de vie
PHASE DE TRANSITION
 Le système est déployé chez les utilisateurs

 Les feedbacks récoltés serviront à améliorer le système
96
UP – Activités
Expression de besoins
 Recenser les besoins fonctionnels et non fonctionnels du

système
 Le diagramme UML de cas d’utilisation est utilisé pour cette
phase
97
UP – Activités
Analyse
 Détaille les besoins en spécifications détaillées

 Une ébauche de la conception
98
UP – Activités
Conception
 Décide comment sera construit le système durant

l’implémentation
 Définition des sous-systèmes et composants
 Création d’abstractions de la solution
99
UP – Activités
Implémentation
 Traduire les résultats de la conception en un système

opérationnel
 Livrables : code source, exécutables, …etc.
100
UP – Activités
Tests
 Vérification et validation des résultats de l’implémentation

101
UP – Avantages
 Méthodologie complète

 Largement adoptée en entreprise
 Intégration avec UML
 Séparation concise des phases et des livrables
 Des formations / livres / tutoriaux disponibles
102
Débat (05 Mns) COURS IGL
• La méthode UP est -elle une méthode
agile ? Cycles de vie
de logiciels
• C’est une méthode bidimensionnelle,
pourquoi ?
• C’est une méthode itérative et
incrémentale, pourquoi ?
• Pourquoi est-elle largement adoptée à
votre avis ?
103

COURS IGL
Section 6 : Outils de Cycles de vie
de logiciels
supports (CASE – Computer-
Aided Software
Engineering)
104

Cours 2 – Cycle de vie de OUTILS CASE
logiciels
Introduction
 CASE est un nom donné aux logiciels utilisés dans les

différentes activités de GL (besoins, conception,…)

 Exemples : compilateurs, éditeurs, débogueurs, …etc.
 Le but des outils CASE est d’automatiser les tâches et /
ou gérer le projet de développement
105
logiciels
Limite des CASE
 Le développement est essentiellement basé sur

l’intelligence humaine, là, les outils CASE ne peuvent pas
trop intervenir

 Le gros d’un projet de développement c’est la
communication entre les membre de l’équipe. Là aussi,
les CASE n’ont pas une grande intervention.
106
logiciels
Classification des CASE
Les outils CASE peuvent être classés :

 D’un point de vue fonctionnel : selon la fonction de
l’outil.
 D’un point de vue activité : selon les activités dans

lesquelles intervient l’outil
107
logiciels
Classification fonctionnelle
Outil Exemples Références
Outils de planification Outils PERT, outils Microsoft Project, Excel,

d’estimation, tableurs GanttProject, DotProject
Editeurs Editeurs de texte, éditeurs vi, bloc notes, GIMP,
d’image, éditeurs de Photoshop, Visio
diagrammes
Gestion de Gestion de versions, gestion de SVN, CVS, Team
configuration builds Foundation Server,
ClearCase
Outils de support de Générateurs de code, outils Team Foundation Server,
procédé d’assistance, IDE Accurev, Enterprise
Architect
Outils de traitement de Compilateurs, interpréteurs,
langage débogueurs
108
logiciels
Classification fonctionnelle
Outil Exemples Références
Outils de test Environnements de tests, Junit, Nunit, TestWorks,

outils de tests unitaires Bugzilla
Outils de Documents de projet, Word, Open Office,
documentation documents de code Sandcastle, Doxygen,
javadoc
109
COURS IGL
Cycles de vie
de logiciels
Démonstration : outil de
génération de documents
110

COURS IGL
Cycles de vie
de logiciels
gestion de tests unitaires
111

COURS IGL
Cycles de vie
de logiciels
gestion de tests unitaires
112

COURS IGL
Débat (05 Mns) Cycles de vie

de logiciels
• Quels sont les outils CASE avec
lesquels vous avez déjà travaillé ?
• Quels sont ceux que vous souhaiteriez
découvrir ?
113

Cours 2 – Cycle de vie de BIBLIOGRAPHIE
logiciels
Bibliographie
 Software Engineering Right Edition, Ian Sommerville,

Addison Wesley, 2007

 Software Development and Professional Practice, John
Dooley, APress, 2010
 Software Development Life Cycle (SDLC), Togi Berra,
course session 2
 Rational Unified Process - Best Practices for Software
 Development Teams, IBM / Rational, 1998
114

IGL - Cours 2 - Cycles de Vie

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

IGL - Cours 2 - Cycles de Vie

Загружено:

Авторское право:

Доступные форматы

COURS IGL

LOGICIELS Cycles de vie

Mostefai Mohammed Amine – m_mostefai@esi.dz

 Découvrir les principales activités de développement de

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

 Tout logiciel passe par plusieurs étapes pour être

Cours IGL, Copyright © 2011, ESI

Définition Développement Support

 Définir les besoins :

Cours IGL, Copyright © 2011, ESI

Transformation des données collectées pendant l’étape de

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

 Correction : réparation des fonctions qui ne marchent pas

Cours IGL, Copyright © 2011, ESI

 Chaque projet de développement est composé de

Cours IGL, Copyright © 2011, ESI

 Tous les projets de développement ont des activités

Cours IGL, Copyright © 2011, ESI

 Conditions qui doivent être respectées par un nouveau

Cours IGL, Copyright © 2011, ESI

 La conception utilise les spécifications pour décider les

Cours IGL, Copyright © 2011, ESI

 Le codage est une activité très importante du GL

Cours IGL, Copyright © 2011, ESI

 Les tests déterminent la qualité du logiciel

Cours IGL, Copyright © 2011, ESI

 La maintenance consiste à modifier le produit (le

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

 Un procédé logiciel (software process) est un ensemble

Cours IGL, Copyright © 2011, ESI

 Un modèle de procédé est une abstraction d’un procédé

Cours IGL, Copyright © 2011, ESI

Modèles de procédés – Pourquoi ?

 Pour maîtriser les gros projets

Cours IGL, Copyright © 2011, ESI

 Il existe deux types de modèles de procédés :

Cours IGL, Copyright © 2011, ESI

Méthodes classiques • Modèles stricts

Cours IGL, Copyright © 2011, ESI

Méthodologies agiles • Modèles incrémentaux et itératifs

Choix d’un modèle

 Aucun modèle n’est meilleur que l’autre

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

 L’un des premiers modèles proposés, inspiré du modèle

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

 Variante du modèle en cascade qui fait l’accent sur la

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

Cours IGL, Copyright © 2011, ESI

 Le projet se fait sur plusieurs itérations

Cours IGL, Copyright © 2011, ESI