Réingénierie 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 reconnaître 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)

[modifier | modifier le code]

Définitions de la réingénierie logicielle

[modifier | modifier le code]
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 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].

Domaines d’application

[modifier | modifier le code]

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].

Différents acteurs

[modifier | modifier le code]

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.

Processus utilisés

[modifier | modifier le code]

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 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.

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

[modifier | modifier le code]

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

[modifier | modifier le code]

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].

Mises en œuvre

[modifier | modifier le code]

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
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].

Formation

[modifier | modifier le code]

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].

Facteurs de risques

[modifier | modifier le code]

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’importance[25]. 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

[modifier | modifier le code]

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

Aspects sociaux

[modifier | modifier le code]

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].

Aspects techniques

[modifier | modifier le code]

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.

Facteur de risque pour la réécriture du code[26]
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

[modifier | modifier le code]
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].

Pour aller plus loin : le SOSR

[modifier | modifier le code]

Le Service-Oriented Software Reengineering (SOSR)[note 4] est une méthode 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éthode 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 participants[10]. 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évelopper[37].

Notes et références

[modifier | modifier le code]

Notes

[modifier | modifier le code]
  1. ↑ Définition anglaise de la réingenierie logicielle contenue dans le SWEBOK : « the examination and alteration of software to reconstitute it in a new form, including the subsequent implementation of the new form. »
  2. ↑ : Définition anglaise de la réingénierie logicielle contenue dans la norme ISO/IEC/IEEE 24765:2010(E) Ingénierie des systèmes et du logiciel — Vocabulaire : « the complete cycle of performing reverse engineering followed by forward engineering. »
  3. ↑ OAR pour options analysis for reegineering qui pourrait être traduit par « options pour l'analyse de la réingénierie »
  4. ↑ SOSR pour Service-Oriented Software Reengineering qui pourrait être traduit par « réingénierie logicielle orientée services »

Références

[modifier | modifier le code]
  1. ↑ a b c et d Chikofsky 1990, p. 15
  2. ↑ swebok 2004, p. 6-9
  3. ↑ IEEE 2010, p. 294
  4. ↑ Phillip 1995, p. 51
  5. ↑ swebok 2004, p. 10-2
  6. ↑ a b et c Chikofsky 1990, p. 14
  7. ↑ a b et c Agarwal 2003, p. 3
  8. ↑ a et b El-Ramly 2002, p. 447
  9. ↑ Agarwal 2003, p. 2
  10. ↑ a et b Chung 2007, p. 2
  11. ↑ a b c d et e Abran 1994, p. 31
  12. ↑ Kullbach 1999, p. 3
  13. ↑ Kullbach 1999, p. 2
  14. ↑ a et b Agarwal 2003, p. 2
  15. ↑ Sneed 2013, p. 231
  16. ↑ Sneed 1999, p. 210
  17. ↑ Jarzabek 1993, p. 100
  18. ↑ Welcker 1994, p. 254
  19. ↑ Smith 2001, p. 728
  20. ↑ Kullbach 1999, p. 1
  21. ↑ El-Ramly 2006, p. 700
  22. ↑ a b et c El-Ramly 2006, p. 699
  23. ↑ Feng 2003, p. 1489
  24. ↑ El-Ramly 2006, p. 701
  25. ↑ Rashid 2013, p. 6
  26. ↑ a et b Sneed 1999, p. 204
  27. ↑ Sneed 2005, p. 119
  28. ↑ Sneed 2005, p. 120
  29. ↑ a et b Agarwal 2003, p. 4
  30. ↑ Rashid 2013, p. 7
  31. ↑ a et b Sneed 1999, p. 7
  32. ↑ Sneed 2013, p. 232
  33. ↑ Sneed 2013, p. 240
  34. ↑ Welker 1994, p. 252
  35. ↑ Welker 1994, p. 253
  36. ↑ Chung 2007, p. 1
  37. ↑ Chung 2007, p. 10

Bibliographie

[modifier | modifier le code]
  • (en) E.J. Chikofsky et J.H. Cross II, « Reverse engineering and design recovery: a taxonomy », Software, IEEE, vol.7, no.1,,‎ , p. 13-17 (DOI 10.1109/52.43044, lire en ligne)
  • (en) H.M. Sneed et K. Erdoes, « Migrating AS400-COBOL to Java: A Report from the Field, », Software Maintenance and Reengineering (CSMR), 2013 17th European Conference on,‎ , p. 231-240 (DOI 10.1109/CSMR.2013.32)
  • (en) Mohammad El-Ramly, « Experience in teaching a software reengineering course, », ICSE '06 Proceedings of the 28th international conference on Software engineering,‎ , p. 699-702 (DOI 10.1145/1134285.1134395, lire en ligne)
  • (en) B. Kullbach et A. Winter, « Querying as an enabling technology in software reengineering, », Software Maintenance and Reengineering, 1999. Proceedings of the Third European Conference on,‎ , p. 1-9 (ISBN 0-7695-0090-0, DOI 10.1109/CSMR.1999.756681, lire en ligne)
  • (en) Dennis Smith, Liam O'Brien et John Bergey, « Mining components for a software architecture and a product line: the options analysis for reengineering (OAR) method », ICSE '01 Proceedings of the 23rd International Conference on Software Engineering,‎ , p. 728 (ISBN 0-7695-1050-7, lire en ligne)
  • (en) P. Bourque et R. Dupuis, « Guide to the Software Engineering Body of Knowledge 2004 Version SWEBOK », IEEE Computer Society Professional Practices Committee,‎ , p. 1-1 - D-7 (ISBN 0-7695-2330-7, lire en ligne)
  • (en) S. Jarzabek, « Software reengineering for reusability », Computer Software and Applications Conference, 1993. COMPSAC 93. Proceedings., Seventeenth Annual International,‎ , p. 100-106 (ISBN 0-8186-4440-0, DOI 10.1109/CMPSAC.1993.404221)
  • (en) Alain Abran et Pierre Bourque, « An innovative software reengineering tools workshop—a test of market maturity and lessons learned », ACM SIGSOFT Software Engineering Notes Volume 19,‎ , p. 30-34 (DOI 10.1145/182824.182829, lire en ligne)
  • (en) H.M. Sneed, « Planning the reengineering of legacy systems », Software, IEEE, vol.12, no.1,‎ , p. 24-34 (DOI 10.1109/52.363168, lire en ligne)
  • (en) Rakesh Agarwal, Ajit Sarangui et Swati Das, « Reengineering of database intensive application », ACM SIGSOFT Software Engineering Notes,‎ , p. 1-4 (lire en ligne)
  • (en) Mohammad El-Ramly, Eleni Stroulia et Paul Sorenson, « Recovering software requirements from system-user interaction traces », SEKE '02 Proceedings of the 14th international conference on Software engineering and knowledge engineering,‎ , p. 447-454 (ISBN 1-58113-556-4, DOI 10.1145/568760.568837, lire en ligne)
  • (en) Sam Chung, J.B.C. An et S. Davalos, « Service-Oriented Software Reengineering: SoSR », System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on,‎ , p. 1-10 (ISBN 0-7695-2755-8, DOI 10.1109/HICSS.2007.479)
  • (en) Nasir Rashid, Muhammad Salam, Raess Khan Alam et Fakhre Khan Shah Sani, « Analysis of Risks in Re-Engineering Software Systems », International Journal of Computer Applications,‎ , p. 5-8 (DOI 10.5120/12783-9851, lire en ligne)
Notices d'autoritéVoir et modifier les données sur Wikidata :