Comme indiqué dans le Concept : Evolution du système en vigueur, lorsqu'il est question de systèmes en
vigueur, on suppose que :
-
Le système est volumineux et ancien.
-
Le développement original du système n'a pas été effectué avec le processus RUP.
Ce dernier point signifie généralement que les produits, lorsqu'ils existent, ne portent pas les noms RUP habituels ou
n'ont pas la forme à laquelle on pourrait s'attendre dans RUP. La plupart du temps, ils sont manquants, obsolète ou
tellement anciens qu'il est impossible qu'ils soient toujours pertinents pour le système. On peut penser que d'autres
techniques ont été utilisées : la conception n'a pas été effectuée avec une technologie orientée objet, les exigences
ne faisaient pas appel aux cas d'utilisation, etc.
On peut également penser que le système en vigueur représente un actif significatif (un "existant") qu'il est important
de réutiliser, sous une forme ou une autre, au lieu de tout retravailler. La valeur de l'actif existant doit donc être
déterminée : s'agit-il du code ? De la conception ? Des exigences ? De certains algorithmes ou de certaines données ?
Ou bien tout simplement de la part de marché que le produit représente ? Malheureusement, plus le système est ancien,
plus il est difficile d'appréhender et d'utiliser les actifs existants. La documentation du logiciel est le plus
souvent obsolète et la conception nécessite une ingénierie inverse (c'est-à-dire une "récupération de la conception"),
la plupart du temps à partir du code lui-même.
Devoir composer avec un système en vigueur est souvent considéré comme un point négatif, mais l'existence d'un système
"précédent" permettant t'établir un point de comparaison et pouvant servir de source d'informations est en fait très
utile. La définition et la conception de systèmes sans précédent sont souvent plus difficiles et risquées.
En particulier, votre système en vigueur vous permet d'identifier facilement les éléments suivants :
-
Exigences et règles métier
-
Eléments ayant une importance architecturale
-
Cas d'utilisation principaux
-
Priorités, souhaits et comportements des utilisateurs
Le seul danger est que le système en vigueur devienne un frein et gêne l'examen et l'étude de nouvelles approches.
Une fois votre système en vigueur évalué, vous pouvez définir une approche pour son évolution.
Il existe un large éventail de modifications évolutives que vous pouvez entreprendre, de la simple extension de
fonctionnalité à une modification architecturale radicale, en passant par une reconception et réimplémentation totale.
Pour chaque modification, différentes solutions techniques et niveaux de formalité de processus s'appliquent. Voici
quelques exemples d'évolutions de systèmes en vigueur :
Extension
Dans les situations simples, il vous suffit d'ajouter certaines fonctions ou fonctionnalités. Les évolutions, comme les
modifications de normes, l'émergence de besoins métier ou la création de nouvelles fonctions par la concurrence,
nécessitent une évolution adaptée du système en vigueur. Pour de nombreux systèmes en vigueur, plus ceux-ci ont
anciens, plus les évolutions sont difficiles, même lorsqu'il s'agit de simples ajouts. Les effets de l'accumulation
d'extensions pendant des années engendrent une dégradation de l'intégrité de l'architecture du système et une plus
grande difficulté d'extension de ce système.
Modification cosmétique
La plupart du temps, il n'est pas nécessaire de récupérer l'intégralité du système mais uniquement de lui donner une
nouvelle apparence ou peut-être de tirer partie d'une nouvelle technologie d'interface intersystème ou d'interface
utilisateur. Une solution basée sur l'encapsulage de certains composants de votre système afin de leur donner une
nouvelle interface ou de permettre leur réimplémentation peut donner des résultats acceptables avec un développement
réduit. C'est le cas, par exemple, de nombreuses applications devant être rapidement adaptées pour le Web.
Migration
Il est possible que la limite de durée de vie du matériel, du système d'exploitation ou du middleware du système soit
atteinte. Celui-ci repose sur des technologies qui ne sont plus utilisées ou très coûteuses à garder actives. La
solution consiste à migrer le système en vigueur vers une nouvelle plateforme (matérielle ou logicielle) et préserver
ainsi une grande partie du logiciel existant. Par exemple, une application développée pour un environnement DEC VAX VMS
doit être rapidement déployée sur une large gamme de plateformes Unix et Linux. C'était le cas lorsque nous avons migré
l'environnement Rational (comportant deux millions de lignes de code) de notre plateforme propriétaire vers une gamme
de plateformes Unix. C'est pour cela que le produit est aujourd'hui appelé Rational Apex. Si l'extension implique
l'ajout d'un nouveau comportement spécifique au domaine, la migration implique l'adaptation du système en vigueur à une
plateforme de technologie différente. La valeur spécifique au domaine de la migration est moins tangible mais ne pas
effectuer de migration efficace à temps peut avoir de graves conséquences.
Redéveloppement
Si le système en vigueur est vital et qu'il est devenu très difficile à faire évoluer ou impossible à mettre à niveau
ou qu'il repose sur des technologies logicielles ou matérielles obsolètes, il peut être nécessaire de le redévelopper.
Vous devez généralement effectuer ce redéveloppement graduellement car vous ne pouvez pas vous permettre de perdre
votre base client existante. Ce cas s'est présenté pour le système Canadian Automated Air Traffic System (système
canadien du trafic aérien automatisé), qui utilisait un matériel très vieux et un système d'exploitation datant d'il y
a plus de vingt ans. Vous pouvez penser que cette option n'a pas sa place ici, mais même si vous avez l'intention de
reconstruire complètement votre système, il est bon d'exploiter votre système en vigueur pour comprendre les aspects
clés du nouveau système. Vous pouvez en retirer une expérience et des connaissances aussi bien positives que négatives.
Intégration
Dans la mesure où le redéveloppement intégral d'un système en vigueur n'est pas une option financièrement viable pour
de nombreuses entreprises, celles-ci préfèrent souvent développer de nouvelles fonctionnalités en utilisant des
nouvelles technologies et intégrer ces nouvelles applications à leur système en vigueur. Cette approche, appelée
intégration d'applications d'entreprise, leur permet d'accéder à de nouvelles technologies tout en optimisant leurs
actifs existants. Pour plus d'informations sur cette approche, consultez Concept : Intégration d'applications d'entreprise et Technique : Intégration d'applications existantes à des architectures modernes.
"Toutes les évolutions ci-dessus"
Pour finir, certaines circonstances peuvent conduire une entreprise à effectuer successivement une migration, une
modification cosmétique et un redéveloppement ou une intégration. Elle peut devoir déplacer rapidement un système en
vigueur vers une nouvelle plateforme et lui donner une nouvelle apparence pour répondre à une demande du marché, puis
reconcevoir le système et graduellement remplacer l'ancienne base de code, morceau par morceau, en utilisant une
nouvelle technologie (composants logiciels, nouveaux langages et middleware) pour pouvoir évoluer. Il s'agit de
l'approche la plus complexe et la plus risquée, mais cela reste possible.
Par exemple, une entreprise disposant d'une application MIS très volumineuse contenant plusieurs millions de lignes de
code RPG (Report Program Generator) développé sur une plateforme IBM AS/400 devait convertir ce code en code Java est
être capable d'exécuter celui-ci sur le Web ainsi que sur de nombreux systèmes Windows et Unix. L'entreprise a
successivement reconçu et implémenté l'application en Java sur une période de deux à trois ans, sans perturbation
majeure pour les utilisateurs.
Le document Vision doit refléter une approche sensée. Vous ne faites pas évoluer un système en vigueur juste parce
qu'il existe. En général, il raisonnable de conserver les systèmes en vigueur : leur développement ou leur acquisition
représente le plus souvent des coûts irrécupérables et il n'y a la plupart du temps aucune justification pour les
éliminer. En revanche, les ressources utilisées pour conserver un système en vigueur peuvent aussi être consacrées à de
nouvelles opportunités. Si vous constatez que vous vous engagez simplement dans la conservation (vous consacrez des
ressources à un système pour des raisons historiques ou affectives plus que pour des raisons professionnelles
significatives ou parce que vous n'avez pas étudié les autres possibilités), alors il est probablement temps d'examiner
l'étude de rentabilité.
Une bonne étude de rentabilité doit prendre en compte les impacts à court et long terme des différentes possibilités,
de la conservation du système en vigueur tel quel aux différentes options d'évolution. Les recommandations de l'étude
de rentabilité doivent trouver le juste équilibre entre les objectifs métier tactiques à court terme et les objectifs
stratégiques à long terme de l'organisation.
|