ICSSEA 2002 Assises n7 Denis

UML/RUP : Organisation des

processus de dveloppement
Des concepts la ralit
Application et complments pour construire une ingnierie du
processus de dveloppement

Les directions des entreprises marquent un intrt renouvel la notion de processus.

Si on entend par l ce que fait lentreprise, avec quelles ressources, pour servir quels objectifs, cest la
raffirmation de principes simples et anciens :
Pour matriser la performance de lentreprise, il faut rapporter la consommation de ressources
(financires, humaines ou matrielles) lintrt de ce quelles produisent (article ou service la
vente, support dun objectif stratgique).
Pour organiser la ractivit de lentreprise il faut mesurer limpact de diffrents scnarios sur des
ressources, des produits ou des critres particuliers. Ces scnarios peuvent relever de lorganisation
(re engineering), du march (variation des caractristiques de la demande) ou du risque (dfaillance
dune ressource ou dun processus).
Pour organiser la prennit de lentreprise il faut pouvoir reproduire les savoir-faire dans le temps.
Il faut intgrer de nouvelles ressources ou largir le primtre de lentreprise pose videmment le
besoin de faire savoir ce qui doit tre fait pour raliser le programme de lentreprise.
Une organisation qui se consacre au dveloppement informatique est une vritable entreprise. La mise sous
contrle de ses processus de production (informatique) dterminera sa capacit satisfaire ces trois
vocations.
UML/RUP (Rational Unified Process) donne un cadre rfrentiel aux processus de dveloppement
informatique.
La liste des activits quil prvoit, et aussi bien le modle de consommation des ressources quelles
induisent, sont utiles au gestionnaire de projet. Ils lui fixent un cadre conceptuel de planification.
Cependant, la prise en charge de la notion de processus par RUP savre relativement trop sommaire pour
fournir un outillage oprationnel dans lorganisation pratique dun projet de dveloppement.
Cest pourquoi il a fallu tayer son utilisation avec des concepts et des moyens plus oprationnels, apports
par un outil particulier danalyse de processus.
Ceux ci ouvrent en outre la voie dune capitalisation de lexprience de lquipe de dveloppement, dans le
cadre dune gestion de la connaissance applique.

RUP : un modle gnral de gestion des projets de dveloppement

informatique
Rational Unified Process (RUP) est un modle type de processus de dveloppement informatique. Il
rsulte de lunification des travaux de MM. Booch, Rumbaugh, et Jacobson. Il est troitement li la
technologie Unified Modeling Language (UML)
Ce modle propose de grer les dveloppements informatiques en utilisant un modle dactivits
rparties en 4 catgories

Assises ADELI 4 dcembre 2002 1

 ICSSEA 2002 Assises n7 Denis

Phases Contenu des phases

Establish business case for system
Inception High-level project definition (define actors and general
use cases)

Dveloppement
de
Analyse problem domain
Elaboration
Phase Establish architectural foundation
Develop project plan and eliminate high risk areas

Cycle
Construction Develop, test, and integrate all project components
Phase
Transition Handover product to user community
Phase

Taxonomie : Un modle logique

Appliquer ce modle confre chaque dveloppement des garanties de productivit et de fiabilit.
En tablissant un rfrentiel dactivits, dobjectifs et de livrables, le Schma Directeur que constitue
RUP apporte une meilleure structure aux diffrentes parties dun projet de dveloppement, notamment
dans un contexte distribu.
Il donne aux diffrents acteurs un vocabulaire identique, voire une reprsentation logique homogne,
pour dcrire et comprendre les diffrents travaux, livrables et points de contrle qui construisent
chaque phase dun cycle de dveloppement.

Phases
Inception Elaboration Construction Transition

Define system scope
Identi fy Actors and high-
level interactions (Use
Cases)
Define project success
criteria
Activities
Analyse problem domain
Establish sound architectural
foundation
Develop project plan
Eliminate highest risk
elements of project
Implement and test all Focus on delivering the product
features to the user community
Integrat e and test all Preliminary user interaction
components ( beta-testing)
Bug fixes, enhancem ents
Parallel operation with

Identi fy risk Look at every aspect of the previous legacy system

Estimate required system; but not very deep
resources (people, tools,
software, machines, etc.) Most critical phase of project
Develop phase plan Most difficult technical
showing major project decisions are tackled
milestones Technical prototypes validate
design and provide fra mework
for Construction
Databas e conversion
User and maintenance
Management transitions documentation
from developing intellectual User and maintenance training
property to producing quality Product roll-out to marketing,
deployable software
sales and distribution

2 Assises ADELI 4 dcembre 2002

 ICSSEA 2002 Assises n7 Denis

Phases
Inception Elaboration Construction Transition

Vision Document Nearly completed Use Case Software Achieve user sel f-
Core requirements, Key Model Complete supportability
features, Main Non-functional requirements Integrat ed Stakeholder agreement that
constraints Software architecture Tested software is stable, complete
Business Case description and executabl e Fully-functional and consistent with visions
Deliverables

Business Context, prototype Deployable evaluation criteria

Succes Criteria, Market Development plan for entire Achieve final product baseline
Recognition, Financial project User manual as quickly and cost-effectively
Forecast Define iterations Release notes as possible
Initial Use Case model Update of any existing
Business Model documents
Project Glossary Risk list
Project Plan Business Case
Prototypes

Phases
Inception Elaboration Construction Transition

Stakeholder Lifecycle Architecture Initial Operational Product Release Milestone

agreement/signoff on
scope, cost, and schedule
estimates
Understanding of
requirem ents based on
Use Cases
Credibility of estimates,
priorities, risks, process
Milestone
Milestone
Is project vision stable?
Is architecture stable?
Is Construction phase
reasonably planned in
suffi cient detail?
Do stakeholders agree that
current vision can be
Capability Milestone
Is the release stable and
mature?
Are the stakeholders
ready for the transition
to the user community?
Actual costs vs. Planned
costs
Have objectives been met?
Should another development
cycle start?
Are the users satisfi ed?
Actual costs vs. Planned costs

Actual costs vs. Planned achieved?

costs
Is the depth and
breadth of developed
architectural
prototypes sufficient?
Actual costs vs. Planned
costs
Believable plan based actual
time spent?
Have major risks been
addressed and resolved?

P roject may be cancelled or P roject may be cancelled or re- P roject may be postponed by
re-analysed if milestone not analysed if milestone not met a release if milestone not met
met

Consommation de ressources : Un modle prdictif

Chacun des groupes dactivits utiliss par RUP peut tre caractris par un comportement type.
Les types de ressource consommes, leur niveau de consommation et leur calendrier dintervention est
interpol par le modle, en fonction dune exprience postule a priori.

Assises ADELI 4 dcembre 2002 3

 ICSSEA 2002 Assises n7 Denis

Un tel calendrier peut encore tre amend par des stratgies gnrales dorganisation.

Un dveloppement en mode fontaine rinitialisera les phases de travail amont loccurrence dun
problme inopin, ou lapparition dune variation de contextes. De ce fait, il y a ncessairement une
sur utilisation des phases, directement fonction de leur place dans lenchanement des taches.
Un dveloppement en mode continu (Workflow) lisse les surconsommations dans la mesure o les
mmes perturbations (problmes et contextes) ne rinitialisent les phases quaprs la fin de leur
enchanement, et donc galement pour chacune.

Un rfrentiel conceptuel
Les assertions du modle RUP restent gnrales. Sil donne la forme gnrale dun discours, il n
affiche pas vraiment lambition de structurer un dveloppement concret.
Labsence de formats standardiss de livrables laisse aux quipes informatiques une grande latitude de
comprhension des termes employs, voire des taches oprationnelles impliques dans les diffrentes
rubrique s du rfrentiel.
UML est le support naturel de la communication aux travers des projets RUP. Le pari que ce mdia
puisse apporter a lui seul une garantie dinter oprabilit des informations contenues dans les
documents, et de leur inter interprtabilit dans des tches particulires, ne suffit pas garantir un
rsultat dans ce domaine.

La matrise des paramtres de performance du dveloppement

RUP attire juste titre lattention sur limportance de larchitecture gnrale du processus de
dveloppement dans la recherche de performance.

Les limites des approches techniques

Lvolution des pratiques informatiques a permis dintgrer successivement diffrentes composantes
de cette performance : en termes doutils techniques (bases de donnes relationnelles) en termes de
mthodes de construction du code (Langage C, Modle Objet)
Cependant, le dveloppement informatique reste complexe. Il ncessite lintervention de plusieurs
corps de mtier ayant ou matrisant des cultures et des outils diffrents.
Il pose en permanence, comme un dfi, le besoin de matriser lapplication des contextes mouvants
(Aspect fonctionnel = besoins mtier) de macro innovations (aspect T echnologique : Concepts et
offres technologiques nouvelles) ou de micro innovations (aspect organique = intgrations des
contextes chaque fois particuliers) dont la combinatoire est trs importante.

4 Assises ADELI 4 dcembre 2002

 ICSSEA 2002 Assises n7 Denis
La programmation de type Objet, par exemple, est une avance marquante dont les limites sont
cependant maintes fois reconnues en ce que, pour garantir la rutilisabilit des composants, il faut les
rduire des dimensions extrmement rduites.
Le choix de leur primtre renvoie la modlisation de leur contexte dapplication (sur les trois plans
technologique, organique et fonctionnels) qui savre rapidement un exercice inductif (a priori)
impossible.

Les apports de la matrise du processus

Si tous les contextes dapplication du dveloppement informatique ne peuvent tre cerns a priori dans
un modle technique gnral, il reste possible de modliser la meilleure manire dapprocher, de
dfinir, puis dapprhender, ces mmes contextes.
Cette meilleure manire de faire se dfinit comme un processus, cest dire un ensemble dactivits,
rattaches en domaines homognes de finalit, nonces dans un plan denchanements et de
dpendances, dans un modle contrlable.
UML/RUP tente bien de dfinir un tel paradigme : former un rfrentiel sur les modes dorganisation
des quipes de dveloppement, sur la manire de dvelopper la comptence de groupe, sur la manire
dintgrer la relation avec les clients des projets.
Cependant, il ne peut tre considr comme une technique de modlisation du processus de
dveloppement informatique. ( lintrieur dune plus large incomptence, puisquil ne peut non plus
nous guider dans la modlisation des processus Mtier des utilisateurs. Voir plus bas)
RUP propose un modle postul, un rsultat donn, sans proposer de mcanisme dadaptation de ce
modle, et a fortiori un mcanisme de gestion dautres modles.

La notion de savoir-faire au centre de la matrise de linnovation.

Dans les dveloppements informatiques, il y a bien des acteurs, des activits, des enchanements de
tches, des produits, des consommations de temps, des itrations, des changes et, plus loin encore,
des objectifs, des contraintes, des indicateurs dvaluation de performance.
Toutes ces choses caractrisent classiquement les processus dune entreprise, aussi bien quun projet
de dveloppement informatique.
Pourtant le terme de processus est demble suspect aux dveloppeurs informatiques. Avant peu, on
obtient lobjection quun projet ne ressemble aucun autre alors que la notion de processus renverrait
celle de re-production du mme et en grande srie si possible.
Cette objection est lgitime et pose lexercice de modlisation une contrainte majeure : ce qui doit
tre modlis est le savoir faire du dveloppement, qui est avec le processus (de dveloppement) dans
le rapport de la cause leffet :
Tout processus est linstance dun savoir faire thorique (Modle).
Le processus est leffet observable, dans le cadre dune instance particulire, du savoir faire qui est
luvre en dessous. Le second ne peut tre reconnu que par lintermdiaire du premier, mais seul le
second permet de modliser (a priori) le premier.
La voie de la modlisation du processus de dveloppement informatique, si elle se veut oprationnelle
(au regard de lobligation dinnovation) doit prendre en charge, au travers de la notion de savoir faire,
un problme quasiment pistmologique.

Lapport dune technique volue danalyse de processus

La confrontation des modles proposs par RUP aux concepts manipuls par un outil danalyse de
processus (Kapi : Knowledge Acces & Process Intellligence) aide reconnatre leurs apports, puis
les relativiser, et les complter.
Lanalyse des processus est clairement une technique ncessaire tout projet informatique. Par nature,
un programme informatique est une fiction plaque sur la ralit de lentreprise.

Assises ADELI 4 dcembre 2002 5

 ICSSEA 2002 Assises n7 Denis

Une connaissance exacte des processus (oprationnels) qui doivent tre supports permet de rduire
lcart entre produit (logiciel) et besoin (de lactivit informatiser).
Mais la vision que permet dobtenir lanalyse de processus sur le contexte externe du projet peut
sappliquer avec beaucoup davantages sur lintrieur du dveloppement lui mme.

La fonction topologique
Le modle dun processus tablit par nature une topologie de toutes les interactions entre besoins,
stratgies, moyens, contraintes et savoir faire dans lentreprise.
Pour les besoins du planificateur, cette topologie forme une grille o peuvent tre positionns des
temps, des acteurs, des contraintes . Elle prend en support la reprsentation du processus en arbres
de dcomposition et en flux transversaux.
Pour les besoins du gestionnaire du projet, elle forme une grille o peuvent tre lues de nombreuses
informations, qui peuvent alors tre values dans le contexte qui leur donne un sens. Elle prend en
support la reprsentation multi dimensionnelle, qui utilise les contextes en niveaux de synthse de
linformation, et le choix des dimensions danalyse comme autant de cadres logiques de contrle
(qualit des livrables, respect des charges, respect des dlais, respect des cots, divergences des
activits prises en charge, contrle des affectations de ressources).

La fonction topologique salimente de leffort de typologie (concepts et catgories particuliers) que

postule UML/RUP.
Elle rsulte en une urbanisation gnralise des lments du processus de dveloppement (acteurs,
activits, consommations, outils, objectifs ).

La fonction de contextualisation
La notion de savoir-faire sur laquelle on a insist prcdemment prend corps avec la fonction de
contextualisation prsente dans la plate-forme danalyse de processus prise en rfrence (Kapi), et qui
met en uvre lobservation suivante :
Dans la ralit, toute entreprise combine de manire diffrente ses ressources (quelle trouve dans ses
modles structurels) et ses comptences individuelles (activits) ou organisationnelles (savoir faire)
pour rpondre des vnements (besoins, demandes, contraintes) particuliers. De ces combinaisons ou
scnarios naissent des processus diffrents et en crent ventuellement de nouveaux.
Lutilisation de la notion de savoir-faire dans la gestion de projet inductive conditionne la faisabilit
de toute dmarche de contrle de linnovation (particulirement prsente dans le dveloppement
informatique).
Elle rgle la vie de la cellule de dveloppement sur le cycle suivant :
en fonction des diffrents modules ou fonctionnalits prendre en charge par le projet
concern ;
Chaque projet spcifique instancie (en processus contrlables) le modle gnral dactivit
propos par RUP : des acteurs sont slectionns, des activits sont dtailles de faon
oprationnelle, des temps sont fixs
linstance ainsi ralise est un enrichissement du modle. Elle peut prendre directement statut de
modle ds lors que le niveau de performance observ le justifie.
Lvaluation de cette performance est atteint en phase de suivi du processus attendu, sur des
supports varis : feuille de temps, feuille dvaluation de la performance.

Llargissement du modle de processus un modle de gestion de la

connaissance
Lanalyse de processus est sous ces clairages le principal vecteur dune Gestion de la connaissance
applique. La cellule de dveloppement y trouve un moyen de grer chaque projet en rfrence un
modle progressivement enrichi par son exprience directe de la performance observe.
Lambition initiale de RUP se trouve ainsi singulirement complte.

6 Assises ADELI 4 dcembre 2002

 ICSSEA 2002 Assises n7 Denis
De modle postul a priori, il devient lexpression justifie, choisie, dune gestion de la comptence
disponible dans une organisation (entreprise ddie au dveloppement informatique) bien identifie,
au travers de ses ressources disponibles et des activits quelle (ou quelles titre individuel)
matrisent.
Lutilisation de modles de processus (de dveloppement) qualifis dfinis priori ou par
rutilisation de processus dj parcourus claire et scurise les travaux informatiques grce la
normalisation de processus prouvs.

Lanalyse structure des donnes quantitatives et qualitatives du processus

Si comprendre un processus ncessite de le dcrire, le matriser ncessite de le mesurer.
Une approche documentaire (graphique ou textuelle) est limite sur de nombreux points : mise jour
en cas dvolution, fourniture de vues synthtiques, construction de vues slectives (prsence dune
ressource ou dune contrainte, rponse un vnement), ralisation de calculs interactifs (somme des
cots, indicateurs de performance).
Une approche mature des processus pose le besoin de grer des donnes au del des dessins, pour
construire des tableaux de bord sur le squels les cots, la performance, les risques ou les r gles de
gestion peuvent tre dynamiquement suivis.
La capacit crer des tableaux danalyse structure de linformation reprsentative des lments
structurels, quantitatifs ou qualitatifs du processus est essentielle au cycle denrichissement du modle
de rfrence des dveloppements.
Elle permet de coordonner les diffrentes visions qui peuvent tre protes sur le projet (pour
lutilisateur : le niveau de satisfaction de spcifications, pour le gestionnaire: les cots assums, pour
lanimateur : le niveau des comptences vrifies)
Elle permet galement de contrler les modes dadaptation du rfrentiel. Le postulat dun modle a
priori, tout particulirement pour un projet de dveloppement informatique, ne peut exister longtemps
sans phase de contrle de ses variations. Ce contrle na de contenu que mesurable, et de sens quau
travers de domaines de contrle (structures, acteurs, quantits, qualits).

Le projet mis en uvre au sein de BNP Paribas

Le projet dvaluer la pertinence de RUP dans une approche prdictive et une dmarche de
capitalisation de lexprience des quipes de dveloppement nous a amen parcourir les tapes
suivantes.

La phase de modlisation de projet

Touts les points discuts dans les chapitres prcdents rsultent en une modlisation assez complexe
des projets de dveloppement. Chaque tape en est cependant assez clairement dfinie pour pouvoir
tre ralise sans ambigut.
Construction du rfrentiel gnral du processus de dveloppement :
claircissement des termes adopts dans les descriptions des processus de
dveloppement ;
dclinaison des processus gnraux en activits oprationnelles ;
dfinition de larchitecture et des formats des livrables ;
choix des indicateurs dvaluation de la performance des processus de dveloppement
(prennit des produits via leur documentation -, atteinte des objectifs fonctionnels,
respect des dlais ) ;
dfinition des rles intervenants dans les projets (MOA, MOE, Sponsor).
Dfinition de la structure du projet :
dfinition des modules du projet.
Les modules sont des Groupes de fonctionnalits homognes,
Soit parce quils appellent des instances du rfrentiel qui partagent des
caractristiques communes
Soit parce quils rpondent un mme domaine fonctionnel Utilisateur

Assises ADELI 4 dcembre 2002 7

 ICSSEA 2002 Assises n7 Denis

Choix des modles dadaptation du rfrentiel

Dans le cas o le dveloppement dune fonctionnalit particulire peut profiter dun
pattern de dveloppement dj expriment dans le pass (ce dernier tant lui mme une
modification du rfrentiel gnral de gestion de projet, et tant appel en cela pattern
local ) alors la fonctionnalit concerne accdera au rfrentiel par lintermdiaire du
pattern local.
Instanciation des structures du rfrentiel, selon les contextes pertinents.
Un contexte pertinent consiste en la combinaison dvnements ou de cas qui modifie les
proprits, ou la structure du rfrentiel gnral.
Adaptation directe du rfrentiel, au cas o la carence gnrale de ce dernier est rvle
par le cas prcis du projet en cours.
Affectation de ressources aux rles prvus par le rfrentiel. Le choix des ressources
dpendant de chaque projet.
Instanciation quantitative du projet :
Traduction des stratgies dorganisation retenues (modes Fontain ou Workflow )
dans les profils de consommation des phases du rfrentiel.
Dfinition des temps et calendriers allous aux diffrentes activits.

La phase de suivi de projet

Linstanciation du rfrentiel rsulte en un schma de processus qui peut tre utilis comme un pattern
spcifique du projet en cours de dveloppement.
Les annotations de ce pattern rsultent en :
un suivi des ralisations (temps, dates, indicateurs de performance) ;
un amnagement du pattern prvisionnel (au cas o des activits prvues savrent
inutiles, ou inversement), sur ses diffrents objets manipuls (acteurs, activits,
enchanements, livrables, temps, calendrier).
Aprs analyse, et ds lors que le mode dorganisation dun processus particulier a fait la preuve de sa
performance, son mode dinstanciation du rfrentiel gnral peut devenir son tour, selon le
primtre fonctionnel concern :
soit un pattern local ;
soit une adaptation dfinitive (au niveau du pattern gnral) du rfrentiel de gestion de
projet.

Les phases danalyse de projet

tout moment de la construction ou du suivi du projet, le recours lanalyse du processus de
dveloppement est une ncessit.
Sur le plan quantitatif, une telle analyse permet de reprer les incohrences de charge, ou dattribution
de responsabilits.
Sur le plan qualitatif, elle permet de reprer les points de dysfonction, ou les points de risque majeurs
anticips sur le droulement du projet.
Cette analyse dbouche sur des activits darbitrage ou de reporting.
Elle utilise lapport des techniques multi-dimensionnelles, en termes de navigation comme en termes
dinteractivit.
Le tableau suivant donne un exemple de tableau danalyse multidimensionnelle, permettant de
visualiser sous forme de tableau de bord ltat des diffrents indicateurs, synthtiss des niveaux plus
ou moins levs du modle RUP.

8 Assises ADELI 4 dcembre 2002

 ICSSEA 2002 Assises n7 Denis
RESSO QUALITE OPER PERE
URCES ABILIT NITE
E

Sensibilit contextuelle
Rponse Fonctionnelle

Qualit Documentaire
Concours externes
Qualit perue
Taux d'erreur
Scalabilit
Charge
Dlais
T T
a) Spcifier TB
B B
b) Raliser les choix stratgiques T
TB
B
a) Dfinir les Business Use Ca se
b) Modliser les Processu s T T
Mtier B B
a) Raliser T
c) Modliser les Donnes Mtier TB
B
l'analyse
c) laborer le projet
d) Dfinir les crans TB T
B
e) Identifier les API T T T
B B B
f) Raliser la conception T
B
d) Dvelopper T T
TB
B B
a) Dployer T T
B B
e) Grer la T
b) Former les utilisateurs
transition B
c) Organiser la maintenance T
B

Philippe Denis
BNP PARIBAS
BP2S - Internet Reporting et Performance
Bruno Previtali
COTEBA Conseil

Assises ADELI 4 dcembre 2002 9