Vous êtes sur la page 1sur 244

FORMATION ISAIP

Les Nouvelles Méthodologies


de gestion de projet

Source Bibliographique : Anne-Marie Hugues

ALEXANDRE LEPRIEULT 1
Les nouvelles Méthodes
 Avec l’apparition de la programmation
orientée Objet et l’utilisation d’UML et des
RADs de nouvelles Méthodologies ont vues le
jours.
 Certaines telles Merise Objet , RAD sont

franco-françaises , d’autre comme RUP sont


fortement liées à un éditeur d’atelier de génie
logiciel (Rational/IBM)
 D’autre enfin sont plus génériques comme

2TUP ,XP et DSDM


Toutes ces méthodes sont regroupées sous le
nom génériques
ALEXANDRE LEPRIEULT de méthodes Agiles 2
Les nouvelles Méthodes
 Les points communs de ces méthodes
sont :
 Elle sont itératives en oppositions avec les
méthodes classiques qui sont linéaires et
qui interdisent de revenir sur les étapes
précédentes (ou tout au plus revenir d’un
niveau)
 Le client est partie intégrante de l’équipe
projet
 Elles font massivement appelles aux
prototypes dans toutes les étapes
 Elles utilisent UML et les RAD
ALEXANDRE LEPRIEULT 3
Contexte
 Les méthodes de gestion de projet informatique
connaissent, au même titre que les technologies
mises en œuvre, une remise en cause permanente.
 La proportion importante d’échec des projets vient
souvent alimenter des réactions plus ou moins
constructives aux méthodes mises en œuvre. Les
évolutions des architectures technologiques et des
outils de développement y contribuent également
pour part importante.
 Ainsi, UML et Unified Process sont venues en réaction
aux méthodes dites « merisiennes » (cycle en V, etc.)
à la fois poussées par les technologies objet et les
insuffisances de méthodes préconisant des cycles
très longs.

ALEXANDRE LEPRIEULT 4
Contexte
 Les méthodes agiles n’échappent pas à la
règle. Mais elles s’inscrivent dans une
démarche plus radicale, que l’on pourrait
résumer par « trop de méthode tue la
méthode ».
 De manière générale, leur but est
d'augmenter le niveau de satisfaction des
clients tout en rendant le travail de
développement plus facile. Mais les véritables
fondements des méthodes agiles résident
plus précisément dans deux caractéristiques :

ALEXANDRE LEPRIEULT 5
Les méthodes agiles sont "adaptatives" plutôt
que prédictives

 Si les méthodes lourdes tentent d’établir dès le début


d’un projet un planning à la fois très précis et très
détaillé du développement sur une longue période de
temps, cela suppose que les exigences et
spécifications de base restent immuables. Or, dans
tous les projets, les exigences changent au cours du
temps et le contexte évolue aussi. Par conséquent, si
elles fonctionnent sur des projets courts et de petite
taille, ces méthodologies sont trop réfractaires au
changement pour pourvoir être appliquées à des
projets plus importants. A l’inverse, les méthodes
agiles se proposent de réserver un accueil favorable
au changement : ce sont des méthodes itératives à
planification souple qui leur permettent de s’adapter
à la fois aux changements de contexte et de
spécifications du projet.
ALEXANDRE LEPRIEULT 6
Les méthodes agiles sont orientées vers les
personnes plutôt que vers les processus
 Les méthodes agiles s’efforcent de travailler avec les
spécificités de chacun plutôt que contre la nature de
chacun pour que le développement soit une activité
plaisante où chacun se voit confier une part de
responsabilité.
 Nées en réaction aux méthodes traditionnelles, il
existe une grande diversité de méthodes auxquelles
ont peut donner le qualificatif d’agile. Avant de
passer en revue les spécificités de chacune parmi les
principales d’entre elles dans une seconde partie,
essayons tout d’abord de dégager les principales
caractéristiques communes à toutes ces méthodes,
autrement dit : qu’est ce qui fait qu’une méthode de
développement est une méthode agile ?

ALEXANDRE LEPRIEULT 7
Priorité aux applications fonctionnelles sur une
documentation pléthorique
 Les partisans des méthodes agiles affirment la
légitimité d’une certaine forme de documentation
mais ils dénoncent les effets pervers d’une
documentation pléthorique. En effet, l’écriture et le
maintien à niveau de la documentation sont
extrêmement consommateurs de ressources. Un
document qui n’est pas mis à jour régulièrement
devient très rapidement totalement inutile, voire
même trompeur. Le manifeste est donc favorable aux
documentations succinctes, ne décrivant que les
grandes lignes de l’architecture du système mais
régulièrement tenues à jour, et d’une documentation
permanente du code lui-même. Le meilleur transfert
des connaissances sur le système s’effectue de toute
manière par la participation au travail de l’équipe

ALEXANDRE LEPRIEULT 8
Priorité de la collaboration avec le
client sur la négociation de contrat
 Le succès d’un projet requiert un feedback régulier et fréquent
de la part du client. Un contrat qui spécifie les exigences, le
planning et le coût d’un projet a priori relève d’une vision
utopique d’une projet informatique. La meilleure manière de
procéder pour le client est de travailler en étroite collaboration
avec l’équipe de développement, pour lui fournir un feedback
continu qui assure un meilleur contrôle du projet. Ainsi, des
modifications de spécifications peuvent intervenir très tard dans
le cycle de développement du projet. C’est en définitive une
solution répondant réellement aux attentes du client qui est
réalisée et non une solution répondant aux exigences d’un
contrat établi a priori. Nous le verrons en synthèse, ce point ne
reste pas simple à mettre en œuvre. Cela nécessite bien sûr une
grande maturité du client et du prestataire de service afin
d’établir une réelle relation de confiance, ainsi qu’une bonne
compréhension de la réalité opérationnelle du projet par les
juristes en charge du dossier.

ALEXANDRE LEPRIEULT 9
Priorité de l’acceptation du changement
sur la planification
 C’est la capacité à accepter le changement
qui fait bien souvent la réussite ou l’échec
d’un projet. Lors de la planification, il est
donc nécessaire de veiller à ce que le
planning soit flexible et adaptable aux
changements qui peuvent intervenir dans le
contexte, les technologies et les
spécifications.
 En effet il est très difficile de penser dès le
début à toutes les fonctionnalités dont on
aimerait disposer et il est très probable que le
client modifie ses exigences une fois qu’il
aura vu fonctionner une première version du
système.
ALEXANDRE LEPRIEULT 10
"Notre priorité est de satisfaire le client en lui livrant très tôt et
régulièrement des versions fonctionnelles de l’application source de
valeur"

 Les méthodes agiles recommandent de livrer très tôt,


dans les premières semaines si possible une version
rudimentaire de l’application puis de livrer souvent
des versions auxquelles les fonctionnalités s’ajoutent
progressivement. De cette manière, le client peut
décider à tout moment la mise en production de
l’application, dès qu’il la considère comme assez
fonctionnelle. A chaque version (release), un
feedback de la part du client est nécessaire pour
permettre soit de continuer le développement comme
prévu, soit d’opérer des changements. De cette
manière, les changements dans les spécifications
interviennent tôt dans le processus de
développement et sont moins problématiques.

ALEXANDRE LEPRIEULT 11
RAD
 Le RAD (Rapid Application Development) est né dans les années 80 à
la suite d'un double constat. D'une part, le manque de concertation
entre les informaticiens en charge de la réalisation d'un projet et les
utilisateurs conduit souvent à la réalisation d'applications mal adaptées
aux besoins. D'autre part les méthodes classiques de conduite de
projet sont inadaptées à la vitesse des évolutions technologiques et la
durée des projets est beaucoup trop longue.
 Les objectifs premiers du RAD sont de conduire à l'amélioration de la
qualité des développements tout en réduisant les délais et en facilitant
la maîtrise des coûts. Pour cela, il est nécessaire d'associer
méthodologie et relations humaines. Le RAD est fondamentalement
une méthode basée sur la communication.
 Les concepts du RAD ont été définis par James Martin avant d'être
repris et adaptés au contexte français par Jean Pierre Vickoff dès 1989.
 A ses début, le RAD a souvent été qualifié de "chaotique" et considéré
comme une "absence de méthode" plutôt que comme une méthode. Si
le RAD a souffert d'une si mauvaise image, c'est avant tout lié à la
notion de rapidité qu'on a souvent tendance à considérer, à tort,
comme incompatible avec celle de qualité. Pour éviter ce malentendu,
Jean Pierre Vickoff propose de traduire RAD par "développement
maîtrisé d'applications de qualité approuvée par les utilisateurs".

ALEXANDRE LEPRIEULT 12
Les acteurs du RAD
 Dans un projet RAD, la répartition des
rôles est très structurée. Comme dans
une approche classique, l'ensemble de
l'organisation s'appuie sur un principe
fondamental : la séparation des rôles
opérationnels et des responsabilités
entre d'une part la maîtrise d'ouvrage
(MOA) qui représente l'utilisateur et à
ce titre détermine les fonctionnalités à
développer et leur degré de priorité.

ALEXANDRE LEPRIEULT 13
Les acteurs du RAD

 D’autre part la maîtrise d'œuvre (MOE)


qui apporte les solutions techniques aux
problèmes posés par la maîtrise
d'ouvrage. (Cette séparation des rôles
est encore renforcée par la présence du
Groupe d'animation et de Rapport RAD
qui se charge d'organiser la
communication du projet. Son rôle
principal est de faciliter l'expression des
exigences et de les formaliser en temps
réel.
ALEXANDRE LEPRIEULT 14
La maîtrise d'ouvrage
 La maîtrise d'ouvrage a trois responsabilités principales:
 Définir les objectifs et les exigences du système : le maître
d'ouvrage, qui préside le comité de pilotage est responsable de
la rédaction de documents de cadrage dans lesquels sont
explicités les objectifs d'ordre stratégique, fonctionnel,
technologique, organisationnel, ainsi que les contraintes de
projet. Ces objectifs, classés par ordre de priorité servent de
base pour la prise de décisions de pilotage. Le maître d'ouvrage
spécifie aussi les exigences en déléguant leur mise en forme à
diverses personnes compétentes : par exemple, les exigences
fonctionnelles sont exprimées par des représentants
d'utilisateurs et des experts fonctionnels.
 Valider les solutions proposées et élaborées : en collaboration
avec les personnes qui ont exprimé les exigences, le maître
d'ouvrage vérifie que la ou les solutions proposées par la
maîtrise d'œuvre permettent bien de satisfaire ces exigences.
 Préparer et piloter le changement induit : il s'agit là d'opérations
de sensibilisation, formation, communication ainsi que
d'organisation.

ALEXANDRE LEPRIEULT 15
MO: trois acteurs principaux
 Maître d'ouvrage : prend des décisions sur les
objectifs (produit, coût, délai) et les orientations du
projet et décide in fine l'expression des exigences et
la validation des solutions ainsi que les moyens à
mettre en œuvre au sein de la maîtrise d'ouvrage.
 Coordinateur de Projet Utilisateurs ou Maître
d'Ouvrage délégué : coordonne et valide les activités
de la maîtrise d'ouvrage. Réalise le suivi des objectifs
(produits, coûts / charges, délais) et des activités de
la maîtrise d'ouvrage.
 Responsable de la cohérence et de la qualité
fonctionnelle : supervise l'expression des exigences
et de la validation des solutions, contrôle la
cohérence des décisions prises dans les domaines
fonctionnels. Supervise la vérification de la qualité
fonctionnelle (point de vue utilisateurs) des solutions
proposées et élaborées.
ALEXANDRE LEPRIEULT 16
Maitrise d’œuvre
 Elle a également trois responsabilités principales:
 Proposer et réaliser la solution : cela passe
notamment par la définition, et la mise en œuvre du
planning et des moyens humains et logistiques
nécessaires.
 Livrer des "fonctionnalités" : on entend par
fonctionnalités les produits finis mais aussi des
produits intermédiaires et diverses informations qui
permettront à la maîtrise d'ouvrage de préparer et de
piloter le changement. Les dates de fourniture de ces
différents livrables figurent au planning.
 Respecter les directives du Plan d'Assurance Qualité :
en même temps que la réalisation de l'application, la
maîtrise d'œuvre réalise son suivi sur des critères tels
que les fonctionnalités, la qualité, le planning, les
ALEXANDRE LEPRIEULT
coûts, la visibilité. 17
ME: trois acteurs principaux
 Maître d'œuvre : propose des objectifs (coût, délai en
particulier) et des orientations pour le projet. Décide
in fine les propositions de solution et les solutions
elles-mêmes qui seront élaborées. Décide des
moyens et méthodes à mettre en œuvre au sein de
la MOE. Se coordonne avec les MOE des autres
projets et les sociétés extérieures participant à la
MOE du projet
 Pilote de Projet Informatique : coordonne les travaux
de la MOE. Valide les propositions de solution et les
solutions elles-mêmes élaborées par la MOE. Estime
et met en œuvre les moyens MOE (planning de
production, méthodes et outils)
 Responsable par domaine : pilote et suit l'équipe de
production d'un domaine.

ALEXANDRE LEPRIEULT 18
Le Groupe d'animation et de
Rapport RAD
 Le groupe d'animation et de rapport (GAR) a pour
responsabilités la préparation des réunions (convocation,
logistique et suivi), l'organisation des séances de travail, la
formalisation des exigences exprimées, la gestion des comptes-
rendus, la planification et l'animation des focus.
 L'animateur doit adopter une attitude directive sur la forme et
non directive sur le fond. Il se garde d'émettre un avis
personnel, de porter un jugement et de favoriser des opinions.
Il n'ajoute rien au discours des participants et se contente de
maintenir les discussions bien centrées sur le thème voulu et de
canaliser les entretiens. Pour cela, il peut procéder par exemple
par synthèse (résumer l'essentiel en le reformulant) ou par
élucidation (forcer les gens, par le biais de questions, à aller
jusqu'au bout d'une idée).
 Le rapporteur doit être capable de produire une documentation
automatisée et de la maintenir à jour. C'est tout d'abord un
analyste concepteur, spécialement formé aux AGL (Ateliers de
génie Logiciel). Lors des réunions portant sur la conception du
système, il doit être capable de le modéliser en direct. Il est
aussi responsable de la synthèse des comptes-rendus de
réunion
ALEXANDRE LEPRIEULT 19
LES ROLES
 L'organisation du projet s'appuie sur un principe fondamental : la séparation des rôles et des
responsabilités entre maîtrise d'ouvrage (MOA) et maîtrise d'œuvre (MOE). Cette
dichotomie renforcée par la présence d’une instance d’animation RAD (Groupe d’Animation et de
Rapport (GAR)) implique une véritable réingénierie des méthodes de conduite de projet et
impose aux deux maîtrises une redistribution des rôles opérationnels et un apprentissage :
 La maîtrise d’ouvrage représente l'utilisateur. Elle détermine les fonctions, leurs priorités et
impose la " dynamique applicative ".
 Elle utilise des formes de modélisation simplifiées pour représenter la vision de son travail [Henry,
Monkam-Daverat 1995] et ses scénarios opérationnels (use case) [Jacobson 1993].
 La maîtrise d’œuvre s’affirme comme une force de " solution et de proposition " techniques.
 Sous la pression des nouveaux types d'applications et des contraintes économiques, elle fusionne
en un seul profil de concepteur-développeur les rôles de l'analyste et du programmeur [Bouchy
1994].
 Le Groupe d'animation et de Rapport RAD organise la communication du projet. Il facilite
l’expression des exigences et réalise en " temps réel " leur formalisation.
 Il se compose d'intervenants spécialisés en communication et en entretiens de groupe
[Sary 1990]. Il dispose de matériels et de logiciels adéquats dans une salle dédiée. Il réalise " en
direct " la synthèse (rapporteur-secrétaire) et la modélisation (rapporteur-modélisateur) à partir
du discours utilisateur [Vickoff 1996].
 Je suis un dirigeant ou un cadre décisionnaire
Mes préoccupations sont : la stratégie, la visibilité et les résultatsJe
suis cadre d'un service utilisateur
Mes préoccupations sont : l'adéquation de l'outil à mes besoins et les conditions de ma
participation
Je suis un chef de projet informatique
Mes préoccupations sont : le pilotage, la fiabilité, le budget, le délai

ALEXANDRE LEPRIEULT 20
Les cinq phases d'un projet RAD
 Initialisation (préparation de l’organisation et
communication )
Cette phase, qui représente environ 5% du projet, définit le
périmètre général du projet, établit la structure du travail par
thèmes, recense les acteurs pertinents et amorce la dynamique
du projet.
 Cadrage (analyse et expression des exigences)
C'est aux utilisateurs de spécifier leurs exigences et d'exprimer
leurs besoins lors d’entretiens de groupe. Il est généralement
prévu de 2 à 5 jours de sessions par commission (thème). Cette
phase représente environ 10% du projet.
 Design (conception et modélisation)
Les utilisateurs participent à l’affinage et à la validation des
modèles organisationnels : flux, traitements, données. Ils
valident également un premier prototype ayant pour but de
présenter l’ergonomie et la cinématique générale de
l’application. 4 à 8 jours de sessions sont prévus par
commission. Cette phase représente environ 25% du projet.

ALEXANDRE LEPRIEULT 21
Les cinq phases d'un projet RAD

 Construction (réalisation, prototypage)


Durant cette phase, l’équipe RAD (SWAT) construit
au cours de plusieurs sessions itératives l’application
module par module. L’utilisateur participe toujours
activement aux spécifications détaillées et à la
validation des prototypes. Cette phase représente
environ 50% du projet.
 Finalisation (recette et déploiement)
Cette phase, qui représente environ 10% du projet
permet une livraison globale et le transfert du
système en exploitation et maintenance.

ALEXANDRE LEPRIEULT 22
RAD et modélisation
 S'il se veut efficace, le RAD se doit d'être rapide et donc
d'utiliser des techniques de modélisation rigoureuses mais
simplifiées. Le RAD ne préconise pas de technique de
modélisation particulière : il est tout à fait possible d'utiliser des
modèles objets comme UML ou des modèles de Merise, à
condition de les alléger pour n'en conserver que ce qui est
strictement indispensable.
 Dans le cadre d'une approche "classique" par le haut de type
merisienne, tous les modèle d'abstraction merisiens ne sont pas
utilisés. Dans le cas général, ne sont conservés que le modèle
Conceptuel de Communication (MCC), la hiérarchie de fonctions
(ou MCT), le modèle Conceptuel de Données (MCD), et le
modèle Organisationnel de Traitements (MOT).
 Dans le cas d’un développement orienté objet, il est préconisé
d’employer la notation ULM. Les principaux modèles sont les
suivants : modèle de Classes, modèle d’Etat, modèle des Cas
d’utilisation, modèle des Interactions, modèle de Déploiement.

ALEXANDRE LEPRIEULT 23
EXTREME PROGRAMMING (XP)
 L’Extreme Programming (XP) est un processus de
développement logiciel, c’est-à-dire un ensemble de
pratiques destinées à organiser le travail d’une
équipe de développement. Ces pratiques se
focalisent sur la construction proprement dite du
logiciel, en aval des phases préparatoires d’études
d’opportunité ou de faisabilité.
 XP est l'un des principaux représentants d'une famille
émergente de processus : les processus dits "agiles",
qui se démarquent des démarches traditionnelles en
mettant l’accent sur le travail d’équipe et la réactivité.
L’heure est à l’économie et à l’efficacité : « Quelles
activités pouvons nous abandonner tout en
produisant des logiciels de qualité ? ». Ou encore : «
Comment mieux travailler avec le client pour nous
focaliser sur ses besoins les plus prioritaires et être
aussi réactifs que possible ? »
ALEXANDRE LEPRIEULT 24
EXTREME PROGRAMMING (XP)

XP propose une réponse originale à ces questions, avec un


ensemble de pratiques organisées autour des principes
suivants
 Le client (maîtrise d’ouvrage) pilote lui-même le projet, et
ce de très près grâce à des cycles itératifs extrêmement
courts (1 ou 2 semaines).
 L’équipe livre très tôt dans le projet une première version
du logiciel, et les livraisons de nouvelles versions
s’enchaînent ensuite à un rythme soutenu pour obtenir un
feedback maximal sur l’avancement des développements.
 L’équipe s’organise elle-même pour atteindre ses objectifs,
en favorisant une collaboration maximale entre ses
membres.
 L’équipe met en place des tests automatiques pour toutes
les fonctionnalités qu’elle développe, ce qui garantit au
produit un niveau de robustesse très élevé.
 Les développeurs améliorent sans cesse la structure
interne du logiciel pour que les évolutions y restent faciles
etALEXANDRE
rapides.LEPRIEULT 25
OUVERTURE AU CHANGEMENT
 Les démarches traditionnelles, basées
sur la fameuse séquence « spécification
> conception >réalisation > validation
», concentrent la plupart des décisions
en début de projet

ALEXANDRE LEPRIEULT 26
OUVERTURE AU CHANGEMENT
 L’objectif de cette approche est louable : le client veut des
garanties sur ce qu’il obtiendra en fin de projet, et le chef de
projet souhaite disposer des informations nécessaires à
l’organisation de son équipe.
 Malheureusement, les équipes qui évoluent dans un
environnement changeant ou complexe savent à quel point il
est difficile de s’en tenir aux décisions initiales. Le client réalise
que ses besoins ont changé, ou bien l’équipe découvre en phase
d’implémentation des erreurs de spécification ou de conception
qui compromettent les plans de développement. Le changement
s’impose donc tôt ou tard, mais voilà : cette organisation
suppose l’absence de changement, et celui-ci se révèle bien vite
très coûteux - suffisamment parfois pour compromettre la
rentabilité du projet.
 Mais puisque le changement est une composante
incontournable de tout projet de développement logiciel,
pourquoi ne pas l’accepter ? N’existe-t-il pas un moyen pour que
les équipes de développement n’opposent plus de rigidité
excessive aux demandes de leur maîtrise d’ouvrage ?

ALEXANDRE LEPRIEULT 27
OUVERTURE AU CHANGEMENT
 Les créateurs d’XP ont trouvé une réponse à ces questions en
découvrant que certaines pratiques d’organisation d’équipe et
de programmation, appliquées ensemble, permettent de rendre
le logiciel extrêmement malléable à tel point qu’il devient plus
avantageux de le faire évoluer progressivement que de chercher
à le spécifier et le concevoir complètement dès le départ.
 Partant de ce constat, ils ont conçu une démarche qui diffuse le
processus de décision tout au long du projet grâce à
l’enchaînement de cycles itératifs très courts.
 Le grand gagnant de cette démarche est d’abord le client du
projet. Plutôt que de voir son intervention cantonnée à la phase
initiale de recueil du besoin, il intègre véritablement le projet
pour en devenir le pilote. A chaque itération, il choisit lui-même
les fonctionnalités à implémenter, collabore avec l’équipe pour
définir ses besoins dans le détail, et reçoit une nouvelle version
du logiciel qui intègre les évolutions en question.

ALEXANDRE LEPRIEULT 28
OUVERTURE AU CHANGEMENT
Cette démarche présente de nombreux avantages en termes de
conduite de projet :
 Le client jouit d’une très grande visibilité sur l’avancement des
développements.
 Le client utilise le logiciel lui-même comme support de réflexion
pour le choix des fonctionnalités à implémenter .il peut en
particulier intégrer très tôt les retours des utilisateurs pour
orienter les développements en conséquence.
 La première mise en production du logiciel intervient très tôt
dans le projet, ce qui avance d’autant le moment à partir duquel
le client peut en tirer des bénéfices.
 L’ordre d’implémentation des fonctionnalités n’est pas guidée
par des contraintes techniques, mais par les demandes du
client. Celui-ci peut donc focaliser les efforts de l’équipe sur les
fonctionnalités les plus importantes dès le début du projet, et
ainsi optimiser l’utilisation de son budget

ALEXANDRE LEPRIEULT 29
LE CYCLE DE DÉVELOPPEMENT XP

 L’Extreme Programming vise une réduction


significative de la durée du cycle de
développement, c’est-à-dire du temps qui
s’écoule entre le moment où l’on décide
d’implémenter une fonctionnalité et celui où
l’on met en production une nouvelle version
du logiciel qui intègre la fonctionnalité en
question.
 Dans un projet XP, ce temps correspond
exactement à la durée d’une itération, c’est-à-
dire typiquement deux semaines. Chaque
itération reprend
ALEXANDRE LEPRIEULT
la structure suivante 30
LE CYCLE DE DÉVELOPPEMENT XP

ALEXANDRE LEPRIEULT 31
LE CYCLE DE DÉVELOPPEMENT XP

 Le premier jour de l’itération est consacré à la réunion de


planification, au cours de laquelle le client et l’équipe
conviennent de ce qui doit être implémenté au cours de
l’itération. A la fin de cette journée, l’équipe dispose de la liste
précise des tâches à réaliser.
 Ensuite, l’équipe s’organise pour réaliser les tâches en question.
Elle prend en charge le suivi des tâches, ainsi que les activités
d’analyse du besoin, de conception, d’implémentation et de test
correspondantes. Il est important de noter qu’il n’y a pas de
changement de cap intermédiaire : l’équipe se focalise sur son
objectif sans interruption jusqu’à la fin de l’itération.
 Au terme des deux semaines, l’équipe met une nouvelle version
du logiciel à disposition du client. Ce logiciel est robuste, testé,
et sa structure interne est laissée aussi propre que possible
pour que les prochaines évolutions y restent peu coûteuses.
ALEXANDRE LEPRIEULT 32
LE CYCLE DE DÉVELOPPEMENT XP

Cette organisation extrêmement réactive impose de nouvelles


contraintes sur le fonctionnement de l’équipe, susceptibles de
mettre en défaut les pratiques traditionnelles du développement
logiciel. Par exemple :
 Puisque le contenu fonctionnel du produit ne se décide
précisément qu’au fur et à mesure des itérations, il n’est plus
judicieux de faire reposer l’implémentation sur une conception
définie en début de projet. Dans une démarche purement
itérative, l’équipe doit être capable de faire émerger la
conception tout au long du développement pour suivre les
directions données par le client.
 En termes d’organisation d’équipe, il n’est plus judicieux de
séparer l’application en modules réservés à tel ou tel
développeur puisque pour une itération donnée rien n’empêche
le client de demander des fonctionnalités centrées sur un seul
module. Tous les développeurs doivent donc être en mesure de
travailler sur toute l’application.

ALEXANDRE LEPRIEULT 33
LES PRATIQUES XP
 Les pratiques XP sont pour la plupart des pratiques de bon sens
utilisées par des développeurs et des chefs de projets
expérimentés. On retrouve par exemple les tests unitaires
automatisés, les livraisons fréquentes ou encore les relectures
de code.
 La première nouveauté d'XP consiste à pousser ces pratiques à
l'extrême (d’où le nom de la méthode), ou comme le disent ses
auteurs "tourner tous les boutons jusqu'à 10 !" L’équipe utilise
des cycles de développement d’une ou deux semaines, les
développeurs écrivent des tests unitaires pour chaque classe, ils
se livrent à une relecture de code permanente via le travail en
binômes, etc.
 La seconde nouveauté d’XP consiste à organiser ces pratiques
en un tout cohérent, de sorte que chaque pratique renforce les
autres. Il en résulte une méthode complète, qui couvre tous les
aspects du développement - de la relation avec le client jusqu'à
l'écriture du code, en passant par les plannings et l'organisation
de l'équipe.

ALEXANDRE LEPRIEULT 34
principaux éléments du fonctionnement d’XP

 Cycles itératifs pilotés par le client : Le projet


progresse au rythme d’itérations très courtes, dont le
contenu fonctionnel est déterminé par le client.
 Travail d’équipe auto-organisé : L'équipe travaille
réellement... en équipe. Les développeurs organisent
eux-mêmes leur travail, interviennent sur l’ensemble
du code, travaillent systématiquement en binômes, et
synchronisent leurs développements plusieurs fois
par jour.
 Programmation pilotée par les tests : les
développeurs écrivent des test automatiques pour
chaque portion de code qu’ils conçoivent, et ils
s’appuient sur ces tests pour affiner et améliorer sans
cesse la conception de l’application sans craindre de
régression.

ALEXANDRE LEPRIEULT 35
Le rôle de « client XP »
 Le pilotage du projet est assuré par un
membre spécifique de l’équipe projet : le «
client ». Le client détermine les
fonctionnalités du logiciel, gère les priorités,
définit les spécifications précises du produit
en somme, ce rôle correspond à ce que nous
nommons en France la maîtrise d’ouvrage du
projet. Dans un projet XP, ce représentant de
la maîtrise d’ouvrage rejoint le projet à plein
temps.

ALEXANDRE LEPRIEULT 36
La phase initiale d’exploration
 Le projet démarre par une phase d’exploration
volontairement très courte (typiquement un mois
maximum), qui a pour triple objectif de définir le
contenu fonctionnel de l’application, établir un
premier plan de développement pour le projet, et
produire la toute première version du logiciel.
 Au cours de cette phase, le client explore et définit le
contenu fonctionnel qu’il souhaite voir implémenté
dans le produit. Il établit ainsi une liste de
fonctionnalités, qui prennent en XP la forme de «
scénarios client ».
 Un scénario client décrit en quelques mots un besoin
particulier du client. Par exemple, pour un logiciel de
gestion de carnet d'adresses le client pourrait écrire
les scénarios suivants :
 "Je rentre un nom ou prénom, et le logiciel affiche la liste de
toutes les personnes qui possèdent ce nom ou ce prénom"
"Je peux
ALEXANDRE
 exporter mon carnet d'adresses au format HTML." 37
LEPRIEULT
Planification du projet
La planification est réalisée au cours d’une réunion dédiée, qui
réunit l’équipe et le client et se déroule comme suit :
1. Le client présente les différents scénarios à l’équipe, qui tente
de se faire une idée de la charge de travail de chacun d’entre
eux.
2. L’équipe donne pour chaque scénario une estimation de son
coût d’implémentation, en « points » abstraits : tel scénario
coûte 3 points, tel autre 1 point, etc.
3. L’équipe donne au client une estimation de sa « vélocité », c’est-
à-dire du nombre de points de scénarios qu’elle s’estime
capable de traiter en une itération – par exemple 10 points.
Au tout début du projet cette vélocité est seulement estimée,
mais après les premières itérations elle est réajustée en
adoptant la règle suivante : la vélocité estimée pour une
itération donnée correspond exactement au nombre de points
effectivement traités à l’itération précédente.
4. Le client établit lui-même le plan de développement en affectant
les différents scénarios aux itérations à venir, de sorte qu’à
chaque itération la somme du nombre de points des scénarios
choisis soit égale à la vélocité annoncée.
ALEXANDRE LEPRIEULT 38
Première mise en production
 Cette première mise en production
intervient aussi tôt que possible dans le
projet : il faut trouver le contenu
fonctionnel minimal qui commence à
avoir un sens pour les utilisateurs,
quitte à faire preuve d’imagination en
amenant par exemple le nouveau
logiciel en complément d’un système
existant dans le cadre d’une
fonctionnalité bien précise.

ALEXANDRE LEPRIEULT 39
Livraisons suivantes
 Les mises en production s’enchaînent ensuite à un
rythme régulier, toujours fixé par le client. L’objectif
est d’obtenir un feedback très rapide sur le
développement. en pratique toutes les une à six
itérations selon la complexité de déploiement du
produit. Le plan de développement est
continuellement mis à jour si nécessaire pour tenir
compte des événements suivants :
 L’équipe de développement progresse à une vitesse
différente de celle prévue (dans le bon ou le mauvais sens)
 Le client décide de changer le contenu des itérations
restantes. Il peut ainsi permuter des scénarios en fonction
de nouvelles priorités, ou encore remplacer certains
scénarios du plan par de nouveaux.

ALEXANDRE LEPRIEULT 40
Tests de recette automatiques
 Pour chaque scénario planifié, un ensemble de tests de recette est
écrit. Ces tests ont pour but de vérifier de manière automatique (c’est-
à-dire sans intervention ou interprétation humaine) chacune des
fonctionnalités demandées par le client. Le client définit ces tests et
participe éventuellement à leur implémentation, assisté pour cela d’un
certain nombre de testeurs.
 Ces tests peuvent prendre plusieurs formes. Il peut s’agir de jeux de
données, sous forme par exemple de feuilles de tableur ou de fichiers
XML, qui définissent une transformation effectuée par le logiciel : «
pour telle entrée, le logiciel doit produire tel résultat ». Il peut s’agir
également de scripts pour les cas plus complexes, ces scripts décrivant
par exemple des séquences d’interactions de l’utilisateur avec
l’interface graphique du produit.
 Ces tests représentent dans un projet XP les spécifications détaillées de
l’outil – des spécifications formelles, toujours en phase avec le
développement. Dans un contexte « pur XP », ce sont les seules
spécifications : il n’y a pas de document de spécifications à proprement
parler. En pratique, cependant, des documents peuvent être exigés par
l’organisation qui encadre le projet. Des documents synthétiques sont
alors réalisés par le client.

ALEXANDRE LEPRIEULT 41
Travail d’équipe auto-organisé

 L’organisation d’une équipe XP s’éloigne de


l’organisation traditionnelle d’une équipe de
développement, dans lequel différents
développeurs travaillent sur des parties
distinctes de l’application, coordonnés par un
chef de projet responsable de l’intégrité de
l’ensemble. Ce schéma de séparation des
activités fait place dans XP à un schéma
d’intégration, ou de collaboration intensive.

ALEXANDRE LEPRIEULT 42
Responsabilité collective du code
 Chaque développeur d’une équipe XP est
susceptible de travailler sur toutes les parties
de l'application, sans être bloqué par une
éventuelle spécialisation initiale. Cette liberté
d’action s’accompagne toutefois d’une
responsabilité : chaque membre de l’équipe
est garant de la qualité de l’ensemble de
l’application – en particulier, chacun a le
devoir de laisser le code qu’il parcourt aussi
clair et propre que possible, pour faciliter le
travail de ceux qui y intervienvront par la
suite.

ALEXANDRE LEPRIEULT 43
Travail en binômes
 Les développeurs d’une équipe XP
travaillent quasiment tout le temps en
binômes, c’est-à-dire à deux sur un
même poste. L’idée n’est en aucun cas
d’avoir une personne qui code pendant
que l’autre la surveille, mais au
contraire d’aboutir à un dialogue
permanent par lequel les deux
membres du binôme sont engagés à
100% dans leur tâche.

ALEXANDRE LEPRIEULT 44
Stand-up meetings
 Chaque jour, toute l’équipe se réunit pour un
« stand-up meeting » d’une quinzaine de
minutes
 les participants se tiennent d’ailleurs tous
debout (d’où le nom) pour éviter que cela ne
traîne. A l’occasion de cette réunion, tous les
membres de l’équipe prennent la parole pour
faire un point sur l’avancement de l’itération,
et surtout pour organiser la journée de travail
à venir.

ALEXANDRE LEPRIEULT 45
Le rôle du coach
 Dans un contexte où l’équipe s’organise elle-même
en définissant et en choisissant ses tâches, le rôle de
chef de projet tel que nous le connaissons devient
inadéquat. L’activité de coordination de l’équipe est
prise en charge par un « coach », qui est davantage
un facilitateur qu’un donneur d’ordres. Le but du
coach est en effet de former l’équipe aux pratiques
XP, et ensuite de travailler en permanence sur les
pratiques de l’équipe pour améliorer son
fonctionnement et l’amener à l’autonomie.
 Les fonctions hiérarchiques et administratives du chef
de projet font l’objet dans XP d’un rôle particulier : le
« manager ». Le manager est le patron de l’équipe, il
s’assure qu’elle dispose des moyens nécessaire à son
fonctionnement, fait l’interface avec le reste de
l’organisation, et vérifie enfin que les résultats sont
bien là.
ALEXANDRE LEPRIEULT 46
PROGRAMMATION PILOTÉE PAR LES
TESTS
 La démarche extrêmement itérative proposée
par XP n’est viable que si l’équipe est en
mesure de garder la maîtrise technique de
l’application, c‘est-à-dire de faire en sorte que
les modifications du code restent longtemps
faciles et rapides malgré les nombreuses
évolutions.
 Cette maîtrise n'est pas le fruit du hasard, elle
est le résultat d’une discipline de
développement qui s’appuie sur les pratiques
suivantes :

ALEXANDRE LEPRIEULT 47
PROGRAMMATION PILOTÉE PAR LES
TESTS
 Mise en place intensive de tests unitaires
 En complément des tests de recette, qui servent à prouver au client que le
logiciel remplit ses objectifs, XP utilise intensivement les tests unitaires de non-
régression. Ces tests sont écrits par les développeurs en même temps que le
code lui-même, pour spécifier et valider le comportement de chaque portion de
code ajoutée.
 Quasiment chaque classe de l'application possède une classe jumelle de test.
Lorsque des développeurs doivent ajouter une nouvelle méthode à la classe
applicative, ils commencent par ajouter à la classe de test un ensemble
d'assertions qui décrivent le comportement de la méthode à ajouter. La méthode
n'est implémentée qu'ensuite, pour que ces tests passent. Il est important de
noter que les tests s'exécutent sans aucune interprétation de la part du
développeur : les assertions en question doivent vérifier automatiquement si le
code testé fonctionne ou non.
 Les classes de tests ne sont pas jetées après usage : elles sont gérées par un
framework dédié qui permet de les exécuter individuellement ou en totalité. La
batterie de tests de l'application ne cesse donc de s'enrichir, et forme avec le
temps un filet de sécurité qui permet aux développeurs d’effectuer des
modifications dans le code existant sans crainte de régression.
 Ces tests sont lancés à longueur de journée par les développeurs - en fait, à
chaque compilation. Tous les tests unitaires doivent passer à 100% dans
l’environnement d’un binôme avant tout report de modifications dans la version
d'intégration du logiciel.

ALEXANDRE LEPRIEULT 48
La démarche RAD DSDM
 La méthode s'applique bien dans le cadre de petites applications de gestion, n'ayant pas de
cycle de vie d'une trop longue durée

ALEXANDRE LEPRIEULT 49
DSDM

 0 Etude de Faisabilité ;
 1 Etude du Business ;
 2 Modèle Fonctionnel Itératif ;
 3 Conception et Réalisation Itératives
 4 Mise en OEuvre

ALEXANDRE LEPRIEULT 50
ALEXANDRE LEPRIEULT 51
DSDM
 LES 9 PRINCIPES FONDAMENTAUX

1. L'implication active des utilisateurs est impérative


DSDM se présente comme une approche centrée sur les
utilisateurs.
Si les utilisateurs ne sont pas fortement impliqués pendant tout
le cycle de vie, on aura des retards dans la prise de décisions.
Les utilisateurs ne sont plus seulement des fournisseurs
d'information et des recetteurs de modules extérieur à l'équipe,
mais de véritables acteurs du développement.

2. Les équipes DSDM doivent être autorisées à prendre des


décisions
Les équipes DSDM sont constituées des développeurs et
d'utilisateurs.
Ils doivent être capables de prendre des décisions concernant
l'évolution des besoins, et leur éventuelle modification.
Ils doivent disposer d'un pouvoir pour déterminer le niveau de
fonctionnalité sans avoir recours à la direction.
ALEXANDRE LEPRIEULT 52
DSDM
3. Le produit est rendu tangible aussi souvent que possible
Une approche basée sur la livraison régulière de fournitures est
plus flexible qu'une approche orientée activités.
L'équipe DSDM vise la livraison de fournitures dans un délai
limité ; et l'équipe détermine la meilleure approche pour aboutir
aux résultats souhaités dans le temps imparti.
Des périodes de délais très courts permettent de définir les
activités nécessaires pour atteindre les résultats prioritaires.

4. L'adéquation au besoin métier est le critère essentiel pour


l'acceptation des fournitures
DSDM vise la livraison dans les délais des fonctions métier
nécessaire pour satisfaire les objectifs de l'entreprise. Si on le
souhaite, le système complet peut être élaboré plus tard.
L'approche traditionnelle consiste à répondre aux exigences
d'un cahier de charges en restant cohérent avec des produits en
place. Trop souvent, on perd de vue le fait que le cahier de
charges est inexact et que les produits existants sont imparfaits.

ALEXANDRE LEPRIEULT 53
DSDM
5. Un développement itératif et incrémental permet de converger vers
une solution appropriée
DSDM permet une évolution incrémentale des systèmes. Par
conséquent, l'équipe de développement exploite à fond le contact avec
les utilisateurs.
De plus, des solutions partielles peuvent être livrées pour satisfaire des
besoins immédiats.
L'itération est inhérente à la réalisation informatique. DSDM le
reconnaît, et pour le rendre explicite, renforce l'emploi de l'itération.
Lorsque les rebuts ne sont pas explicitement admis, le retour en arrière
est entouré de procédures de contrôle qui ralentissent le
développement. Grâce à l'intégration du principe de rebuts dans la
démarche DSDM, le développement peut avancer plus rapidement lors
des itérations.

6. Toute modification pendant la réalisation est réversible


Les retours en arrière font partie du DSDM. Cependant, en certaines
circonstances, une reconstruction peut s'avérer plus facile qu'un retour
en arrière. Tout dépend de la nature du changement et de
l'environnement.
Cette réversibilité nécessite une bonne maîtrise de la gestion de
configuration du logiciel en développement.
ALEXANDRE LEPRIEULT 54
DSDM
7. Les besoins sont définis à un niveau de synthèse
Le schéma directeur fixe les exigences du système à
un niveau suffisamment élevé pour permettre une
évolution itérative des niveaux plus détaillés.

8. Les tests sont intégrés pendant tout le cycle de vie


Les tests ne sont pas traités comme une activité à
part. Au fur et à mesure que le système évolue, les
tests servent à valider que la réalisation est en cours
sur le plan technique et fonctionnel.
En amont, les tests assurent que les priorités du
développement sont bien prises en compte.
Vers la fin d'un projet, les tests assurent les
utilisateurs et les développeurs que le système
fonctionne efficacement.
ALEXANDRE LEPRIEULT 55
DSDM

9. Un esprit de coopération entre tous les


acteurs est primordial
Dans la démarche DSDM les fonctions
détaillées ne sont pas figées dès le départ.
Le fil conducteur doit être défini sans
recours à une procédure de gestion de
modifications trop contraignante.
Le demandeur et le réalisateur doivent faire
preuve d'une capacité de souplesse pendant
la phase préalable et une fois que le contrat
est en cours.

ALEXANDRE LEPRIEULT 56
DSDM
 C’est une approche incrémentale basée sur des
prototypes de validation
 Il est possible à tout moment de revenir sur toutes
les phases précédentes du développement
 Elle met en avant le travail en équipe avec des
notions de : Visionnaire , d’ambassadeurs
 Au niveau documentation , le stricte nécessaire sera
produit
 La notion de TimeBoxing et de temps impartie pour
réaliser une fonction est primordiale ce qui peux
entraîner une hiérarchisation sur le développement
avec accord du client

ALEXANDRE LEPRIEULT 57
Les règles MoSCoW (FISPE)

 Dans la mesure ou les timeboxes


doivent demeurer fixes, il arrive que le
nombre de fonctions livrées soit
inférieur à celui initialement prévu. Il
est toutefois indispensable que
l’essentiel du travail soit réalisé et que
seules les tâches les moins importantes
soient laissées de côté. La méthode qui
permet d’y parvenir est la prioritisation
des besoins.

ALEXANDRE LEPRIEULT 58
Les règles MoSCoW (FISPE)

 Les Fonctions Indispensables,


Souhaitables, Possibles, Eliminées
(FISPE) : Les règles
 MoSCoW (FISPE) permettent d’établir
une hiérarchie claire des besoins. Les «
o » du terme MoSCoW en anglais n’ont
d’autre objet que d’ajouter une pointe
d’humour. Quant aux lettres M, S, C,
elles ont la signification suivante :

ALEXANDRE LEPRIEULT 59
Les règles MoSCoW (FISPE)

 « Must have » (Indispensable)


désigne les besoins fondamentaux du
système. Si ces besoins ne sont pas
satisfaits, le système sera inexploitable
et donc inutile. Les « Must Have »
définissent le sous-ensemble
minimum utilisable. Un projet DSDM
garantit la réalisation intégrale du sous-
ensemble minimum utilisable.

ALEXANDRE LEPRIEULT 60
Les règles MoSCoW (FISPE)

 « Should have » (Souhaitable)


désigne les besoins importants qui
peuvent être contournés dans le court
terme et qui seraient considérés comme
obligatoires dans des conditions de
délai moins contraignantes. Le système
demeure cependant exploitable et utile
même si ces besoins ne sont pas
satisfaits.

ALEXANDRE LEPRIEULT 61
Les règles MoSCoW (FISPE)

 « Could have » (Possible) désigne


les besoins dont la satisfaction peut être
aisément omise durant le
développement d’un incrément

ALEXANDRE LEPRIEULT 62
Les règles MoSCoW (FISPE)

 « Want to have but Won’t have


this time round » (souhaité mais
non réalisable dans l’immédiat,
donc Elimine) désigne des besoins
dont la satisfaction peut être remise à
plus tard, lors de développements
futurs.

ALEXANDRE LEPRIEULT 63
Comparatif avec les méthodes classiques

BSDM
Classiques

ALEXANDRE LEPRIEULT 64
MÉTHODE MERISE (TARDIEU 1978)
 MERISE est une méthode de conception et de
développement définie et mise au point dans sa première
version durant les années 1978 et 1979, sous l'égide du
Ministère de l'Industrie, par un groupement formé par les
6 SSII majeures et certaines grandes administrations
(Finances, Equipement, Défense, ...).
 MERISE constitue depuis le milieu des années 80 un
standard de fait dans le domaine des systèmes
d'information de gestion en France et dans les pays
francophones.
 Cette méthode intègre à la fois les aspects décisionnels et
techniques, elle s'apparente en cela au modèle en spirale
mais procède plutôt en cascade.
 Elle est utilisée pour développer des systèmes
d'information complets et subit des mises à jour
fréquentes.
 Plusieurs outils la supportent (Mega, AMC Designor,
foundation...)
ALEXANDRE LEPRIEULT 65
MÉTHODE MERISE (TARDIEU 1978)

 Elle traite l'ensemble du


cycle de vie d'un système
d'information et adopte une
approche systémique de
l'entreprise.
 Elle tient compte des 3 axes:
cycle de décision, cycle
d'abstraction et cycle de vie.

ALEXANDRE LEPRIEULT 66
MÉTHODE MERISE (TARDIEU 1978)

 Elle procède par étapes


 Schéma directeur: approche globale du
problème prenant en compte la stratégie
 Étude préalable de chaque domaine
 Étude détaillée de chaque sous domaine
 Étude technique par projet
 Réalisation par projet
 Mise en oeuvre projet par projet
 Exploitation de l'ensemble
 Maintenance de l'ensemble

ALEXANDRE LEPRIEULT 67
ALEXANDRE LEPRIEULT 68
MÉTHODE MERISE (TARDIEU 1978)
 Comme dans le cycle de vie en spirale ou dans le modèle
incrémental on met en exploitation les projets issus des
différents domaines les uns après les autres jusqu'à obtenir un
système complet.
 La méthode opère par une modélisation descendante des
systèmes et utilise une séparation données / traitements
/communication
 Une version Merise objets est aujourd'hui proposée
 Le système d'information est décomposé en différents niveaux
- conceptuel (description de l'activité: QUOI)
- organisationnel (QUI, OU, QUAND)
- physique (description des moyens, COMMENT, avec quelle
ressource)
 Ces trois niveaux s'appuient sur un certain nombre de modèles,
Modèle de communication ,Modèles de données, Modèles de
traitements sur lesquels
 MERISE est en constante évolution, en particulier MERISE
intègre aujourd'hui les concepts et techniques de l' approche
objets.
ALEXANDRE LEPRIEULT 69
MODÈLE DE CYCLE DE VIE ORIENTE OBJETS

 Dans une approche orientée objets, la


différence entre analyse et conception est
peu visible. On procède plutôt par itérations
et raffinements successifs.
 Le modèle en fontaine (Henderson) fait
apparaître ce recouvrement des phases
d'analyse et conception. Les flèches
représentent les itérations à l'intérieur d'une
phase.

ALEXANDRE LEPRIEULT 70
ALEXANDRE LEPRIEULT 71
MODELE DE CYCLE DE VIE ORIENTE REUTILISATION DE
COMPOSANTS

 La volonté de réutilisation du code induit des


cycles de vie légèrement différents de ceux
vus jusqu'ici.
 Les objets décrits dans un projet peuvent être
réutilisés dans un autre et sont donc récoltés
en fin de cycle de vie pour être placés dans
une bibliothèque d'objets.
 Il est important de consacrer une part non
négligeable du temps du projet à gérer la
réutilisation.

ALEXANDRE LEPRIEULT 72
MODÈLE DE CYCLE DE VIE ORIENTE RÉUTILISATION DE
COMPOSANTS

ALEXANDRE LEPRIEULT 73
Les méthodes orientées-objet

 Dans l'approche orientée-objet, on


s'intéresse aux données sur lesquelles
les traitements agissent. Au lieu de
décomposer les problèmes ou
fonctionnalités, on considère les
données en tant qu'entité de première
classe. Les fonctions sont alors
attachées aux données.

ALEXANDRE LEPRIEULT 74
Rational Unified Process

Rational Unified Process (RUP) : est un


processus de conception/développement de
logiciel défini par Rational Software.

http://www.rational.com/
ALEXANDRE LEPRIEULT 75
Organisation séquentielle
Le risque est au début

• Les décideurs prennent le risque


• Les concepteurs assument…
• Les développeurs suivent…
Prérequis
R
I Conception
S
Q Développement
U
E Tests unitaires

Test système

ALEXANDRE LEPRIEULT TEMPS 76


Organisation participative
Le risque est partagé

Equipe
Inception

Conception
Risque

Construction

Transition

Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Post-


Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration deployment

ALEXANDRE LEPRIEULT
Temps 77
Développement itératif
– Les risques sont évalués avant les
premières itérations permettent d’avoir
des retours utilisateur
– Le test et l’intégration sont continus
– Les jalons permettent de fixer les objectifs
– Les avancées sont mesurées au fur et à
mesure de l’implémentation
– Des maquettes intermédiaires peuvent
être déployées
ALEXANDRE LEPRIEULT 78
Accroître la productivité en
conception/développement
Tous les membres partagent
• Des bases de connaissance
• Une même méthode
Performance
• Une organisation du travail Engineer

• Un langage
Database
Administrator
Release
Engineer
Project
Leader

Analyst Designer / Tester


ALEXANDRE LEPRIEULT 79
Developer
Le langage RUP : un modèle visuel
Activité

Oriente Se focalise

Guide

Travailleur

Automatisent Fédèrent

Instrumentent Accélèrent
Outils Services

Amplifient Utilisent

ALEXANDRE LEPRIEULT 80
Quatre éléments de modélisation dans
RUP

• Membre est le qui : Chef de projet, Analyste,


Testeur, Utilisateur, etc.
• Artéfact est le quoi : Document de l’architecture,
Modèle des cas d’utilisation, Fichier exécutable, etc.
• Activité est le comment : Analyse de cas
d’utilisation, Conception de cas d’utilisation, etc.
• Enchaînement d’activités est le quand :
Modélisation de métier, implémentation, test, etc.

ALEXANDRE LEPRIEULT 81
Notations
Décrit une partie du
travail
Activité
Membre

Décrit un rôle
Use-Case
dans le Specifier
processus
Artéfact
Responsable de

Décrit une connaissance


ou une donnée
Use Case Use-Case
Package

ALEXANDRE LEPRIEULT 82
Exemple : rôles du concepteur

activité1 activité2

Concepteur Analyse de cas Conception de


d ’utilisation cas d ’utilisation

est responsable de produit


Connaissance
Réalisation de cas d ’utilisation Document

ALEXANDRE LEPRIEULT 83
Planification des RH
R e s o u rc e Wo rk e r A c tiv itie s

Paul Designer Define Operations


...

Mary Us e-Case Specifier Des cribe a Use Cas e


...

Joe Us e-Case Designer Dis tribute Behavior


...

Sylvia Design Reviewer Review Us e-Cas e Model


...

Stefan Archite ct Define Us e-Case View


Define Logical Viiew
...

Chaque membre est


considéré comme un
acteur
ALEXANDRE LEPRIEULT 84
Exemple d’un Workflow

ALEXANDRE LEPRIEULT 85
RUP est itératif et incrémental

Exigences Analyse & conception

Implémentation
Gestion
Environnement
Planification initiale

Déploiement

Planification
Tests

Chaque itération a pour finalité une version exécutable.

ALEXANDRE LEPRIEULT 86
Architecture bidirectionnelle
du RUP

ALEXANDRE LEPRIEULT 87
Enchaînement d’activités dans
RUP

6 enchaînements
d'activités essentielles
• Modélisation du métier
3 enchaînements
• Gestion des exigences
d'activités de soutien
• Analyse et Conception
• Gestion de Projet
• Implémentation
• Gestion de la configuration
• Test et des changements
• Déploiement • Environnement

ALEXANDRE LEPRIEULT 88
Enchaînement d’activités dans RUP
Modélisation du métier

Il a pour but
• de décrire la structure et la dynamique de
l'organisation (ou de l ’équipe participative)

• de garantir que les clients, les utilisateurs finaux et les


développeurs partagent une vision commune de
l'organisation

• de réaliser une base d'information qui contiendra le


cahier des charges du produit et la planification des
tâches de l ’organisation.
ALEXANDRE LEPRIEULT 89
Enchaînement d’activités dans RUP
Gestion des exigences

Il a pour but

• de définir une vision du produit

• de traduire cette vision en un modèle de cas d'utilisation,


(ce modèle, accompagné des spécifications externes,
constitue le cahier des charges logicielles)

• d’organiser et de gérer les exigences

• de définir et de construire une maquette de l'interface


utilisateur.
ALEXANDRE LEPRIEULT 90
Enchaînement d’activités dans RUP
Analyse et conception

• L'objectif de l'analyse est de comprendre le cahier des


charges et d ’écrire les spécifications internes.  L'analyse
permet d'obtenir une vue interne du produit
• La conception a pour but de définir l'architecture du
système/produit

• L'analyse se concentre sur le "quoi faire", la conception se


concentre sur le "comment le faire".

ALEXANDRE LEPRIEULT 91
Enchaînement d’activités dans RUP
Test

• La phase de test a pour objectif d'évaluer le niveau de


qualité atteint par le produit et d'en tirer les conclusions.
Elle s'appuie sur les cas d'utilisation et définit des cas de
test.

ALEXANDRE LEPRIEULT 92
Enchaînement d’activités dans RUP
Déploiement

• Le but de l'enchaînement des activités de


déploiement est de livrer le produit aux utilisateurs
finaux.

ALEXANDRE LEPRIEULT 93
Enchaînement d’activités dans RUP
Gestion de projet

• La planification d'un projet itératif

• La gestion des risques

• Le contrôle des progrès.

ALEXANDRE LEPRIEULT 94
Enchaînement d’activités dans RUP
Gestion de la configuration et des
changement

• Le but de la gestion de la configuration et des


changements est de garder la trace de tous les éléments
tangibles qui participent au développement, et de suivre
leur évolution.

ALEXANDRE LEPRIEULT 95
Enchaînement d’activités dans RUP
Environnement

Il a pour but de fournir


• un processus de développement adapté au projet

• des outils de travail qui aident à réaliser les activités


et les artefacts du processus.

ALEXANDRE LEPRIEULT 96
Phases dans RUP

Inception Conception Construction Transition

Jalon : Jalon : Jalon : Jalon :


objectifs architecture du prototype livraison du
système produit

Temps

ALEXANDRE LEPRIEULT 97
Inception

• Il s’agit de décrire quelle vision on a du


produit final et où on veut aller, de réaliser
une étude de rentabilité et de définir le
projet.
• La phase Inception se termine par le jalon
«  objectifs»

ALEXANDRE LEPRIEULT 98
Conception

• Il s’agit de
¤ planifier les activités et les ressources
nécessaires à la réalisation du projet
¤ spécifier les fonctionnalités
¤ concevoir l’architecture
• La phase de conception se termine par
le jalon «  architecture du système »
ALEXANDRE LEPRIEULT 99
Construction

• Il s’agit de construire le système et de faire


évoluer la vision, l ’architecture et les plans de
développement jusqu’à l ’obtention d’un
produit prêt à être testé.
• La phase construction se termine par le jalon
«  prototype »

ALEXANDRE LEPRIEULT 100


Transition

• Il s’agit de soumettre le produit aux


utilisateurs (béta-test)
• La phase transition se termine par le
jalon « livraison du produit » ou par une
nouvelle itération

ALEXANDRE LEPRIEULT 101


Ambition de RUP

• Faire face aux changements en


cours du projet qui restent les causes
principales de l’échec du projet.

• Par exemple :
¤ Les utilisateurs changent leurs exigences
¤ L’équipe de développement modifie
l’architecture du logiciel
ALEXANDRE LEPRIEULT 102
Changement des exigences

• Au départ, les utilisateurs ne savent pas


quelles sont leurs exigences et comment
les spécifier de façon précise.
• Ils changent leurs exigences quand ils
voient les livrables

Effet: IKIWISI
I Know It When I See It - Je le saurai quand je l ’aurai vu
Bary Boehm - Université de Californie du Sud
ALEXANDRE LEPRIEULT 103
Changements de l’architecture

• Les membres de l’équipe :


¤ n’ont peut-être pas bien compris le système
exigé
¤ n’ont peut-être pas partagé une même
compréhension du système

ALEXANDRE LEPRIEULT 104


RUP : tracer les changements

• RUP définit un enchaînement d’activités de


soutien : gestion des configurations et des
changements
• RUP est piloté par les cas d ’utilisation

ALEXANDRE LEPRIEULT 105


RUP est piloté par les cas
d’utilisation

Réalisé Vérifié
Vérifiépar
Réalisépar
par par

Implémenté
Implémentépar
par

Modèle
Modèlede
deconception
conception Modèle
Modèled’implémentation
d’implémentation Modèle
Modèlede
detest
test
ALEXANDRE LEPRIEULT 106
Avantages

• RUP améliore la qualité du produit


• RUP augmente le taux de succès du projet
• RUP est supporté par les outils du Rational
Software

ALEXANDRE LEPRIEULT 107


RUP améliore la qualité du produit

• RUP améliore la compréhension du système


¤ RUP est itératif
¤ RUP reste centré sur l’architecture
¤ RUP utilise UML pour modéliser le logiciel

ALEXANDRE LEPRIEULT 108


RUP améliore la qualité du produit

• RUP contrôle et trace le processus de


transformation de la compréhension du
système en produit
¤ RUP est piloté par les cas d’utilisation
¤ RUP contrôle l’avancement de travail à l ’aide des
livrables fournis dans les jalons

ALEXANDRE LEPRIEULT 109


RUP augmente le taux de succès
du projet

RUP permet d’anticiper et de limiter les


risques. On peut mieux les traiter quand ils
sont petits...

ALEXANDRE LEPRIEULT 110


RUP est intégré par les outils du
Rational Software
Apex Purify
Visual Studio
Quantify
PureCoverage

Rose

TeamTest

RequisitePro
ClearQuest

SoDA ClearCase
ALEXANDRE LEPRIEULT 111
Interface

ALEXANDRE LEPRIEULT 112


Présentation des rôles

ALEXANDRE LEPRIEULT 113


Présentation des scénarios

ALEXANDRE LEPRIEULT 114


Diagramme de la collaboration

ALEXANDRE LEPRIEULT 115


Présentation des classes (UML)

ALEXANDRE LEPRIEULT 116


Diagramme des états de transition

ALEXANDRE LEPRIEULT 117


Diagramme des composants

ALEXANDRE LEPRIEULT 118


Points faibles de RUP

• RUP ne supporte pas les multi-projets


• RUP exige des experts
• RUP est propriété de Rational Software

ALEXANDRE LEPRIEULT 119


RUP est un cadre de processus

• RUP décrit qui, quoi, comment et quand faire à


l’aide d’un langage visuel
• RUP apporte des outils et une méthode
d’organisation pour l’ingénierie participative
• RUP apporte une vision unifiée sur le processus
qui peut être partagée par tous les acteurs

ALEXANDRE LEPRIEULT 120


2TUP
 Comment gérer la complexité technologique ?
 La meilleure façon d’aborder un problème, c’est de

s’y attaquer de front. C’est ce que propose le 2TUP


en faisant une place à part entière à la technologie
dans le processus de développement !
 Le 2TUP propose un cycle de développement en Y,

qui dissocie les aspects techniques des aspects


fonctionnels.
 le processus en Y s’articule autour de 3 phases:

•= une branche technique


•= une branche fonctionnelle
•= et une phase de réalisation

ALEXANDRE LEPRIEULT 121


2UP

ALEXANDRE LEPRIEULT 122


Quelle Méthode choisir ?

ALEXANDRE LEPRIEULT 123


ALEXANDRE LEPRIEULT 124
Processus 2TUP

 La branche fonctionnelle comporte:


 capture des besoins fonctionnelles
 analyse fonctionnel du système à produire
en terme métier indépendament de la
techno.

ALEXANDRE LEPRIEULT 125


Processus 2TUP
 La branche architecture technique:
 capture des besoins techniques:
 recencement des contraintes
 dimensionnement.
 conception générique:
 définition des composants

prototype

ALEXANDRE LEPRIEULT 126


Processus 2TUP
 Ces deux branches se réunissent dans
les phases:
 Conception préliminaire
 Conception détaillée
 Codage et test
 Recette

ALEXANDRE LEPRIEULT 127


Processus incrémental

1. validation fonctionnelle: validation du


principe du système
2. validation technique: focalisation sur
architecture: prototype
3. réalisation des fonctions les plus
propriétaire
4. finition

ALEXANDRE LEPRIEULT 128


Processus pilotés par les exigenes
les utilisateurs
 branche fonctionnelle
 cas d'utilisation sur les plus value métiers
des fonctions du système
 classes d'analyse avec les concepts des
utilisateurs
 branche technique
 cas d'utilisation techniques pour spécifier
l'architecture
 décomposition en couches logicielles
 conception des classes

ALEXANDRE LEPRIEULT 129


Modélisation
 Le modèle évolue en fonction de l'étape
on l'on est:
 capture des besoins: le système est
considéré comme une boîte noire
 analyse: on représente le système vu de
l'intérieur
 conception: on modélise en utilisant:
 outils
 langage
 plateforme de développement

ALEXANDRE LEPRIEULT 130


 Diagrammes UML ET 2TUP

ALEXANDRE LEPRIEULT 131


Diagrammes des cas d'utilisation
(statique)
 représente la structure des
fonctionnalités nécessaires aux
utilisateurs du système
 utilisés dans
 capture des besoins fonctionnels
 capture des besoins techniques

ALEXANDRE LEPRIEULT 132


Diagrammes de classes (statique)

 branche fonctionnelle: développe la


structure des entités connues des
utilisateurs
 conception: représente
 la structure d'un code OO
 module du langage de dev

ALEXANDRE LEPRIEULT 133


Diagrammes d'objets (statique)

 illustre la structure des classes


 en analyse, vérifie l'adéquation d'un
diagramme des classes aux différents
cas possible

ALEXANDRE LEPRIEULT 134


Diagrammes de composants
(statique)
 représentation des concepts pour installation
et maintenance du système,
 détermination de la structure des composants:
 librairies dynamiques
 instances de base de données
 applications
 progiciels
 objet distribués
 exécutables
 représentation des concepts de configuration
logicielle
 agencement des composants
fichiers sources
 packages

ALEXANDRE LEPRIEULT
 librairies 135
Diagrammes de dépoiement
(statique)
 structure du réseau informatique
 installation des composant informatique

ALEXANDRE LEPRIEULT 136


Diagrammes d'états (dynamique)

 représentent le cycle de vie des objets


d'une classe
 utilisés en analyse, dans le
développement du modèle dynamique
 utilisés en conception, dans la phase
conception détaillée

ALEXANDRE LEPRIEULT 137


Diagrammes d'activité (dynamique)

 régles d'enchaînement des activités du


système
 consolidation des spécifications d'un cas
d'utilisation (phase capture des besoins
fonctionnels)
 conception d'une méthode (phase
conception détaillée - étude détaillée)

ALEXANDRE LEPRIEULT 138


Diagrammes de collaboration et de
séquence (dynamiques)
 diagrammes d'interraction
 représentent les échanges de messages entre
objets, pour une fonction donnée du système
 les diagrammes de collaboration
 modélisent le contexte du système (en étude
préliminaire)
 aide la conception des méthodes (en conception
détaillée)
 les diagrammes de séquence développent en
analyse les scénarios d'utilisation (en phase
du développement du modèle dynamique)

ALEXANDRE LEPRIEULT 139


Processus itératif
 Avancement par étapes successives, de plus en plus
détaillée, en se basant sur l'étape précédente. Le
volume d'information grossit à chaque étape.
 Capture des besoins fonctionnels:
 niveau du contexte: définition de la frontière fonctionnelle
entre le système, considéré comme boîte noire, et son
environnement
 niveau des cas d'utilisation: définition des activité de chaque
utilisateur par rapport au système toujours considéré
comme boîte noire
 Pour l'analyse:
 Modèle d'analyse du domaine: définition de la structure et
du comportement des objets connus dans le "métier" des
utilisateurs, qui définissent le système;
 Modèle d'analyse de l'application: on ajoute des objets
nécessaires pour répondre aux besoins.

ALEXANDRE LEPRIEULT 140


Processus itératif
 Pour la capture des besoins techniques, le modèle
d'analyse:
 établit les couches logicielles
 spécifie les activités techniques attendues
 Pour la conception générique, le modèle de
conception générique:
 définit les composants qui répondent aux exigences
opérationnelles du système
 Pour la conception préliminaire, le modèle de
conception système:
 organise le système en composants
 ce modèle fait le lien entre les couches logicielles, produites
pendant la capture des besoins techniques, et les classes
décrites pendant l'analyse.
 Pour la conception des classes
ALEXANDRE
 LEPRIEULT
utilisation du modèle de conception des composants 141
Les points de vue de modélisation

ALEXANDRE LEPRIEULT 142


Spécifications fonctionnelle

 besoins fonctionnels exprimés par les


utilisateurs
 éléments:
 cas d'utilisation organisé en packages
 acteurs
 activités
 interractions entre objets
 contraintes dynamiques

ALEXANDRE LEPRIEULT 143


Structurel

 besoins élaborés en classes


 éléments:
 catégories
 classes
 associations
 généralisations
 attributs
 contraintes structurelles

ALEXANDRE LEPRIEULT 144


Matériel

 structure physique des machines et


réseau , prévoir le dimensionnement
des processeurs et des bandes
passantes concerne les ingénieurs
système et réseau
 éléments:
 noeuds
 connexion

ALEXANDRE LEPRIEULT 145


Déploiement

 concerne l'ingénieur d'exploitation


chargé d'installer le système
 elements
 postes de travail
 serveurs
 connexions
 composants qui permettent d'étudier les
échanges internes/externes

ALEXANDRE LEPRIEULT 146


Exploitation
 organisation des composants
 concerne
 les ingénieurs d'exploitation (trouver une panne)
 les concepteurs (recherche de dépendance
logicielle)
 éléments:
 composants
 interfaces

dépendances entre composants

ALEXANDRE LEPRIEULT 147


Spécification logicielle
 répartition par couches des exigences techniques
 dissocier par nature de responsabilités
 éléments:
 cas d'utilisation technique
 exploitants
 activité
 interactions entre objets
 contraintes dynamique
 utilisation de couches réparties en responsabilités:
 de présentation
 gestion des applications
 gestion du métier
 d'accès aux données

stockage des données
ALEXANDRE LEPRIEULT 148
Point de vue logique
 organisation du modèle de solution
 élaboré en classes
 éléments:
 classes regroupées en catégories
 interfaces
 associations
 généralisations
 réalisations
 attributs
 états
 opérations
 méthodes
 vision prêt à coder
 documente le code produit

ALEXANDRE LEPRIEULT 149


Configuration logicielle
 retrace la construction des composants
 mesure l'impact d'un changement
 établi les configurations et les
compatibilités entre les versions des
composants
 éléments
 sous-système
 composants de construction
 dépendance de fabrication

ALEXANDRE LEPRIEULT 150


Remarques
 La spécification fonctionnelle réalise le point de vues des utilisateurs.
Elle conditionne les points de vue structurelle et logique, le
déploiement de la conception système:
 les cas d'utilisation permettent de trouver les classes de la vue structurelle
du modèle d'analyse
 les scénarios élaborés par cas d'utilisation permettent de trouver les
opérations des interfaces de la vue logique du modèle de conception
système
 les cas d'utilisation identifie les fonctions qu'il faut répartir sur le
déploiement du modèle de conception système.
 La spécification logicielle se place du point de vue des exploitants:
 les cas d'utilisation techniques permettent de trouver les classesde la vue
logique du modèle de conception technique
 les cas d'utilisation techniques identifient les fonctions d'exploitation qu'il
faut répartir surt le déploiement du modèle de conception/
 La vue matérielle: support du déploiement
 La vue structurelle: projette ses classes dans la vue logique au niveau
de la conception système
 La vue d'exploitation: définit ses composants à partir
 des interfaces de la vue logique du modèle de conception technique
 des composants de déploiement
 La vue de configuration dépend des classes du modèle logique
ALEXANDRE LEPRIEULT 151
Un processus centré sur
l'architecture
 Architecture: Ensemble des décisions
d'organisation du système logiciel qui
défend les intérêts de son propriétaire
final. Les intérêts s'expriment en termes
de:
 d'exigences fonctionnelles;
 d'exigences techniques;
 d'exigences économiques.

ALEXANDRE LEPRIEULT 152


Axe de solutions génériques

 Architecture client/serveur en tiers


 capacité de montée en charge
 2-tiers: nombre limité d'utilisateur
 3-tiers/n-tiers: évolution du nombre
d'utilisateurs par introduction d'un
middleware

ALEXANDRE LEPRIEULT 153


Axe de solutions génériques
 Architecture en couche
 distributions des responsabilités
 exemple à 5 couches
 présentation
 application
 métier
 accès aux données
 stockage
 évolution et maintenance technique aisée

ALEXANDRE LEPRIEULT 154


Axe de solutions génériques
 Architecture en niveaux
 déploiement des fonctions sur les postes de
travail
 trois niveaux pour l'entreprise
 central
 départemental
 local
 contrôle de l'imbrication des fonctions du
sytème
 évolution et maintenance fonctionnelle aisée

ALEXANDRE LEPRIEULT 155


Axe de solutions génériques

 Architecture en composant
 opportunités de ré-utilisation
 nécessite une définition stricte de la
décomposition modulaire

ALEXANDRE LEPRIEULT 156


Avantages d'un processus centré sur
l'architecture
 L'architecture implique des décisions d'organisation
qui se répercutent sur la structure du modèle. Les
différents points de vue de modélisation deviennent
des outils de contrôle de l'architecte logiciel.
 impose le respect des décisions d'architecture à
chaque étape condition à l'intégrité d'un projet
complexe car
 structure et...
 ...rends cohérent les points de vue
 facilite la repartition du travail
 la documentation apportée par les modèles facilite
les textes, l'intégration, aide à identifier les sources
d'erreurs.

ALEXANDRE LEPRIEULT 157


Processus orienté Composants

 respect des règles d'architecture


 structuration du modèle à toutes les étapes
tendent naturellement à :
 regrouper les concepts à forte cohérence
 identifier les couplages entre parties
 L'expression des couplages implique:
 spécification des règles d'interface opportunités de
réutiliser les regroupements de concepts à
d'autres concepts de développement.
 Les regroupements de concepts définissent des
packages de composants dans le modèle.

ALEXANDRE LEPRIEULT 158


Processus orienté Composants
 Capture des besoins Les cas d'utilisation sont regroupés en
package pour organiser le modèle de spécification fonctionnel.
Ces packages :
 représentent les besoins d'un métier
 structurent la répartition en applications du système
 pendant l'analyse Les classes sont regroupés en catégories pour
organiser:
 modèle d'analyse métier
 modèle d'analyse de l'application
 Les catégories métier
 représentent la description détaillée des concepts de l'entreprise
 constituent des références réutilisables
 Les catégories d'analyse
 structurent les catégories de conception
 structurent la répartition en composant métier

ALEXANDRE LEPRIEULT 159


Processus orienté Composants

 Capture des besoins techniques


 Les cas d'utilisation sont regroupés en couches
logicielles...
 ...pour organiser le modèle de spécification
technique.
 Les couches logicielles structurent la création d'un
framework technique.
 Pendant conception technique
 Les classes sont regroupés en framework...
 ...qui organisent les classes répondant à des
fonctions techniques spécifiques.

ALEXANDRE LEPRIEULT 160


Processus orienté Composants
 Les frameworks:
 fournissent des services directement utilisable par la conception
 constituent éventuellement des composants du modèle
d'exploitation
 Les frameworks abstraits structurent les classes de conception
détaillée et participent au modèle de configuration logicielle.
 Pendant conception détaillée Les classes sont organisée en
catégories. Les catégories de conception
 constituent éventuellement des composants du modèle
d'exploitation
 structurent le sous-système de configuration logicielle
 Les composants d'exploitation Éléments déployer pour installer
le système:
 instances de base de données
 applications à disposition des utilisateurs
 librairies dynamiques
 objets distribués
 java beans

ALEXANDRE LEPRIEULT 161


Étude préliminaire

 Objectifs
 Il s'agit de commencer à déterminer les
besoins fonctionnels en considérant le
système comme une boîte noire, pour
étudier la place du système à l'intérieur
du système métier plus globale de
l'entreprise cliente

ALEXANDRE LEPRIEULT 162


Étude préliminaire

 On procède en deux étapes:


 identifications des acteurs
 développement de modèles UML contexte
pour délimiter fonctionnellement le
système à développer

ALEXANDRE LEPRIEULT 163


Éléments utilisés

 acteurs, stéréotype de classe


 message, événement
 contexte dynamique, diagramme de
collaboration
 contexte statique, diagramme de
classes

ALEXANDRE LEPRIEULT 164


Identification des acteurs

 Définition
 Représente une abstraction d'un rôle
joué par des entités externes.
 Un acteur peut être représenté en
notation UML par stéréotype prédéfini
de classe.

ALEXANDRE LEPRIEULT 165


Identification des acteurs

 Actions: un acteur peut


 émettre/recevoir des messages qui
interagissent avec le système pour
 consulter, modifier l'état du système

ALEXANDRE LEPRIEULT 166


Pièges
 les acteurs communiquent directement
avec le système
 les acteurs se trouvent à l'extérieur du
système
 confondre un rôle et une entité
concrète:
 une même entité concrète peut avoir
plusieurs rôles
 un rôle peut être tenu par plusieurs entités
concrètes.

ALEXANDRE LEPRIEULT 167


Conseils

 Éliminez les acteurs «physiques» au


profit des «logiques»: un acteur doit
avoir une autonomie de décision et
bénéficier de l'utilisation du système.
Donc ne pas mettre acteur des simples
dispositifs comme: terminaux, balance,
lecteur de carte, etc.

ALEXANDRE LEPRIEULT 168


Identification des messages

 Définition
 spécification d'une communication entre
objets
 transporte de l'information
 intention de déclencher une activité
chez le récepteur.
 la réception d'un message est un
évènement

ALEXANDRE LEPRIEULT 169


Méthodes et Conseils

 Pour chaque acteur: quels sont les


messages qui déclenchent une action
ou un changement d'état du système,
 Pour le système: quels sont les
message émis pour un acteur, porteur
d'information utilisée par le destinataire.

ALEXANDRE LEPRIEULT 170


Pièges

 Ne pas étudier les messages entre


acteurs

ALEXANDRE LEPRIEULT 171


Représentation du contexte
dynamique
 Par l'utilisation d'un diagramme de
collaboration:
 système étudié est au centre
 autour les acteurs
 liens entre le système et chacun des acteurs,
 sur chaque lien, les messages en entrée, et en
sorties, sans numérotation.
 décrire sur une feuille à part le contenu des
messages plus en détail.
 distinguer les messages
synchrones
 asynchrones

 périodiques
ALEXANDRE LEPRIEULT 172
Représentation du contexte
dynamique
 Pour simplifier on pourra:
 ne pas représenter les simples consultation
sans effet de bord
 les actions de connexions/deconnexion

ALEXANDRE LEPRIEULT 173


Représentation du contexte statique

 Optionnel, pour mettre en évidence les


différences de multiplicité entre les
acteurs, lorsqu'il y a beaucoup
d'acteurs.
 Utilisation d'un diagramme de classes
avec uniquement des acteurs du
système et le système, en spécifiant le
nombre d'instances d'acteurs reliés au
système à un moment donné.

ALEXANDRE LEPRIEULT 174


Expression de la décomposition en systèmes
fonctionnels au niveau du contexte
 Pour les très grands systèmes, lorsque l'on
connaît déjà la décomposition en grands
sous-systèmes:
 élaborer le modèle de contexte dynamique du
système comme précédemment;
 traiter le système comme un objet composite,
réprésenter les différents sous-systèmes dans une
inclusion graphique;
 répartir les flots de messages entrant/sortant du
système vers les sous-systèmes;
 ajouter les messages principaux entre les sous-
systèmes

ALEXANDRE LEPRIEULT 175


Résumé de la phase préliminaire

 Établissement d'un recueil initial des besoins


fonctionnels et opérationnels
 modéliser le contexte du système, considéré
comme une boîte noire:
 identifier les entités externes du systèmes qui
interagissent avec lui: les acteurs
 répertorier les interactions (émission/réception des
messages) entre ces acteurs et le système
 représenter l'ensemble des interactions sur un
modèle de contexte dynamique,
éventuellement sur un modèle de contexte
statique, ou décomposé pour faire apparaître
les principaux sous système fonctionnels

ALEXANDRE LEPRIEULT 176


Capture des besoins fonctionnels

 Objectifs
 identifier les cas d'utilisation du système
par ses acteurs
 décrire les cas d'utilisation
 organiser les cas d'utilisation
 identifier les classes candidates du modèles
d'analyse

ALEXANDRE LEPRIEULT 177


Quand?

 après l'étude préliminaire


 en parallèle à la capture des besoins
techniques
 avant l'analyse (branche fonctionnelle)

ALEXANDRE LEPRIEULT 178


Élements mis en jeu
 messages, acteurs, modèles de contexte dynamique
 acteurs principal, acteur secondaire
 cas d'utilisation, description préliminaire d'un cas
d'utilisation,
 diagramme de cas d'utilisation
 fiche de description textuelle d'un cas d'utilisation
 scénario, enchainement, digramme d'activités
 inclusion, extension et généralisation des cas
d'utilisation
 package de cas d'utilisation
 classes candidates, responsabilités, diagramme de
classes participantes
 traçabilité des cas d'utilisation, avec les besoins
fonctionnels, incrément.
ALEXANDRE LEPRIEULT 179
Cas d'utilisation

 Définition
 Un cas d'utilisation représente:
 un ensemble des séquences d'actions
réalisés par le système produisant un
résultat intéressant, une valeur ajoutée
«notable», pour un acteur particulier

ALEXANDRE LEPRIEULT 180


Cas d'utilisation

 Un cas d'utilisation modèlise:


 un service rendu par le système.sans
spécifier comment L'ensemble des cas
d'utilisation doivent: décrire
exhaustivement les exigences
fonctionnelles
 Chaque cas d'utilisation: correspond à
une fonction métier du système selon le
point de vue d'un de ses acteurs
ALEXANDRE LEPRIEULT 181
Méthode
 Pour chaque acteur identifié durant
l'étude préliminaire, en utilisant les
messages identifiés:
 rechercher les différentes intentions métier
avec lesquelles il utilise le système
 déterminer dans le cahier des charges les
services fonctionnels attendus du système
 Pour chaque cas d'utilisation candidat:
 vérifier qu'il fournit une valeur ajoutée
«notable» dans le cadre de son métier
 contrôler qu'un évènement externe au

système en déclenche l'exécution.


ALEXANDRE LEPRIEULT 182
Méthode
 distinguer acteur principal et acteur
secondaire
 l'acteur principal est celui pour qui le cas
d'utilisation produit la plus value métier .
généralement, c'est lui qui déclenche, le cas
d'utilisation.
 acteurs secondaires sont les autres
participants du cas d'utilisation
 sollicités pour des informations complémentaires
 consultent ou surveillent le système
 Établir une première description succincte de
chaque cas d'utilisation candidat
 intention de l'acteur
 actions qu'il effectue
ALEXANDRE LEPRIEULT 183
Méthode
 Diagramme d'utilisation: détailler les rôles
(principal ou secondaire) et les sens des
associations
 par défaut le rôle de l'acteur est principal. Sinon
indiquer explicitement que c'est secondaire sur
son association
 si un acteur a pour rôle unique de consommer les
informations du système, sans en modifier l'état
point de vue niveau métier, représentez une
flèche vers l'acteur, sur son association.
 Éviter la prolifération des cas d'utilisation
 un cas d'utilisation décrit plusieurs scénarios
se restreindre à une vingtaine de cas

ALEXANDRE LEPRIEULT 184


Pièges
 un cas d'utilisation n'est ni une transaction, ni
une fonction: ne pas descendre trop bas en
terme de granularité. Un cas d'utilisation ne
doit pas se réduire à une seule séquence ou à
une simple action.
 ne pas mélanger IHM et cas d'utilisation: les
cas d'utilisation doivent être indépendants
des interfaces et des moyens techniques. Ils
visent une description métier.
 ne pas faire de décomposition fonctionnelle:
 nature fonctionnelle des cas d'utilisation,
 difficulté de savoir à quel niveau de détail
s'arrêter.

ALEXANDRE LEPRIEULT 185


Décrire les cas d'utilisation
 Utilisez le style de description adapté
 description des cas d'utilisation pour le client
 description des cas d'utilisation pour le programmeur
 Fiches de description des cas d'utilisation:
 Sommaire d'identification
 titre
 but
 résumé
 date
 version
 responsable
 acteurs
 Description des enchainements
 enchainements nominaux
 enchainements alternatif
 exception
 préconditions
 postconditions
 Besoins IHM (optionnel)
 contrainte interface homme-machine
ALEXANDRE LEPRIEULT 186
Décrire les cas d'utilisation
 Contraintes non fonctionnelles (optionnel)
 fréquences
 volumétrie
 disponibilité
 fiabilité
 intégrité
 confidentialité
 performance
 concurrence
 Complétez les descriptions textuelles avec des diagrammes
dynamiques simples
 Pour les cas d'utilisations
 diagramme d'activités, pour les activités qui se déroulent en
parallèle
 diagramme d'états, pour modéliser les déroulements
évenementiels
 Scénarios particuliers
 diagramme de séquence
 diagramme de collaboration
ALEXANDRE LEPRIEULT 187
Organiser les cas d'utilisation
 ajouter des relations entre cas d'utilisation:
 d'inclusions
 d'extensions
 de généralisation/spécialisation
 regrouper les cas d'utilisation en Package
 Relation «include» entre cas d'utilisation:
 Le cas de base incorpore explicitement un autre
cas.
 Le cas inclus n'est jamais exécuté seul, mais
uniquement en tant que partie
 Cette relation est utilisée pour factoriser un
comportement commun présent dans plusieurs
cas d'utilisation
 Exemple: l'authentification
ALEXANDRE LEPRIEULT 188
 Relation «extend» entre cas d'utilisation:
 Le cas de base incorpore un autre cas, à un
endroit spécifié.
 Le cas de base peut fonctionner tout seul, ou être
aussi complété par un autre.
 Utilisé pour séparer le comportement optionnel
 Relation de généralisation:
 Les cas d'utilisation peuvent être hiérarchisés par
généralisation/spécialisation.
 Les cas d'utilisation enfant héritent de certains
comportement de leur parent.

ALEXANDRE LEPRIEULT 189


Conseils

 On peut généraliser aussi les acteurs


 Regroupement des cas d'utilisation par:
 domaine d'expertise
 acteur (si chaque cas d'utilisation ne fait
pas intervenir plusieurs acteurs)
 lot de livraison

ALEXANDRE LEPRIEULT 190


PACKAGE
 Définition
 Un package UML est un espace de nommage
qui peut contenir:
 des éléments d'un modèle
 des diagrammes qui représentent les éléments du
modèle
 d'autres packages
 Dans un package, on trouve des éléments
qui:
 représentent un ensemble fortement cohérent
 sont généralement de même nature et de même
niveau sémantique.

ALEXANDRE LEPRIEULT 191


Identifier les classes candidates

 Conseils
 Deux objectifs:
 dialoque avec le client sur son expression
préliminaire de besoins grâce à une description
fonctionnelle
 préparer la modèlisation orientée objet.
 Nous entrons maintenant dans la deuxième
étape:
 Mettre à jour les principales abstractions du
système sous forme d'objets et de classes
 tout en dialoguant avec le client
 pour obtenir un consensus sur les concepts clés

ALEXANDRE LEPRIEULT 192


Identifier les classes candidates
 identifiés dans cette classe doivent être des
concepts connus des utilisateurs du sytème:
les objets métiers.
 L'analystes doit ensuite identifier les
concepts «applicatifs» liés à l'informatisation
(ex: Transmissions comptable, Profil
utilisateur, etc.)
 Pour chaque objet, vérifier ses propriété:
 identité,
 propriété,
 comportement,
 Puis définir ses responsabilités

ALEXANDRE LEPRIEULT 193


responsabilité
 Définition
 Une responsabilité est un contrat, une
obligation pour une classe. Les propriétés
d'une classe (attributs, opérations,
association) lui permettent de remplir ses
responsabilités.
 Chaque classe doit avoir au moins une
responsabilité
 mais elle doit en avoir un nombre limité:
inférieur à 5.

ALEXANDRE LEPRIEULT 194


Méthodologie

 Pour chaque cas d'utilisation


représenter dans un diagramme
statique les classes et les associations
qui interviennent.
 Nous créerons ainsi les «diagrammes de
classes participantes». La réunion de
ces diagrammes constituent le squelette
du modèle statique d'analyse.

ALEXANDRE LEPRIEULT 195


Valider et consolider
 La validation inclut une phase de présentation
au futurs utilisateurs, qui devront répondre
aux questions suivantes:
 les frontières du système sont-elles bien définies?
 les acteurs sont-ils tous pris en compte (au moins
une fois)?
 chaque d'utilisation a-t-il un processus de
déclenchement?
 le niveau d'abstraction des cas d'utilisation est-il
homogène?
 toutes les fonctionnalités du ssytème sont-elles
traitées?
ALEXANDRE LEPRIEULT 196
Méthodologie
 Traçabilité des cas d'utilisation avec l'expression des
besoins
 ligne: cas d'utilisation avec découpage par scénario
 colone: liste des exigences
 Utilisation des Cas d'Utilisation pour définir les
incréments
 identifier les cas d'utilisation les plus critiques en
terme de risque
 le client doit affecter une priorité fonctionnelle à
chaque cas
 le chef de projet doit alors établir une priorité
générale
 prendre en compte les dépendances entre cas
d'utilisation
 développer plutôt les cas factorisés (<<include>>)

développer
ALEXANDRE plutôt les cas qui étendent (<<extend>>)
LEPRIEULT 197
Conclusion
 Cette phase a pour objectif de
 compléter le recueil initial des besoins effectués pendant l'étude préliminaire
(utilisation des cas d'utilisation de la notation UML).
 préparé l'analyse orienté objet: identification des classes candidates du modèle
statique d'analyse.
 Identifier les cas d'utilisation
Utilisation de:
 Cahier des charges
pour produire
 Fiches de description
 Diagrammes dynamiques
 Décrire les cas d'utilisation
Production de:
 Fiches de description
 Diagramme dynamique
 Organiser les cas d'utilisation
Production de:
 Package de spécification fonctionnelle
 Identifier les classes candidates
Production de:
 Diagrammes de classes
 Valider et consolider
Production de:
 Diagrammes de cas d'utilisation raffinés
ALEXANDRE
 TraçabilitéLEPRIEULT 198
Capture des besoins techniques

 Objectifs
 Rôle d'UML dans l'étape «Capture des besoins
techniques». Utilisation de cas d'utilisation.
 Plan:
 construction d'un modèle d'analyse technique avec
UML
 avantages d'une organisation en couches
logicielles
 emploi des cas d'utilisation pour décrire les
comportements techniques du système
 description des cas d'utilisation techniques

ALEXANDRE LEPRIEULT 199


Quand

 après l'étude préliminaire en


complément et en parallèle à la capture
des besoins fonctionnels
 après un minimum de prérequis
techniques, comme par exemple:
 le système matériel
 outil de dev (décision stratégique)
 avant la conception générique

ALEXANDRE LEPRIEULT 200


Quoi

 Deux points de vue:


 spécification logicielle
 le matériel

ALEXANDRE LEPRIEULT 201


Éléments utilisés
 diagramme de déploiement, noeuds et
connexions du réseau, architecture à
trois niveaux.
 diagramme de composants, composants
d'exploitation, architecture trois tiers.
 diagramme de cas d'utilisation, cas
d'utilisation techniques, description d'un
cas d'utilisation technique, organisation
en couches logicielles, architecture en 5
couches
ALEXANDRE LEPRIEULT 202
Spécification technique du point de
vue matériel
 Contraintes
 configuration du réseau
 de natures géographiques
 de natures organisationnelle
 de natures technique

ALEXANDRE LEPRIEULT 203


Définition: Style d'architecture en
niveaux
 deux niveaux (départemental et local)
 trois niveaux (central, départemental et
local)
 multi-niveaux quand il y a une
répartition géographique

ALEXANDRE LEPRIEULT 204


Conseil

 Structurez les spécifications


d'exploitation technique autour du
modèle de configuration matérielle.

ALEXANDRE LEPRIEULT 205


Spécification d'architecture et influence
sur le modèle de déploiement

 Définition: Composant
d'exploitation
 Une partie du système qui doit être
manipulée par les exploitants du
système doit être interchangeable entre
différentes versions
 peut être arrêté ou démarré
séparément
 assume des fonctions bien déterminées

ALEXANDRE LEPRIEULT 206


Définition: Style d'architecture en
tiers
 Spécification particulière des
interactions des composants.

ALEXANDRE LEPRIEULT 207


Définition: Composant métier

 Composant d'exploitation dont la


fonction est de distribuer les services
d'un ou de plusieurs objets métier.

ALEXANDRE LEPRIEULT 208


Élaboration du modèle de
spécification logicielle
 Organisation du modèle de spécification
logicielle
 Développement des couches logicielles
 Définition des concepts techniques
 Description d'un cas d'utilisation technique

ALEXANDRE LEPRIEULT 209


Conclusion
 Capture des spécifications techniques liées à la configuration
matérielle:
 identifier les contraintes techniques liées aux machines, aux
connexions et au déploiements existants;
 produire le diagramme de configuration matérielle;
 identifier les contraintes d'organisation spécifiées par les choix
d'architecture.
 Capture initiale des spécifications logicielles:
 identifier les besoins logiciels du point de vue des exploitants;
 élaborer la description sommaire des cas d'utilisation techniques.
 Spécifications logicielles détaillée:
 identifier un découpage en couches logicielles;
 identifier les cas d'utilisation techniques pour chaque couches;
 élaborer la description détaillée des cas d'utilisation techniques

ALEXANDRE LEPRIEULT 210


Découpage en catégorie
 Objectifs
 démarrage de l'analyse objet
 découpage du modèle UML en blocs logiques
indépendants
 passer d'une structuration fonctionnelle (cas
d'utilisation, packages) à une structuration
objet (classes et catégories)
 organiser ainsi le processus de
développement (par équipe par exemple)

ALEXANDRE LEPRIEULT 211


Notion de catégories
 regroupement de classes...
 à forte cohérence interne,
 à faible couplages externes,
 ... fortement liées par
 des associations
 des agrégations
 des compositions
 des généralisations
 des interactions entre instances

ALEXANDRE LEPRIEULT 212


Découpage
 Regrouper les classes sémantiquement
proches par
 finalité
 évolution
 cycle de vie des objets
 Objectifs:
 regroupement par compétences métier
 séparation des parties applicatives des
parties métiers

ALEXANDRE LEPRIEULT 213


Dépendance entre catégories

 En analyse il ne faut utiliser que les


relations
 d'association
 de généralisation
 Objectifs
 Orientation composant
 minimisation des dépendances

ALEXANDRE LEPRIEULT 214


La démarche

 Répartir les classes candidates en


catégorie
 Élaborer les diagrammes de classes
préliminaires par catégorie
 Décider des dépendance entre
catégories

ALEXANDRE LEPRIEULT 215


Développement du modèle statique

 Un objectif: le diagramme de classe

ALEXANDRE LEPRIEULT 216


Quand

 Deuxième activité de l'analyse


 Activité itérative
 En parallèle et couplé avec la
modélisation dynamique

ALEXANDRE LEPRIEULT 217


Demarche
 Affiner les classes
 Affiner les associations
 Préciser
 multiplicités
 propriétés
 contraintes
 agrégation ou composition
 Ajouter des attributs
 Ajouter les opérations
 Optimiser avec la généralisation
 Nettoyage
 Homogénéité
 Cohérence

 Modularité
ALEXANDRE LEPRIEULT 218
Développement du modèle
dynamique
 Objectifs
 Description des interactions entre objet
par:
 diagramme de séquence (chronologie)
 diagramme collaboration (relation
strucuturelles des objets)
 Description du cycle de vie des objets,
utilisation des diagrammes d'états.

ALEXANDRE LEPRIEULT 219


Quand

 Troisième activité de l'analyse


 Activité itérative
 En parallèle et couplé avec la
modélisation dynamique

ALEXANDRE LEPRIEULT 220


Démarche
 Identifier les scénarios
 Formaliser les scénarios
 Construire les diagrammes d'état
 Conseil
 Pas de diagramme d'états à moins de trois états
 Valider les diagrammes d'états
avec les diagrammes d'interactions
 Confronter les modèles statiques et
dynamiques

ALEXANDRE LEPRIEULT 221


Conseil

 Compléter les diagrammes de classes


avec les attributs et opérations
identifiées grâce à l'analyse dynamique.

ALEXANDRE LEPRIEULT 222


Conclusion

 Deux techniques:
 description des communications entre
instances de classes - collaboration:
 vue structurelle avec liens statiques entre
objets
 vue dynamique, avec flot de messages sur
les liens statiques
 description du cycle de vie d'un objet:
 machines à états

ALEXANDRE LEPRIEULT 223


CMM

 Le niveau de maturité du processus de


développement (CMM) se décline en 5
niveaux de maturité pour les
organisations qui développent du
logiciel :

ALEXANDRE LEPRIEULT 224


CMM
 Niveau 1 : ‘initial’. Processus chaotique, c’est à dire non discipliné et non
prédictible. Coûts, délais, qualité non maîtrisés. A traiter en priorité : gestion de
projet, assurance qualité, gestion de configurations.
 Niveau 2 : ‘repeatable’. Processus reproductible du point de vue de la gestion
de projet, avec des estimations raisonnables en main d’oeuvre et en temps pour
la classe de projets considérée. Processus qui reste artisanal et très lié aux
individus. Délais fiables, mais qualité et coût variables. A traiter en priorité
:méthodes et techniques d’analyse et conception, revues par des
pairs,formation, renforcement des contrôles qualitatifs.
 Niveau 3 : ‘defined’. Processus défini aussi bien dans les aspects gestion de
projet que dans les aspects ingénierie. Délais et coûts assez fiables. Qualité
variable. Définition et suivi essentiellement de nature qualitative. A traiter en
priorité : renforcement des contrôles quantitatifs (analyse et mesures des
produits et des processus).
 Niveau 4 : ‘managed’. Processus géré, c’est à dire contrôlé et mesuré. Qualité
fiable. A traiter en priorité : gestion du changement (processus,
technologies),prévention des défauts.
 Niveau 5 : ‘optimizing’. Processus en adaptation continue (CPI) : chaque projet
est analysé pour améliorer le processus et donc les coûts, délais et qualité. Le
niveau d’une organisation est évalué par des questionnaires, des entretiens, et
des examens de documents.

ALEXANDRE LEPRIEULT 225


IEEE
 Pour l’IEEE (Institute of Electrical and Electronical Engineers) , le GL est
intimement lié à l’idée de mesure : le GL est « l’application au
développement, à la mise en oeuvre et à la maintenance du logiciel
d’une approche systématique, disciplinée et mesurable ; en fait
l’application des méthodes de l’ingénieur au logiciel ». La mesure est
incontournable. « si tu ne peux pas le mesurer, tu ne peux pas le
contrôler ; si tu ne peux pas le contrôler, tu ne peux pas le gérer ; si tu
ne peux pas le gérer, tu ne peux pas l’améliorer ».
 Les mesures peuvent porter sur les processus et sur les produits
 Sur les produits, les mesures sont le plus souvent statiques (sans
exécution) ; on peut citer à titre d’exemples pour les approches à
objets: le nombre et la complexité des méthodes pour implanter une
classe, la profondeur de l’arbre d’héritage, le nombre de couplages
entre classes (appels de méthodes ou accès aux instances), le nombre
de méthodes qui peuvent être appelées en réponse à l’appel d’une
méthode, etc.
 Sur les processus on mesure :
 l’avancement
 la stabilité (nombre de changements par période)
 l’adaptabilité ou effort pour effectuer les changements qui doit diminuer
 la qualité, via les mesures d’erreurs, etc.

ALEXANDRE LEPRIEULT 226


Exercice
A propos de la difficulté de spécifier précisément un besoin
fonctionnel.
La spécification de la règle de notation à un examen est la suivante
« L’examen est un ensemble de 20 questions à réponses multiples.
Chaque bonne réponse à une question rapporte 1 point. Chaque
mauvaise réponse fait perdre 1/3 de point. Chaque question
sans réponse donne 0 point. »
Pensez vous que cette spécification est claire ?
Pour le vérifier, calculez chacun la note des 3 étudiants suivants :
réponses correctes incorrectes sans doubles réponses

Recensez les résultats possibles.


Donnez une spécification plus précise.

ALEXANDRE LEPRIEULT 227


Revues
 Les inspections sont à la base des décisions prises en
revues. Une revue est une réunion permettant de
valider une des phases du cycle de vie.
 On distingue :
 les revues produits: état d'un projet sous ses différents
aspects: Techniques, Financiers, Commerciaux,
Calendrier, ...
 les revues techniques (celles qui nous intéressent le plus
dans le cadre de ce cours): elles permettent de fournir au
marketing et à l'unité de développement une évaluation des
aspects techniques du projet et des coûts de réalisation
 les réunions de décision: elles valident le passage à la
phase suivante et font bien souvent suite à l'une des deux
précédentes.

ALEXANDRE LEPRIEULT 228


Notion de cycle de vie
 C'est la description d'un processus couvrant les
phases de:
- Création d'un produit,
- Distribution sur un marché
- Disparition.
 Le but de ce découpage est de

- Maîtriser les risques


- Maîtriser au mieux les délais et les coûts
- Obtenir une qualité conforme aux exigences.
 On distingue deux types de cycle de vie

- Le cycle de vie des produits s'applique à tous les types


de produits, et peut être considéré comme un outil
de gestion.
- Le cycle de développement des logiciels s'insère dans
le précédent, on l'appelle souvent abusivement cycle
de vie des
ALEXANDRE logiciels
LEPRIEULT 229
Justification du cycle de vie
 Cycle de vie et assurance qualité sont fortement liés;
il faudra donc en permanence assurer:
 La validation et la vérification sont en général garanties par
la mise en place d'inspections et de revues. L'inspection est
une lecture critique d'un document (spécification,
conception, code, plan d'intégration...); elle est destinée à
améliorer la qualité d'un document.
 De manière générale, l'inspection est faite par une
équipe indépendante du projet constituée par: un
Modérateur, un Experts(s), Secrétaire , le client
éventuellement, un représentant du service qualité...
 Pour qu'elle puisse être profitable, une inspection
doit donner lieu à la rédaction de fiches de défauts
avec une échelle de gravité et la définition des
responsabilités concernant la correction des
défauts.
ALEXANDRE LEPRIEULT 230
LES DIFFÉRENTES PHASES DU CYCLE DE VIE

 Définition des Objectifs


 Définition des Besoins
 Définition du Produit
 Planification et gestion de projet
 Conception globale
 Codage et tests unitaires
 Intégration
 Qualification
 Maintenance

ALEXANDRE LEPRIEULT 231


Définition des Objectifs
 Le management étudie la stratégie et décide
de la nécessité de fabriquer ou acheter un
nouveau produit. On s'intéresse aux produits
contenant du logiciel.
 C'est pendant cette phase qu'est défini un
schéma directeur dans le cas de la création
ou de la rénovation d'un système
d'information complet d'une entreprise
prenant en compte la stratégie de l'entreprise
(voir méthode Merise).

ALEXANDRE LEPRIEULT 232


Définition des Besoins
 Un cahier des charges est établi par le client après
consultation des divers intervenants du projet
( utilisateurs, encadrement...), un appel d'offres est
éventuellement lancé.
 Le cahier des charges décrit, en langage naturel, les
fonctionnalités attendues du produit ainsi que les
contraintes non fonctionnelles (temps de réponse,
contraintes mémoire...).
 Dans le cas de la refonte d'un système complet on
peut avoir un cahier des charges par sous domaine.
 Le produit intermédiaire obtenu à l'issue de cette
phase est le cahier des charges.
 On peut décrire le produit à partir de différents
scénarii d'utilisation (Use Case).

ALEXANDRE LEPRIEULT 233


Définition du Produit
 Les spécifications précises du produit sont décrites ainsi que les
contraintes de réalisation.
 A l'issue de cette phase, les fournitures intermédiaires sont le
dossier de spécifications fonctionnelles et une première version
du manuel utilisateur.
 On peut également désigner cette phase par le terme analyse
des besoins. A l'issue de cette phase, le client et le fournisseur
sont d'accord sur le produit à réaliser et les contraintes
auxquelles il doit obéir ainsi que sur la façon de l'utiliser et en
particulier sur l'interface utilisateur qu'il s'agisse d'une interface
homme-machine ou d'une API.
 Les produits intermédiaires à l'issue de cette phase sont
 le dossier d'analyse comprenant les spécifications fonctionnelles
et non fonctionnelles du produit
 une ébauche du manuel utilisateur
 une première version du glossaire contenant les termes propres
au projet

ALEXANDRE LEPRIEULT 234


Planification et gestion de projet
 Il est évident que le client comme le développeur doivent être
d'accord sur les coûts et la durée du projet. La phase de
planification permet de découper le projet en tâches, de décrire
leur enchaînement dans le temps, d'affecter à chacune une
durée et un effort calculé en homme*mois. Il est également
important de définir les normes qualité qui seront appliquées
comme la méthode de conception choisie ou les règles qui
régiront les tests. On notera également les dépendances
extérieures (comme par exemple l'arrivée d'une nouvelle
machine ou d'un nouveau logiciel) afin de mesurer les risques
encourus. Les produits intermédiaires à l'issue de cette phase
sont
 le plan qualité
 le plan projet destiné aux développeurs,
 une estimation des coûts réels (utile pour le management)
 un devis destiné au client précisant le prix à payer, les délais et les
fournitures.
 une liste des dépendances extérieures : En cas de réalisation du
produit par un sous-traitant le dossier de spécifications
 fonctionnelles ainsi que le plan projet et le plan qualité terminent
cette phase et sont contractuels.
ALEXANDRE LEPRIEULT 235
Conception globale
 Pendant cette phase l'architecture du logiciel
est définie ainsi que les interfaces entre les
différents modules. On veillera tout
particulièrement à rendre les différents
constituants du produits aussi indépendants
que possible de manière à faciliter à la fois le
développement parallèle et la maintenance
future. A l'issue de cette phase les produits
intermédiaires sont
 le dossier de conception
 le plan d'intégration
 les plans de tests
 le planning mis à jour

ALEXANDRE LEPRIEULT 236


Codage et tests unitaires

 Chaque module est ensuite codé et


testé indépendamment des autres.
 A l'issue de cette phase les produits
intermédiaires sont
 les modules codés et testés
 la documentation de chaque module
 les résultats des tests unitaires.
 le planning mis à jour

ALEXANDRE LEPRIEULT 237


Intégration
 Chaque module testé est intégré avec
les autres suivant le plan d'intégration
et l'ensemble est testé conformément
au plan de tests.
 A l'issue de cette phase, les produits
intermédiaires sont:
 le logiciel testé
 les tests de régression
 le manuel d'installation
 la version finale du manuel utilisateur

ALEXANDRE LEPRIEULT 238


Qualification

 Lorsque le logiciel est terminé et les


phases d'intégration matériel/logiciel
achevées, le produit est qualifié, c'est à
dire testé en vraie grandeur dans des
conditions normales d'utilisation.
 Cette phase termine le développement.
A l'issue de cette phase le logiciel est
prêt à la mise en exploitation

ALEXANDRE LEPRIEULT 239


Maintenance

 Lorsque le produit a été accepté, il


passe en phase de maintenance jusqu'à
son retrait. C'est pendant cette phase
que tous les efforts de documentation
faits pendant le développement seront
particulièrement appréciés de même
que la transparence de l'architecture et
du code.

ALEXANDRE LEPRIEULT 240


Prototypage rapide ou maquettage
 La maquette ou prototype rapide est utilisée en
amont du cycle de développement :
 Analyse des besoins,
 Spécifications fonctionnelles.
 Elle permet la validation des spécifications par
expérimentation :"Je saurai ce que je veux lorsque je le
verrai!"
 Elle permet au client et au développeur de bien se mettre
d'accord sur la nature du produit à réaliser et en
particulier sur l'interface et les fonctionnalités. La notion
de rapide est importante car cette phase conditionne tout
la suite du cycle de vie et permet de raccourcir la durée
des allers/retours client/développeur pendant la phase
d'analyse des besoins.

ALEXANDRE LEPRIEULT 241


Prototype expérimental
 Utilisé au niveau de la conception pour :
- S'assurer de la faisabilité de parties critiques
- Valider des options de conception
 Exemple : Prototype d'un analyseur
syntaxique avec une grammaire réduite

ALEXANDRE LEPRIEULT 242


Prototype évolutif

 La première version
du prototype est
l'embryon du produit
final
 On itère jusqu'au
produit final
 Exemple
:Développement
d'un système expert

ALEXANDRE LEPRIEULT 243


Analyse des risques
 La mise en oeuvre demande des compétences managériales et devrait être
limitée aux projets innovants à cause de l'importance que ce modèle accorde à
l'analyse des risques.
Citons, par exemple
• risques humains:
− défaillance du personnel ; surestimation des compétences
− travailleur solitaire, héroisme, manque de motivation
• risques processus
− pas de gestion de projet
− calendrier et budget irréalistes ;
− calendrier abandonné sous la pression des clients
− composants externes manquants ;
− tâches externes défaillantes ;
− insuffisance de données
− validité des besoins ;
− développement de fonctions inappropriées
− développement d'interfaces utilisateurs inappropriées
• risques technologiques
− produit miracle, "plaqué or";
− changement de technologie en cours de route
− problèmes de performance
− exigences démesurées par rapport à la technologie
ALEXANDRE LEPRIEULT 244
− incompréhension des fondements de la technologie

Vous aimerez peut-être aussi