Activités à travers le cycle de vie :
-
Introduction
-
Définition d'une version de référence
-
Evoluer avec le processus RUP
-
Le cycle d'évolution
-
Résumé
-
Références
Rubriques supplémentaires :
-
Concepts
-
Instructions
-
Livres blancs
|
Un système en vigueur est défini comme un système qui "résiste de façon significative aux modifications et à
l'évolution pour répondre à des exigences toujours changeantes de l'entreprise". [1] Le
système est généralement volumineux et vieux. Dans ce contexte, cela fait également référence à "un système développé à
l'origine en utilisant un processus autre que RUP".
Le terme "évolution" fait référence à un projet significatif de mise à jour, d'intégration ou de redéveloppement d'un
système en vigueur. C'est pourquoi cette feuille de route ne décrit pas comment le processus RUP peut être utilisé pour
la maintenance continue de systèmes existants.
Généralement, il est conseillé de commencer par définir une vision pour l'évolution envisagée, en répondant à des
questions telles que :
-
Où se trouve la valeur de votre système en vigueur ?
-
Comment voulez-vous le faire évoluer ?
-
Existe-t-il une étude de rentabilité relative à l'évolution prévue ?
Vous trouverez une discussion plus approfondie de ces rubriques dans Guideline: Définition d'une vision pour l'évolution du système en vigueur.
Principaux défis lors de l'évolution de systèmes en vigueur :
-
Le système est mal compris.
-
La documentation est obsolète.
-
Les développeurs d'origine ne sont pas disponibles et le reste du personnel n'a qu'une connaissance limitée
de la façon dont le système fonctionne.
-
Le système a été développé en utilisant des méthodes et des technologies de développement d'applications anciennes
qui ne sont plus adaptées au futur effort de développement.
Comme pour tous les projets, les principes fondamentaux du processus RUP s'appliquent aux projets d'évolution de
systèmes en vigueur.
Ces principes sont les suivants :
-
Limitation précoce des risques
-
Développement itératif
-
Evaluation de l'avancement en fonction de preuves concrètes et mesurables
-
Organisation autour d'équipes réduites et autonomes
-
Vérification continue de la qualité
-
Gestion de la portée
-
Ne produire que les produits nécessaires
Ces éléments rendent le canevas de cycle de vie RUP de base (avec ses quatre phases : création, élaboration,
construction et transition) totalement applicable à un projet de système en vigueur. De ce fait, la plupart des
activités de gestion de projet RUP sont également totalement applicables.
L'adaptation du processus RUP pour la prise en charge l'évolution des systèmes en vigueur est développée plus en détail
ci-dessous.
Pour ne pas vous contenter d'appliquer le cycle de vie RUP et utiliser d'autres disciplines du processus RUP pour
évoluer, vous devez définir un point de départ. Vous devez identifier un ensemble minimal des produits essentiels
décrivant le système en vigueur.
Selon la portée de l'évolution, vous aurez plus ou moins besoin de :
-
Exigences
-
Architecture et conception
-
Tests
-
Documentation utilisateur
Une fois la version de référence des produits RUP définie, vous pouvez traiter le projet comme s'il s'agissait d'un
cycle d'évolution du processus RUP.
Définir un ensemble minimal de produits permettant à votre projet de s'adapter au processus RUP nécessite de procéder à
une ingénierie inverse sur votre système en vigueur. L'ingénierie inverse fait référence à l'identification,
l'extraction ou la recréation d'une quantité d'information suffisante pour vous permettre de procéder comme si le
projet avait été développé à l'origine en utilisant le processus RUP. A ce stade, les responsables de projet sont
souvent prêts à abandonner le processus RUP pour leur projet existant car cet effort d'ingénierie inverse leur semble
être une grande perte de temps. Cet effort n'a cependant pas besoin d'être important car son but n'est pas de récréer
chaque produit mais de comprendre les attributs clés du système en vigueur et de déterminer ce qui doit être conservé
et ce qui doit être remplacé ou mis à niveau.
Les canevas RUP pour ces produits peuvent être utilisés, tout comme certaines des instructions et des listes de
contrôle, mais il peut être préférable d'adapter tout d'abord ces canevas afin d'éviter de documenter des éléments dont
vous n'avez pas besoin. Dans de nombreux cas, vous pouvez "remplir" les canevas (lors de votre premier passage) par
références croisées, c'est-à-dire en indiquant dans quel document existant l'information correspondante peut être
trouvée. Si la documentation est en ligne au format HTML, vous pouvez utiliser des hyperliens.
Notez que cette étape de la définition d'une version de référence n'est pas spécifique au processus RUP. Quel que soit
le processus ou la méthode que vous utilisez pour évoluer, vous devez procéder à une ingénierie inverse du système
existant. Le site Web de"Renaissance," projet Esprit sur
la réingénierie de logiciels, est une bonne source d'informations sur l'ingénierie inverse.
Exigences
L'avantage principal du système en vigueur et qu'il fournit la spécification des exigences pour le nouveau système.
Par exemple, lors du démarrage de Rational Apex, le premier brouillon du notre document
Vision indiquait "... son premier objectif est d'effectuer tout les tâches que l'environnement Rational (version
Delta) effectue, et de ne pas être plus lent". Nous avons ensuite spécifié des déviations de l'environnement Rational :
ajout de fonctionnalités, suppression de fonctionnalités.
Une équipe astucieuse ne documente jamais retrospectivement les exigences d'un système en vigueur. Vous n'avez donc pas
à reprendre l'effort de définition des exigences depuis le début. Vous n'avez qu'à identifier vos cas d'utilisation
clés. Vous les avez d'ailleurs sûrement dans le manuel d'utilisation en vigueur. Un simple inventaire des cas
d'utilisation (Rapport : Synthèse de modèle de cas d'utilisation) peut être suffisant. Il vous
suffit de détailler les cas d'utilisation devant être modifiés. La plupart des exigences non-fonctionnelles peuvent
être dérivées de votre documentation d'installation ou de votre documentation marketing : capacités, caractéristiques
de taille et de performances, systèmes d'exploitation, mémoire, périphériques, autres logiciels, contraintes générales,
etc. Si vous n'utilisez pas d'outil de gestion des exigences, il est peut-être temps de commencer. Enfin, un autre
artefact intéressant à créer lors de cette ingénierie inverse est un glossaire des termes utilisés dans le système en vigueur, en
collectant les termes au fur et à mesure que vous les rencontrez. Il peut être très utile lors de l'évolution.
Architecture et conception
Votre système en vigueur ne nécessite pas d'être intégralement reconçu avec des techniques orientées objet. Vous aurez
cependant besoin de certaines informations architecturales. Vous pouvez créer un Document sur l'architecture logicielle minimal, à partir de la vue d'implémentation : Quels sont les divers sous-systèmes et éléments principaux du
code ? Quelles sont les interfaces critiques ? A partir de ces informations, vous pouvez identifier votre vue de déploiement et votre vue de processus
si le système en vigueur est distribué. Vous devez disposer d'un inventaire précis des logiciels existants et
identifier clairement tous les éléments et les relations entre ceux-ci. Si les logiciels ne sont pas contrôlés par la
gestion de la configuration, c'est le bon moment pour commencer.
La description des interfaces et des scénarios dans lesquels ces interfaces sont vérifiées est cruciale. Par la suite,
vous identifierez les sous-systèmes qui ne sont pas touchés par l'évolution : les parties stables, principales et
réutilisables du système en vigueur. Avez-vous besoin d'une documentation de conception de logiciel plus détaillée avec
ces descriptions d'interface ? Si vous possédez cette documentation et que celle-ci est fiable, tant mieux. Mais ne
vous lancez pas dans un effort conséquent pour obtenir cette documentation avant de savoir quels éléments doivent être
modifiés. Même dans ce cas, procédez au cas par cas. Des outils peuvent vous permettre d'effectuer cette ingénierie
inverse en quelques jours.
Vous devez également identifier les différentes sources de données de votre système en vigueur devant être migrées et
enregistrer leur profil de données dans les spécifications de migration de données. Ces informations seront
cruciales lorsque vous commencerez à définir le mappage des données sources existantes et les données requises par la
nouvelle version du système.
Tests
Quels que soient les tests, scripts de test, jeux d'essai et routines de test développés pour le système en vigueur,
ceux-ci seront pour la plupart applicables au nouveau système.
Documentation utilisateur
S'il n'est pas nécessaire de la reprendre complètement, la documentation utilisateur du système en vigueur peut
constituer une bonne version de référence pour le nouveau système.
Une fois votre version minimale de référence du produit RUP définie, pour la plus grande partie par référence à des
informations existantes, vous pouvez poursuivre. La plupart des tâches du processus RUP s'appliquent de la même façon
que dans les itérations de construction et de transition dans le cadre d'un nouveau projet. Cependant, comme toujours,
essayez de limiter au maximum la sélection des éléments à adopter dans le processus RUP : n'exécutez pas de tâches et
ne créez pas de produits non nécessaires.
Gestion des exigences
Exprimez de nouvelles exigences en utilisant des cas
d'utilisation. Il peut être nécessaire de recréer un cas d'utilisation pour une fonctionnalité afin de mieux
définir les éléments modifiés. Si plusieurs cas d'utilisation doivent être ajoutés ou modifiés, il peut être utile de
dériver un petit modèle de domaine de votre glossaire.
Architecture et conception
Vous pouvez envisager d'utiliser des techniques orientées objet et le langage UML (Unified Modeling Language) pour
votre nouveau développement. Une technique utile consister à considérer certains des sous-systèmes récemment affectés
comme des grandes classes composites, plus particulièrement pour les diagrammes de séquence. Le modèle de conception obtenu ne doit détailler que les classes ayant
une importance pour l'architecture ou devant évoluer. Vous pouvez créer des proxys pour ces classes, en mappant leurs
fonctionnalités au code existant.
Si votre objectif à long terme est ambitieux et vise un remplacement total et graduel du système en vigueur, vous devez
procéder à une conception architecturale pour le nouveau système, puis le mapper aux sous-systèmes existants. Vous
pouvez créer des encapsuleurs autour de certaines parties du corps du code existant pour que celui-ci ressemble à du
code conçu avec des techniques orientés objet. Le réassemblage du système complet avec les différents encapsuleurs peut
constituer un jalon interne de votre phase d'élaboration. Au cours de la conception du cas d'utilisation, vos réalisations de cas d'utilisation indiqueront l'impact sur les
différents sous-systèmes. Vous pourrez alors décider quels "sous-systèmes encapsulés" doivent être convertis, portés,
réécrits ou intégrés à une infrastructure Intégration d'applications d'entreprise.
Les spécifications sur la migration de données doivent être complétées avec le mappage données source-données cible.
Cela permettra l'implémentation des composants de migration nécessaire à la migration des données.
Dans certains cas limités, vous pouvez utiliser des outils, IBM Rational XDE ou Rose par exemple, pour procéder à une
ingénierie inverse sur des éléments du code existant vers le langage UML. Mais n'utilisez jamais les résultats
aveuglément : une interprétation humaine est toujours nécessaire.
Déploiement
Selon la portée de l'évolution, le déploiement du nouveau système peut constituer un défi plus complexe que le
développement d'un nouveau projet. Si vous avez migré le système vers une nouvelle architecture ou redéveloppé de
grandes parties de celui-ci, vous devez choisir une stratégie : passer de l'ancien système au nouveau du jour au
lendemain ou utiliser une stratégie par phases et effectuer la transition par petites étapes incrémentielles. Les deux
systèmes peuvent fonctionner en parallèle jusqu'à ce que le nouveau système soit totalement fiable. En pratique, le
déploiement est souvent beaucoup plus délicat avec un système en vigueur qu'avec une nouvelle application, car vous
devez régler des problèmes de conversion et de migration des données, de continuité des opérations, de reformation du
personnel, etc. Cette stratégie de développement peut être décrite dans le plan
de déploiement.
Autres disciplines
D'autres disciplines de développement d'application, ainsi que leurs tâches, instructions, techniques et outils,
s'appliquent également, le test et l'implémentation par exemple. La gestion de configuration peut être plus pertinente
et requise de façon plus précoce dans le projet que s'il s'agissait d'un nouveau développement, car vous démarrez dès
le début avec de nombreux produits existants, ayant parfois des dépendances complexes les uns avec les autres. Dans le
cadre d'une mise à niveau d'un système en vigueur, la gestion des modifications devient une activité prépondérante.
Souvent, redévelopper un système en vigueur offre l'opportunité de remanier les processus métier, en utilisant la
modélisation métier, ce qui peut permettre d'obtenir un ensemble d'exigences différent pour le nouveau système.
Un projet d'évolution de systèmes en vigueur suit le même cycle de phases que tous les autres projets du processus RUP.
Les objectifs de ces phases sont essentiellement les mêmes. Les sections suivantes décrivent cependant certaines
spécificités des projets d'évolution de systèmes en vigueur.
Phase de création
La phase de création du processus RUP définit la création d'un document de vision, d'une étude de rentabilité ainsi que
d'un cas de développement, indiquant les produits que vous devez recréer. Dans cette phase, vous devez également lancer
le processus d'ingénierie inverse pour certains des produits, principalement les exigences et l'architecture, de façon
à pouvoir choisir la stratégie d'évolution appropriée et estimer son coût.
Phase d'élaboration
Dans cette phase, vous devez achever votre version de référence du processus RUP, c'est-à-dire l'ensemble minimal de
produits dont vous avez besoin pour évoluer, y compris la conversion de certains anciens produits vers le nouvel
ensemble d'outils. Pour de simples extensions, une seule courte itération suffit. Mais si de nombreux changements
architecturaux doivent être effectués, dans le cas d'une stratégie de migration ou d'un redéveloppement par exemple,
plusieurs itérations seront nécessaires dans cette phase d'élaboration pour implémenter une nouvelle version
architecturale de référence. Il est même possible que cette phase d'élaboration soit la phase prédominante et que les
phases de constructions et de transition ne nécessitent que peu de travail. Le test est mis en place dans le nouvel
environnement et le test de régression peut débuter de façon précoce. Contrairement à la phase d'élaboration du
développement d'un nouveau projet, un grand nombre de produits, principalement du code, doit être géré dès le début, et
les tâches des disciplines de gestion de la configuration et des modifications doivent être accentuées plus tôt.
Phase de construction
Cette phase diffère peu de celle de tout autre projet RUP, excepté le fait que la plus grosse partie du travail
implique l'interfaçage ou le retravail de code existant au lieu du développement de nouveau code. Les éléments
supplémentaires subissent une ingénierie inverse et une reconception, et sont documenté le cas échéant.
Phase de transition
La phase de transition peut être plus délicate, selon la stratégie de déploiement choisie pour passer de l'ancien
système au nouveau. Reportez-vous à la section relative au déploiement
ci-dessus.
L'approche itérative du processus RUP est particulièrement utile pour transférer les évolutions de systèmes en vigueur,
ainsi que leurs objectifs concrets et mesurables pour chaque itération. Joe Marasco, responsable du projet Rational
Apex a déclaré :
"Nous avons décidé quelles parties de la fonctionnalité devaient être transférées en premier, quelles parties
devaient être transférées sans aucune modification et quelles parties seront transférées au cours d'itérations
ultérieures. La version sous le système d'exploitation Sun a été reportée à une itération ultérieure, une fois la
version sous AIX stable. Au lieu de voir le papillon sortir de son cocon un jour, vous planifiez sa métamorphose et
suivez son évolution itération par itération. Je ne peux pas envisager la gestion de l'évolution d'un système en
vigueur complexe d'une autre façon."
Comment appliquer le processus RUP à un système en vigueur ?
-
Vous devez tout d'abord comprendre ce que vous tentez de faire.
-
Vous devez ensuite exploiter de façon intelligente ce dont vous disposez déjà.
-
Enfin, vous devez vous concentrer sur les principes et non pas sur les détails du processus RUP.
De grandes parties du processus RUP peuvent être utilisées pour l'évolution d'un système en vigueur, en nécessitant
plus ou moins de personnalisation et de formalité, selon le type d'évolution envisagée et la quantité d'informations
relatives au système dont vous disposez.
Dans la mesure où il s'agit d'un système en vigueur, vous n'avez aucune raison de ne pas disposer d'un document de
vision décrivant les objectifs à atteindre, d'un plan de projet indiquant les jalons principaux et vos objectifs,
éventuellement d'itérations et leurs objectifs spécifiques ainsi que d'une liste de
risques. Vous avez également besoin d'une étude de rentabilité pour pouvoir débattre des avantages de l'exécution
du projet et de l'approche à prendre.
Des produits RUP supplémentaires peuvent également être développés en procédant à une extraction ou une ingénierie
inverse sur le système en vigueur. Procédez cependant de façon judicieuse car il est souvent plus rentable de continuer
à utiliser et référencer une documentation existante que de la convertir au format RUP.
Soyez cependant prudents car il arrive que des projets échouent lorsque de trop nombreuses tentatives de modifications
sont effectuées simultanément : évolution majeure d'un système en vigueur (migration vers une nouvelle plateforme par
exemple) en même temps qu'un changement de processus (évolution vers RUP par exemple) et un changement d'ensemble
d'outils (adoption de Rational Suite par exemple). Il est préférable d'introduire un nouveau processus et de nouveaux
outils lors d'un projet précédent avant d'entreprendre une évolution majeure de système en vigueur, afin que les
développeurs se familiarisent avec le processus RUP, sa philosophie, son contenu et les outils qui l'accompagnent.
Evitez de multiplier les risques pour le projet en introduisant de trop nombreux changements et inconnues
simultanément.
-
Michael Brodie et Michael Stonebraker, Migrating Legacy Systems, San
Francisco : Morgan Kaufmann Publishing, 1995.
|