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://agilemanifesto.org/

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
• http://blog.octo.com/qu-est-ce-que-le-lean
• 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://contrat-agile.org/
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