Experience N 52. Les expériences d ERNI dans l univers du management, des processus et des technologies. Mars 2012

Transcription

1 Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 MIGRATIONS Garder la maîtrise lors de migrations

2 GARdER la maîtrise LORS de migrations Lors de migrations de systèmes et de données, l ingénierie des exigences joue un rôle déterminant. Les projets de migration sont complexes et risqués. L ingénierie des exigences soutient la réalisation sur tout le déroulement du projet: cela commence par le reverse engineering généralement nécessaire, en passant par l analyse des exigences actuelles et nouvelles jusqu à la planification de la migration et l élaboration des cas de test. par Peter Zuber ET Ugo Bonanni Les migrations font aujourd hui partie du quotidien des entreprises. La migration d un système vers l état actuel de la technique réduit les coûts, augmente la disponibilité du système ainsi que la sécurité des données et permet à l entreprise de continuer à se développer. En bref, les migrations renforcent l aptitude à la compétitivité. En revanche, les anciens systèmes sont limités quant à leur accroissement et au développement linéaire de leur capacité. A cela s ajoute un entretien coûteux et l exploitation de matériel partiellement obsolète. Dans le cas de systèmes dépassés mais toujours en usage, les manuels des applications sont généralement incomplets et le savoir-faire pour autant qu il soit toujours présent est souvent concentré en quelques collaborateurs. Une grande attention et de nombreuses ressources sont ainsi consacrées aux adaptations et aux modifications. Cela s avère nécessaire non seulement en raison de leur importance cruciale, mais aussi parce que les projets de migration sont complexes et peuvent même mettre en danger l entreprise lorsqu ils touchent au système central. Comme pour tous les projets complexes de grande importance, le requirements engineering est aussi déterminant lors de migrations. Cela est d autant plus vrai lorsque la nouvelle version du logiciel est développée auprès d un partenaire d outsourcing en Asie ou en Europe de l Est. Le recensement et l analyse systématiques des exigences garantit que le produit final prenne en charge les processus commerciaux de la façon souhaitée. En renonçant entièrement à ces étapes, on court le risque de ne découvrir les divergences que lors des tests d approbation, ce qui engendre inévitablement des retards et des adaptations coûteuses. Il convient en tous les cas de ne pas saisir seulement les nouvelles exigences qui doivent être intégrées dans le développement, mais aussi celles qui sont remplies par les applications existantes. C est pourquoi la première étape consiste généralement en un reverse engineering. Exemple 1 Reverse engineering d une application centrale Une grande entreprise de services exploite pour son back-office une application centrale développée à l interne. Celle-ci saisit de grandes quantités de données, les traite à l aide de business rules bien définies et transmet les résultats à des clients internes dans l entre-

3 MIGrationS Comme pour tous les projets complexes de grande importance, le requirements engineering est aussi déterminant lors de migrations. Cela est d autant plus vrai lorsque la nouvelle version du logiciel est développée auprès d un partenaire d outsourcing en Asie ou en Europe de l Est. Le recensement et l analyse systématiques des exigences garantit que le produit final prenne en charge les processus commerciaux de la façon souhaitée. En renonçant entièrement à ces étapes, on court le risque de ne découvrir les divergences que lors des tests d approbation, ce qui engendre inévitablement des retards et des adaptations coûteuses.

4 Le reverse engineering inclut des ateliers réunissant toutes les personnes impliquées dans un projet, qui sont ellesmêmes en contact avec les utilisateurs. Une source d information particulièrement importante se trouve par ailleurs auprès des collaborateurs travaillant à la maintenance de l application et disposant ainsi d une grande somme de savoir implicite. Afin de faciliter la communication, le requirements engineer devrait assez tôt établir un glossaire pour garantir que tous les collaborateurs impliqués se servent des mêmes termes. Application Application Ancien Nouveau Migration système 1:1 Données? 1:0 0:1? Données Ill. 1: Migration de données en recourant au requirements engineering 1:n n:1

5 MIGrationS prise. Cette application doit être développée en une nouvelle version. Dans une première étape, la solution existante est analysée au moyen d un reverse engineering. Au total, 80 business rules sont identifiées, deux interfaces inconnues sont trouvées dans l environnement informatique et les processus commerciaux sont consignés pour la première fois. Cet exemple illustre parfaitement à quel point le savoir explicite concernant les applications existantes est peu tangible dans les organisations. Souvent, des documents existent, mais ils ne correspondent généralement pas à l état actuel. Après quelques années déjà, les changements et les business rules introduites ultérieurement ont tellement modifié l application que les anciens documents sont très peu pertinents pour décrire son état actuel. Pour les migrations, il est donc généralement impossible de se baser sur les exigences qui ont été retenues des années auparavant lors du développement d une application. Bien que le reverse engineering engendre une charge de travail relativement importante, il est cependant recommandé dans de très nombreux cas. Il devrait en tout cas être effectué lors de la migration d une application centrale. Exemple 2 Reverse engineering après une modification des conditions légales Le cadre légal est modifié pour une entreprise du secteur des assurances. Cette modification concerne le traitement des prestations et donc le système central. L entreprise tente d abord de procéder à l adaptation nécessaire par l introduction d une nouvelle business rule. Cela génère cependant des réactions en chaînes. Pour remédier au problème, un requirements engineer expérimenté procède à un reverse engineering. Cette mesure permet finalement de mettre en place la modification avec succès. Le reverse engineering inclut des ateliers réunissant toutes les personnes impliquées dans un projet, qui sont ellesmêmes en contact avec les utilisateurs. Une source d information particulièrement importante se trouve par ailleurs auprès des collaborateurs travaillant à la maintenance de l application et disposant ainsi d une grande somme de savoir

6 Lors de migrations, le rôle du requirements engineer ne se limite pas au recensement et à l analyse des exigences. Il fonctionne plutôt comme responsable partiel de projet. Cela illustre une fois de plus la grande importance du requirements engineer dans les projets de migration. Lorsque l on maîtrise cette discipline, on met toutes les chances de son côté pour réussir le déroulement d un projet complexe de migration.

7 MIGrationS implicite. Afin de faciliter la communication, le requirements engineer devrait assez tôt établir un glossaire pour garantir que tous les collaborateurs impliqués se servent des mêmes termes. Dans cette première phase se révèle déjà le profil global auquel doit correspondre le requirements engineer pour les migrations. Cette tâche nécessite en premier lieu d excellentes capacités de communication, car les collaborateurs familiers des applications utilisées n ont souvent que peu de motivation à partager leur savoir. Les compétences de l ingénieur doivent en outre lui permettre de comprendre l application autant du point de vue commercial que sur le plan technique. Il doit aussi se confronter à des détails, comme par exemple dans le domaine de la migration des données, et trouver des solutions aux problèmes en collaboration avec les membres compétents d une équipe. Exemple 3 Résolution de problèmes lors d une migration de données Le système obsolète d une grande entreprise de services ne correspond plus aux directives internes sur la technologie et la sécurité. Il doit donc être remplacé. L objectif est de se baser à l avenir sur une solution qui est déjà employée par d autres utilisateurs dans des buts légèrement différents. La migration concerne donc autant l application que les données qu elle contient. En procédant au reverse engineering, le requirements engineer remarque que l application existante et la nouvelle application prévue utilisent des modèles de données différents. A première vue, les résultats des deux applica- tions paraissent semblables. Une analyse détaillée révèle cependant qu elles se basent sur des sources différentes de données, ce qui engendrerait des erreurs critiques lors de l introduction du nouveau système. Cette différence n est pas négligeable, car le résultat doit avoir une pertinence juridique. En collaboration avec le département spécialisé, le requirements engineer développe donc une solution qui garantit que les deux applications parviennent au même résultat à partir des mêmes prémisses. Cet exemple illustre un problème typique de la migration de données: une différence de cardinalité entre les éléments d une ancienne et d une nouvelle base de données. Mais il révèle un point qui n est pas seulement important en lien avec la migration des données. De manière générale, les migrations représentent un défi en ce qu elles doivent unir le nouveau à l ancien. Cela vaut aussi pour les exigences. Somme toute, l application existante ne doit pas simplement être remplacée, mais aussi améliorée. Il convient notamment de vérifier la cohérence de toutes les exigences. Le comportement du nouveau système pourra parfois se différencier notablement de celui de l ancien système. Les étapes suivantes d un projet ne peuvent être lancées que lorsque l ensemble des exigences constitue une unité cohérente et entière. Ce n est que sur cette base que les cas de test peuvent être élaborés et que le développement de la nouvelle application peut commencer. C est pour ces raisons que le requirements engineer devrait être impliqué dès la décision initiale. Le savoir accumulé par le requirements engineer sur l application existante est en outre important pour la planification de la migration elle-même. Parmi les variantes possibles de migrations (big bang, exploitation parallèle ou remplacement échelonné), la troisième est souvent choisie parce qu elle réduit les risques. Pour un remplacement par étapes, il est toutefois nécessaire de tenir compte des dépendances de la nouvelle application à l environnement informatique. Lors de migrations, le rôle du requirements engineer ne se limite pas au recensement et à l analyse des exigences. Il fonctionne plutôt comme responsable partiel de projet. Cela illustre une fois de plus la grande importance du requirements engineer dans les projets de migration. Lorsque l on maîtrise cette discipline, on met toutes les chances de son côté pour réussir le déroulement d un projet complexe de migration. ERNI Innovation in process and technology Peter Zuber Activité de conseiller: amélioration des processus, activités commerciales et informatiques Ugo Bonanni Activité de conseiller: ingénierie des exigences, gestion de projets

8 enables & delivers