Vous êtes sur la page 1sur 114

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, Copyright © 2011, ESI


COURS IGL

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

Cours IGL, Copyright © 2011, ESI


Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Etapes de développement

 Tout logiciel passe par plusieurs étapes pour être


développé

Cours IGL, Copyright © 2011, ESI


 Ces étapes peuvent être résumées dans les étapes ci-
dessous :

Définition Développement Support

5
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Définition

 Définir les besoins :


 Que doit faire le logiciel

Cours IGL, Copyright © 2011, ESI


 De quelle façon
 Et sous quelles conditions

6
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Développement

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


définition en plusieurs produits :

Cours IGL, Copyright © 2011, ESI


 Logiciel fonctionnel
 Code source
 Produits connexes

7
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Support

Correction

Cours IGL, Copyright © 2011, ESI


Prévention Changements Adaptation

Amélioration

8
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Support

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


ou qui ne marchent pas comme souhaité.

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Activités

 Chaque projet de développement est composé de


plusieurs activités

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Principales activités

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


communes

Cours IGL, Copyright © 2011, ESI


Analyse de
Conception
besoins

Codage Tests

Maintenance

11
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Analyse de besoins

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


produit ou un produit altéré

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Conception

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


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

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Codage

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


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

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Tests

 Les tests déterminent la qualité du logiciel


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

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 1 -
logiciels INTRODUCTION

Maintenance

 La maintenance consiste à modifier le produit (le


logiciel) après sa livraison au client

Cours IGL, Copyright © 2011, ESI


 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, Copyright © 2011, ESI


COURS IGL

Cycles de vie
de logiciels
Section 2 : Cycle de vie de
logiciels

18

Cours IGL, Copyright © 2011, ESI


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

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de S E C T I O N 2 – C YC L E S
logiciels DE VIE DE LOGICIELS

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

Cours IGL, Copyright © 2011, ESI


perspective
 Un procédé logiciel est une application d’un modèle pour
un projet spécifique, qui peut inclure une certaine
adaptation

20
Cours 2 – Cycle de vie de S E C T I O N 2 – C YC L E S
logiciels DE VIE DE LOGICIELS

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

 Pour maîtriser les gros projets


 Pour découper le projet et affecter correctement les

Cours IGL, Copyright © 2011, ESI


tâches
 Pour anticiper et gérer les risques

21
Cours 2 – Cycle de vie de S E C T I O N 2 – C YC L E S
logiciels DE VIE DE LOGICIELS

Modèles de procédés

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

Cours IGL, Copyright © 2011, ESI


Méthodes
classiques

Méthodologie
agiles
22
Cours 2 – Cycle de vie de S E C T I O N 2 – C YC L E S
logiciels DE VIE DE LOGICIELS

Modèles de procédés

Caractéristiques

Méthodes classiques • Modèles stricts

Cours IGL, Copyright © 2011, ESI


• 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
Cours 2 – Cycle de vie de S E C T I O N 2 – C YC L E S
logiciels DE VIE DE LOGICIELS

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

Cours IGL, Copyright © 2011, ESI


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, Copyright © 2011, ESI


COURS IGL

Cycles de vie
de logiciels
Section 3 : Cycles de vie
classiques

26

Cours IGL, Copyright © 2011, ESI


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)

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en cascade

Cours IGL, Copyright © 2011, ESI


28
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en cascade

Avantages :
 Facile à utiliser et à comprendre

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en cascade

Inconvénients :
 Les besoins des clients sont très rarement stables et

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en cascade

Quand l’utiliser ?
 Quand les besoins sont connus et stables

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en V

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


vérification et la validation

Cours IGL, Copyright © 2011, ESI


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

32
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en V

Cours IGL, Copyright © 2011, ESI


33
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en V

Avantages :
 Met l’accent sur lest tests et la validation et par

Cours IGL, Copyright © 2011, ESI


conséquent, ça accroît la qualité du logiciel
 Chaque livrable doit être testable
 Facile à planifier dans une gestion de projets
 Facile à utiliser

34
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en V

Inconvénients :
 Ne gère pas les activités parallèles

Cours IGL, Copyright © 2011, ESI


 Ne gère pas explicitement les changements des
spécifications
 Ne contient pas d’activités d’analyse de risque

35
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en V

Quand l’utiliser:
 Quand le produit à développer à de très hautes exigences

Cours IGL, Copyright © 2011, ESI


de qualité
 Quand les besoins sont connus à l’avance
 Les technologies à utiliser sont connues à l’avance

36
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Prototypage

 Le projet se fait sur plusieurs itérations


 Les développeurs construisent un prototype selon les

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Prototypage

Ecouter le

Cours IGL, Copyright © 2011, ESI


client

Développer
Evaluer le
le
prototype
prototype

38
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Prototypage

Avantages
 Implication active du client

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Inconvénients

Inconvénients
 Le prototypage implique un code faiblement structuré

Cours IGL, Copyright © 2011, ESI


 Degré très faible de maintenabilité
 Le processus peut ne jamais s’arrêter
 Très difficile d’établir un planning

40
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Inconvénients

Quand l’utiliser ?
 Quand les besoins sont instables et/ou nécessitent des

Cours IGL, Copyright © 2011, ESI


clarifications
 Peut être utilisé avec le modèle en cascade pour la
clarification des besoins
 Quand des livraisons rapides sont exigées

41
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

 Chaque incrément est une construction partielle du


logiciel

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

Spécifications Conception Implémentation Tests Incrément 1

Cours IGL, Copyright © 2011, ESI


Spécifications Conception Implémentation Tests Incrément 2

Spécifications Conception Implémentation Tests Incrément N

43
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

Avantages
 Développement de fonctionnalités à risque en premier

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

Inconvénients
 Exige une bonne planification et une bonne conception

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

Quand l’utiliser ?
 Quand la plupart des spécifications sont connues à

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

 Modèle itératif
 Des incréments sous forme de cycle

Cours IGL, Copyright © 2011, ESI


 À 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

Cours IGL, Copyright © 2011, ESI


48
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

Détermination des objectifs


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

Cours IGL, Copyright © 2011, ESI


 Déterminer les alternatives : développer, réutiliser,
acheter, sous-traiter…etc.
 Contraintes : coûts, plannings, … etc.

49
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

Identification et évaluation de risques


 Etudier les alternatives de développement

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

Développement et test
 Contient pratiquement la plupart des activités :

Cours IGL, Copyright © 2011, ESI


conception, codage, test, … etc.

Planification de la prochaine itération


 Un planning de l’itération
 Un plan de tests

51
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

Avantages
 Identification rapide des risques

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

Inconvénients
 L’évaluation des risques peut prendre beaucoup de temps

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en spirale

Quand est-ce que l’utiliser ?


 Quand le prototypage est exigé

Cours IGL, Copyright © 2011, ESI


 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, Copyright © 2011, ESI


COURS IGL

Cycles de vie
de logiciels
Section 4 : Méthodologies
Agiles

56

Cours IGL, Copyright © 2011, ESI


Cours 2 – Cycle de vie de SECTION 4 –
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

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principes agiles

Individus et Logiciel
interactions au fonctionnel au lieu

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principes

INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET


OUTILS

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principes

LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION


MASSIVE

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principes

COLLABORATION DU CLIENT AU LIEU DE LA


NÉGOCIATION DE CONTRATS

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principes

RÉAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN


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

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principes

LES DOUZE PRINCIPES AGILES


1. Toujours satisfaire le client à travers des livraisons rapides

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principes

LES DOUZE PRINCIPES AGILES


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

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Principales méthodologies agiles

Adaptive
Feature Driven
Software
Development Crystal Clear

Cours IGL, Copyright © 2011, ESI


Development
(FDD)
(ASD)

Dynamic
Rapid Application
Software
Development Scrum
Development
(RAD)
Method (DSDM)

Extreme
Programming
(XP)

65
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP

 eXtreme Programming
 Créée en 1995 Kent Beck and Ward Cunningham

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP - Fondamentaux

Implication Test unitaire

Cours IGL, Copyright © 2011, ESI


massive du client continu (TDD)

Itérations
Programmation courtes et
par paires livraisons
fréquentes

67
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Principales activités

Tests
Codage

Cours IGL, Copyright © 2011, ESI


(pendant le
(noyau de XP)
codage)

Ecoute (le Conception


client ou le (encore basée
partenaire) sur le codage)

68
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Les 12 pratiques

1- LE JEU DE PLANNING :
 Le client et les développeurs décident quoi mettre dans la

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Les 12 pratiques

3- LES MÉTAPHORES
 Exprimer de manière naturelle et très simples des fonctions

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Les 12 pratiques

6 – REFACTORING
Les développeurs améliorent continuellement le code tout en

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Les 12 pratiques

10 – intégration continue
Construire le système à chaque fois qu’une tâche est terminée.

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Avantages

 Implication active du client


 Forte réactivité des développeurs

Cours IGL, Copyright © 2011, ESI


 Responsabilisation et solidarité de l’équipe
 Appel aux meilleurs pratiques de développement
 Souplesse extrême

73
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Inconvénients

 Demande une certaine maturité des développeurs


 La programmation par paires n’est toujours pas applicable

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

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

Cours IGL, Copyright © 2011, ESI


 Utilisé comme méthodologie dans le livre : « Agile Software
Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en
2001

75
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Principes

Simple Empirique
• Peut être combiné avec • Itérations courtes (sprints)
d’autres méthodes • Feedback continu

Cours IGL, Copyright © 2011, ESI


• 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
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Principes

Cours IGL, Copyright © 2011, ESI


77
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Principes


Processus Backlog
• Sprint • Product Backlog
• Sprint Backlog

Cours IGL, Copyright © 2011, ESI


Equipe Réunions
• Srum Master • Scrum quotidien
• Product Owner • Planning
• Team • Revue
• Users and stakeholders • Rétrospective

Suivi
• Rapports
• Vélocité

78
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Avantages

 Méthode très simple et très efficace


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

Cours IGL, Copyright © 2011, ESI


 Orientée projet contrairement à XP qui est orientée
développement
 Peut inclure d’autres activité venant d’autres méthodologies
(surtout XP)

79
Cours 2 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Inconvénients

 N’est pas 100% spécifique au GL


 Difficulté de budgétiser un projet

Cours IGL, Copyright © 2011, ESI


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, Copyright © 2011, ESI


COURS IGL

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

82

Cours IGL, Copyright © 2011, ESI


Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP

 UP est un modèle de procédé très populaire


 UP est incrémental et itératif

Cours IGL, Copyright © 2011, ESI


 UP a plusieurs implémentation et / ou variation dont la plus
célèbre est RUP (Rational Unified Process)

83
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Implémentations

Agile Unified
Basic Unified
RUP (Rational Process (AUP)
Process (BUP)

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Principes

Processus Basé sur les

Cours IGL, Copyright © 2011, ESI


itératif et cas
incrémental d’utilisation

Centré sur Accent sur


l’architecture les risques
85
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP - Principes

PROCESSUS ITÉRATIF ET INCRÉMENTAL


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

Cours IGL, Copyright © 2011, ESI


(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
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP - Principes

PROCESSUS BASÉ SUR LES CAS D’UTILISATION


 Les cas d’utilisation formalisent les spécifications

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP - Principes

PROCESSUS CENTRÉ SUR L’ARCHITECTURE


 UP supporte plusieurs architectures logicielles

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP - Principes

PROCESSUS QUI MET L’ACCENT SUR LES RISQUES


 Identification rapide des risques

Cours IGL, Copyright © 2011, ESI


 Traitement des risques dans les premières phases du projet

89
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

 UP est composé de quatre phases principales : analyse de


besoins (inception), élaboration, construction et transition

Cours IGL, Copyright © 2011, ESI


90
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

 UP est un processus bidimensionnel


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

Cours IGL, Copyright © 2011, ESI


 La phase verticale représente les activités

91
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

Cours IGL, Copyright © 2011, ESI


92
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

PHASE D’ANALYSE DE BESOINS (INCEPTION)


 La plus petite phase et la plus courte

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

PHASE D’ÉLABORATION
 Capturer la majorité des cas d’utilisation

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

PHASE DE CONSTRUCTION
 La phase la plus longue du projet

Cours IGL, Copyright © 2011, ESI


 Le reste du système est développé durant cette phase
 Chaque itération produit un incrément vers le système final

95
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

PHASE DE TRANSITION
 Le système est déployé chez les utilisateurs

Cours IGL, Copyright © 2011, ESI


 Les feedbacks récoltés serviront à améliorer le système

96
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Activités

Expression de besoins
 Recenser les besoins fonctionnels et non fonctionnels du

Cours IGL, Copyright © 2011, ESI


système
 Le diagramme UML de cas d’utilisation est utilisé pour cette
phase

97
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Activités

Analyse
 Détaille les besoins en spécifications détaillées

Cours IGL, Copyright © 2011, ESI


 Une ébauche de la conception

98
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Activités

Conception
 Décide comment sera construit le système durant

Cours IGL, Copyright © 2011, ESI


l’implémentation
 Définition des sous-systèmes et composants
 Création d’abstractions de la solution

99
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Activités

Implémentation
 Traduire les résultats de la conception en un système

Cours IGL, Copyright © 2011, ESI


opérationnel
 Livrables : code source, exécutables, …etc.

100
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Activités

Tests
 Vérification et validation des résultats de l’implémentation

Cours IGL, Copyright © 2011, ESI


101
Cours 2 – Cycle de vie de SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Avantages

 Méthodologie complète
 Identification rapide des risques

Cours IGL, Copyright © 2011, ESI


 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, Copyright © 2011, ESI


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

104

Cours IGL, Copyright © 2011, ESI


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,…)

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de OUTILS CASE
logiciels

Limite des CASE

 Le développement est essentiellement basé sur


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

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de OUTILS CASE
logiciels

Classification des CASE

Les outils CASE peuvent être classés :

Cours IGL, Copyright © 2011, ESI


 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
Cours 2 – Cycle de vie de OUTILS CASE
logiciels

Classification fonctionnelle

Outil Exemples Références

Outils de planification Outils PERT, outils Microsoft Project, Excel,

Cours IGL, Copyright © 2011, ESI


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
Cours 2 – Cycle de vie de OUTILS CASE
logiciels

Classification fonctionnelle

Outil Exemples Références

Outils de test Environnements de tests, Junit, Nunit, TestWorks,

Cours IGL, Copyright © 2011, ESI


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, Copyright © 2011, ESI


COURS IGL

Cycles de vie
de logiciels
Démonstration : outil de
gestion de tests unitaires

111

Cours IGL, Copyright © 2011, ESI


COURS IGL

Cycles de vie
de logiciels
Démonstration : outil de
gestion de tests unitaires

112

Cours IGL, Copyright © 2011, ESI


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 IGL, Copyright © 2011, ESI


Cours 2 – Cycle de vie de BIBLIOGRAPHIE
logiciels

Bibliographie

 Software Engineering Right Edition, Ian Sommerville,


Addison Wesley, 2007

Cours IGL, Copyright © 2011, ESI


 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