Concepts :
|
Livres blancs : |
Le Rational Unified Process (RUP) est un cadre de processus que Rational Software a perfectionné au fil des années, et qui est communément utilisé pour tout type de projets logiciels, petits ou grands. Un nombre croissant de processus "agiles", tels qu'eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) et la méthodologie Crystal Clear, sont depuis quelque temps reconnus comme étant des méthodes efficaces en matière de construction de systèmes plus petits. (Voir www.agilealliance.org pour plus d'informations sur l'Alliance Agile.)
Les sections qui suivent ont pour objectif d'aider les équipes de projet à évaluer certaines des pratiques "agiles" tirées de l'une de ces méthodes afin de voir comment elles sont traitées par le processus de développement logiciel plus complet défini par RUP.
La communauté agile a fait la synthèse d'un certain nombre des "meilleures pratiques" qui s'appliquent particulièrement bien aux équipes de projet réduites et travaillant au même endroit. Bien que le RUP cible des équipes de projet de toute taille, il peut être appliqué avec succès à de petits projets. En général, les RUP et les processus de la communauté Agile partagent une vision similaire des principales meilleures pratiques nécessaires au développement d'un logiciel de qualité - par exemple, le fait d'utiliser le développement itératif ou celui de se focaliser sur les utilisateurs finaux.
Les paragraphes suivants expliquent comment appliquer certaines des "meilleures pratiques"
identifiées dans la communauté agile à des projets RUP qui voudraient en bénéficier. Pour cela, nous nous axerons ici sur les pratiques proposées par la méthodologie eXtreme Programming (XP). (Pour plus d'informations sur XP, merci de visiter le site : http://www.extremeprogramming.org.)
XP compte quatre "activités" de base (l'écriture du code, le test, l'écoute et la conception), qui se rapprochent en fait plus des disciplines du RUP. Ces activités XP sont conduites au moyen d'un ensemble de pratiques qui nécessitent l'exécution d'activités supplémentaires, qui correspondent à certaines des autres disciplines du RUP. Les pratiques d'XP, selon Extreme Programming Explained, sont :
Les activités conduites au titre de la pratique du "jeu de planification", par exemple, seront essentiellement mappées à la discipline de gestion de projet du RUP. Mais certaines rubriques du RUP, tels que la modélisation métier et le déploiement du logiciel mis sur le marché, sortent du cadre d'XP. L'obtention des exigences dépasse largement le cadre d'XP, étant donné que le client définit et fournit les exigences. Par ailleurs, du fait de la plus grande simplicité des projets auxquels il s'applique, XP peut gérer plus superficiellement des problèmes que le RUP couvre en détails dans la discipline de gestion de la configuration et des changements ainsi que dans la discipline d'environnement.
Dans les disciplines dans lesquelles XP et le RUP se chevauchent, les pratiques suivantes décrites dans XP pourraient être (et dans certains cas sont déjà) employées dans le RUP :
La suggestion selon laquelle il faut s'assurer au niveau "micro" que les processus sont efficaces est souvent peu agréable à entendre et peut ne pas correspondre à certaines cultures d'entreprise. Le RUP ne défend donc pas l'idée d'une application stricte de la règle. Toutefois, dans certaines circonstances, le fait de travailler par paire (de même que certaines des autres pratiques d'équipe qu'XP encourage à adopter) est indéniablement avantageux, chaque membre de l'équipe pouvant aider l'autre à avancer ; par exemple :
Les pratiques XP suivantes ne s'adaptent pas bien aux systèmes plus importants (XP n'affirme d'ailleurs pas que ce soit le cas) ; on les utilisera donc dans le RUP en ayant toujours cette réserve à l'esprit.
Pour finir, voici une pratique XP qui, à première vue, semble potentiellement utilisable dans le RUP (Conception simple), mais qui requiert en fait de l'élaboration et de la précaution lorsqu'elle est appliquée de façon générale.
Il y a un problème, analogue à celui des optimisations locales, à traiter de ce que le RUP appelle les exigences "non-fonctionnelles". Ces exigences fournissent également de la valeur commerciale au client, mais elles sont plus difficiles à exprimer sous forme de témoignages. Certaines des conditions qu'XP appelle contraintes appartiennent à cette catégorie. Le RUP ne plaide pas non plus en faveur d'une conception qui vise à faire plus que ce qui est nécessaire, de quelque façon spéculative que ce soit, mais il favorise en revanche une conception réalisée avec un modèle architectural en tête (ce modèle étant l'une des clés pour satisfaire les exigences non-fonctionnelles).
Aussi le RUP s'accorde-t-il avec XP pour affirmer que la "conception simple" doit impliquer l'exécution de tous les tests, mais en précisant que ces tests incluent ceux qui démontrent que le logiciel satisfera les exigences non-fonctionnelles. Là encore, cela ne devient un problème majeur qu'à mesure que la taille et la complexité du système augmentent, lorsque l'architecture est sans précédent ou bien encore lorsque les exigences non-fonctionnelles sont onéreuses. Par exemple, le besoin de trier les données (afin d'opérer dans un environnement réparti de façon hétérogène) semble complexifier le code à l'excès, mais il n'en est pas moins nécessaire tout au long du programme.
Lorsque l'on adapte le RUP à un petit projet et que l'on réduit les exigences en termes d'artefacts
en conséquence, quelle comparaison peut-on en faire avec l'équivalent en artefacts d'un projet XP ? En observant l'exemple de plan de développement pour petits projets du RUP, on peut voir qu'un échantillon de configuration RUP a été configuré dans le but de produire moins d'artefacts (voir Tableau 1).
Artefacts XP
|
Artefacts RUP
(tiré d' ![]() |
---|---|
Témoignages Documentation additionnelle tirée des conversations |
Vision Glossaire Modèle de cas d'utilisation |
Contraintes | Spécifications supplémentaires |
Tests d'acceptation et tests unitaires Données d'essai et résultats de tests |
|
Logiciel (code) | Modèle d'implémentation |
Versions | ![]() ![]() |
Métaphore | Document d'architecture logicielle |
Conception (CRC, ébauche UML) Tâches techniques et autres tâches Documents de conception produits à la fin Documentation de support |
Modèle de conception |
Standards de code | ![]() |
Espace de travail Cadre de test et outils |
![]() ![]() |
Plan de version Plan d'itération Evaluations de témoignages et estimations des tâches |
Plan de développement logiciel
Plan d'itérations |
Plan et budget globaux | Cas métier Liste des risques |
Compte-rendus sur la progression Carte de pointage pour charge quotidienne Données de métrologie (incluant les ressources, la portée, la qualité et le temps) Suivi des résultats Compte-rendus et notes sur les réunions |
Evaluation de l'état Evaluation de l'itération Enregistrement des révisions |
Défauts (et données associées) | Demandes de changement |
Outils de gestion de code | Référentiel de projets ![]() |
Pointe (solution) |
Prototypes |
XP lui-même (ses recommandations et conseils) |
|
[Non-inclus dans XP] |
Tableau 1 : Mappage de XP à RUP d'artefacts destinés à un petit projet
Bien que la granularité des artefacts varie des deux côtés, en général, les artefacts du RUP destinés à de petits projets (du type de ceux qu'XP traiterait sans problème) se mappent fort bien à ceux d'un projet XP.
Notez que l'Exemple de plan de développement pour petits projets inclue également quelques artefacts qui ne sont pas couverts par XP mais sont nécessaires sur de nombreux projets. On trouve parmi eux le modèle de données, ainsi que des artefacts associés au déploiement, tels que le
matériel d'aide à l'utilisateur final.
Le RUP définit une activité comme une tâche réalisée par un rôle (soit en utilisant et transformant des artefacts d'entrée, soit en produisant de nouveaux artefacts de sortie modifiés. RUP va plus loin en énumérant ces activités et en les catégorisant selon ses disciplines. Celles-ci incluent : la modélisation métier, les exigences, l'analyse et la conception, le déploiement et la gestion de projets (entre autres).
Les activités sont liées au temps au travers des artefacts qu'elles produisent et consomment : une activité peut logiquement débuter lorsque ses entrées sont disponibles (et dans l'état de maturité approprié). Cela signifie que les paires d'activité producteur-consommateur peuvent se chevaucher dans le temps, dès lors que l'état de l'artefact le permet ; elles n'ont pas besoin d'être séquencées de façon rigide. Les activités ont vocation à donner des indications fortes de la manière dont un artefact doit être produit, et peuvent également servir d'aide à la planification pour le chef de projet.
Incorporées dans le RUP décrit en termes de cycle de vie, artefacts et autres activités, on trouve les "meilleures pratiques" : des principes de génie logiciel réputés pour la possibilité qu'ils offrent de produire des logiciels de qualité dans un temps et pour un budget prévisibles. Le RUP, au travers de ses activités (et de leurs artefacts associés), prend en charge et applique ces meilleures pratiques - qui sont des thèmes qui traversent le RUP dans son intégralité. Notez qu'XP utilise également la notion de "pratiques" mais, comme nous le verrons, celle-ci ne s'aligne pas exactement sur le concept de meilleure pratique que l'on retrouve dans le RUP.
XP offre une vision simple et attrayante du développement logiciel dans laquelle quatre activités de base (code, test, écoute et conception) sont habilitées et structurées selon certaines pratiques de prises en charge (abordées dans Extreme Programming Explained, Chapitre 9). En fait, comme on l'a fait remarquer plus haut, les activités d'XP sont, en matière de portée, plus proches des disciplines du RUP que de ses activités, et l'essentiel de ce qui se passera sur un projet XP (en plus de ses quatre activités de base) viendra de l'élaboration et de l'application de ses pratiques.
Les activités du RUP ont donc un équivalent XP, mais les "activités" d'XP ne sont pas formellement identifiées ou décrites comme telles. Par exemple, si vous examinez le chapitre 4, intitulé "Témoignages d'utilisateurs", dans Extreme Programming Installed, vous trouverez le titre "Définir les exigences avec des témoignages rédigés sur des cartes" et, tout au long du chapitre, un mélange de description de processus et d'indications sur ce que sont les témoignages d'utilisateurs d'une part, et sur la façon dont elles doivent être produites (et par qui) d'autre part. Et ainsi de suite : dans les différentes parties des Livres XP (sous des rubriques qui sont à la fois centrées sur les artefacts, et sur les activités) sont décrites à la fois les "éléments produits" et les "éléments effectués", à des niveaux variés de prescription et de détail.
Le niveau de prescription apparemment élevé du RUP résulte de son caractère complet et du plus grand formalisme qu'il observe dans le traitement des activités et de leurs entrées et sorties. XP ne manque pas de prescription mais, peut-être du fait de sa volonté de rester léger, le formalisme et le détail y sont simplement omis. Le manque de spécificité n'est ni une force ni une faiblesse, mais il ne faut pas prendre le manque d'informations détaillées dans XP pour de la simplicité. Le fait de ne pas avoir de détails peut satisfaire les développeurs les plus expérimentés mais, dans bien des cas, des détails en plus grand nombre sont d'un grand secours au nouveaux membres d'une équipe, ainsi qu'à ceux qui en sont encore à se familiariser avec l'approche de l'équipe en matière de développement logiciel.
Pour les activités, comme pour les artefacts, il est important de rester concentré sur ce que l'on cherche à accomplir. Réaliser une activité en aveugle n'est jamais une bonne pratique.
Les activités et les principes et conseils associés sont faits pour être consultés lorsque l'on en a besoin pour atteindre un objectif, mais ne doivent pas servir d'excuse pour ne pas avoir à se faire une idée d'ensemble de ce que l'on cherche à faire. Cet état d'esprit est bien exprimé dans XP, et nous pensons qu'il devrait être adopté par chaque utilisateur du RUP.
Dans le RUP, il est dit des activités qu'elles sont menées par des rôles (ou, plus précisément, par des individus ou des groupes jouant des rôles). Les rôles sont également responsables d'artefacts spécifiques ; le rôle responsable créera généralement l'artefact et s'assurera qu'un changement opéré par un autre rôle (si jamais il y est autorisé) ne casse pas l'artefact. Un individu ou un groupe de personnes peut jouer un seul ou plusieurs rôles. Un rôle n'a pas à être mappé à un seul poste ou à une seule"case" d'une organisation.
Extreme Programming Explained identifie sept rôles applicables à XP : programmeur, client, testeur, détecteur, formateur, consultant et grand patron ; puis décrit leur responsabilités ainsi que les compétences attendues des gens qui les joueront. Il est également fait référence à ces rôles dans certains des autres Livres XP. La différence dans le nombre de rôles entre XP et le RUP s'explique facilement :
Lorsque des rôles RUP sont mappés à un petit projet, le nombre de rôles de type XP auxquels ils correspondent est considérablement réduit, puisque le nombre de postes, ou dénominations de poste, est de 5. Le tableau 3 (extrait du RUP) présente ce mappage avec le rôle XP correspondant.
Rôle XP | Exemple de membre d'une équipe sur un petit projet RUP | Rôle RUP |
---|---|---|
Formateur Consultant Grand patron |
Sally Slalom, Responsable en chef | Chef de projet![]() Réviseur technique Responsable de la configuration Responsable du contrôle des changements |
Client | Partie prenante (voir Vision) |
Réviseur de gestion Réviseur technique (exigences) |
Client Grand patron Détecteur |
Tom Telemark, Ingénieur logiciel en chef | Analyste système Spécificateur d'exigences Concepteur d'interface utilisateur Architecte logiciel Réviseur technique Responsable de tests ![]() et dans une moindre mesure les rôles de développement. |
Programmeur Testeur |
Susan Snow, Ingénieur logiciel Henry Halfpipe, Ingénieur logiciel junior |
Concepteur Implémenteur Réviseur technique Intégrateur ![]() ![]() ![]() |
Détecteur | Patrick Powder, Adjoint administratif | Responsable de la maintenance du site Web du projet, assiste le rôle de chef de projet pour les activités de planification/planning, et assiste le rôle de responsable du contrôle des changements pour le contrôle des changements apportés aux artefacts. Peut aussi être amené à assister d'autres rôles si nécessaire. |
Tableau 3 : Mapper les rôles XP aux rôles RUP sur un petit projet
Le RUP est un cadre de processus à partir duquel des processus particuliers peuvent être configurés puis instanciés. Le RUP doit être configuré : c'est là une étape obligatoire définie dans le RUP lui-même. Au sens strict, nous devrions donc comparer XP à une version du RUP adaptée aux caractéristiques de projet qu'XP établit explicitement (et à celles qui peuvent en être déduites). Un tel processus RUP adapté pourrait contenir de nombreuses pratiques XP (telles que la programmation par paire, la conception pilotée par le test et le réusinage), mais il n'en serait pas pour autant identique à XP du fait de l'importance qu'accorde le RUP à l'architecture, à l'abstraction (dans la modélisation) et au risque, et à cause de sa structure temporelle (phases et itérations) différente.
XP est volontairement conçu pour implémenter un processus léger à de petits projets. Ce faisant, il contient également des descriptions (du moins dans les livres) qui ne sont pas complètement élaborées. Dans une implémentation XP, il y aura toujours des éléments à découvrir, à inventer ou à définir à la volée. Le RUP gérera des projets qui correspondent à la portée d'XP et la dépassent en terme d'échelle et de type.Comme le montre cette feuille de route, le RUP est ainsi tout à fait compatible avec la plupart des pratiques décrites dans la documentation XP.
Gardez à l'esprit que l'essence d'XP réside dans sa focalisation sur l'organisation, les personnes et la culture. C'est important dans tous les projets, et très certainement applicable à ceux qui utilisent le RUP. Les petits projets pourraient tirer un grand profit d'une utilisation conjointe de ces pratiques.
RUP (Rational Unified Process)
|