Cours 1 :

COURS 1 Cycles de vie

de logiciels

CYCLES DE VIE DE
LOGICIELS
 Cours1–Cycledeviede
OBJECTIFS DU COURS
logiciels

Objectifs du cours

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

logiciels
 Connaître les cycles de vie (SDLC systems development life cycle) et leur
motivation
 Connaître les SDLC classiques et les méthodes agiles
 Pourvoir choisir un SDLC concernant un projet de développement
 Prise de contact avec la méthodologie UP
 Découvrir les outils de support (CASE)

2
 Section 1 :
Activités de Section 2 : Cycle INTRODUCTION
développement de vie AU GÉNIE
LOGICIEL

Cours 1
Section 3 : Cycles de vie
Modèles de Section 4 : de logiciels
procédés Méthodes Agiles
classiques

Section 5 : Section 6 : Outils

Méthodologie UP de support 3
(CASE)
 Cycles de vie
de logiciels
Section 1 : Activités de
développement

4
 C o u r s 1 – 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
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

Définition

 Définir les besoins :

 Que doit faire le logiciel
 De quelle façon
 Et sous quelles conditions

6
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

Développement

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

définition en plusieurs produits :
 Logiciel fonctionnel
 Code source
 Produits connexes

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

Support

Correction

Prévention Changements Adaptation

Amélioration

8
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

Support

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

ou qui ne marchent pas comme souhaité.
 Adaptation : adaptation des fonctionalités aux évolutions
actuelles.
 Amélioration : en terme de performance, ergonomie, …
 Prévention : Rendre le logiciel plus facile à la
maintenance

9
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

A c t i v i t é s de GL

 Chaque projet de développement est composé de

plusieurs activités
 Chaque activité est conduite et réalisée par plusieurs
développeurs
 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
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

P r i n c i p a l e s a c t i v i té s

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

communes

Analyse de
Conception
besoins

Codage Tests

Maintenance

11
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

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, 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
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

Conception

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

solutions relatives aux 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
 Cours1–Cycledeviede 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
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
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

Te s t s

 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
 Cours1–Cycledeviede SECTION 1 -
logiciels INTRODUCTION

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
 Le degré de maintenance dépend de la qualité de la
conception

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

logiciels
 Cours1–Cycledeviede S EC T IO N 2 – C YC L ES
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
 Cours1–Cycledeviede S EC T IO N 2 – C YC L ES
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
perspective
 Un procédé logiciel est une application d’un modèle pour
un projet spécifique, qui peut inclure une certaine
adaptation

20
 Cours1–Cycledeviede S EC T IO N 2 – C YC L ES
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
tâches
 Pour anticiper et gérer les risques

21
 Cours1–Cycledeviede S EC T IO N 2 – C YC L ES
logiciels DE VIE DE LOGICIELS

Modèles de procédés

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

Méthodes
classiques

Méthodologie
agiles

22
 Cours1–Cycledeviede S EC T IO N 2 – C YC L ES
logiciels DE VIE DE LOGICIELS

Modèles de procédés

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
 Cours1–Cycledeviede S EC T IO N 2 – C YC L ES
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
du projet, sa taille, la nature du client et les compétences
de l’équipe

24
 Cycles de vie
Section 3 : Cycles de vie de logiciels

classiques
 Cours1–Cycledeviede 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

27
Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en cascade

28
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Questions:

• avez-vous déjà développé un logiciel où le Cycles de vie

besoin était bien claire? Justifiez vos de logiciels
réponses.
• Avez-vous déjà annulé un processus de
développement à cause des contraintes
technologiques? Lequel? Quelle solutions vous
avez envisagé? (expression de besoin,
modélisation, …)
 Cours1–Cycledeviede 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
 Le test du produit se fait en parallèle par rapport aux
autres activités

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

Modèle en V

33
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en V

Avantages :
 Met l’accent sur les 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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle en V

Inconvénients :

 Ne gère pas explicitement les changements des

spécifications
 Les tests sont souvent difficiles à rédiger (prévoir les
erreurs et les défaillances)
 Le cout du logiciel devient élevé.

35
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Questions:

• Trouvez vous que le cycle en V est Cycles de vie

convenable pour un projet basé sur une de logiciels
nouvelle idée innovante? Pourquoi?
• trouver vous que le cycle en V est convenable
pour la création d’une version Web d’une
application existante? Pourquoi?
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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

Prototypage

Ecouter le
client

Evaluer le Développer
prototype le
prototype

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

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Inconvénients

Quand l’utiliser ?
 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
 Questions:

• Comment trouvez vous que le prototypage Cycles de vie

peut servir des applications web destinés de logiciels
aux internautes.
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

Modèle Incrémental

Quand l’utiliser ?
 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

46
 Questions:

• Trouvez vous que le modèle incrémental Cycles de vie

est convenable pour une société qui de logiciels
recrute des développeurs avec des
contrats qui ne dépasse pas 3 mois?
Pourquoi?
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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

Modèle en spirale

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

Modèle en spirale

Le Concept d'opération se traduit dans un document qui décrit

• la manière d’utiliser les forces,
• la chronologie retenue pour atteindre les objectifs fixés, et
• la façon dont il convient de synchroniser les différents moyens et
ressources mis à disposition
La gestion des exigences consiste à gérer les exigences hiérarchisées
d'un projet, à détecter les incohérences entre elles et à assurer
leur traçabilité.

48
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Cours1–Cycledeviede SECTION 3 –
logiciels MODÈLES CLASSIQUES

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
 Questions:
Cycles de vie
de logiciels
• Quel est le modèle le plus simple et le
plus complexe ?
• Quels sont les critères qui définiront
quel modèle choisir ?
 Cycles de vie
Section 4 : Méthodologies de logiciels

Agiles

56
 Cours1–Cycledeviede 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
 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 1 – Cycle de vie de SECTION 4 –
logiciels MÉTHODES AGILES

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
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

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

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
 Produire toujours des documents aussi courts que
possible

60
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

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
 Cours1–Cycledeviede 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
 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
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

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
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

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

Principales méthodologies agiles

Adaptive Feature Driven

Software Development Crystal Clear
Development (FDD)
(ASD)

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

Extreme
Programming
(XP)

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

Méthodologie XP

 eXtreme Programming
 Créée en 1995 Kent Beck and Ward Cunningham
 XP est un moyen léger, efficace, à bas risques, flexible,
et scientifique 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
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP - Fondamentaux

Implication Test unitaire

massive du client continu (TDD)

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

67
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

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
 Cours1–Cycledeviede 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
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
 Cours1–Cycledeviede 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
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
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie XP – Les 12 pratiques

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
 Cours1–Cycledeviede 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.
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
Ex: organisation des fichiers, style d'indentation, conventions de
nommage, commentaires, Recommandations sur la déclaration des
variables, Recommandations sur l'écriture des instructions, des
structures de contrôle et l'usage des parenthèses dans les expressions.

72
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

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
 C o u r s 1 – 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
 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
 Cours1–Cycledeviede 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
 Utilisé comme méthodologie dans le livre : « Agile Software
Developmentt with SCRUM” par K. Schwaber et M.. Beedlle en
2001

75
 Cours1–Cycledeviede 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
• 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
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Principes

Processus Backlog
• Sprint • Product Backlog
• Sprint Backlog

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

Suivi
• Rapports
• Vélocité

78
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Principes

77
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Principes

77
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

p Méthodologie Scrum - Principes

Exemple de Product Backlog:

77
 Cours1–Cycledeviede SECTION 4 –
logiciels MÉTHODES AGILES

Méthodologie Scrum - Principes

77
 Cours 1 – 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, ...
 Orientée projet contrairement à XP qui est orientée
développement
 Peut inclure d’autres activité venant d’autres méthodologies
(surtout XP)

79
 Cours1–Cycledeviede 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

80
 Questions:
• Quelles sont les différences entre une
méthode agile et une méthode classique ? Cycles de vie
de logiciels
• Qu els sont les points forts des méthodes
agiles ?
• Quels en sont les points faibles ?
• Qu elle est la différence entre Scru m et XP ?
• Est-ce que Scrum et XP peuvent -elles être
combinées ?
 Cycles de vie
Section 5 : Processus Unifié de logiciels

(Unified Process / UP)

 Cours1–Cycledeviede 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
 UP a plusieurs implémentation et / ou variation dont la plus
célèbre est RUP (Rational Unified Process)

83
Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Implémentations

Agile Unified
RUP (Rational Basic Unified
Process (AUP)
Unified Process) Process (BUP)
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
Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Principes

Processus Basé sur les

itératif et cas
incrémental d’utilisation

Centré sur Accent sur

l’architecture les risques
85
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

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
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

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
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP - Principes

PROCESSUS CENTRÉ SUR L’A RCHITECTURE

 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
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP - Principes

PROCESSUS QUI MET L’A CCENT SUR LES RISQUES

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

89
 Cours1–Cycledeviede 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

90
 Cours1–Cycledeviede 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
 La phase verticale représente les activités

91
C o u rs 1 – Cyc l e d e v i e de SECTION 5 –
l o g i ci e ls MÉTHODOLOGIE UP

U P – C yc l e d e v i e

92
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Cycle de vie

PHASE D’A NALYSE 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
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

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
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

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
 Cours 1 – 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
 Les feedbacks récoltés serviront à améliorer le système

96
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

U P – A c t i v i té 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
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

U P – A c t i v i té s

Analyse
 Détaille les besoins en spécifications détaillées
 Une ébauche de la conception

98
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

U P – A c t i v i té 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
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

U P – A c t i v i té s

Implémentation
 Traduire les résultats de la conception en un système
opérationnel
 Livrables : code source, exécutables, …etc.

100
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

U P – A c t i v i té s

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

101
 Cours1–Cycledeviede SECTION 5 –
logiciels MÉTHODOLOGIE UP

UP – Avantages

 Méthodologie complète
 Identification rapide des risques
 Largement adoptée en entreprise
 Intégration avec UML
 Séparation concise des phases et des livrables
 Des formations / livres / tutoriaux disponibles

102
Questions:
• 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
 Section 6 : Outils de Cycles de vie
supports (CASE – Computer- de logiciels

Aided Software
Engineering)
 Cours1–Cycledeviede
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
 Cours1–Cycledeviede
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
 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
 Cours1–Cycledeviede
OUTILS CASE
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
 Cours1–Cycledeviede
OUTILS CASE
logiciels

Classification fonctionnelle

Outil Exemples Références

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

d’estimation, tableurs
Editeurs Editeurs de texte, éditeurs
d’image, éditeurs de
diagrammes
Gestion de Gestion de versions, gestion de
configuration builds
Outils de support de Générateurs de code, outils
procédé d’assistance, IDE
Outils de traitement de Compilateurs, interpréteurs,
langage débogueurs
GanttProject, DotProject
vi, bloc notes, GIMP,
Photoshop, Visio
GIT, SVN, CVS,
Team Foundation
Server, ClearCase
Team Foundation Server,
Accurev, Enterprise
Architect

108
 Cours1–Cycledeviede
OUTILS CASE
logiciels

Classification fonctionnelle

Outil Exemples Références

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

outils de tests unitaires TestWorks, Bugzilla
Outils de Documents de projet, Word, Open Office,
documentation documents de code Sandcastle, Doxygen,
javadoc

109
 Cours1–Cycledeviede
BIBLIOGRAPHIE
logiciels

B i b l i o g ra p h i e

 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