Chapitre:
Les méthodes « itéra2ves » : Le cycle
en « Y » ou
2 TUP : 2 Tracks Unified Process
et la méthode Agile SCRUM
Les méthodes « itéra2ves » : Le cycle en « Y » ou
2 TUP : 2 Tracks Unified Process
RUP et 2TUP
En plus du RUP Il existe d’autres processus unifiés.
Le RUP : Rational Unified Process c’est la Version
commerciale des principes de UP, propriété́ de
l’entreprise Rational, créée par les inventeurs d’UML.
Il existe aussi: le 2TUP : 2 Track Unified Process
(Cycle en Y)
Très proche du RUP mais avec une différence
d’approche : les aspects architecture technique sont
traités séparément, en parallèle des questions
fonctionnelles.
2
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP : 2 Tracks Unified
Process
Description des processus métier Spécifications Techniques
Spécifications Fonctionnelles Architecture Technique
Charte graphique Architecture Logicielle
Maquette / Prototype
Conception itération 1
Réalisation itération 1
Tests Techniques itération 1
Tests Fonctionnels itération 1
Recette Technique itération 1
Recette Fonctionnelle itération 1
Itération 2
Itération n
Recette Technique itération n
Recette Fonctionnelle itération n
Mise en production
Déploiement
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP : 2 Tracks Unified
Process
Présentation de 2TUP
Présentation de 2TUP
2TUP, un processus UP
2TUP et UML
Les apports de 2TUP
2TUP en détail
2TUP dans la pratique
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Scrum
RUP
XUP
ASD
2TUP EssUP
Extreme Programming
AUP
EUP Crystal
UP DSDM
Méthodes unifiées Méthodes agiles
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Présentation de 2TUP
Processus créé par Valtech
• Pourquoi 2TUP ?
Réponse aux contraintes de changement continuel imposées aux SI des
entreprises
Contraintes Contraintes
techniques fonctionnelle
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Présentation de 2TUP
Définition d’un processus :
Séquence obtention d’un
Processus
Contraintes
Objectif
d’étapes, en système logiciel
ou évolution
Délais
partie d’un système
ordonnées existant qui
satisfasse le Coûts
client
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Présentation de 2TUP
Plusieurs processus unifiés, pas un Trame commune des meilleures
seul pratiques de développement
Piloté par les Orienté Orienté
Incrémental Itératif
risques composant utilisateur
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Présentation de 2TUP
Axe
fonctionnel
La réalisation du
système consiste
à fusionner les
résultats des
deux branches
Axe
technique
Présentation de 2TUP
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
2TUP, un processus UP
Un processus piloté par les risques
Les solutions
4 principaux risques apportées par ce
processus
L’incapacité de
l’architecture Gestion
L’inadéquation Le non respect
technique à Le manque de prioritaire des Politique
aux besoins des des coûts et
répondre aux qualité deux premiers d’incréments
utilisateurs délais
contraintes risques
opérationnelles
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
2TUP, un processus UP
Un processus piloté par les exigences des
utilisateurs
La branche
La branche gauche droite est
Deux types d’acteurs est chargée de chargée de
capturer les capturer les
besoins
fonctionnels besoins
L’utilisateur L’utilisateur auprès des techniques
consommateur utilisateurs auprès des
des fonctions du exploitant le consommateurs utilisateurs
système système exploitants
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
2TUP et UML
Définition de Unified Modeling Langage :
Langage de comprendre et Unification des
Buts
UML
décrire des notations et
modélisation concepts orientés
besoins,
graphique et spécifier et
objet
textuel documenter Moyen d’établir le
suivi des décisions
des systèmes, prises, depuis la
concevoir des spécification
solutions, jusqu’au codage
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
2TUP et UML
Le recours à la modélisation est une pratique
indispensable au développement
Relation entre 2TUP et UML
UML est le langage de Correspondance entre les
modélisation objet standard différents diagrammes d’UML
de ce processus et les étapes de 2TUP
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
2TUP et UML
• Diagramme des cas d’utilisation,
Capture des besoins • Diagrammes de séquence,
fonctionnels • Diagrammes de collaboration
• Diagramme de classes,
Analyse • Diagrammes d’états transition
Capture des besoins
techniques • Diagramme des cas d’utilisation
Conception générique • Diagramme de déploiement
Conception • Diagramme de composants,
préliminaire • Diagramme de déploiement
• Diagramme de classes,
• Diagramme de séquence,
• Diagramme de collaboration,
Conception détaillée • Diagramme d’états,
• Diagramme d’activités,
• Diagrammede composants
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Les apports de 2TUP
Capitalisation de la
Capitalisation d’un
connaissance de
savoir-faire technique
l’entreprise
investissement pour le
investissement pour le
moyen et long terme
court et moyen terme
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
2TUP en détail
Capture des besoins
Étude Besoins Besoins
préliminaire fonctionnels techniques
Cahier des charges Spécifications
Cas d’utilisations
techniques
Acteurs
Spécifications de
Classes candidates
l’architecture
Messages
Modélisation du Validation et Cas d’utilisation
contexte consolidation techniques
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
2TUP dans la pratique
Analyse
Découpage Modèle Modèle
en catégorie statique dynamique
Classes Scénarios
Découpage en
catégorie
Diagrammes états
Associations
transitions
Diagrammes
Opération
d’interaction
Dépendances
Optimisation Validation
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Conception d’architecture
Conception Conception Conception
générique préliminaire détaillée
Modèle de déploiement/
Framworks techniques exploitation
Interfaces utilisateurs
Modèle logique Tout
Interface catégories
Développement de
prototype Conception IHM
Les méthodes « itéra2ves » : Le cycle en « Y » ou 2 TUP :
2 Tracks Unified Process
Avantages
d’une
méthode
Grand projet
Gestion des
et SI
risques
complexe
Management
UP
de projet
Les méthodes « Itéra2ves » : Comment contractualiser?
(en général)
◦ Le client envoi son cahier des charges plus ou mois flou
◦ Le prestataire effectuer une réponse chiffrée l’engageant sur le respect de
besoin et de son es2ma2on de charge
◦ Problème ! Cahier des charges flou => Nombreuses discussions contractuelles
(= pertes de temps pour le projet) => Nombreux avenants => Non maîtrise du
budget du projet
◦ Une fois le client sa2sfait de la qualité, il paie son prestataire
◦ De plus en plus les clients meZent des pénalités sur :
Les retards de livraison (1 jour de retard = 1 000 euros)
Sur la non qualité (1 anomalie bloquante = 2 000 euros)
21
Les méthodes « itéra2ves » : Synthèse
Intérêts :
◦ PermeZent de connaître rapidement les principales fonc2onnalités d’une
applica2on è Rassurant
◦ Autorise de revoir une par2e du besoin en cours de route
◦ Fournies une documenta2on avancée du logiciel
◦ Simple à appréhender et à contractualiser è Rassurant pour beaucoup de
décideurs
Difficultés à postériori :
◦ Méthode encore trop orientée sur une défini2on figée du besoin u2lisateur
◦ Ne traite pas les probléma2ques de qualité de code, de non régression
Ces méthodes s’approchent d’un processus de créa2on
incrémental
22
Les méthodes « Agile »
23
Les méthodes Agiles : Le manifeste
Extrait du manifeste Agile : hZp://[Link]/
Nous découvrons comment mieux développer des logiciels par la
pra2que et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :
◦ Les individus et leurs interac/ons plus que les processus et les ou2ls
◦ Des logiciels opéra/onnels plus qu’une documenta2on exhaus2ve
◦ La collabora/on avec les clients plus que la négocia2on contractuelle
◦ L’adapta/on au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions
les premiers.
24
Les méthodes Agiles : Le manifeste
Projet
classique Projet agile
Réactivité face au
Suivi d’un plan
changement
Négociation Collaboration
contractuelle cliente
Documentation Logiciel
exhaustive opérationnel
Individus et
Processus et outils
interactions
25
Les méthodes Agiles : plusieurs solu2ons
Scrum
eXtreme Programming
Lean
Devops
Kanban
Crystal clear
FDD
ASD, DSDM, …………
26
Agile : Focus sur SCRUM
La méthode Scrum est un processus itéra2f représenté par le
diagramme suivant :
Agile : Focus sur SCRUM
• Le « Backlog de produit » est cons2tué d’une liste de « User
story », à savoir des cas d’u2lisa2on simples et
représenta2fs. Il est modifié tout au long du projet par le
directeur de produit. Chaque « User story » est orienté «
fonc/onnel » et est iden2fié de façon unique.
Agile : Focus sur SCRUM
Agile : Focus sur SCRUM
Les rôles dans Scrum sont :
Le « Directeur du produit ou Product Owner» est le
représentant des clients et u2lisateurs. C’est lui qui défini le
produit au travers du « Backlog » de produit.
Le « ScrumMaster » est chargé de protéger l'équipe de tous
les éléments perturbateurs extérieurs à l'équipe et de
résoudre ses problèmes non technique.
L’ « Equipe » ne comporte pas de rôle prédéfini et est
autogérée. Elle s’adresse directement au directeur de
produit.
Agile : Focus sur SCRUM
Le « Backlog de sprint » est réalisé à chaque début de sprint.
Il con2ent l’ensemble des « User story » à réaliser pour
celui ci. Le « Backlog de sprint » n’évolue jamais.
La mêlée quo2dienne (ou Daily Scrum) est effectuée chaque
ma2n afin de vérifier qu’aucun élément ne perturbe le
développement. Il s’agît d’un Stand-up Mee/ng (on reste
debout pour que la réunion ne s’éternise pas…)
◦ Point court de 10 à 15min
◦ Exposer l’avancement de chacun et les
problèmes rencontrés
Agile : Focus sur XP
• Méthode résolument incrémentale et focalisée sur la
programma2on qui met en œuvre les pra2ques suivantes :
• TDD (Test Driven Developement)
• Refactoring
• Intégra2on Con2nue
• Propriété collec2ve
• Normes de développement
• Pair programming
• Rythme soutenable
• Approche très complémentaire avec Scrum qui met en place
l’organisa2on projet
• Scrum et XP se sont mutuellement inspirées
32
Agile : Focus sur Lean
• [Link]
• Ensemble de principes et de pra2ques issus de Toyota :
• Respect des gens :
• Le travail doit être mo2vant, épanouissant, inspirant
• Le personnel doit être formé, encouragé et responsabilisé
• Eliminer le gaspillage :
• Surproduc2on,
• Délai (exemple : temps d’organisa2on d’une réunion),
• Stock,
• Transport, mouvement inu2le, processus inu2le et défauts
• Améliora2on con2nue :
• Innover : faire quelque chose de nouveau
• Imiter : reprendre quelque chose qui a déjà marché ailleurs
• Améliorer en con2nu pas à pas : par2r de la situa2on actuelle et
la changer pe2t à pe2t en s’assurant que chaque changement est
une améliora2on
33
Agile : Focus sur Lean
• Ensemble de principes et de pra2ques issus de Toyota :
• Management visuel :
• Consiste à rendre visible les écarts par rapport au
standard. Comme cela il n’est pas besoin d’être
courageux pour parler de ces écarts, ils sont traités tout
de suite soit en renforçant la forma2on aux bonnes
pra2ques, soit en ajustant le standard.
• Gemba : Avoir conscience du lieu où la valeur ajoutée est
crée.
• Kanban : Méthode de planifica2on de produc2on d’un flux
tendu
• AZen2on : Comme tout principe (méthode, dogme, religion,
…), lorsque celui-ci est appliqué de manière excessive il devient
34
néfaste!
Les méthodes « Agiles » : Comment
contractualiser?
Rappel sur un contrat forfait classique :
Fournisseur
Client
◦ Le client porte le risque du besoin, tant dis que le fournisseur porte le risque du
produit.
◦ Du fait qu’en ingénierie logicielle, le besoin évolue très fréquemment, mais que
le contrat lui ne bouge pas, le client tente souvent de faire porter le risque du
besoin sur le prestataire, ce qui donne souvent lieu à de nombreuses
négocia2ons contractuelles.
35
Les méthodes « Agiles » : Comment
contractualiser?
Solu2on pour contractualiser en agile :
◦ Engagement de moyen (régie) sur une équipe complète (Scrum
Master Architecte, Développeur)
Les itéra2ons étant courtes, en cas de non sa2sfac2on de la part du client,
celui-ci pourra remercier rapidement l’équipe cons2tuée.
◦ Forfait basé sur une métrique de produc2vité
1ères itéra2ons facturées au temps passé pour mesurer la vélocité de
l’équipe
L’équipe est capable de produire tant de points (si l’on est en SCRUM)
Ensuite l’engagement forfaitaire porte sur un nombre d’itéra2ons devant
respecter un certaine vélocité
Le besoin fonc2onnel peut évoluer en cours, à condi2on que la vélocité des
itéra2ons à produire reste la même.
◦ D’autres formes contractuelles existent :
Target Coast, Target Delay, Partage de profit
◦ Exemple de contrat Agile proposé par Xebia :
hZp://[Link]/
36
Les méthodes « Agiles » : Synthèse
Intérêts :
◦ Favorise clairement la produc2vité
◦ Permet aux u2lisateurs de mieux appréhender leurs besoins
Difficultés à postériori :
◦ Nécessite une forte implica2on du client
◦ Conceptuellement plus complexe à appréhender (pour le client et
pour les prestataires)
◦ Nécessite des collaborateurs très compétents, capables d’être
performants aussi bien sur le fonc2onnel que sur le technique
◦ Nécessité absolue de meZre en œuvre des ou2ls de contrôle de
qualité et de non régression
◦ Méthodes (très) difficiles à meZre en œuvre sur des gros projets (30,
40, … ETP)
◦ La contractualisa2on est rendue plus difficile
37
Cycle de vie des TMA
TMA
• Le Cycle de vie peut être
spécifique à chaque mé2er Management et suivi de la prestation Réversibilité
– Tierce Maintenance
Applica/ve (exemple => ) Prise en compte Maintenance Opérationnelle Réversibilité
Organisation O Montée
– Infogérance Maintenance en mode r en charge
autonome g équipe
a Client
en mode assisté
– Etc. Acquisition des
connaissances
Réalisation des services de
Maintenance
n
maintenance is
a
ti
Transfert de
Projets d’évolution o
l’activité
n
Les TMA : Comment contractualiser?
(en général)
• La phase de prise en compte est forfaitaire
Il arrive qu’elle soit offerte au client en tant que geste
commercial
• En phase opéra2onnelle :
Les ac2vités de MCO, Support sont forfaitaires, mais
basées sur un volume d’ac2vité déjà constaté ou es2mé
(nombre d’anomalies, nombre d’incidents, …)
Les évolu2ons sont forfaitaires et u2lisent des Unités
d’Œuvre pour les valoriser
• La phase de réversibilité est forfaitaire
39
En synthèse
40
Quelle méthode pour quel cas ?
Comment savoir quelle méthode appliquer ?
uPas de modèle idéal
Ø Cascade : risqué pour les projets innovants
Ø évolutif : coûteux pour les projets clairs dès le début
uPour les projets de taille petite ou moyenne (< 500 000 l)
Ø Une approche incrémentale est souvent plus appropriée
uPour les grands projets (multi-sites, multi-équipes)
Ø Approche mixte intégrant des aspects des modèles
évolutifs et des modèles en cascade
ü Exemple : utilisation d’un prototype pour stabiliser les
exigences et développement en V
Quelle méthode pour quel cas ?
Comment savoir quelle méthode appliquer ?
Client
CQFD !
Peu impliqué Volontaire Expérimenté
« Votre »
méthode
Technique
ERP/Décisionnel Important
Type (>5000 j/h)
de projet Dév. Spécifique C/S
Moyen
Dév. Spécifique J2EE
Petit Taille
(<500 j/h)
Normal Élevé Très élevé du projet
Risque
