Rubriques
Le processus Rational Unified Process (RUP) est une infrastructure préfabriquée de processus que le Rational Software a
amélioré au fil des ans et qui a été largement utilisée pour tous les types de projets logiciels, des plus petits aux
plus grands. Un nombre croissant de processus dits "agiles" (comme les méthodes eXtreme Programming (XP), SCRUM,
Feature-Driven Development (FDD) et Crystal Clear) ont récemment été reconnus comme des méthodes efficaces pour
concevoir des systèmes plus petits. (Pour plus d'informations sur le groupe Agile Alliance, voir www.agilealliance.org.)
Les sections suivantes fournissent une aide aux équipes projet dans l'évaluation des pratiques "agiles" identifiées
dans ces méthodes, afin de voir comment elles sont traitées par le processus de développement logiciel le plus complet
défini par RUP (pour plus d'informations sur RUP, voir Introduction à RUP).
La communauté agile a synthétisé un certain nombre de "meilleures pratiques" qui s'appliquent particulièrement bien aux
petites équipes de projet travaillant dans un même site. Bien que le processus RUP soit conçu pour des équipes de toute
taille, il peut s'appliquer avec succès à de petits projets. En général, RUP et les processus de la communauté Agile
ont une même conception des meilleures pratiques clés requises pour développer un logiciel de qualité - appliquant, par
exemple, un développement itératif et mettant l'accent sur les utilisateurs.
Les sections suivantes expliquent comment appliquer certaines des "meilleures pratiques" identifiées dans la communauté
agiles aux projets utilisant RUP et voulant bénéficier de certaines de ces pratiques. Dans ce cas, l'accent est
particulièrement mis sur les pratiques de la méthodologie eXtreme Programming (XP). (Pour plus d'informations sur XP,
voir le site web : http://www.extremeprogramming.org.)
Pratiques XP
XP présente quatre "activités" de base (coder, tester, écouter et concevoir) qui, en fait, correspondent davantage aux
disciplines de RUP. Ces activités XP sont réalisées à l'aide d'un ensemble de
pratiques nécessitant la réalisation d'activités supplémentaires, qui sont mappées à d'autres disciplines dans le
processus RUP. Selon Extreme Programming Explained, les pratiques XP sont :
-
Jeu de la planification : Détermine rapidement la portée de l'édition suivante en combinant les priorités
métier et les estimations techniques. La réalité dépassant souvent la planification, il faut mettre cette dernière
à jour.
-
Petites éditions : Lancer la production d'un système simple rapidement, puis sortir de nouvelles éditions
sur un cycle très court.
-
Métaphore : Guide tout le développement avec une explication simple et commune du fonctionnement de
l'ensemble du système.
-
Conception simple : Le système doit être conçu aussi simplement que possible, à tout moment. Toute
complexité doit être supprimée dès qu'elle est détectée.
-
Test : Les programmeurs écrivent continuellement des tests d'unité, qui doivent fonctionner parfaitement
pour que le développement continue. Les clients écrivent des tests démontrant que les fonctions sont terminées.
-
Restructuration : Les programmeurs restructurent le système sans en modifier le comportement afin de
supprimer les doublons, d'améliorer la communication, de simplifier le système ou d'améliorer la flexibilité.
-
Programmation par paire : Tout code de production est écrit par deux programmeurs sur une seule machine.
-
Propriété collective : N'importe qui peut changer n'importe quel code n'importe où dans le système, à tout
moment.
-
Intégration continue : Intégration et construction du système plusieurs fois par jour, chaque fois qu'une
tâche est terminée.
-
Semaine de 40 heures : Ne pas travailler plus de 40 heures par semaine est une règle. Ne jamais faire
d'heures supplémentaires deux semaines d'affilée.
-
Client sur site : Inclure un utilisateur réel dans l'équipe, disponible à temps plein pour répondre aux
questions.
-
Normes de codage : Les programmeurs écrivent le code conformément aux règles établies en mettant l'accent
sur la communication via le code.
Les activités réalisées en tant que résultat de la pratique "jeu de la planification" par exemple, seront mappées à la
discipline de gestion de projet de RUP. Certains sujets de RUP, comme le déploiement du logiciel édité, n'entrent pas
dans la portée de XP. La clarification des exigences est largement en dehors de la portée de XP, puisque le client
définit et fournit les exigences. En raison des projets de développement plus simples qu'il traite, XP ne peut traiter
que simplement les questions que RUP couvre en détail dans la discipline de configuration et de gestion des changements
et dans celle d'environnement.
Pratiques XP compatibles avec RUP
Pour les disciplines où XP et le processus RUP se recoupent, les pratiques suivantes qui ont été décrites pour XP
pourraient (et dans certains cas le sont déjà) être employées dans le processus RUP :
-
Jeu de la planification : Les conseils de planification XP peuvent servir pour atteindre plusieurs des
objectifs indiqués dans la discipline de gestion de projet de RUP pour un projet très petit. Cela est
particulièrement utile pour les projets peu formels n'étant pas contraints de produire des artefacts de gestion de
projet intermédiaires formels.
-
Conception pilotée par les tests et restructuration : Ce sont de bonnes techniques pouvant s'appliquer dans
la discipline d'implémentation du processus RUP. La pratique de test XP nécessitant une conception pilotée par les
tests est un excellent moyen de clarifier les exigences à un niveau détaillé. Comme nous le verrons à la section
suivante, la restructuration peut ne pas bien s'adapter à des systèmes plus vastes.
-
Intégration continue : Le processus RUP prend en charge cette pratique par le biais de constructions, au
niveau du système et du sous-système (au sein d'une itération). Les composants testés de façon unitaire sont
intégrés et testés dans le contexte du système émergeant.
-
Client sur site : De nombreuses activités du processus RUP bénéficient largement de la présence d'un client
au sein de l'équipe, ce qui peut réduire le nombre de livrables intermédiaires nécessaires, en particulier les
documents. Comme il s'agit de son moyen de communication préféré entre client et développeur, XP met l'emphase sur
la conversation, qui implique un certain degré de continuité et de familiarité. Cependant, lorsqu'il faut effectuer
la transition d'un système, même petit, la conversation seule ne suffit pas. XP tient compte de cela après coup
avec, par exemple, les documents de conception à la fin d'un projet. Bien que n'interdisant pas la production de
documents ou autres artefacts, XP préconise de produire uniquement ceux dont vous avez vraiment besoin. Il en est
de même avec le processus RUP, mais celui-ci décrit ce dont vous pouvez avoir besoin lorsque la continuité et la
familiarité ne sont pas parfaites.
-
Normes de codage : Le processus RUP possède un artefact (les instructions de programmation) qui est presque
toujours considéré comme obligatoire. (La plupart des profils de risque d'un projet, qui sont un élément majeur de
personnalisation, le considéreraient comme tel.)
-
Semaine de 40 heures : Comme XP, le processus RUP préconise que les heures supplémentaires ne deviennent pas
une habitude. XP ne préconise cependant pas une limite fixe de 40 heures par semaine ; il tolère un nombre d'heures
de travail différent. Les ingénieurs logiciel sont connus pour faire de longues journées sans compensation
supplémentaire - simplement pour le plaisir de terminer ce qu'ils ont commencé - et les responsables n'y mettent
pas obligatoirement un frein. Ils ne doivent par contre ni exploiter cette pratique, ni l'imposer. Ils devraient
toujours comptabiliser les heures de travail effectives, même non rémunérées. Si le journal des heures travaillées
de quelqu'un semble élevé sur une certaine période, cela doit cependant être sujet à vérification. Mais il s'agit
là d'une question à résoudre entre le responsable et l'individu, selon les circonstances dans lesquelles cela s'est
produit, et en fonction des problèmes que cela peut soulever par rapport au reste de l'équipe. Quarante heures
n'est qu'une indication, mais une indication fortement recommandée.
-
Programmation par paire : Pour XP, la programmation par paire est bénéfique pour la qualité du code et cette
compétence est plus agréable à utiliser une fois acquise. Le processus RUP ne décrit pas la mécanique de la
production de code à un niveau aussi détaillé bien qu'il soit certainement possible d'utiliser la programmation par
paire pour un processus basé sur RUP. Certaines informations sur la programmation par paire - ainsi que la
conception pilotée par les tests et la restructuration - sont maintenant fournies avec le processus RUP, sous la
forme de livres blancs. De toute évidence, il n'est pas obligatoire d'utiliser une de ces pratiques dans le
processus RUP. Cependant, dans un environnement d'équipe avec une culture de communication ouverte, nous pouvons
supposer que les avantages de la programmation par paire (en termes d'effet sur les coûts totaux du cycle de vie)
sont difficiles à cerner. Les gens vont se regrouper naturellement pour discuter des problèmes et les résoudre dans
une équipe qui fonctionne bien, sans être obligés de le faire.
Le principe selon lequel un bon processus doit être appliqué au niveau "micro" est souvent désagréable à entendre et ne
convient pas à certaines cultures d'entreprise. RUP ne prône donc pas une application stricte. Dans certaines
circonstances, néanmoins, il est de toute évidence avantageux de travailler par paire - et selon certaines autres
pratiques en équipe prônées par XP - car chaque membre peut aider l'autre, comme par exemple dans les cas suivants :
-
les premiers jours de la formation des équipes, lorsque les gens apprennent à se connaître
-
les équipes qui ne connaissent pas une nouvelle technologie
-
les équipes comprenant du personnel expérimenté et des débutants
Pratiques XP qui ne s'adaptent pas bien
Les pratiques XP suivantes ne s'adaptant pas bien à des systèmes plus larges (et XP ne prétend pas qu'elles le
fassent), nous mettons à profit leur utilisation dans RUP sous certaines conditions.
-
Métaphore : Pour les systèmes complexes plus vastes, l'architecture en tant que métaphore ne suffit pas. Le
processus RUP fournit une infrastructure préfabriquée de description beaucoup plus riche pour l'architecture, qui
n'est pas simplement faite - comme le décrit Extreme Programming Explained - de
"grandes cases et connexions." Même dans la communauté XP, la métaphore a plus récemment été désapprouvée. Il ne
s'agit plus d'une pratique utilisée par XP (jusqu'à ce qu'ils trouvent comment la décrire correctement - une
métaphore les aiderait peut-être).
-
Propriété collective : Utile si les membres d'une équipe responsable d'un petit système ou d'un sous-système
sont familiers avec l'intégralité du code. Mais avoir tous les membres de l'équipe habilités à effectuer des
changements à tout moment dépend de la complexité du code. Il sera parfois plus rapide (et plus sûr) que l'individu
(ou la paire) travaillant sur le segment de code en question le corrige. La familiarité avec le code, même s'il est
bien écrit, diminue rapidement dans le temps, particulièrement s'il est complexe au niveau des algorithmes.
-
Restructuration : Dans un vaste système, une restructuration fréquente ne compense pas une insuffisance de
l'architecture. Selon Extreme Programming Explained, "La stratégie de conception
XP ressemble à un algorithme d'escalade. Vous prenez une conception simple, vous la complexifiez un peu, puis vous
la simplifiez un peu et de nouveau, vous la complexifiez un peu. Le problème des algorithmes d'escalade est
d'atteindre un optimum local, où la situation peut être améliorée par de grands changements mais pas par des
petits." Dans le processus RUP, l'architecture permet de voir et d'accéder à la "grande pente" pour rendre
tractable un système vaste et complexe.
-
Petites éditions : Le rythme auquel un client peut accepter et déployer de nouvelles éditions dépend de
plusieurs facteurs, dont la taille en général, qui est habituellement liée à l'impact métier. Un cycle de deux mois
peut s'avérer bien trop court pour certains types de systèmes ; la logistique de déploiement peut l'interdire.
Pratiques XP qui nécessitent une certaine prudence
Enfin, lorsqu'on applique de façon générale une pratique XP qui, à première vue, semble potentiellement utilisable dans
le processus RUP (comme la conception simple) il faut la retravailler un peu et l'utiliser avec prudence.
-
Conception simple
XP est fortement axé sur les fonctionnalités : les besoins fonctionnels de l'utilisateur sont sélectionnés,
décomposés en tâches puis implémentés. Selon Extreme Programming Explained, une
bonne conception pour un logiciel, à tout moment, est celle qui exécute tous les tests, n'a pas de logique en
doublon, expose toutes les intentions importantes pour les programmeurs et a le moins de méthodes et de classes
possibles. D'après XP, il n'est pas nécessaire d'ajouter quoi que ce soit qui ne soit pas nécessaire pour livrer la
valeur métier au client.
Il y a un problème ici, lié aux problèmes d'optimisations locales, avec ce que le processus RUP appelle les
exigences "non fonctionnelles". Ces exigences donnent aussi au client une valeur métier, mais il est difficile
de les exprimer en tant que besoins fonctionnels de l'utilisateur. Certaines des contraintes, appelées ainsi
par le processus XP, tombent dans cette catégorie. RUP ne préconise pas une conception plus élaborée que
nécessaire à quelque fin spéculative que ce soit, mais il préconise d'élaborer la conception avec un modèle
d'architecture en tête, ce modèle étant l'une des clés pour répondre aux exigences non fonctionnelles.
Pour RUP comme pour XP, une "conception simple" doit donc comprendre l'exécution de tous les tests, mais RUP
précise en plus qu'elle doit comprendre des tests démontrant que le logiciel répond aux exigences non
fonctionnelles. Là encore, cela apparaît comme un problème majeur au fur et à mesure que la taille du système
et la complexité augmentent, lorsque l'architecture n'a pas de précédent ou lorsque que les exigences non
fonctionnelles sont onéreuses. Le besoin de convertir des données (pour opérer dans un environnement distribué
hétérogène) semble par exemple rendre le code trop complexe, mais cela sera toujours requis dans tout le
programme.
Mappage des artefacts pour un petit projet
Lorsque nous personnalisons le processus RUP pour un petit projet et réduisons en conséquence les exigences relatives
au produit, comment cela se passe-t-il pour l'équivalent de nos artefacts dans un projet
XP ? Le tableau 1 montre un ensemble type d'artefacts de RUP pour un petit projet RUP.
Tableau 1 : Mappage des artefacts de XP et de RUP pour un petit projet
Bien que la granularité des artefacts varie dans RUP et XP, les artefacts de RUP pour de petits projets (type de
projets que XP traite facilement) sont facilement mappés aux artefacts d'un projet XP.
Notez qu'il y a dans le tableau des artefacts qui ne sont pas traités par XP mais sont nécessaires pour bon nombre de
projets. Il s'agit du modèle de
données et des artefacts liés au déploiement tels que le matériel de support de l'utilisateur.
Activités
Le processus RUP définit une tâche comme
étant un travail réalisé par un rôle, soit en
utilisant et en transformant des artefacts d'entrée, soit en produisant des artefacts de sortie nouveaux et modifiés.
Il énumère aussi ces activités et les répertorie selon ses disciplines. Ces disciplines comprennent : les exigences, l'analyse et la conception,
le déploiement et la gestion de projet (entre autres).
Les activités sont liées au temps par le biais des artefacts qu'elles produisent et utilisent : une activité peut
normalement commencer si ses entrées sont disponibles (dans un état de maturité convenable). Si l'état de l'artefact le
permet, les activités producteur-consommateur peuvent se chevaucher dans le temps ; il n'est pas nécessaire qu'elles
soient divisées en séquences de façon stricte. Les activités doivent fournir des conseils sur la façon dont un artefact
doit être produit et peuvent aussi aider le responsable du projet dans sa planification.
Les "meilleures pratiques" sont intégrées au processus RUP tel qu'il est décrit en termes de cycle de vie, d'artefacts
et d'activités : ce sont des principes d'ingénierie logicielle reconnus pour produire un logiciel de qualité, construit
selon un calendrier et un budget prévisibles. Le processus RUP prend en charge ces meilleures pratiques (ce sont des
thèmes qui reviennent tout au long du processus) et les réalise à travers ses activités (et leurs artefacts associés).
Elles respectent les principes clés qui fondent le RUP. Notez que XP utilise aussi la notion de
"pratiques" mais, comme nous le verrons plus loin, elles ne correspondent pas exactement au concept de "meilleures
pratiques" de RUP.
XP présente une vision du développement logiciel plutôt engageante du fait de sa simplicité car il a quatre activités
de base - coder, tester, écouter et concevoir - qui doivent être exécutées et structurées selon certaines pratiques de
support (comme mentionné dans le chapitre 9 de Extreme Programming Explained). Comme il a déjà été dit, en termes de
portée, les activités XP se rapprochent davantage des disciplines RUP que des activités RUP, et une grande partie de ce
qui a lieu au cours d'un projet XP (en plus des quatre activités de base) résulte de l'élaboration et de l'application
de ses pratiques.
Il existe donc un équivalent XP des activités du processus RUP, mais les activités XP ne sont pas formellement
identifiées et décrites comme telles. Dans le chapitre 4 "User Stories" de Extreme Programming
Installed par exemple, vous trouverez un paragraphe traitant de la "définition des exigences avec des besoins
fonctionnels, décrits sur des cartes". Ce chapitre est un mélange de description de processus et de conseils sur les
besoins fonctionnels et comment les produire. Et cela continue de la même manière : dans les différentes sections des
livres XP (sous des titres qui sont un mélange de contenu orienté sur les artefacts et de
contenu orienté sur les activités), vous trouverez une définition des "choses produites" et des "choses faites" avec un
niveau de détail et de prescription varié.
Le degré de prescription apparemment élevé de RUP résulte du fait qu'il est plus complet et formel dans le traitement
des activités et des entrées et sorties de ces dernières. Il n'y a pas d'insuffisance de prescription dans XP, mais
peut-être qu'en voulant rester simple, il omet simplement le formalisme et les détails. Un manque de spécificité ne
représente ni une force ni une faiblesse, mais il ne faut pas pendre le manque d'informations détaillées dans XP pour
de la simplicité. Les développeurs expérimentés peuvent très bien se passer de détails mais, dans beaucoup de cas,
c'est une aide pour les nouveaux membres de l'équipe d'avoir davantage de détails ainsi que pour ceux qui essaient de
rattraper leur retard par rapport à l'approche de l'équipe concernant le développement logiciel.
Avec les activités, tout comme avec les artefacts, il est important de rester concentré sur ce que l'on cherche à
atteindre. Mener une activité à l'aveuglette n'est jamais très bon. Les activités et les instructions qui y font
référence sont faites pour être consultées lorsque vous avez besoin d'atteindre un objectif mais elles ne représentent
en aucun cas une excuse pour ne pas avoir à chercher à comprendre ce que vous essayez de faire. Les utilisateurs de XP
ont cet état d'esprit et nous pensons qu'il devrait en être de même avec chaque utilisateur de RUP.
Rôles
Dans le processus RUP, les activités sont
réalisées par les rôles (où plus
précisément par des individus ou des groupes jouant des rôles). Les rôles sont aussi responsables d'artefacts particuliers ; le rôle qui est responsable va généralement créer l'artefact
puis s'assurer que tout changement, quel qu'il soit, effectué par d'autres rôles (si cela leur est permis) n'endommage
pas l'artefact. Un individu ou un groupe de personnes peut avoir un seul rôle ou plusieurs. Il n'est pas nécessaire de
mapper un rôle à une position unique seulement ou un "emplacement" dans une organisation.
Extreme Programming Explained identifie sept rôles pouvant être appliqués à XP -
programmeur, client, testeur, auditeur, conseiller, consultant et patron - et décrit leurs responsabilités et les
compétences requises pour les personnes qui vont tenir ces rôles. Certains autres livres
XP y font aussi référence. La différence entre le nombre de rôles dans XP et dans RUP est facile à expliquer :
-
XP ne couvre pas toutes les disciplines de RUP.
-
Les rôles dans XP sont davantage comparables aux positions au sein d'une organisation (peut-être avec plusieurs
responsabilités) qu'aux rôles dans RUP. Par exemple, un programmeur de XP tient plusieurs rôles de RUP -
implémenteur, réviseur de code et intégrateur - qui requièrent des compétences légèrement différentes.
Rôles XP et RUP pour un petit projet
Lorsque les rôles de RUP sont mappés vers un petit projet, le nombre de rôles de style XP correspondants est
considérablement réduit en ce sens que les positions, ou fonctions, sont au nombre de 5. Le tableau 3 (tiré du
processus RUP) montre ce mappage avec le rôle XP correspondant.
Table 3 : Mappage des rôles XP aux rôles RUP pour un petit projet
Utilisation des pratiques XP avec RUP
Le processus RUP est une architecture préfabriquée de processus à partir de laquelle on peut configurer et instancier
des processus particuliers. Il doit être configuré ; cette étape est obligatoire, définie par le processus lui-même.
Nous devons comparer une version personnalisée de RUP avec XP, c'est-à-dire avec le processus RUP personnalisé selon
les caractéristiques du projet que XP établit explicitement (ainsi que celles que l'on peut induire). Un tel processus
RUP personnalisé peut intégrer beaucoup de pratiques XP (telles que la programmation par paire, la conception pilotée
par les test et la restructuration) mais il n'en est pas pour autant identique à XP en raison de l'importance qu'il
donne à l'architecture, à l'abstraction (dans la modélisation), aux risques et de sa structure différente dans le temps
(phases et itérations).
XP est volontairement orienté sur l'implémentation d'un processus léger pour de petits projets. Il comprend aussi les
descriptions partielles (tout au moins dans les livres). Lors d'une implémentation XP, il y a toujours des choses à
découvrir, inventer ou définir à la volée. Le processus RUP peut être utilisé à la fois pour des projets dans la portée
de XP ou en dehors, que ce soit en termes de taille ou de type. Comme le montre cette introduction, le processus RUP
est finalement bien compatible avec la plupart des pratiques décrites par XP.
Il faut bien garder à l'esprit que l'essence de XP est de se concentrer sur l'organisation, les gens et les cultures.
C'est un élément important pour tous les projets et cela s'applique certainement aux projets utilisant le processus
RUP. Les projets de petite envergure peuvent grandement bénéficier du recours à ces pratiques.
Références concernant le processus Agile
-
eXtreme Programming (XP) (voir http://www.extremeprogramming.org/more.html pour plus
d'informations.):
-
Extreme Programming Explained: Embrace Change. Kent Beck explique les concepts et la philosophie
de cette méthode. Ce livre explique le quoi et le pourquoi mais pas le comment.
-
Refactoring Improving the Design of Existing Code. Martin Fowler écrit ici le premier volume de
référence sur la restructuration. Il est présenté sous la forme de patterns et beaucoup d'exemples sont
au format Java. Ce livre explique comment et pourquoi restructurer.
-
Extreme Programming Installed. De Ron Jeffries, Chet Hendrickson, Ann Anderson. Ce livre
présente des pratiques XP particulières de manière plus détaillée que Extreme Programming Explained. Ce
livre explique comment programmer XP.
-
Planning Extreme Programming. De Kent Beck et Martin Fowler. Ce livre présente les dernières
réflexions sur la planification de logiciel dans un environnement de livraison rapide. Ce livre
explique comment mener un projet XP.
-
Extreme Programming Examined. De Giancarlo Succi et Michele Marchesi. Articles présentés à la
conférence XP2000. Ensemble d'articles qui couvre la plupart des sujets.
-
Extreme Programming in Practice. De Robert C. Martin et James W. Newkirk. Description en détail
d'un projet réel ayant eu recours à XP.
-
Extreme Programming Explored. De William C. Wake. Ce livre est basé sur le fameux site web
XPlorations. Il explore en détails certains sujets particuliers.
-
Extreme Programming Applied: Playing to Win. De Ken Auer et Roy Miller. Expériences menées par
des pionniers sur l'application de XP. Publication en septembre.
Pour des informations concernant les autres membres du groupe Agile Alliance, voir http://www.agilealliance.org.
|