Tuesday, June 19, 2018

Réingénierie logicielle



https://fr.wikipedia.org/wiki/R%C3%A9ing%C3%A9nierie_logicielle

La réingénierie logicielle (RL) ou Software reengineering est un processus qui a pour objectif la transformation et l’amélioration d’un logiciel à partir du modèle existant. Le logiciel en question ne doit pas subir de régression au niveau fonctionnel mais doit gagner en performance et en évolutivité. L’obsolescence logicielle est rapide dans un secteur en évolution permanente et augmente le coût de la maintenance. Il y a pénurie des compétences pour ce qui concerne les plus vieux logiciels. Ces anciennes applications ne sont pas adaptées au changement de technologie et perdent de ce fait de leur performance.
La réingénierie logicielle se fait en plusieurs étapes successives.
La première est la rétroingénierie, processus qui permet l’analyse d’un programme afin d’identifier ses composants et leurs interrelations. Cette étape inclut la recherche de la documentation pour améliorer la compréhension du logiciel. Cette phase d’inventaire est utile à la création d’une représentation du logiciel sous une autre forme ou à un niveau d’abstraction plus élevé. Elle permet de reconnaitre les éléments à conserver de ceux qui doivent être écartés ou remodélisés.
La seconde est le processus d’ingénierie de reconstruction. Ce processus englobe des sous domaines très utilisés que sont la re-documentation, la restructuration du code et des données et la recomposition du logiciel. Elle se termine par un ensemble de tests pour valider la nouvelle solution et permettre sa standardisation.
Cette réorganisation logicielle comporte de multiples risques comme l’implication humaine, l’existence ou non d’une documentation, la complexité logicielle, sa durée ou le couple performance – évolutivité. Il convient de mesurer au plus près ce danger avant de commencer la réingénierie logicielle.

Cadre de la réingénierie logicielle (RL)

Définitions de la réingénierie logicielle

Les différentes phases de la Rréingénierie logicielle
Les différentes phases de la réingénierie logicielle
La réingénierie logicielle est l'étude et la modification d'un système logiciel en vue de le recréer sous une nouvelle forme. Elle n'altère pas obligatoirement les fonctionnalités du logiciel mais elle peut éventuellement en créer de nouvelles. Elle se nomme aussi « rénovation logicielle » voir « réhabilitation logicielle »1.
Le SWEBOK, document de base à la normalisation en ingénierie du logiciel, la définit comme suit2 : « c'est l'analyse et la transformation d'un logiciel en vue de le recréer sous une nouvelle forme en incluant l'implémentation de cette nouvelle forme »note 1.
La norme ISO/IEC/IEEE 24765:2010(E) Ingénierie des systèmes et du logiciel — Vocabulaire, de l'IEEE, définit aussi la réingénierie logicielle3. Ce document regroupe les termes couramment utilisés dans les technologies de l'information et en donne une définition comme étant : le cycle complet de l'exécution de la Rétroingénierie et de la reconstruction logiciellenote 2.
La réingénierie logicielle est plus globalement un processus qui assure la transformation d'un logiciel. Elle enchaîne d'autres processus plus basiques dont elle utilise les outils associés. Elle les organise et les enchaîne séquentiellement. Les deux processus basiques les plus rencontrés sont la Rétroingénierie et la reconstruction logicielle4.

Domaines d’application

La réingénierie logicielle fait partie du domaine de la maintenance logicielle5. C'est un processus de transformation utilisé pour l'analyse des besoins (définition des spécifications des problèmes, des objectifs, des contraintes...), le design (spécification des solutions) et l’implémentation logicielle (codage, réécriture, tests ...) 6. Mais un logiciel n'est pas seulement du code sur lequel la réflexion et l'intervention va porter. C'est aussi de la documentation, des représentations graphiques se rapportant au cahier des charges (aux spécifications), des données de tests, de validation et tout un ensemble de documentations et d'informations qui composent le logiciel lui-même et lui donne du corps7.
En s’appliquant au logiciel, la réingénierie logicielle s’applique aussi à tout son environnement. Elle assure non seulement la maintenabilité et l'évolutivité technique, mais aussi la création ou la mise à jour complète et illustrée de la documentation8. Souvent négligée, la documentation est très importante pour la réingénierie logicielle. Elle améliore la connaissance du logiciel, de ses fonctions et ainsi une meilleure compréhension de son code. C'est un véritable défi que d'assurer une réingénierie logicielle avec une documentation fréquemment obsolète, incomplète, voire indisponible8.

Différents acteurs

Trois groupes principaux d'acteurs sont identifiés. Leur engagement dans le processus de la réingénierie logicielle est essentiel9.

L'équipe experte de la réingénierie logicielle
Elle représente le cœur du projet. Elle se compose principalement d'intervenants comme le pilote de projet informatique, l'analyste, l'Architecte informatique, le développeur, le spécialiste en sécurité, l'administrateur système, l'administrateur de base de données, l'intégrateur d'application.
Mais de nouveaux métiers avec de nouveaux noms voient le jour. Les architectes Service Orienté Architecture, les concepteurs de modèle, les concepteurs de service, les concepteurs de processus, les développeur de service, les spécialistes d'intégration, les testeurs d'interopérabilité, les pilotes de projet SOA, les administrateurs système SOA10.

Les exploitants du logiciel
L'utilisateur de l'application se rattache quant à lui à l'équipe des exploitants du logiciel11.La réussite du projet de réingénierie est en grande partie attachée à l'acceptation qu'ils ont de la transformation de l'application qu'ils utilisent.
Les exploitants du logiciel mais extérieurs à la structure ou la RL va s'effectuer
Ils assurent une bonne objectivité quant aux évolutions choisies.

Processus utilisés

On trouve dans la littérature, essentiellement anglaise, plusieurs termes proches qui n'ont pas la même signification mais qui gravitent autour du sujet. On peut confondre leurs noms mais ils ont chacun un objectif différent. Ce sont des processus qui ont une fonction bien précise et des outils qui leur sont associés. Ces termes sont souvent cités dans le processus de réingénierie logicielle car ils y sont organisés et enchainés de manière cohérente.
Schéma des principaux processus utilisés en réingénierie logicielle.
Schéma des principaux processus utilisés en réingénierie logicielle.
La réingénierie logicielle s'appuie sur une multitude de processus6.

Forward engineering
Recomposition. Processus qui permet la conception physique d'un système informatique à partir de sa définition logique (le plus haut niveau d'abstraction)6.

Reverse engineering
Rétroingénierie. Activité qui consiste à étudier un objet pour en déterminer le fonctionnement interne ou la méthode de fabrication.

Design recovery
C'est un sous-ensemble du Reverse engineering. Il permet de comprendre la fonction d'un programme grâce à l'interprétation de code et de documentation de l'application1.

Restructuring
C'est la transformation d'un logiciel en un autre logiciel avec pour objectif de préserver son comportement externe sur les fonctionnalités et la sémantique. Le nom de transformation code-to-code est aussi employé pour décrire le restructuring1.

Redocumentation
C'est la modification des informations contenues dans le code et des documents spécifiques au logiciel12.
Le software measurement, le browsing, le cross referencing, le object recovery, la remodularization peuvent être utilisés dans une démarche de réingénierie logicielle13.

Software measurement
Activité qui cherche à représenter les caractéristiques d’un système logiciel par des valeurs numériques. Chaque métrique s’associe une caractéristique du logiciel.
Browsing
Permet de comprendre les interconnexions d’une partie d’un système et de ses différentes vues. On peut déterminer les chemins d’accès des objets du système.
Cross referencing
Cherche à découvrir les relations entre les différents composants d'un système logiciel.
Object recovery
Sert à la transformation d’un système basé sur du code procédural en un système orienté objet. L’objectif est de créer des objets au sens programmation, à partir de morceaux de code procédural.
Remodularisation
Tente de changer la structure d'un système selon des critères communs. Cette technologie s’appuie principalement sur une analyse typologique du système.

Démarches et mise en œuvre de la réingénierie logicielle

Intérêt de la réingénierie logicielle

La mise à niveau du parc logiciel fait partie de l'évolution de l'entreprise. Les logiciels les plus anciens sont les premiers concernés par une évolution. C'est la lutte contre l'obsolescence logicielle dont l'objectif est d'améliorer les performances générale du logiciel mais aussi augmenter la fiabilité de l'application concernée et de réduire ses coûts d'exploitation14.
La lutte contre l'obsolescence logicielle permet aussi d'atteindre un autre objectif : La libération du code de l'application des contraintes propriétaires. L'entreprise peut différencier le matériel du logiciel et ainsi assurer la portabilité de son logiciel vers d'autres plate-formes. Elle peut aussi s'extraire d'une ancienne logique commerciale associant le matériel et le logiciel, qui s'avère pesante et couteuse15.
Les programmes éligibles ont un socle commun qui est souvent leur ancienneté technologique, logicielle ou matérielle. Le coût de maintenance est élevé, certaines fonctionnalités sont obsolètes, le support matériel est dépassé. Il en résulte un coût global élevé. La réingénierie logicielle est moins couteuse et plus sécurisante qu'un nouveau développement complet d'application. Ce coût et cette sécurité évoluent en fonction de l'importance de la réingénierie effectuée. Plus le code est modifié en quantité, plus le coût augmente et inversement pour la sécurité dont le niveau diminue16.
Le choix de faire de la réingénierie logicielle est parfois inévitable car certaines applications ont souvent une valeur « interne » au sein de l'entreprise, qui les rend indispensables. L'objectif suivi est d'améliorer la maintenabilité du logiciel, c'est-à-dire l'effort à fournir en vue de le corriger ou de le transformer. L'objectif est d'assurer une migration des logiciels anciens vers de nouveaux matériels plus performants et de nouvelles technologies de programmation plus modulables et plus aisées à maintenir17.
Mais la réingénierie logicielle ne s'applique pas qu'aux « vieux » logiciels. Ce processus s'applique à tous les logiciels qui participent à la flexibilité des entreprises. Dans un environnement économique très actif, une entreprise doit se concentrer sur les clients et les marchés. Une société doit sans cesse tester sa faculté d'adaptation au changement. Pour être efficace et rentable elle doit pouvoir changer ses exigences opérationnelles. Elle doit être capable d'implémenter de nouvelles fonctionnalités dans son système d'information de manière efficientes14.

Mises en œuvre

Il n'existe pas une mise en œuvre unique mais plusieurs. Le principe consiste à enchaîner des processus et d'assurer leur cohérence, en fonction des besoins et de l'importance du projet de réingénierie logicielle. Le champ de domaine de la réingéniérie logicielle est vaste. Il convient de situer et d'analyser chaque contexte de solution, ce qui se fait par l'établissement d'une classification des démarches à effectuer11.La réingéniérie logicielle implique un mixage entre les principes et les techniques de génie logiciel. Il faut faire du cas par cas pour chaque solution de réingénierie logicielle18.
En amont de la phase de réingénierie logicielle proprement dite, il est nécessaire de situer et d'analyser chaque contexte dans lequel le processus s’inscrit. Il faut évaluer la faisabilité et les bénéfices de l’opération. En premier lieu il faut décrire l'environnement dans lequel le processus va s’inscrire. Cela veut dire comprendre l'organisation logicielle, l’architecture matérielle et connaitre les composants techniques associés. Puis il convient d'effectuer un inventaire. Celui-ci va identifier tous les composants et donner leurs caractéristiques. À ce moment précis, la phase d’analyse peut commencer. Elle va évaluer le potentiel de chaque composant et leur pertinence. Enfin, la dernière phase avant la décision de rentrer dans un processus de réingénierie logicielle, est l’évaluation des coûts et des risques encourus. La méthode de L'OAR note 3 reprend toutes ces phases19
Modèle général pour la réingénierie logicielle
Modèle général pour la réingénierie logicielle
Le processus de réingénierie s'organise autour de deux grands groupes de processus. D'un côté, l'ingénierie inverse et de l'autre l'ingénierie de reconstruction20.
La phase d'ingénierie inverse du logiciel englobe l'analyse du logiciel, de ses composants et de leurs interrelations, l'analyse des risques et la recherche de la documentation. Elle permet la mesure de sa complexité et de sa qualité au niveau logique, physique et conceptuel. Il en ressort une meilleure compréhension du programme au niveau du code et de sa documentation. Cette étape est importante car elle permet de pouvoir convertir le logiciel originel sans en modifier sa/ses fonctionnalité(s)initiale(s). Il est ainsi créé une représentation du programme à un niveau plus haut d'abstraction ce qui facilite la phase suivante qui va permettre l'altération du logiciel11.
La seconde phase est l'ingénierie de reconstruction. C'est la réorganisation du logiciel, la réécriture de l’application et de sa documentation. Elle permet la reconstitution sous une nouvelle forme du logiciel avec ses nouvelles fonctionnalités21,1.
Elle commence par l’amélioration fonctionnelle par ajout de nouveaux composants, mais aussi par modification de ceux existants. Il est pour cela nécessaire de récupérer la structure, ce qui permet de recouvrir les informations logicielles (spécifications) et conceptuelles (objectifs, contraintes, etc.).
Cette étape consiste aussi à effectuer une analyse d’impact qui doit permettre une évaluation des changements apportés et des efforts à fournir pour se rapprocher des nouveaux standards, comme la norme ISO 9000-3. Après des tests et si ceux-ci confirment l’amélioration logicielle, la migration technologique du logiciel est effectuée11.

Formation

Les programmes d'études fournissant les formations nécessaires dans le domaine de la réingéniérie sont insuffisants. La plupart du temps, les personnes sont formées à la création de nouveaux programmes ou à leur développement s'ils sont récents. Ils n'apprennent pas comment comprendre et améliorer des logiciels existants ou complexes22,23. Ils doivent apprendre la théorie et la pratique de la maintenance logicielle, mais aussi appréhender et comprendre de vieux programmes en exploitation22.
La réingénierie, en 2006 est encore presque ignorée22. Mohammad El-Ramly, indique qu'il ne trouva aucun manuel sur la réingénierie logicielle pour préparer ses cours. Il dût les construire à partir d'éléments comme des articles sur les systèmes, sur les logiciels ou encore dans les documents associés24.

Facteurs de risques

Si la réingénierie logicielle est un outil puissant de transformation d’un logiciel, il n’en est pas moins risqué dans son utilisation. Son efficacité peut être très variable. Le processus rassemble beaucoup d’autres processus et de notions qui sont autant de facteurs de risques potentiels. Il convient de faire une analyse des dangers du processus pour un logiciel donné. Les points de vigilance se structurent autour de la satisfaction utilisateur, les coûts de la réingénierie logicielle, de l'ingénierie inverse, de la reconstruction logicielle, des performances du logiciel et de sa maintenance. Il faut les identifier et évaluer leur degré d’importance25. Pour cela, il faut évaluer un taux d'exposition au risque en fonction des pertes et de leurs occurrences. Ainsi un facteur de risque est calculé, fonction du taux d'exposition et du coût estimé26.

Aspects économiques

Financièrement la réingénierie logicielle est dans la plupart des cas moins coûteuse qu'une réécriture complète d'un code ou qu'une une nouvelle acquisition27. Mais avant de prendre une décision, il est nécessaire de connaître précisément les gains attendus. Chaque projet doit mettre en lumière les gains amenés par la réingénierie logicielle. Ils sont fonction des bénéfices apportés, des coûts mis en œuvre et des facteurs de risques identifiés28.
Les facteurs risques de la réingénierie logicielle
Les facteurs de risques de la réingénierie logicielle
La réingénierie logicielle se situe entre deux versions logicielles, celle du logiciel initial et celui dans son état final ou cible. Il y a une crainte de perdre du chiffre d'affaires au cours de cette période 29. Après la modification, le système testé et le système à remplacer doivent fonctionner en parallèle. Cette période peut augmenter les coûts car beaucoup de ressources et de main-d'œuvre peuvent être nécessaires30.

Aspects sociaux

La gestion des ressources humaine se révèle difficile car le changement de métier peut être important. Les personnes impliquées par le processus peuvent nourrir beaucoup d’appréhensions face à ce bouleversement. Une réticence au changement peut naître. Il est essentiel d'estimer les barrières psychologiques et émotionnelles et de les gérer soigneusement tout au long du processus7. La communication et la confiance sont des éléments primordiaux pour atteindre un succès de réingénierie. Si les salariés de l'entreprise, directement impliqués avec le processus, estiment qu'il y a un ordre du jour caché ou que l'on cache une réduction d'effectifs, le projet sera condamné dès le début29. Il est essentiel que chaque contributeur participe à toutes les étapes de l'opération11. Les utilisateurs ne valideront pas le nouveau système proposé s'ils n’ont pas été impliqués dans le processus et si leurs besoins n'ont pas été pris en compte. La conséquence en serait un nouvel outil non adapté31.

Aspects techniques

Pour la migration d'un ancien système, le problème essentiel provient de l’adhérence du langage de programmation à l'architecture matérielle. Le changement de plate-forme ou de langage utilisé peut amener une baisse de performance du logiciel final 32.
Il est aussi essentiel que les fonctionnalités du « nouveau logiciel » soient suffisamment bien définies et puissent être testées. Car le manque de tests sur les accès aux données ou des choix architecturaux mal précisés peuvent augmenter des délais de réponse de l'application et la rendre inexploitable31.
La réécriture de code est aussi un facteur à risque. Il n'est pas aisé de re-coder des fonctionnalités dans une nouvelle architecture surtout quand l'adhérence entre le matériel et le logiciel est forte. Le taux de changement du logiciel est évalué en fonction du taux de réécriture de code. Il s'avère que plus le taux de changement est élevé plus le coût et les risques augmentent.
Facteur de risque pour la réécriture du code26
Désignation Taux de réécriture de code Coûts et risques
Encapsulation 20 % faibles
Rénovation 20 % à 50 % moyens
Migration 50 % à 100 % importants

Exemples

AS-400 COBOL
Migration d'un système AS-400 cobol vers un système portable en java. Cette migration montre qu'il n'est pas possible de convertir tout le code cobol en code java car la programmation initiale est très liée au matériel. Il en résulte que 60 % de code a pu être transformé. Les 40 % restants devront être ré-encodés manuellement33.
Le logiciel de l'Air Force
Expérience de réingénierie sur un logiciel de modélisation électronique pour l'Air Force. La réingénierie logicielle terminée, les concepteurs ont voulu établir une confirmation formelle que le logiciel recréé était vraiment plus recevable que le logiciel original34. Les tests sur le logiciel en question montrent une augmentation de la maintenabilité35.
Le cas de la Base de données hiérarchique
Dans ce cas, la réingénierie logicielle s'applique sur une Base de données hiérarchique et débouche en fin de processus sur une Base de données relationnelle, type de base de donnée plus récente et plus performante. Les changements sont importants. Très peu de composants initiaux peuvent être ré-utilisés. Il s'agit d'une RL à risque car sa durée est plus longue7.

Pour aller plus loin : le SOSR

Le Service-Oriented Software Reengineering (SOSR) note 4 est une méthodologie de réingénierie logicielle qui implémente le concept d'Architecture orientée services pour assurer la réorganisation d'ancien système informatique. C'est la réingénierie logicielle vue comme un service 36. Elle ajoute à toutes les notions de web-service, la notion de responsabilité des participants et la définition de leur rôle. la méthodologie SOSR consiste à appliquer, à chaque étape de la réingénierie logicielle, un nombre de concepts définis et d'identifier les rôles précis de chaque participants10. SOSR s'appuie sur les concepts suivants :
Le socle de connaissance du SOSR n'est pas assez stable car le nombre d'applications étudiées est encore faible. Il doit se développer37.

No comments:

Post a Comment