Ré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 suit[2] : « 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 logicielle[3]. 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 logicielle[note 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 logicielle[4].

La réingénierie logicielle fait partie du domaine de la maintenance logicielle[5]. 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 corps[7].

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 documentation[8]. 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 indisponible[8].

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

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 SOA[10].

Les exploitants du logiciel

L'utilisateur de l'application se rattache quant à lui à l'équipe des exploitants du logiciel[11].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.

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.

La réingénierie logicielle s'appuie sur une multitude de processus[6].

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'application[1].

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 restructuring[1].

Redocumentation

C'est la modification des informations contenues dans le code et des documents spécifiques au logiciel[12].

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 logicielle[13].

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.

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'exploitation[14].

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 plates-formes. Elle peut aussi s'extraire d'une ancienne logique commerciale associant le matériel et le logiciel, qui s'avère pesante et couteuse[15].

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 diminue[16].

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 à maintenir[17].

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 efficiente[14].

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 à effectuer[11].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 logicielle[18].

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 phases[19]

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 reconstruction[20].

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 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 logiciel[11].

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és[21] - [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ée[11].

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 complexes[22] - [23]. Ils doivent apprendre la théorie et la pratique de la maintenance logicielle, mais aussi appréhender et comprendre de vieux programmes en exploitation[22].

La réingénierie, en 2006 est encore presque ignorée[22]. 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és[24].

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 acquisition[27]. 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és[28].

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écessaires[30].

La gestion des ressources humaines 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 processus[7]. 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ébut[29]. Il est essentiel que chaque contributeur participe à toutes les étapes de l'opération[11]. 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].

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 inexploitable[31].

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.

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 manuellement[33].

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 original[34]. 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ées 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 longue[7].