Méthodes de réingénierie des logiciels.

Transcription

1 Université Saint Denis Paris VIII Méthodes de réingénierie des logiciels. Mémoire de Maitrise d informatique Option transversale Rédigé sous la direction de M. Le professeur Jean-François Degremont Par Depoortere Franck Département informatique Septembre 2002 Depoortere Franck - 1 -

2 Depoortere Franck - 2 -

3 Université Saint Denis Paris VIII 2, rue de la liberté, Saint Denis Cedex 02 Département Informatique Méthodes de réingénierie des logiciels. Mémoire de Maitrise d informatique Option transversale Rédigé sous la direction de M. Le professeur Jean-François Degremont Par Depoortere Franck Etudiant n [email protected] Paris, Septembre 2002 Depoortere Franck - 3 -

4 Résumé: Un problème souvent rencontré dans l industrie du logiciel: on dispose d un logiciel et ses codes sources, mais on n a pas ou peu de documentation, et aucune possibilité de contacts avec les auteurs du code. A partir de ce code source, il faut reconstituer l architecture du logiciel, afin de l entretenir, de le faire évoluer, de le faire vivre. De nombreuses sociétés sont tombées devant ce cas difficile : un vieux logiciel Cobol qui l on doit convertir dans un nouveau langage. D innombrables systèmes bancaires utilisent pour partie d anciennes applications écrites dans d anciens langages, que l on doit maintenir ou transformer régulièrement. Ces dernières années, d ailleurs, les entreprises ont vécu avec l an 2000 et l Euro les deux plus grandes opérations de maintenance que l informatique n'ait jamais connue. La maintenance des applications est une préoccupation majeure pour les applications de grande taille. Le problème de maintenance du logiciel est souvent du à l'incohérence qui existe entre le code source et la documentation. C est une phase de plus en plus coûteuse par rapport aux phases de développement. Les outils développés pour la maintenance ne sont pas encore efficients. Les publications sur la maintenance ont été plutôt rares comparativement aux publications sur le développement, abondamment fourni. Dans les années 80, le terme restructuration a été remplacé par le terme réingénierie. La réingénierie est devenue très importante pour l'évolution d'une application. Son rôle est d'améliorer la maintenabilité des systèmes existants. On peut la définir comme un processus de récupération d'une application existante. La réingénierie inclut la rétro-ingénierie, la restructuration, l ingénierie en avant, et redocumentation. Pour ne pas échouer, les projets de réingénierie doivent être conduit par des processus élaborés, formalisant leur déroulement, le suivi des étapes conduisant au bon déroulement du projet. Certains prônent la fusion des outils de conception, devenus désormais abondant, compatibles avec la représentation UML, et complémentaires, et les outils de maintenance qui font figure de parents pauvres de l industrie logiciel. Nous nous sommes mis dans la situation d une application non documentée, et nous avons appliqué des méthodes de retro-ingénierie. Nous sommes parvenus à re-documenter l ensemble du code, à décrire l architecture de l application dans le but, d une part d une reprise plus aisée par d autres développeurs, et pour entamer d autre part quelques modifications fonctionnelles sur le logiciel. Depoortere Franck - 4 -

5 Mots Clés : UML Centre for Software Maintenance AGL outils CASE : Un atelier de génie Logiciel est un logiciel aidant à la réalisation de logiciels. Un AGL est basé sur des méthodologies qui formalisent le processus logiciel, et à l'intérieur de ce processus, chacune des phases qui le composent. génie logiciel : «Le génie logiciel est l'ensemble des activités de conception et de mise en oeuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi» (arrêté du 30 déc. 83) cycle de vie du logiciel retro-conception / rétro conception Ingénierie inverse / reverse engineering : Le jargon français définit les rétro techniques utilisées dans le reverse engineering (ou ingénierie inverse) de la manière suivante : En général, il s'agit de décompiler ou de désassembler un programme, c'est-à-dire de prendre quelque chose de compréhensible par une machine mais pas par un être humain et d'en faire quelque chose de lisible pour un homme mais plus pour un ordinateur. Dans la pratique, le reverse engineering consiste à analyser le fonctionnement d'un programme ou d'un périphérique (typiquement en analysant la communication qu'il a avec le reste du système), ou alors en examinant pas à pas les résultats de son exécution. La réingenierie (reengineering) : La réingenierie est le processus d analyse et de modification d un logiciel afin de le reconstituer dans une forme améliorée. C est une technique consistant à déterminer l'utilité d'un objet que l'on voit pour la première fois, en analysant cet objet. On est amené à se poser des questions comme : «Si j'avais voulu fabriquer une machine ayant telle fonction, aurais-je réalisé cet objet précis?», ou «Cet objet pourrait-il être une machine qui a telle fonction?». Voir rétrotechnique. cross - compilation pour transférer une application, un module, d'un langage ancien vers un nouveau ; Rétrotechnique : Littéralement, «technique inverse». En général, il s'agit de décompiler ou de désassembler un programme, c'est-à-dire de prendre quelque chose de compréhensible par une machine mais pas par un être humain et d'en faire quelque chose de lisible pour un homme mais plus pour un ordinateur. S'écrit aussi «Rétro-Technique». S.I.G. : Système d Information Géographique. Un système d Information Géographique est un outil informatique permettant de représenter et d analyser toutes les choses qui existent sur terre ainsi que tous les événements qui s y produisent. Les SIG offrent toutes les possibilités des bases de données (telles que requêtes et analyses statistiques) et ce, au travers d une visualisation unique et d analyse géographique propres aux cartes. Les enjeux majeurs auxquels nous avons à faire face aujourd hui (environnement, démographie, santé publique ) ont tous un lien étroit avec la géographie. Depoortere Franck - 5 -

6 Sommaire : RESUME:... 4 MOTS CLÉS :... 5 SOMMAIRE :... 6 LISTE DES TABLEAUX... 8 LISTE DES FIGURES... 8 LISTE DES SIGLES ET ABREVIATIONS... 8 REMERCIEMENTS... 9 CHAPITRE 1 : INTRODUCTION CHAPITRE 2 : LA MAINTENANCE "!$# % & '"()+* &,- "!$. /+0 -(1 + 0* + * 2$ +* 435,5 "! 6 / () : ;+*& 0, "! < = '>? ;+ "! < CHAPITRE 3 : LA REINGENIERIE DU CODE :... A()+,B C D % 0 +: E2$ +* F GH 83I 5 CI! /+I(1 : &,J CI! CHAPITRE 4 : LA CRISE DU LOGICIEL... 25! " # $ # % CHAPITRE 5 : LE PROCESSUS LOGICIEL, OU CYCLE DE VIE DU LOGICIEL KL * ;&* &F * M C N KL * ;&PO1 # D KL * ;&F (1 #I! /+ * ;&* 9Q? R,S # # /+ * ;&*)T U : # V /+ * ;&* &? 21 #I6 " CHAPITRE 6 : LA PRESENTATION DES DONNEES & # Depoortere Franck - 6 -

7 -K /, 0 GH * ; # N / T? *1T -K /. D ' ( = '>? ;,. V $ CHAPITRE 7 : APPLICATION: RETRO-INGENIERIE D UN VIEWER DE DONNEES CARTOGRAPHIQUES " ) ) # $ * ) $ * + CHAPITRE 8 : CONCLUSION REFERENCES : BIBLIOGRAPHIE : Depoortere Franck - 7 -

8 Liste des tableaux ", Liste des figures - ' *. ( + + " FIGURE 6.2 : LE MODELE EN V " " % " + ) + " ", " & & & $ + / + $ ) # $ * + $ * 0 0 Liste des sigles et abréviations CASE AGL API CASE DTD IEEE OMG SIG UML XML Computer Aided Software Engineering Atelier de Génie Logiciel Application Programming Interface Computer-Aided Software Engineering Document Type Definition Institute of Electrical and Electronic Engineers Object Management Group Système d'information Géographique Unified Modeling Language Extensible Markup Language Depoortere Franck - 8 -

9 Remerciements En premier lieu, je tiens à remercier mon directeur de recherche, Jean-Francois Degremont. Son encadrement, et sa disponibilité m ont grandement aidé pour réaliser mon projet dans mes conditions particulières de salariés à plein temps. Ses remarques pertinentes et éclairées m ont permis de mieux structurer mon travail, mes idées et, de mieux les décrire. Je remercie également ma sœur qui m a aidée à sa manière afin que je puisse terminer mon mémoire. Enfin, je remercierai les dirigeants de la Société ConnectSuite, dans laquelle j ai travaillée 2 ans en tant que développeur, qui m on fait profiter des locaux et du matériel informatique lors du développement du projet. Mes remerciements vont aussi à tous mes ami(e)s pour leur soutien moral. Depoortere Franck - 9 -

10 Chapitre 1 : Introduction Les développements informatiques constituent désormais un facteur économique important qui conditionne la croissance, la mutation et la survie de la plupart des secteurs de l économie moderne. Incontournable, l informatique s est donc imposée comme un outil stratégique aux chefs d entreprise, mais la plupart ignorent que 53% des projets dérivent ou ne satisfont pas les utilisateurs et que 31% sont abandonnés avant leur mise en exploitation (sources 1996 : Standish Group et Sema Group). Ces chiffres sont édifiants mais non surprenants. Peut-on imaginer de construire un immeuble de 20 étages sans faire de plans, sans organiser la succession des différentes étapes de constructions. C est pourtant ce que l on fait couramment en informatique. Durant les trois dernières décennies, peu d organisations utilisaient des processus de qualité, formalisés, détaillés, complets et spécialisés pour guider leurs développements. Au mieux, une approche de modélisation comme Merise ou une méthodologie de conduite de projet proposaient quelques grandes lignes directrices. Les statistiques résultantes de ces pratiques sont éloquentes quant à leur efficacité et à leur effectivité, ce qui n est pas la même chose. L histoire des développements informatiques est celle d'une série de catastrophes le plus souvent bien dissimulées. Le constat statistique de 84% d échecs relatifs ou totaux met en évidence la réalité d un problème que la complexité des applications et des technologies amplifie dramatiquement. Des centaines, des milliers d années d ingénieurs ont été ainsi englouties en pure perte dans des projets pharaoniques aux frontières du réel. Une réingénierie des procédés de développement s impose. L objectif de ce mémoire est d identifier les problèmes auxquels sont confrontés les communautés de maintenances logiciel, et de proposer des solutions à mettre en place dès la conception du logiciel, et tout au long de sa vie. Si beaucoup de projets de développement échouent par manque de méthodes, il existe également beaucoup de projets de reingénierie qui échouent également par manque de procédures. La réingénierie s effectue bien-sur plus aisément lorsque le produit logiciel a suivie des règles de développements, de documentation évoluées. Car c est lors du développement et même lors de la conception que l on prépare la phase de maintenance du logiciel. Le maître mot de notre concept sera donc l emploi de méthodes, de procédures de suivi, de contrôle de processus. La mise en place de processus a un coût que certaines entreprises pensent économiser en ne les respectant pas, mais elle sont indispensable dans la vie d un logiciel. Lorsqu un logiciel ne peut évoluer, il disparaît. Contexte de la recherche : Ce projet a été réalisé dans le cadre de la reprise d un logiciel de cartographie, nommé «Compilo Graphic Database» déjà utilisé par quelques départements et communes Francaises, afin de visualiser de informations sur des cartes, d effectuer des études et statistiques sur leurs réseaux routiers, le trafic, et exploiter toutes autres informations stockées dans la base de données du logiciel. Le projet consiste à reprendre le projet, abandonné depuis maintenant plusieurs années, et effectuer un travail de maintenance sur l ensemble de l application. Cette étude comprend d abord un objectif de redocumentation du code source, du design global de l application, mais également de petites modifications, des améliorations, des corrections de comportements de l application. Le travail se découpera en plusieurs étapes : - Nous commencerons par un travail de recherche afin de reconstituer à partir des quelques documents commentant l application, une documentation énumérant les fonctionnalités de l application, coté utilisateur. Depoortere Franck

11 - nous passerons ensuite au code source, nous définirons l architecture du logiciel, et les aspects fonctionnels des modules composant le projet, puis nous effectuerons un travail de documentation du code source. Les buts à atteindre sont d une part de remonter l indice de maintenabilité du logiciel, et de rendre l application plus aisément reprenable par les prochains développeurs, et d autre part d effectuer des corrections, et changements de comportements sur le logiciel. Structure du mémoire : Le mémoire est organisé de la façon suivante : Le chapitre 2 définie le terme de maintenance, et propose une vue synthétique sur le monde actuel de la maintenance logiciel, ces défauts, des types de maintenances appliquées au logiciel en production. Le chapitre 3 définie les grandes étapes de ce qu on nomme la «réingénierie», c est à dire la rétro-ingénierie, la redocumentation, et la restructuration et le but de reingénierie, à savoir l amélioration de la compréhension du logiciel, l amélioration du logiciel lui-même, et enfin l amélioration du niveau de maintenabilité et d évolution et de réutilisation de l application.. Le chapitre 4 met en lumière l échec actuel des procédures d ingénierie logicielle, du manque de méthodes et de processus employés dans l industrie informatique. Le chapitre 5 introduira l étude et l emploi de modèles formels connus de procédures de développement et de maintenance dans le cycle de vie des logiciels. Dans le chapitre 6, nous allons introduire deux progrès récents dans le monde du développement Orienté Objet (OO) que nous supportons dans notre approche, à savoir, le langage UML qui est un langage visuel pour la modélisation des systèmes OO, ainsi que les patrons de conception qui permettent de documenter et de communiquer l expertise en matière de conception logicielle OO. Enfin, dans le chapitre 7, nous mettrons en pratique nos théories en effectuant une procédure de réingénierie sur un outils de cartographie en production depuis 5 ans. Il s agira d effectuer des représentations, de retrouver l architecture globale du logiciel, d ajouter un module d aide utilisateur, et d effectuer un travail de redocumentation, de corriger les bugs identifiés, et enfin d énumérer les changements à effectuer. Depoortere Franck

12 Chapitre 2 : La maintenance Alors que les entreprises viennent de vivre avec l an 2000 et l Euro les deux plus grandes opérations de maintenance que l informatique ait jamais connues, le thème de la maintenance n occupe qu une place modeste dans la presse spécialisée et les séminaires professionnels. Faut-il en conclure que la maintenance n est plus une préoccupation majeure des responsables informatiques? La réalité du terrain vient contredire cette apparente indifférence. En effet, la maîtrise de la maintenance devient des plus critiques pour les raisons suivantes : Les coûts de maintenance, déjà très importants, continueront de croître et deviendront d autant plus visibles que le prix des matériels diminuent. La rapidité d adaptation des entreprises à l environnement économique est un facteur clé de réussite. Cette flexibilité est conditionnée par leur capacité à faire évoluer rapidement leurs applications stratégiques, c est à dire à maîtriser la maintenance évolutive. Les entreprises doivent également maîtriser la maintenance adaptative si elles veulent ouvrir leurs applications existantes (saisie de commande, suivi des livraisons, ) au client final via des infrastructures de type Internet. En ouvrant leurs applications à l Internet les entreprises affichent leur niveau de qualité. Elles doivent donc maîtriser leur processus logiciel, notamment leurs activités de maintenance (corrective, adaptative, perfective et évolutive). Soulignons de plus que la problématique de la maintenance ne concerne pas uniquement les vieilles applications qu il suffirait de remplacer pour éliminer le problème. En fait, dès qu une application nouvelle est mise en production elle entre dans le cycle de maintenance. Il est essentiel pour un gestionnaire de systèmes de bien gérer la maintenabilité pour planifier et contrôler adéquatement les projets de maintenance. Puisqu'on ne peut gérer ce qu'on ne peut pas mesurer, il apparaît nécessaire de pouvoir quantifier la maintenabilité pour bien gérer la maintenance. Nous discutons aussi des approches pour estimer cet indicateur durant la phase de développement. Nous tentons également de clarifier le concept de maintenabilité, et de le distinguer des autres caractéristiques du logiciel. Il est inutile de produire un logiciel s il ne peut être compris et utilisé par ses développeurs, et s il est très difficile, voire impossible à modifier. Définition de la maintenance : La maintenance, ce n est pas seulement la détection et la correction des erreurs trouvées dans un programme. On trouve différentes définitions de la maintenance logiciels. Des acteurs important du domaine définissent l activité de la façon suivante : 1. L organisme de standardisation des logiciels, L IEEE, définie dans la référence «software maintenance standard», IEEE STD , le terme de maintenance logiciel comme ceci : «la modification d un logiciel après son entré en production, afin de corriger ses erreurs, d améliorer ses performances et autres attributs, ou pour adapter le produit à son environnement» 2. Martin et Mc Clure, éminents théoriciens du domaine définissent la maintenance comme «Les changements effectués sur les programmes informatiques après livraison à leurs utilisateurs» 3. Von Mayrhauser: «La maintenance couvre le cycle de vie des systèmes logiciels à partir de leur mise en production jusqu'à la fin de leur utilisation.» Le thème commun de ces multiples définitions est que la maintenance est une activité qui poursuit la réalisation d un travail. L activité de maintenance commence dès la mise en production du logiciel. Depoortere Franck

13 Pourquoi la maintenance est nécessaire? Pour répondre à cette question, on se doit simplement d observer la mise en production d un logiciel livré à des utilisateurs. Lorsque les premiers utilisateurs vont utiliser le produits, ils vont trouver de nombreux problèmes, et disfonctionnements, et trouver d innombrables fonctions à rajouter. Ces changements vont être demandés aux mainteneurs de l application, qui vont corriger et améliorer le système. Puis les utilisateurs vont s adapter aux changements et nouvelles fonctionnalités et à nouveau perturber les mainteneurs. Dans la plupart des cas, le cycle de maintenance d un logiciel constitue la plus grosse part de son cycle de vie, en temps et en argent. Cette maintenance sans fin se justifie par le fait qu une application doit sans cesse évoluée pour continuer à être utilisée, et ne pas mourir. Environnement organisationnel Besoins des utilisateurs Maintenance Application Logiciellle Process et personnel Influence Environnement opérationnel Figure 2.1 : Inter-relation entre les différents facteurs influençant la maintenance logicielle Faits et chiffres Deux études américaines (General Accounting Office), menées sur un nombre conséquent de projets informatiques dans les années 90, illustrent bien la problématique de la maintenance : L étude identifie les 3 facteurs les plus négatifs rencontrés dans la maintenance : 1. L absence de processus de maintenance logicielle (73% des cas). 2. Le manque de documentation à jour (68% des cas) qui se traduit par sa non-utilisation. 3. Le manque de temps pour mettre à jour la documentation (54% des cas). Elle démontre également que les coûts de maintenance augmentent dans le temps au fur et à mesure que les multiples modifications apportées au code rendent les interventions de plus en plus complexes. Depoortere Franck

14 Quatre types de maintenance : Maintenance Adaptative Maintenance Corrective Maintenance Corrective Maintenance Préventive Implique Figure 2.2 : Relations potentielles entre les différents types de maintenance logicielle Maintenance corrective : La maintenance corrective ce réfère aux modifications initiées du aux défauts du logiciel. Ces défauts peuvent résulter d erreur de spécifications, de choix d architecture ou d erreur de programmation, ou de tests invalides ou incomplets. Les défauts peuvent également provenir de problèmes de performances ou de traitements de données. Ces erreurs sont souvent nommées «erreurs résiduelles», empêchant le logiciel d être conforme aux spécifications. Lors de l apparition de problèmes bloquants sur un système, la maintenance résout le problème en proposant des «patchs». Maintenance perfective : Ce terme est utilisé afin de décrire les changements mis en œuvre afin d étendre le système et d améliorer l'efficacité d'un système d'information en exploitation. Une application tend à devenir performante grâce à la succession de changements résultant de l accroissement des fonctionnalités. Imaginons une application faite sur l architecture constituée d un noyau central et des multiples modules implémentant les fonctionnalités du logiciel. On peut dans ce cas, ajouter à volonté de nouvelles fonctionnalités, à la demande des utilisateurs. Durant les diverses étapes, le système évolue grâce à l ajout de petits programme, ou modules, facilement intégrable, aisément maintenable. On constitue ainsi une grosse application offrant une bonne résistance à la modification. Ce peut donc être l ajout de nouvelles fonctionnalités ou la redéfinition de fonctions existantes, ou la suppression, de fonctions inutiles ou redondantes, alourdissant inutilement le système. Maintenance adaptative : Elle a pour but d'effectuer les modifications nécessaires pour adapter un système d'information aux changements. Même en l absence d erreur résiduelle, une application est vouée à changer pour s adapter à l environnement. Lorsque l on emploi le terme d environnement dans notre contexte, on se réfère aux conditions influençant le système : Par exemple, les règles fiscales, les changements de stratégies commerciales, les changements de législation, les changements de plates-formes, ou de Depoortere Franck

15 matériel. Tous ces facteurs sont des éléments déterminant l adaptation des logiciels, à de nouvelles contraintes. La maintenance adaptative inclus tout travail autours d une plate-forme, d un OS ou d un compilateur différent. Elle peut être rendue nécessaire afin d améliorer les performances d une application pour cause de demandes accrues et donc migrer par exemple d un système séquentiel de traitement de taches, vers un système de traitement en parallèle. Similairement, des applications peuvent être portées sur d autres plates-formes afin de tirer avantage d un nouvel OS, ou le support d une nouvelle base de données, pour des gains de performances, une sauvegarde plus facile, ou une résistance à la défaillance accrue. Un exemple de maintenance adaptative, pour cause de changement de règle économique, est le passage à l Euro. Tous les systèmes d informations bancaire ont du être adaptés pour supporter la nouvelle monnaie. Maintenance préventive : La maintenance préventive a pour but d'anticiper tous les problèmes possibles. Les phases de maintenance corrective, adaptative, et perfective peuvent être considérées comme des travaux qui détériorent généralement peu à peu la structure de l application si aucun travail de maintient n est réalisé. Ce travail constitue des changements préventifs. La maintenance préventive est une entreprise de prévention de disfonctionnement, ou d amélioration de la maintenabilité du logiciel. Ces changements sont souvent initiés par le département de maintenance souhaitant rendre plus simple la compréhension ou la structure du programme pour des futurs travaux de développement. Les changements préventifs ne donnent généralement pas d amélioration substantielle des fonctions de base. Le changement préventif peut être une restructuration du code, ou la mise à jour de la documentation. La mise à jour du système documentaire est fréquemment oubliée. Les documents affectés par les changements doivent être modifiés afin de refléter l état courant du système. En principe, les activités de maintenance logiciel peuvent être classées dans ces quatre catégories. En pratique, elles s entremêlent souvent. Par exemple, lors de l adaptation d une application à un nouvel OS, donc une activité d adaptation, de curieux bugs peuvent apparaître. On effectue donc une correction dans une maintenance corrective. Similairement, l activité d amélioration d algorithme peu impliquer la restructuration du code, et donc une activité de maintenance préventive. Pourtant, malgré l enchevêtrement des ces diverses activités, il est bon de garder la distinction entre les différents types de changements. En premier lieu, ceci permet d allouer des niveaux de priorités aux demandes de changements. Certains changements requièrent des réponses plus rapides que d autres. Depoortere Franck

16 Les implications économiques des modifications de logiciel : Une proportion substantielle des ressources dépensées dans les l industries logicielles sont versées dans la maintenance. Dans les années 90 95, 70% des dépenses de développement logiciel ont été occupée par des activités de maintenance, et seulement 30%, par les nouveaux développement. Les coûts de maintenance croissent de 10% chaque année, suivant la tendance de grossissement, de complexification des applications informatiques. Une étude réalisée aux USA, auprès de 490 sociétés éditrice de logiciels, ont ressorti les statistiques des différentes catégories de maintenance. La maintenance corrective comptait 20% du temps, adaptative 25%, 50% du temps était dédié aux perfectionnements et enfin, 5% était occupé par la maintenance préventive. Chaque application représente un grand investissement financier et ne peut être écartée suite à l'arrivée d'une nouvelle technologie. Abandonner un système et développer un nouveau devient pour la plupart de compagnies très dispendieux. Alors on essaie une alternative : ajouter de nouvelles fonctionnalités dans le système actuel et s'assurer qu'il soit compatible avec les autres systèmes. Les entreprises fournissent un effort considérable pour mettre en œuvre les modifications souhaitées par l'utilisateur. Il est très important d'être en mesure de réaliser ces modifications sans affecter la qualité des applications. Les systèmes d'exploitation par exemple, demeurent en exploitation plus longtemps que prévue, et restent en maintenance et en exploitation plusieurs dizaines d années. On peut citer certains systèmes bancaires conçus dans les années 70 écrites en Cobol, toujours en activité à l heure actuelle. Le département de la défense américaine a un budget alloué pour la maintenance supérieur à 5,5 milliards $ par année, soit 60% du budget total de 9 milliards dédié aux développement des systèmes informatiques. On trouve des applications crées même dans les années Le grand nombre et types d'applications et l étendue des centres ont crée de gros problèmes, parce que la plupart des applications avaient été crées sans utiliser un standard de développement. La DISA (Defense Systems Agency) et le DAPMO (Data Administration Management Office ) ont été chargé du développement d'une structure standard pour les applications du ministère de la Défense, afin de pallier les difficultés d entretient de ces gros systèmes. Le fait de ne pas mettre la documentation à jour ne fait que rendre la compréhension éventuelle du système plus difficile. Il est très fréquent de trouver des systèmes de logiciels dotés d'une documentation incomplète ou quasi inexistante. Le coût de la maintenance a eu une croissance exponentielle et couramment on l'estime entre 50 à 80 % du budget total du système informatique. Au cours du développement d'un logiciel, les exigences des utilisateurs varient énormément. Comme résultat, les changements des spécifications au niveau de la documentation sont souvent retardés en raison de plusieurs contraintes, comme les échéanciers de livraison et les coûts. Ce qui explique l'absence de la documentation de certaines fonctions ou l'incohérence du code par rapport à la structure conceptuelle de la plupart des systèmes existants. Les entreprises n'ont pas de philosophie de maintenance claire et articulée malgré le fait qu'elles utilisent des méthodes structurées pour la conception ou le développement des applications. la maintenance est très mal planifiée et on surveille peu l'exécution des travaux de maintenance. Depoortere Franck

17 Les solutions aux problèmes de maintenances : En se basant sur l observation que la maintenance logiciel coûte au moins autant que les nouveaux développements, certains proposent de mettre moins de ressources sur la maintenance des systèmes difficilement maintenable et de consacrer davantage de temps dans le développement, la spécification et le design de systèmes plus maintenable. Il est maintenant convenu que l utilisation d approches plus avancées dans les spécifications, les techniques et les outils de design, et les processus d assurance qualité, durant le cycle de développement des logiciels procurent des systèmes beaucoup plus maintenable à long terme. Les phase de maintenance sont obligatoires, car le remplacement complet des systèmes ne donne pas la garantie d un fonctionnement meilleur que l ancien. On découvre même souvent que les nouveaux logiciels ont des erreurs sur des fonctionnalités que l ancien système gérait parfaitement. En effet, il est impossible qu un nouveau système soit totalement parfait et sans erreur. L ancien système possède intrinsèquement des richesses d expérience, un réservoir d idées que les nouveaux systèmes sont souvent incapables de reprendre. Le complet remplacement des systèmes n est souvent pas une bonne solution. L alternative est de rendre le système potentiellement capable d évoluer, de rendre son management plus sophistiqué et plus facile à gérer. Synthèse Nous avons donc défini le terme de maintenance comme la modification d une application en production, afin de corriger les erreurs, d améliorer ses performances ou de l adapter à un environnement ou des contraintes modifiées. La maintenance logicielles peut donc être percue comme la continuité naturelle du développement, malgré des différences sur certains points. La qualité du logiciel en production influence directement la productivité de la maintenance. Les activités de maintenance sont constituées par les changements correctifs, adaptatifs, perfectifs et préventifs. En pratique, ces activités s entremêlent souvent. Les coûts de maintenance des systèmes tournent souvent autours de 40 à 70% des ressources allouées tout au long du cycle de vie du logiciel. Les problèmes de maintenance sont souvent liés à un code non structuré, ou à une documentation incomplète ou inexistante. Les solutions aux problèmes de maintenances se trouvent souvent dans l investissement de davantage de ressources sur les méthodes employées lors des premières phases de développement du logiciel pour avoir des systèmes plus maintenable. Le remplacement total des applications est souvent économiquement non viable. Les solutions employées sont donc la restructuration, le reverse ingeniering. Depoortere Franck

18 Chapitre 3 : La réingenierie du code : Depuis de nombreuses années, l industrie du logiciel s était concentrée sur le développement de nouvelles applications. La plupart des efforts de recherche étaient investis dans la création de procédures de développement plus efficaces, améliorant la qualité du logiciel, réduisant le temps de développement et sa mise sur le marché. En se focalisant sur ces aspects de développement, un autre aspect du cycle de vie du logiciel, la maintenance de l application, n obtenait qu une attention insuffisante dans le cycle de production. La pression du marché rendait les cycles de production très courts. Il en résultait une situation ou la plupart de versions de logiciels ne rentraient jamais en phase de maintenance, mais étaient sans cesse remplacées. Beaucoup de sociétés ont du faire face à de sérieux problèmes lorsque les systèmes d informations étaient devenus si complexe, si gros et représentaient des couts d investissements tels, qu elles ne pouvaient plus changer leur système d information par un nouveau. Il n est donc pas rare de voir des grandes compagnies garder leur système une quinzaine d années, et donc organiser une maintiennent régulièrement. Pourtant, leurs applications, fruit de nombreuses années de modifications de développements non structurés et de maintenances non documentées devenaient des amas d informations non documentées et de savoirs perdus. Ce savoir était présent dans la tête de quelques ingénieurs qui avaient souvent quitté l organisation, l information était donc perdue. Remplacer l application par un nouveau système peut avoir de gros effets pervers. Dans certains cas, les nouvelles applications risquent d avoir des fonctionnalités ne répondant pas aux besoins. Afin d éviter ces problèmes, la solution alternative est la rétro-ingénierie. De 50 à 75 % de l'effort logiciel est consacré à la maintenance de systèmes. La productivité des équipes de maintenance est fortement influencée par la maintenabilité. Il est donc essentiel pour un gestionnaire de systèmes de bien gérer la maintenabilité pour planifier et contrôler adéquatement les projets de maintenance. Un logiciel est le fruit de plusieurs années de recherche, et d énormes investissements financiers. Malgré cet investissement, certains logiciels sont abandonnés du fait des difficultés parfois trop importantes pour les maintenir, les modifier. Ceci peut être du à une perte du savoir-faire, à l impossibilité de contacter les auteurs du code. On préfère dans ce cas refaire en partie ou totalement l application. Que de travail, de savoir-faire, de temps et d argent perdu On inclut dans la réingénierie d un logiciel, les étapes de rétro-ingénierie, «d ingénierie en avant», de restructuration, et enfin de redocumentation. La rétro-ingénierie représente la première étape de la réingénierie qui consiste à effectuer le chemin inverse par rapport au processus de développement. On pourrait la définir comme le contraire de l'ingénierie autrefois nommée "forward engineering". Le reverse engineering est une partie indispensable de la maintenance logiciel, puisque celle-ci ne peut être réalisée sans une compréhension complète du système. Parfois, la compréhension d'un logiciel est si complexe en l'absence de toute documentation, que la tache est presque impossible. C'est la raison pour laquelle la retro-ingénierie est un processus qui a pour rôle de comprendre les différentes informations inconnues ou cachées du système logiciel. La redocumentation constitue la forme la plus ancienne du processus de rétro-ingenierie puisque c est la révision ou la création des représentations équivalentes à un code source donné. La restructuration est la transformation d'une forme de représentation en une autre au même niveau d'abstraction en préservant l'interface externe du système. On peut utiliser la restructuration afin d'adapter un système à de nouvelles contraintes, ou comme maintenance préventive pour améliorer l'état physique du système en respectant par exemple des standards existants. Depoortere Franck

19 La rétro-ingénierie On l utilise pour accroître la compréhension du système ou pour remplacer une partie du système. La rétro-ingénierie représente la première étape du processus de réingenierie et constitue une portion très importante du processus de réingenierie dans son ensemble. Il existe des similitudes entre la retro-ingénierie logiciel et dans le monde matériel lorsque l on étudie le produit d un compétiteur afin d en trouver sa conception et ses secrets de fabrication. Dans ces cas précis, la documentation n est pas fournie... Dans le monde logiciel, le code du système et sa documentation sont souvent incohérentes, en raison de plusieurs changements de code, qui n ont pas fait l objet d une mise à jour de la documentation. La rétro-ingénierie part du code source, retrace ou recrée les décisions de conception et déchiffre les exigences mises en œuvre par le système, en permettant d identifier les différents modules du système et leurs relations. Ces taches sont la plupart du temps exécutées à la main. Les approches de base de la compréhension sont : L approche systématique ou on examine le programme en entier en identifiant les interactions entre les modules. L approche pragmatique qui essaie de trouver les sections ou se trouvent les composants du programme à modifier, mais qui ouvre le risque à l omission de composantes qui peuvent influencer le comportement d autres composantes. La lecture du code représente une méthode intéressante pour comprendre une application. La méthode «top down» donne des programmes assez lisibles. Toutefois, le style de conception des applications à une grande influence dans le processus de compréhension. Un programme écrit par une seule personne sera souvent moins lisible que celui d un groupe de travail. Pour les grands programmes les noms de variables significatifs simplifient la conversion d'une représentation syntaxique en une représentation sémantique. Pour automatiser la lecture du code on utilise les techniques statiques et dynamiques : L analyse statique est l analyse d un programme sans son exécution afin d identifier des variables non initialisées, l identification du code non utilisé, produire des algorithmes d analyse incrémentale pour mettre à jour un système sans ré-analyser le système en entier. L analyse dynamique, c est l analyse des applications avec leur exécution. Le but de la rétro-ingénierie est d identifier les composantes du système et leurs relations, et de créer des représentations du système dans une forme ou un plus haut niveau d abstraction. La rétroingénierie n entraîne pas un changement du système ou la création d un nouveau système. La plupart des ingénieurs logiciel préfèrent le développement plutôt que le maintient d anciens systèmes. La rétro-ingénierie est un retour en arrière par rapport au processus de développement. C est un travail perçu comme moins enthousiasment et assez fastidieux. Il n en est pas moins important. Pour générer une description on a besoin d'identifier : Les modules qui peuvent être des fonctions simples ou une série de fonctions ; Les ressources échangées entre les modules, les types de données, les variables et les procédures ; Les propriétés fonctionnelles identifiées avec l'aide des assertions qui caractérisent les ressources ; Les propriétés dynamiques par la conversion de l'algorithme de bas niveau dans un langage de spécification ; Un système est composé d'une hiérarchie de sous-systèmes qui doivent être identifiés ; Avec l'analyse statique on identifie les propriétés structurelles des modules. Depoortere Franck

20 Le processus de rétro-ingénierie commence par l'extraction de l'information de conception à partir du code source et de la documentation existante. Des abstractions de hauts niveaux sont extraites à partir de cette information. Ces représentations de conception sont exprimées par des diagrammes de structure, de flux de données et de flux de contrôle. Etapes : 1. La collecte de l'information : C'est un rassemblement de toutes les informations possibles sur le programme. Les sources d'information peuvent comprendre le code source, les documents et les personnes connaissant le système. 2. L'étude de l'information : Il s'agit de la revue des informations rassemblées. Cette étape permet aux intervenants de se familiariser avec le système et ses composantes. Un plan pour analyser le programme et enregistrer l'information récupérée, peut être formulé durant cette étape. 3. L'extraction de la structure : Il s'agit de l'identification de la structure du programme et de la création d'un ensemble de diagrammes de la structure. Chaque nœud dans un diagramme de la structure correspond à une routine appelée dans le programme. Chaque arrête dans le diagramme représente les entrées/sorties des données dans les nœuds. 4. L'enregistrement des fonctionnalités: Pour chaque nœud dans les diagrammes de structure, il faut enregistrer le traitement effectué dans le programme. La fonctionnalité peut être décrite en langage naturel ou en une notation plus formelle. 5. L'enregistrement du flux de données : La structure du programme récupéré peut être analysée pour identifier les transformations des données dans le système. Ces étapes de transformation montrent le traitement des données réalisé dans le programme. Cette information est utilisée pour développer un ensemble de flux de données hiérarchique qui modélisent le système. 6. L'enregistrement du flux de contrôle : Il s'agit de l'identification de la structure de contrôle de haut niveau qui affecte l'opération générale du système. 7. Passer en revue la conception récupérée : C'est la vérification de l'exactitude des informations disponibles. Il faut détecter les items d'informations manqués et tenter de les récupérer, vérifier si l'information de conception récupérée représente correctement le programme. 8. La génération de la documentation : C est l'étape finale de la documentation de conception. Depoortere Franck

21 Quelles sont les bénéfices de la rétro-ingenierie? Il est plus facile de modifier le code existant que de recommencer à nouveau. Ces options, parfois inéluctables, ont l inconvénient d être risquées, car de type " big bang ", et coûteuses. On trouve dans le code existant des informations sur l application qui pourraient ne pas exister ailleurs. La possibilité d utiliser les outils CASE On améliore le potentiel de réutilisation du code, des objets. On améliore souvent l application en la rendant plus claire, plus fiable, plus maintenable et on augmente la qualité du programme. Des outils existent aujourd hui, pour la rendre plus facile et automatique Elle est très utile pour les outils stratégiques qui ont une longue durée de vie. Elle est indispensable pour la maintenance du système La problématique : Beaucoup d anciens systèmes ont été développés de facon «artisanale», au fur et à mesure des besoins des utilisateurs, sans s appuyer sur des règles de développements précises ou des outils de conception, et souvent sans aucune documentation ou avec une documentation qui est totalement inutile. En conséquence, les ressources nécessaires pour faire fonctionner l'application consomment entre 50% et 90 % du temps de maintenance. Les coûts sont en croissance parce que chaque nouvelle fonction va augmenter les coûts de la maintenance. Il devient de plus en plus difficile de faire des changements. Le temps nécessaire pour faire les changements augmente progressivement et des opportunités d'affaires pourraient être perdues. L investissement des des procédures de rétroingénierie permet de résoudre ces problèmes. Après la rétro-ingénierie il faut s'assurer que le système satisfait la plupart des standards qui ont été appliqués aux systèmes et il faut faire de la retro-ingénierie une part de qualité du système. Une documentation de qualité doit être produite, il faut inclure dans le plan une représentation graphique de la retro ingénierie. Les outils statiques peuvent être appliqués pour vérifier la conformité entre le code et le «coding standards ". Les outils des mesures donnent la possibilité de comparer la complexité du logiciel avant et après la restructuration. Pour que la phase soit totalement complète et tracable, la conduite du processus de rétro - ingénierie doit être décrite, afin de vérifier la qualité, la conformité de la tache effectuée. On nomme se document le REQP (Retro-Engineering Quality Plan ). La documentation produite est à plusieurs niveaux de détails. Il faut mettre en place une gestion de toutes les versions de retro-ingénierie réalisées, pour avoir une vue d'ensemble de tous les processus et produits réalisés. Ce document va permettre de valider la qualité du produit logiciel, en répondant aux questions suivantes : - Est-ce que la documentation satisfait les standards? - Est-ce qu'elle est clairement et correctement décrite? - Est-ce que le système est compréhensible pour la maintenance future? La vérification peut être faite par l'introduction d'une revue après un jalon dans le projet. La plupart des standards utilisés pour l'ingénierie en avant pourraient être utilisés pour la rétro ingénierie. Le besoin d'avoir des standards est certain. Les standards pour la maintenance doivent être bien définis pour donner au système un niveau de qualité satisfaisant. Depoortere Franck

22 La redocumentation La documentation des applications a toujours été le maillon faible des projets applicatifs. Chez les grands comptes, les applications développées pour des grands systèmes sont souvent anciennes et leur documentation est souvent jugée insuffisante ou obsolète. Pour les équipes chargées de la maintenance logicielle, la difficulté est d autant plus grande que les personnes qui maintiennent les programmes ne sont pas celles qui les ont écrit. Si la maintenance logicielle est de mauvaise qualité, c est la plupart du temps pour les raisons suivantes : le manque de modèle de processus logiciel, le manque de documentation, ou le manque de temps consacré à la mise à jour de la documentation. Cette tâche de redocumentation, même si elle n ait pas nécessairement porteuse de motivation, est malgré tout indispensable à la maintenance du logiciel. Le constat est navrant, mais il s avère selon l étude de NGSET (NGSET : que 95% des applications logicielles ne sont pas ou peu documentées. Le corollaire de ce manque de connaissance sur les applications est que 60% du temps de maintenance est passé, non pas en améliorations ou corrections, mais en recherche, lecture et tentatives de compréhension. L implémentation représente 15%, et les tests 25% du temps. Une documentation véritablement utile dépasse les simples commentaires décrivant une ligne de code ou un ensemble d instructions. Elle contient l ensemble des informations nécessaires à la maintenance de l application, notamment l organisation de l application (découpage fonctionnel, organisationnel, ), l ensemble des composants mis en jeux : Programmes, fichiers et base de données, transactions, les relations entre les composants ou à l intérieur d un composant, et le dictionnaire des données. Soulignons bien que la qualité de la documentation d un logiciel est aussi importante que son code. Pour respecter cette qualité, il est important de mettre en place une procédure de production, de présentation et de vérification des documents. Il ne faut pas sous-estimer l importance du contrôle de qualité des documents. Une documentation mal faite ne sera pas utilisée. Les standards de documentation doivent décrire précisément le contenu et les notations utilisées pour chaque document. Notamment les formats de couverture, la numérotation des pages, les conventions à suivre pour les notes de bas de page, les renvois, les titres, L évolution technologique des outils de développement et de maintenance permet aujourd hui une automatisation partielle de cette documentation. Ces logiciels sont capables de générer des documents automatiquement à partir du code source des logiciels, des bases de données, des commentaires insérés dans le code, de présenter une vision hiérarchique globale du système applicatif, et des visions détaillées au niveau composant, de construire les interrelations entre les composants de l application. Cette automatisation de documentation est aujourd hui indispensable sur les applications importantes. Certains logiciels atteignent plusieurs centaines de milliers, voire plusieurs millions de lignes de code. Il serait difficile d avoir une documentation à jour et avec des coûts raisonnables, en effectuant celle-ci manuellement. En matière de diffusion et de visualisation de l information, la technologie Internet, à base de serveurs centralisés de fabrication de pages HTML et XML, de serveurs de pages et de postes de travail dotés de navigateurs, est très adaptée à la documentation des applications. Cependant, même si ces outils allègent considérablement les taches fastidieuses de documentation, tout le processus de documentation n est pas entièrement automatisable. Les connaissances du logiciel ne sont pas seulement dans le code source, mais également chez les experts. Cette capture des connaissances des experts doit être également être rendue accessible par des documents s ajoutant à la documentation automatique. Les logiciels de documentation sont capables de lier l ensemble des documents à une version du logiciel. La majorité des documents associés à un projet logiciel sont mal écrits, difficile à comprendre, périmés ou incomplets. D une façon générale, le travail de documentation est largement sous-estimé. La production de documents de qualité n est ni facile, ni bon marché. Néanmoins, la qualité de documentation est au moins aussi importante que la qualité du programme. Depoortere Franck

23 La restructuration L objectif premier de la restructuration est d améliorer la maintenabilité du code pour diminuer les coûts de maintenance. Au-delà de cet objectif, la rénovation a des implications sur la stratégie d évolution des applications. En effet, lorsqu une application devient trop difficile à maintenir le management a deux options : Réécrire l application. Remplacer l application par une autre application ou un progiciel par exemple. Figure 3.1 : Stratégies de maintenance et coûts de maintenance (source : Economics of SW Reengineering Harry M. Sneed) La restructuration vise à améliorer la représentation d un système sans en changer les fonctionnalités. L activité de restructuration est basée sur le principe que par la suite d une chaîne de modifications, la structure globale du programme tant à ce dégrader. Le code devient de plus en plus difficile à comprendre et sa structure de moins en moins saine. Le programme doit donc être restructuré. Cette activité de restructuration recouvre différents types d actions, qui vont s adapter à la façon dont est fait le logiciel. On va recourir souvent à trois étapes de travail : 1. la restructuration des flux : on va tenté d améliorer la structure globale des modules composants l application. Ceci va se traduire par exemple par le regroupement de routines éparpillées dans divers modules, de classer les diverses fonctions avec plus de cohérence. Le but de ce travail de nettoyage du code est de retrouver une structure globale tout à fait cohérente sur l application. 2. La restructuration peut également s effectuer sur l algorithmique du code, afin de le rendre plus efficace, ou plus clair. On va dans cette phase, supprimer le code mort et les variables non utilisées, supprimer les fichiers devenus inutiles, remplacer par exemple les structures IF- ELSE IF imbriqué par des structures CASE, plus clair, et surtout moins coûteux en temps de calcul (L interprétation d un case consomme une seule évaluation d instruction booléenne, tandis qu il y a autant d instructions et de test évalués que de IF imbriqués). Ce peut être également la normalisation du code et des noms. Depoortere Franck

24 Synthèse La rétro ingénierie est donc une technique utilisée afin d obtenir une compréhension globale du programme, afin de pouvoir le modifier sans causer d autres phénomènes de bords, du à l ignorance de certaines parties de l application. La redocumentation est une autre forme de rétro ingénierie, qui présente une autre forme d abstraction de l application logicielle. L activité de rétro ingénierie est de retrouver les informations perdues lors du développement, de rendre éventuellement le code plus facilement migrable vers d autres plates-formes ou d autres langages de programmations, de rendre les composants du logiciel réutilisable. L accomplissement de l ensemble de ces objectifs pourra finalement réduire considérablement le coût de maintenance de l application, et élever le niveau de qualité du logiciel. Malheureusement, cette activité, souvent considérée comme fastidieuse, est peu automatisable, et doit donc souvent être réalisé manuellement. Depoortere Franck

25 Chapitre 4 : La crise du logiciel Il n y a pas de raison de tolérer des erreurs de conception lors de la construction d un pont, d un immeuble, ou d un produit industriel quelconque Il devrait en être de même dans l ingénierie logicielle. Les projets informatiques ont systématiquement tendance à dépasser le budget fixé au départ. On assiste très souvent à des dépassements moyens de budget de l ordre de 70%, et des délai allongés de plus de 50% par rapport a ceux prévu, voir beaucoup plus dans certains cas. La maintenance est difficile, coûteuse, et souvent à l origine de nouvelles erreurs. On tolère des erreurs, des disfonctionnements, des défauts de qualité qui ne seraient pas tolérés dans d autres industries. C est dans les années 60 que l on constate les premiers gros échecs dans l industrie du logicielle. On découvre déjà que les produits informatiques sont des ensembles compliqués et plein d erreurs, et les échecs de la production logicielle, ces dérapages de délai de livraison, de coût et les problèmes d organisation. On parle pour la première fois de «crise du logicielle» lors de la livraison de l OS d IBM360, et un effectif de maintenance de 6000 personnes. Dans les années 70, le compilateur PL1 de Control Data est abandonné après plusieurs années de travail. Plus proche de nous, des échecs relativement médiatiques sont connus de tous, comme le retard catastrophique du système SOCRATE, système de réservation de la SNCF. Comme exemple de catastrophe, on peut citer le crash de la navette Ariane 501, en juin 1996, causé par une défaillance informatique, qui a entraîné une perte de 4 milliards de Francs. Plus près de nous, le bug de l an 2000 à ralenti la croissance mondiale de 2 à 3%. Figure 5.1: La crise du logicielle Depoortere Franck

26 Pourquoi beaucoup de projets de rétro-ingénierie échouent? L une des principale raison d effectuer une réingénierie est motivée par la migration à d autres technologies, la migration vers un autre système d exploitation. Il est navrant de constater que dans beaucoup de cas, les procédures de re-ingénierie des logiciels, et les transitions technologiques échouent souvent, ou sont en proie à de gros disfonctionnements. D après les expériences vécues, ces échecs sont souvent dus à un manque d organisation, de l absence de méthode, de stratégie dans l effort de réingénierie. Les choix de stratégies ont un fort impact sur le succès ou l échec d un projet de réingénierie. Telle que les choix d architecture ont un impact essentiel sur la structure d un système, les orientations de stratégie de re-ingénierie sont difficile à changer et ont des répercutions tout au long du processus et un fort impact sur le résultat. Les entreprises n'ont pas de philosophie de maintenance claire et articulée malgré le fait qu'elles utilisent des méthodes structurées pour la conception ou le développement des applications. La maintenance est très mal planifiée et on surveille peu l'exécution des travaux de maintenance. le travail est peu valorisé, non reconnu et les expériences et la formation requises pour le personnel sont ambigu. leurs systèmes sont mis en application sans avoir aucune maintenance planifiée. L absence totale de procédés structurés de contrôles des changements alors qu'une grande partie des interventions de maintenance consistent à adapter le système à des changements demandés. Les recommandations que l on pourrait proposer sont les suivantes : Il faut favoriser l'adoption par la direction de l'entreprise d'une vision optimale entre la vision à court et à moyen terme Il faut convaincre la direction de l'entreprise de la nécessité et de l'importance de la maintenance Pour planifier la maintenance il faut l'intégrer dans la planification des technologies et systèmes d'information. Depoortere Franck

27 La qualité du management et la rétro-ingénierie La rétro ingénierie est un processus qui a des entrées et des sorties. Le processus peut être vérifié par un controle qualité, comme un produit industriel standard. Le contrôle de la qualité peut être appliqué pour : le processus, le système, les outils et pour le personnel impliqué. Il faut bien organiser le processus de contrôle. La responsabilité, l'autorité et les relations entre les personnes impliquées doivent être définies. L'expérience et la profession doivent être spécifiées pour chaque poste. Les standards de l'organisation, la vérification de l'organisation doivent être spécifiés pour chaque fonction. Après la rétro-ingénierie il faut s'assurer que le système satisfait la plupart des standards qui ont été appliqués aux systèmes. Il faut rendre le processus de retro-ingénierie comme une certification de qualité du système. Une documentation de qualité doit être produite, il faut inclure dans le plan une représentation graphique de la retro ingénierie. Il est presque impossible d'établir à l avance les demandes et les critères exactes de la rétroingénierie. Les outils statiques peuvent être appliqués pour vérifier la conformité entre le code et «coding standards». Les outils des mesures donnent la possibilité de comparer la complexité du logiciel avant et après la restructuration. Le REQP (Rétro Engineery Quality Plan ) doit décrire le management du processus. La documentation produite peut s effectuer sur plusieurs niveaux de détails. Il faut disposer de la gestion de toutes les versions de retro-ingénierie pour avoir une vue d'ensemble de tous les processus et produits réalisés Les standards REQP doivent être définis pour les produits de la rétro ingénierie. Le style de la documentation doit être choisi et un nombre minimum de demandes peut être donné. La vérification des produits doit être faite en respectant les demandes suivantes : Est-ce que la documentation satisfait les standards? Est-ce qu'elle est clairement et correctement décrite? Est-ce que le système est compréhensible pour la maintenance future? La vérification peut être faite par l'introduction d'une revue après un jalon dans le projet. La qualité de tous les outils utilisés pour la rétro ingénierie doit être vérifiée et pour prévenir toute dérive, il faut avoir un bonne formation pour les utilisateurs. La plupart des standards utilisés pour l'ingénierie en avant pourraient être utilisés pour la rétro ingénierie. Le besoin d'avoir des standards est certain. Le standards pour la maintenance doivent être bien définies pour donner au système actuelle un niveau de qualité satisfaisant. Schémas de développement La conception d un logiciel se résume à une activité intellectuelle s effectuant dans le cadre d un projet découpé en phases visant à exprimer une solution, sous la forme d un document normalisé. Phases du cycle de vie d un logiciel : Le découpage en phases d un projet de réalisation d un logiciel relève du souci de maîtriser l ensemble des tâches à réaliser estimer sa durée spécifier les éléments d informations et les ressources nécessaires à l application de la phase spécifier les fournitures et les résultats attendues en fin de phase, laquelle est ponctuée par une revue de phase, une réunion d avancement. La considération d une activité sous forme de phases n est pas seulement une forme commode de présentation, c est avant tout une contrainte industrielle indissociable de la trilogie coût, délais, qualité. Un autre aspect primordial de la qualité demandée par les clients d un système d information est celui de la maintenabilité du système. Un système d information automatisé ne doit plus être semblable à un «dinosaure», ou la moindre modification risque de mettre tout le système en péril. Le système doit être souple et évolutif. Pour s adapter rapidement à de nouveaux débouchés, les sociétés et les Depoortere Franck

28 organismes doivent pouvoir compter sur la capacité d adaptation au changement de leur système d information. Le dossier de conception décrit les axes majeurs que doivent suivre les programmeurs pour arriver à la solution souhaitée. Ce document sert aussi à montrer l avancement du projet aux personnes concernées. Il servira également plus tard aux équipes de maintenances. Une méthode de conception permet de définir ce que doit comporter un dossier de conception. Les directives expriment des indications sur la manière de remplir chacune des rubriques. L élaboration de documents standards pour la phase de conception constitue la part la plus prépondérante de l apport actuel des méthodes de conception. C est dans le contexte relatif à la normalisation des méthodes d analyse et de conception objet que s inscrit la notation unifiée. L effort d unification entrepris porte avant tout sur le méta-modèle définissant les modèles et la notation à employer. La démarche et la description des processus d analyse et de conception sont pour l instant libres. La présentation de la documentation constituant le dossier d analyse et de conception est également laissée à l appréciation des développeurs, chefs de projets, ou responsables méthodes et qualité. L adéquation entre la lourdeur d application d une méthode et son gain au niveau des résultats n est pas facile à trouver. Intuitivement, plus le projet est important, plus l utilisation d une méthode complète est rentable. On constate généralement que le ratio entre le temps passé hors codage et celui passé au codage croit avec la taille du projet. Ce ratio est compris entre 1 et 4. Plus ce ratio est grand, et plus l usage d une méthode et d un outils de conception est justifié. En outre, plusieurs modèles de maintenance exigent que les changements soient faits et documentés dans les spécifications des besoins et soient par la suite propagés vers le code source à travers les modèles d analyse et de conception. Ces modèles supposent donc un haut niveau de traçabilité comme facteur clé de maintenabilité. Les solutions Ce que nous proposons ici, n est pas la solution miracle pour réussir une réingénierie ou la construction d un gros projet. C est simplement une synthèse des procédures qui ont fait aujourd hui leurs preuves et qu il est sûrement sage de suivre. Depuis les années 90, des milliers d études ont été faites sur le sujet. Depoortere Franck

29 Chapitre 5 : Le processus logiciel, ou cycle de vie du logiciel Le processus logiciel désigne l'ensemble des activités nécessaires au développement et à la maintenance d'un logiciel. Il s'agit d'un processus variable (selon le type d'application) et complexe, composé de différentes phases inter-dépendantes. Un cycle de vie logiciel peut être défini comme une série de cycles de changements d états, déterminés durant son développement et son utilisation. Afin de tenter de résoudre la crise du logiciel, ce processus a fait l'objet de différentes modélisations. Les modèles ont formalisé les changements d états des cycles logiciels. Un modèle est la représentation d une entité, ou d un phénomène. Un plan d architecte est un bon exemple de la représentation d une idée, car il contient toutes les informations nécessaires à la construction du bâtiment. En terme logiciel, le modèle est la représentation abstraite des phases individuelles composant le processus. L historique et l évolution des cycles de vie des logiciels sont étroitement lié à l histoire de l informatique. Les développements logiciels étaient souvent suffisamment petit pour être développés et maîtrisés par une seule personne. Les modèles ont évolué en parallèle avec le changement de l ingénierie logiciels et les sciences informatiques en général. Rappelons que le niveau de maturité sur la maintenance logiciel est finalement assez récent. Il existe aujourd hui énormément de modèles de cycles de maintenance logiciel. Nous n en présenterons que trois, qui sont représentatifs des techniques de processus en général. Historiquement, le premier modèle de développement proposé est celui dit ``de la cascade'', au début des années 70. Ce modèle a été assez largement mis en oeuvre, mais on s'est rapidement aperçu qu'il n'était pas toujours approprié. Sa vision simpliste du processus sous-estime le coût des retours en arrière dans le cycle de vie. Ainsi, plusieurs alternatives au modèle de la cascade ont été proposées, basées notamment sur le prototypage et l'assemblage de composants réutilisables. Modèle de la cascade Dans ce modèle le principe est simple : chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes et activités. Ils sont soumis à une revue approfondie. On ne passe à la phase suivante que s'ils sont jugés satisfaisants. Les phases du modèle se présentent comme une cascade. Les sorties de phase deviennent les points d entrée de la suivante. Certaines phases portent le nom d'une activité, ce qui signifie que l'activité est essentielle pour cette phase, mais n'impose pas qu'elle n'ait lieu que dans cette étape. D'autres activités interviennent, par exemple le contrôle technique et la gestion de la configuration sont présents tout au long du processus. Le modèle met un point central sur la documentation écrite, qui conduit l ensemble des processus. La sortie de chaque étape doit être finalisée sous forme de documents, puis validée, afin de passer à la suivante. Les développements récents de ce modèle font paraître de la validation-vérification à chaque étape : Faisabilité et analyse des besoins : validation ; Conception du produit et conception détaillée : vérification ; intégration : test d'intégration et test d'acceptation ; installation : test du système. Beaucoup de modèles se basent sur celui-ci, avec certaines variantes, tout en gardant la philosophie du modèle. Les variantes ont souvent corrigé les petits défauts du modèle en cascade qui se trouvent dans sa nature trop séquentielle. Certains modèles ont donc introduit certains affinements à l ajout de retours en arrière Ces modifications ont été rajoutées ultérieurement sur la base qu'une étape ne remet en cause que l'étape précédente, ce qui, dans la pratique, s'avère insuffisant. Le modèle porte une autre défaillance, puisqu il ne tient pas compte de l évolution naturelle des logiciels. En effet, le modèle sanctionne toute correction tardive d erreur dans une étape précédente. Il ne tient pas compte des cycles naturels des logiciels qui tendent parfois, pour diverses raisons, Depoortere Franck

30 demander des modifications tardives sur les spécifications d un produit, et ceci dans une phase tardive du cycle de développement. Ceci arrive régulièrement lors de la construction d un projet, et ne peut pas toujours être considéré comme une erreur. L environnement évolue, et un système peut devenir incorrect sans toujours être causé par une erreur, mais parce que le monde est en constant changement. Les modèles qui ont repris les grands principes de ce dernier le rendent donc moins simpliste, et tentent de mieux l accommoder à certaines complexités. Analyse de besoins Spécifications Analyse et Conception Implémentation Tests Le modèle en cascade Mise en production Figure 6.1 : Le modèle en cascade Modèle en V Le modèle en V met l'accent sur le processus. Il confronte les différents niveaux de test avec les phases de projet de même niveau. Ceci permet à chaque étape de définir non seulement les fonctions, mais également les critères de validation. La cohérence entre les deux éléments permet de vérifier en continu que le projet progresse vers un produit répondant aux besoins initiaux. Ce modèle est adapté aux projets de taille et de complexité moyenne. C'est une amélioration du modèle en cascade traditionnel. Il permet d'identifier et d'anticiper très tôt les éventuelles évolutions des besoins. C'est aussi un moyen de vérifier la maturité des utilisateurs, car s'il en était autrement, ils se trouveraient dans l'incapacité de fournir des tests de recettes dès la phase de spécification. C'est un modèle avantageux pour une maîtrise d œuvre, rassurant pour une maîtrise d'ouvrage qui doit cependant s'engager significativement. Depoortere Franck

31 Expression du besoin Spécifications Tests de recette Conception Test d'intégration Développement Tests unitaires Mise en production Modèle en V Figure 6.2 : Le modèle en V Modèle en spirale Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il met l'accent sur l'activité d'analyse des risques : chaque cycle de la spirale se déroule en quatre phases : Détermination, à partir des résultats des cycles précédents - ou de l'analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ; Analyse des risques, évaluation des alternatives et, éventuellement maquettage ; Développement et vérification de la solution retenue, un modèle «classique» (cascade ou en V) peut être utilisé ici ; Revue des résultats et vérification du cycle suivant. L identification des problèmes et leur classification dans une échelle de risque vise à éviter les surcoûts imprévus. Ce modèle ajoute au modèle en cascade la notion de risque. C est le niveau de risque de chaque étape qui conduit le processus de développement. L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de développement classique. Un des avantages de ce modèle défini sur quatre axes, c est qu il peut être ajouté à d autres modèles. On peut ainsi tirer parti des avantages d un modèle, et pallier ses faiblesses en l accommodant au modèle en spirale. Néanmoins, le fait que le modèle soit fondé sur la mesure du risque pose certains problèmes. Lors de la rencontre d une difficulté, on est toujours tenté d effectuer la tache la plus facile en premier, et de repousser les difficultés à plus tard. Les équipes inexpérimentées peuvent tomber dans ce problème et confondre à tord l évaluation des risques avec le niveau de difficulté. Ce modèle a été moins expérimenté que les deux précédents. Sa mise en uvre demande de grandes compétences et devrait être limitée aux projets innovants à cause de l'importance qu'il accorde à l'analyse des risques. Néanmoins, ce dernier concept peut être appliqué aux autres modèles. Depoortere Franck

32 Tem ps / cout Développem ent logiciel / Evaluation en s pirale à travers 4 phases Evaluation des alternatives Identification des ris ques Identification des objectifs, des contraintes et des alternatives Développem ent et vérification Panification de la prochaine phase Figure 6.3 : Le modèle en spirale Depoortere Franck

33 Les modèles de maintenance Le besoin de modèles de maintenance a mainte fois été reconnu, mais la situation actuelle est que les modèles de maintenance sont ni vraiment développés ni vraiment bien compris et n appliquent que les modèles de développement. Aux débuts de l informatique, les problèmes du aux développement étant accablants. On a donc longtemps ignoré les procédures de maintenance en ce concentrant plutôt sur les procédures de développement. Toutefois, une lente évolution est en train de s opérer et on consacre peu à peu au moins autant d importance aux procédures de maintenance qu aux procédures de développement. Il est important de connaître les différences entre les nouveaux développements et la maintenance logicielle, mais il est également important d en connaître les similarités. L industrie informatique préfère trop souvent refaire totalement un logiciel plutôt que d effectuer de lourdes modifications. Si l on fait une analogie avec la construction et l entretien d un immeuble, il serait inconcevable de détruire un immeuble afin d en restructurer certains étages. On en modifierait les plans, on effectuerait une étude de ré-agencement, tout en tenant compte des problèmes logistiques, techniques, causés par le déménagement des personnes et du mobilier éventuellement, ex,. On rencontrera vraisemblablement des problèmes comparables lors d une procédure de maintenance adaptative d une application logicielle. Les interfaces seraient changées, le modèle original modifié, les fonctionnalités modifiées, ajoutées, et les structures de base de données altérées. Enfin, la documentation interne du logiciel serait mise à jour afin d énumérer les changements effectués. En pratique, les immeubles sont beaucoup mieux documentés que les logiciels. Le cœur du problème dans le modèle traditionnel de développement est la non prise en compte de la nature évolutive d un logiciel. Il existe beaucoup de modèles de maintenance, mais nous nous contenterons d en exposés les 3 principaux : Le modèle de Boehm : En 1983, Boehm propose un modèle sur la maintenance logicielle basé sur des principes économiques. Il n est en effet pas faux de se baser sur des principes qui ont fait leurs preuves, et il est clair que l aspect économique des activités a des influences énormes sur la conduite des projets. Boehm propose d améliorer la productivité de la maintenance en se basant sur des modèles économiques. Il présente la maintenance comme un processus de boucle fermée. Il défini la relation économique entre les activités en différentes phases de vie du logiciel, et les bénéfices tirés, selon trois phases : Investissement : c est une phase de dépense, ou le bénéfice est encore invisible. Récompense : l entreprise perçoit les améliorations de sa productivité lorsque les premières phases de maintenance sont lancées. Stabilisation des retours sur investissement : Arrivé à un certain point, la courbe d amélioration des bénéfices ralentit. La productivité optimale est presque atteinte. On recherche maintenant à effectuer des changements radicaux afin de dépenser moins. Depoortere Franck

34 Decision des responsables Proposition des changements Approbation des changements à effectuer Evaluation Implémentation des changements Résultats Nouvelle version du produit Utilisation du logiciel Figure 6.4 : Modèle de maintenance de Boehm Depoortere Franck

35 Le modèle d Osborne La grosse différence du modèle proposé par Osborne avec le modèle précédent, est son adaptation à la réalité, aux situations effective des applications, de l environnement de maintenance, moins idéale que les situations prise en compte dans les modèles. Les autres modèles tendent en effet à idéaliser les situations en se référents à une documentation complète par exemple. Ce modèle de maintenance est présenté comme une itération continue du cycle de vie, avec à chaque étape une vérification de l état de maintenabilité de l application, et la mise en place des taches à effectuer afin de l améliorer. Si le niveau de maintenabilité est satisfaisant, que les spécifications et la documentation sont réalisées et à jour, le modèle valide l état comme bon. Si au contraire, l application à un niveau de maintenabilité insatisfaisant, le modèle invite à la correction du système. L hypothèse d Osborne, c est que les problèmes de maintenances logicielles sont du à un management inadapté et des procédures de contrôles défaillants. Le modèle inclus systématiquement le changement des spécifications lors de procédures de maintenance de l application. Il propose également d établir un circuit d assurance qualité validant les demandes de changement effectuées. Enfin, il insiste sur le fait de vérifier que la maintenance réalisée à bien atteint son but et propose de passer systématiquement en revue les taches réalisées. Identification des besoins et des changem ents à effectuer Dem ande de changem ents Analyse de faisabilité Dem ande de changem ents Planification de la tache Phas e d'analyse Phas e d'analyse Revue d'analyse Modification du code Vérification des changem ents effectués Tes t Mise à jour de la docum entation procédure d'audit Validation de l'utilisation Installation des changem ents dans une nouvelle version du logiel Figure 6.5 : Modèle d Osborne du processus de maintenance Depoortere Franck

36 Le modèle de rehaussement itératif Ce modèle se base sur le fait que l implémentation de changements sur un système logiciel à travers son cycle de vie est un processus itératif et induit l amélioration progressive du système. Adapté à la maintenance, le modèle exige la complète documentation de l application et la mise à jour de celle ci à chaque début d étape du modèle. Le modèle se décompose en un cycle de trois étapes : l analyse du système existant l étude d impacte des modifications proposées la procédure de conception et d implémentation des changements demandés La documentation existante appartenant à chaque étape (cahier des charges, analyse, codage, test), est modifiée avec un haut niveau de qualité et d attention. Il se fonde sur le fait que l environnement de la maintenance est souvent sujet à des demandes de changements urgents, tout en gardant à l esprit que les solutions trop rapides conduisent souvent à de plus gros problèmes. Ce modèle s accommode facilement aux autres. Néanmoins, Le problème du modèle est qu il se fonde sur l hypothèse d une documentation complète et à l habilité de l équipe à analyser et connaître l intégralité du produit logiciel. Synthèse Tous les modèles ont leurs forces et leurs faiblesses. Aucun modèle n est approprié à toutes les situations, et il faut souvent combiner différents modèles pour trouver une bonne solution. Un processus de vie est toujours un mode de fonctionnement idéalisé. Malgré tout, ces méthodes ont fait énormément progresser les méthodes de programmation, du début de l informatique, ou les utilisateurs étaient aussi les programmeurs de l application (mathématiciens, physiciens, ) aux méthodes structurées des gros projets. Les processus de vie formalisés sont souvent plus rigide que la réalité reflété, car ils sont trop cloisonnés en phases rigides. Ils n autorisent généralement pas les différents retours en arrière. Le processus formalise le cycle de fabrication, de maintenance des applications. On passe grâce à ces méthodes d une programmation archaïque à des méthodes structurées. On s aperçoit que la plupart des sociétés ont construit leur propre cycle de processus en adaptant les modèles standards de l industrie logicielle. Il y a autant de modèles de processus que de sociétés, mais le but reste le même, c est de suivre des règles écrites et planifiées, et donc de parvenir à industrialiser son activité. Or penser que la culture de documentation des applications est parfaitement réalisée est une situation qui ne reflète pas du tout la réalité. Depoortere Franck

37 Chapitre 6 : La présentation des données En génie logiciel, une présentation claire et visuelle d'un logiciel peut augmenter, de façon significative, l'effet de sa compréhension. De nos jours, beaucoup de techniques et d outils de visualisation logicielle (VL) sont disponibles aux développeurs pour les aider entre autres à la bonne compréhension de leurs logiciels. Il peut s'agir d'outils d'analyse, de test, de débogage ou encore de maintenance. Afin de "comprendre" des logiciels de grande taille, l'utilisation d'outils de VL a été proposée. Mais peu connaissent les impacts positifs ainsi que les limitations de ce genre d'outils. De plus, les propriétés désirées de tels outils n'ont guère été investiguées. Dans le cadre de notre projet de réingénierie, nous désirons évaluer les outils de VL et trouver des réponses aux questions ci-hautes. Atelier de génie logiciel, ou outils CASE Un AGL (Atelier de Génie Logiciel) ou atelier CASE (Computer Aided Software Engineering) est un logiciel aidant à la réalisation de logiciels. Autrement dit, il s'agit d'un système pour le développement logiciel assisté par ordinateur. Un AGL intègre des outils adaptés aux différentes phases de la production d'un logiciel et facilite la communication et la coordination entre ces différentes phases. Un AGL est basé sur des méthodologies qui formalisent le processus logiciel, et à l'intérieur de ce processus, chacune des phases qui le composent. Les AGL apportent une réelle solution à certains problèmes du génie logiciel et contribuent nettement à l'amélioration de la productivité et de la qualité du logiciel, notamment en faisant le suivi des différentes phases du processus logiciel et en offrant un cadre cohérent et uniforme de production. Néanmoins, cet enthousiasme doit être modéré: le processus logiciel est encore loin d'être maîtrisé et les différentes formalisations qui en sont proposées font encore l'objet de controverses, et dans tous les cas, sont bien loin d'être totalement automatisables. Les AGL intègrent différents outils d'aide au développement de logiciels, appelés outils CASE: éditeurs de texte (vi, emacs,...), de diagrammes (TRAMIS VIEW, X-fig,...), outils de gestion de configuration (make, cvs, ), SGBD, compilateurs, debuggers, outils pour la mise en forme (prettyprinters), la génération de tests, la génération d'interfaces homme-machine,... Ces différents outils interviennent lors d'une ou plusieurs phases du cycle de vie du logiciel: conception (éditeurs de texte, de diagrammes,...), programmation (éditeurs de texte, compilateurs, pretty printers, générateurs d'interfaces homme/machine...), mise au point (debuggers, outils de génération de tests,...), etc,... Certains outils, concernant notamment la gestion de configurations, la gestion de projet, interviennant durant la totalité du processus logiciel. Un AGL intègre différents outils CASE, de manière à les faire coopérer de façon uniforme. Cette intégration peut s'effectuer à deux niveaux: Intégration des données: Les outils CASE manipulent, génèrent, et transforment des données: spécification, modèle conceptuel des données, jeux de test, code, manuel utilisateur,... Différents outils sont amenés à partager une même donnée: les tables générées par un éditeur de diagrammes sont utilisées par un SGBD, le code généré par un éditeur de texte est compilé par un compilateur, à partir d'une spécification algébrique on peut générer des jeux de test,... Intégration des activités: un AGL peut gérer le séquencement des appels aux différents outils intégrés, et assurer ainsi un enchaînement cohérent des différentes phases du processus logiciel. Cet aspect implique que l'on dispose d'un modèle du processus de développement bien accepté (ce qui relève parfois un peu de l'utopie). Depoortere Franck

38 On distingue essentiellement deux types d'agl selon la nature des outils intégrés: 1. Les environnements de conception (upper-case): ces ateliers s'intéressent plus particulièrement aux phases d'analyse et de conception du processus logiciel. Ils intègrent généralement des outils pour l'édition de diagrammes (avec vérification syntaxique), des dictionnaires de données, des outils pour l'édition de rapports, des générateurs de squelettes de code, des outils pour le prototypage,... Ces ateliers sont généralement basés sur une méthode d'analyse et de conception (JSD, Yourdon, Merise,...) et utilisés pour l'analyse et la conception des systèmes d'information. 2. Les environnements de développement (lower-case): ces ateliers s'intéressent plus particulièrement aux phases d'implémentation et de test du processus logiciel. Ils intègrent généralement des éditeurs (éventuellement dirigés par la syntaxe), des générateurs d'interfaces homme/machine, des SGBD, des compilateurs, optimiseurs, pretty-printers, debuggers,... Le temps des budgets informatiques incontrôlables est fini. Nous devons rendre ce service à moindre coût, dans des délais courts, avec un degré de qualité et de fiabilité accrue. Et seuls des outils permettent ces gains de productivité. Il est évident que dans le monde de l'informatique, les ateliers de génie logiciel ont fait leur preuve. Un outil de production automatique évite un grand nombre d'erreurs syntaxiques, parfois très coûteuses en temps de debuggage. Et quand on programme pour une entreprise, on n'a pas le droit de se mettre en situation de devoir résoudre des anomalies dues à ce type de fautes. Depoortere Franck

39 Langage de Modélisation Objet Unifié (UML : The Unified Modeling Language) La réalisation de logiciels industriels ou de systèmes d information informatisés demeure une activité professionnelle difficile. Malgré les progrès apportés par le génie logiciel, les développements d applications répondants aux besoins exprimés se rationalisent lentement. En revanche, l offre d outils de développement ne cesse de croître et l importance des langages de programmation est toujours prépondérante. De plus en plus d applications utilisent même plusieurs langages de programmation dans le cadre d un projet unique. Nous constatons enfin un intérêt grandissant pour les méthodes de spécification et de conception, en particulier celles qui sont basées sur les principes issus des technologies objets. Les méthodes d analyse et de conception orientées objets ont atteint une certaine maturité. D un contexte pléthorique, UML s est dégagée pour devenir le standard de la technologie objet. La réutilisation et l'exploitation de composants logiciels ("sur étagère"), issu de la technologie objet, sont les principaux facteurs de ce succès. Dans ce contexte de programmation objet, UML semble devenir une référence en matière de langage de description de système et d'aide à la conception. L'Uml est un langage pour indiquer, visualiser, construire et documenter des systèmes. L adoption de l UML pour la communauté d analyse, de conception et de développement de logiciels a favorisé les échanges entre les intervenants impliqués dans l élaboration d un logiciel. Cette situation contraste fortement avec la communauté de maintenance des logiciels. La modélisation des logiciels déjà implantés ne répondent à aucune norme. Devant ce résultat peu satisfaisant, des communauté de maintenance ont préconisé l unification des outils et processus de développement et de maintenance. Les outils de maintenances devront donc passer par la compatibilité avec le modèle UML. L obstacle essentiel à cette normalisation des outils de développements provient du fait que le modèle UML a été construit pour la modélisation de logiciel et non pour des logiciels déjà en place. La grande faiblesse d UML est son incapacité à modéliser explicitement le code source implémenter dans les méthodes. Or, la compréhension du code est essentiel dans les étape de rétro conception, conception et réingénierie. UML : Un méta-modèle Lors d'un développement logiciel, le langage naturel nous permet de communiquer les besoins, les langages de programmation nous permettent de mettre en place une implémentation du système. Le langage d'implémentation deviendra certainement un jour obsolète, par contre il existe un langage qui peut subsister à travers tout le cycle de développement du logiciel ou du système, fondamentalement le pont entre l'implémentation du système et les conditions et besoins du système: Unified Modeling Language (UML) de Object Management Group (OMG). La notation UML est dit logique, car normalement indépendant du langage de programmation cible utilisé. Par définition, la notation UML n est pas spécifique à un langage de programmation par objet. Elle peut donc être utilisée avec n importe quel langage objet tel que SmallTalk, Ada, Eiffel, C++, ou JAVA Le développement d'un système peut être caractérisé comme la résolution d'un problème, comprenant la compréhension et la conceptualisation du problème, implémenter sa solution. La conceptualisation d'un problème, implique la représentation d'un problème en utilisant une structure de représentation. Résoudre le problème, implique la manipulation de représentation du problème et sa solution. Implémenter une solution implique de tracer, de construire la solution. L'utilisation de ces constructions est un processus naturel qui conduit naturellement et inconsciemment à résoudre le problème. Depoortere Franck

40 Pour comprendre l'architecture de l'uml, observons les programmes d'ordinateurs. Il y a énormément de langages de programmation différents (C, C++, Java, SmallTalk, etc.), et chaque programme est développée en utilisant un langage spécifique. Tous ces langages supportent une variété de construction déclarative des données, et de procédures de construction de manipulation des données. Parce qu'un modèle est une abstraction, chacun de ces concepts peut être capturé dans un ensemble de modèles relatifs, un meta-model. Figure 6.0 : Describe L histoire d UML L UML est né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet au milieu des années 90 : OMT, Booch et OOSE. Issu "du terrain" et fruit d'un travail d'experts reconnus, UML est le résultat d'un large consensus. De très nombreux acteurs industriels de renom ont adopté UML et participent à son développement. L'approche objet est pourtant loin d'être une idée récente. Simula, premier langage de programmation à implémenter le concept de type abstrait à l'aide de classes, date de En 1976 déjà, Smalltalk implémente les concepts fondateurs de l'approche objet : encapsulation, agrégation, héritage. Les premiers compilateurs C++ datent du début des années 80 et de nombreux langages orientés objets "académiques" ont étayé les concepts objets (Eiffel, Objective C, Loops...). Dans les années 80, on disposait donc d un nombre important de langages orientés objet, et autant de méthodes de représentation de ces objets. Pour remédier à ces inconvénients majeurs de l'approche objet, il fallait donc un langage universel (pour s'exprimer clairement à l'aide des concepts objets), qui devait permettre de représenter des concepts abstraits (graphiquement par exemple), limiter les ambiguïtés (parler un langage commun, au vocabulaire précis, indépendant des langages orientés objet), faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions). Depoortere Franck

41 Les concepteurs avaient également besoin d une démarche d'analyse et de conception objet, pour ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le départ, définir les vues qui permettent de décrire tous les aspects d'un système avec des concepts objets. La prise de conscience de l'importance d'une méthode spécifiquement objet ("comment structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements, mais sur les deux"), ne date pas d'hier. Plus de 50 méthodes objet sont apparues durant le milieu des années 90 : Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE... L'OMG, une association qui fédère 850 importants acteurs du monde informatique, dont le rôle est de promouvoir des standards qui garantissent l'interopérabilité entre applications orientées objet, a proposé UML en réalisant une synthèse des méthodes OMT, Booch et OOSE. Les plus gros acteurs industriels ont tout de suite adopté UML. En quelques années, cette méthode est devenue un standard universel dans la modélisation des applications Orientées Objets, et des bases de données. A tel point que la conception d application en langage objet, qui n utiliserait pas UML deviendrait une hérésie Logiciels AGL ou Origine CASE Imagix 4D Imagix est un outils de reverse-engineering d analyse et de documentation de logiciels "!$#&%' ()( *+-,.0/ ;: 7<5>=@?-AB1DC: A E4?@=@3GFH5>=@: 9;I : 7 J?@KL=@9BM E49B=@14JN=@1149OFHP"F49<51H5Q?@1JN1HP"14JN3G1149 M =R9 1414JN=R9 MS3G7 J?@143TC:UABV4?@143TA 1XW F43G143TAB1YA : 9 9 E4143DJ614?@FH5>=@:U9B9 14?@?R143 1H5[Z\IBF4J]5>=@JA 18C:UABV4?@143A 18^H?RF43H3G143U_ Référence m/ Rational Rose : `[babc0d "e dfc0abfcg Rational Rose est le leader mondial dans la modélisation UML. C est par contre l un des plus couteux. L application propose un outils de liaison avec les outils de développement les plus connu, tels que Borland Jbuilder, Visual Age pour Java, et les outils de développement Delphi hjilknmno>prq i s A 1 t u q)vlo>mnvlw iloyx 14365[7B9:U705>=@? AB1 ^G:U9 ^G14I05>=@:U91H5[A 1\ABEHP"14?@:UI IB14C14905[*zQ#g{} 7 =B=@9 ^G?@705 A 143~:U9 ^65>=@:U9B3A 1\C:UABE4?@=@3GFH5>=@:U9^G:UCIB?@VH5>143 F43G3G:U^G=@E4143Z\A >=@?@= 5>F4=RJN143A 18A EHP"14?@:UIBI 14C149<5 :UJ6=@149<5>E43IBJN:UAB7 ^65>= P"= 5>E4{}3H=RCIB?@= ~6=@F4905[?@1435> 4^G 143 A LF49BF4? ƒ"3g14{)ab1\c: A E4?@=@3GFH5>=@: 91H5[AB L=@CI?@E4C149<5>FH5>=@: 9 A F49B3?@143:UJ6M F49 =R3HFH5>=R:U9 35>J6FHPlF4=R?@?@F49<5QFHPl14^?R143?@F49BM F4M 143Q vl bv {" ˆ {}1H5[3GKL=@9<5>V4MBJN1\FHP"14^?@143 I J6=@9 ^G=@IBF47<ŠO h[œ _ PowerDesigner Sybase Méta Edit + Tableau 6.1 : Logiciels AGL ou CASE Power Designer est un concurrent direct de Describe et Rationnal Rose, et dispose de fonctionnalités similaires (gestion des MPD, MCD, MOO, reverse ingeniering, ). Par contre il n offre pas d architecture client serveur qui permet à Describe de travailler en équipe sur le projet. Depoortere Franck

42 TraceIT, e-traceit Data Integrity CodeSurfer GrammaTech [GrammaTech] Code Integrity Management System Programming Research Ltd. Concerto 2 / AUDIT Sema Discover Upspring Software Genitor Object Construction Suite Starbase Corp Reengineer McCabe & Associates HindSight Integrisoft SNiFF+ Wind River Systems Telelogic Tau Logiscope Telelogic ASG-Insight ASG Software Solutions InstantQA, Reasoning5, Refine Reasoning Systems Tableau 2: Sélection d'outils commerciaux dans la communauté de maintenance Figure 6.2: Diagrammes MERISE, NIAM, OMT, UML : les différences et les points communs entre les méthodes de modélisation de données Depoortere Franck

43 Les démarches d analyse et de conceptions ne sont pas abordées par l UML. Il revient à chacun des utilisateur d UML de fixer son propre processus de développement. Il ne normalise pas les phases de conception, d analyse, de l ingénierie logiciel. La référence à UML indique que les représentations données sont conformes au formalisme proposé. Cela ne veut en aucun cas dire qu une démarche normalisée est appliquée. La notation unifiée facilite la compréhension et la communication d une modélisation objet. De nos jours, programmer dans un langage orienté objet, c est donc bénéficier d une panoplie impressionnante d outils d aide à la conception réalisation et maintenance d applications (modélisation, conception, ingénierie inverse, etc., ), et de langages performants. L approche objet est donc devenue aujourd hui une technologie incontournable, permettant de concevoir et d entretenir plus facilement des logiciels complexes capable de mieux résister aux évolutions incessantes. Néanmoins, l approche objet est beaucoup moins intuitive que l approche fonctionnelle. Malgré les apparences, il est plus difficile de décomposer un problème informatique sous forme d interaction entre objets que sous la forme d une hiérarchie de fonctions atomique. L objet est une technique qui n est entièrement maîtrisée qu après de nombreuses années de développements. Depoortere Franck

44 Proposer de nouvelles structures de représentation : La représentation 2D statique est peut-être beaucoup trop figée, et on arrive rapidement à rendre les schémas totalement incompréhensibles. Les visualisations techniques sont dépendantes des données concrètes : Depoortere Franck

45 But : Maximiser l automatisation en minimisant l intervention humaine. On peut faire appel à des techniques du domaine statistique, de la théorie des graphes, à l Intelligence artificielle. Avec l approche par la théorie des graphes, on déduit petit à petit, la fonctionnalité du code. Graphe de référence des objets : attention, la représentation d un graphe n ai pas évidente, puisque qu il doit être suffisamment synthétique pour être compréhensible. En effet, un graphe trop complexe et touffu peu devenir rapidement illisible. Figure x : Une représentation 2d statique peut rapidement devenir incompréhensible Une première approche sur l ensemble de l application est de former une représentation graphique de l ensemble. Le problème majeur d une telle représentation est quelle deviennent très facilement incompréhensible, lorsque l on tente de mettre un maximum d informations sur un petit espace, cantonner de plus souvent à deux dimensions, dans un environnement statique. Le but consiste à obtenir une représentation mentale du logiciel afin d avoir différents degrés de compréhension, d abstraction. Il faut ensuite pouvoir naviguer dans cette représentation graphique afin d atteindre différents degrés de détails. La réalité virtuelle permet d avoir cette approche dynamique et interactive. Ce concept a eut beaucoup de succès dans la visualisation de l information par l intermédiaire d un moteur full text sur une base de données Figure 3x : Une représentation dynamique pourrait facilité la compréhension Synthèse : Un modèle est une vue subjective, mais pertinente de la réalité. Un modèle définit une frontière entre la réalité et la perspective de l'observateur. Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects importants de la réalité, il en donne donc une vue juste et pertinente. Le caractère abstrait d'un modèle doit notamment permettre de faciliter la compréhension du système étudié. Il réduit la complexité du système étudié, permet de simuler le système, le représente et reproduit ses comportements. Concrètement, un modèle réduit (décompose) la réalité, dans le but de disposer d'éléments de travail exploitables par des moyens mathématiques ou informatiques. Depoortere Franck

46 Chapitre 7 : Application: Retro-ingénierie d un viewer de données cartographiques Enoncé du problème : Nous allons maintenant présenter un cas pratique de reprise d une application. Nous souhaitons reprendre un cycle de maintenance sur une application de cartographie. L état de l application est un cas illustrant idéalement la crise du logicielle évoquée précédemment. En effet, l application à un historique complexe, et une équipe de développement restreinte, avec peu de budget. Le développement de l application s est de plus réalisé d une façon très éparse, au fils du temps, et de façon peu formalisée. Nous disposons donc aujourd hui en tout et pour tout du code source de cette application, écrite en C, une documentation très succincte, les développeurs d origine sont inaccessibles, et un code source restée partiellement inachevée, et non documenté. La tache de maintenance est donc d ores et déjà un gros chalenge, puisqu il va falloir effectuer un important travail de retro-ingenirerie avec beaucoup de rigueur et surtout une patience et un acharnement certain. Un facteur déterminant de réussite de la tache sera contenue dans notre travail méthodique et structuré, mais aussi influencé par la qualité de la structure de codage du logiciel. Certaines applications s avèrent en effet si complexe et mal conçue qu il est parfois impossible de les débuggeur ou de comprendre leur fonctionnement détaillé. Avant, de commencer les phases d analyse de l application, il est nécessaire de connaître globalement le sujet traité par l application, le traitement de l information géographique. Cette petite étude nous sera en effet par la suite d une grande aide pour la suite de notre analyse. Nous présenterons ensuite brièvement l application et ses fonctionnalités. Par la suite, nous commencerons notre tache de re-ingénierie du produit ViewerSig32. Ce travail plus technique sera décomposé et exposé dans l annexe du mémoire, dédiée au travail de redocumentation de l application. Depoortere Franck

47 Qu est ce qu un SIG : Avant de nous lancer dans l étude technique de l architecture logiciel de SIG32, ouvrons une brève parenthèse, en définissant un système d information géographique général. Le logiciel de SIG offre des outils pour stoker, analyser et afficher des informations géographiques. Un SIG est composé de quatre outils majeurs : un outil pour saisir et manipuler les informations géographiques un système de gestion de base de données un outil de requête géographique, d analyse et de visualisation une interface graphique utilisateur, pour une exploitation facile de l information Le concept d un SIG est de stoker des informations sous forme d objets thématiques reliés à des données topographiques. Les données topographiques sont des relevés de points (latitude, longitude, ou grille de coordonnées nationales), et les données géographiques gérées dans le SIG par le géocodeur, sont des objets localisés. Les objets géographiques sont rangés dans diverses catégories : les objets ponctuels, rattachés à un seul point (un arbre, un réverbère, une borne kilométrique, ) Les objets linéaires, rattachés à une succession de points, alignés ou non, et représentés par un symbole linéaire (trait plein, pointillé, ). Par exemple, une bordure de route, de cours d eau, Les objets surfaciques, rattachés à une succession des points dont les liaisons reviennent au point de départ et peuvent être représentés par un symbole surfacique : un bâtiment, une parcelle de propriété, un lac, L information géographique contient soit une référence géographique explicite (latitude & longitude ou grille de coordonnées nationales) ou une référence géographique implicite (adresse, code postal, nom de route ). Le géocodage, processus automatique, est utilisé pour transformer les références implicites en références explicites et permettre ainsi de localiser les objets et les événements sur la terre afin de les analyser. Les SIG exploitent deux catégories de modèles de données : Le modèle vecteur Dans le modèle vecteur, les informations sont regroupées sous la forme de coordonnées x, y. Les objets de type ponctuel sont dans ce cas représentés par un simple point. Les objets linéaires (routes, fleuves ) sont eux représentés par une succession de coordonnées x,y. Les objets polygonaux (territoire géographique, parcelle ) sont, quant à eux, représentés par une succession de coordonnées délimitant une surface fermée. Le modèle vectoriel est particulièrement utilisé pour représenter des données discrètes. Le modèle raster Le modèle raster, quant à lui, est constitué d une matrice de points pouvant tous être différents les uns des autres. Il s adapte parfaitement à la représentation de données variables continues telles que la nature d un sol Chacun de ces deux modèles de données dispose de ses avantages. Un SIG moderne se doit d exploiter simultanément ces deux types de représentation. Notre application SIG32 est un moteur gérant des données. Sa finalité consiste à bien visualiser des cartes et des graphes. La carte est en effet un formidable outil de synthèse et de présentation de l information. Depoortere Franck

48 L information représentée par le viewer peu être de multiples natures. Les SIG s appui sur des thèmes et catégories d informations souvent catalogués : Les données cartographiques de base : les routes, les limites administratives, les cours d eau, Les données sectorielles : informations sur la démographie, aspects financiers, télécommunication, sécurité,. Les données environnementales : informations sur l environnement, ressources naturelles, climats, L usager devra d abord se poser la question de l usage de la finalité sur l analyse et la représentation des données géographiques. Le principe de géocodage : Le géocodage consiste à organiser des données, afin de mettre en œuvre les liens entre les données fournies au système de cartographie et leur représentation cartographique. Une définition plus large de la géocodification est l action de transformation de données numériques localisables vers des objets visualisable, exploitable par le SIG. Par exemple, le géocodage des adresses d habitants d un territoire consisterait à traiter les données pour que les adresses des personnes soient visualisable sur une carte routière présentée par le Sig. Les objets «adresse» seraient donc associés à des coordonnées X,Y, par exemple. Le principe de géocodage des objets est généralisable à toute surface ou point identifié : ilot, parcelle, batiment, route. Mots clés : IGN : L Institut Géographique National est un établissement public à caractère administratif qui a été crée le 1 er juillet 1940, afin d échapper à l occupant. Il a succédé au service géographique de l armée, dissout le même jour. Il compte aujourd hui environ 2000 personnes dont 400 ingénieurs. C est l IGN qui est chargé en France, d établir la cartographie de base, ainsi que l équipement géographique de base. Topométrie : pratique des mesures, angles et altitudes sur le terrain Depoortere Franck

49 Première prise en main de VIEWERSIG32 : L application SIG32 est un cas d école pour mettre en application les quelques principes d ingénierie évoqués plus haut. En effet, cette application à été réalisée par une équipe réduite. Comme la plupart des micros-structures, on ne suivait pas de méthode de développement élaborée, avec un cycle de cahier des charges, de spécification écrit, de document de conception, de validation, de documentation des changements effectués,.. De plus, les quelques documents réalisés ont pour la plupart, été égarés. Ce cas arrive quelque fois dans le monde de l industrie logicielle. Nous disposons donc du code source de l application, écrite entièrement en C, et une interface utilisateur utilisant les bibliothèques Microsoft win32. La première ouverture de l application permet rapidement à l utilisateur d ouvrir une base géographique, qui nous dévoile en l occurrence la cartographie des départements de la France. C est par la suite que l action se complique, puisque l on ne sait pas précisément quoi faire avec la carte Apres un peu de recherche et de tâtonnements, nous parvenons à effectuer quelques zooms, et à afficher des informations sur les objets géographiques pointés. On découvre par la suite l utilisation de filtres de recherches, des fonctions de sélections de différentes familles d objets,. Figure 4: Capture du Viewer Après quelques heures d utilisation, nous commençons à nous familiarisé avec les outils de l application. Globalement, l application semble avoir vieillie, par rapport aux applications actuelles, beaucoup plus conviviales et intuitives (les derniers développements sur l application datent de 1995). Pourtant, l outils semble offrir des fonctionnalités très puissantes, et présente globalement un outils d informations géographique de bonne facture, même s il faut un certain temps d adaptation. Les critères de sélection et d affichage sont évolué, et l application possède toutes les fonctionnalités essentielles à une application SIG. Figure 5 capture du viewer : on zoom sur une zone du département Depoortere Franck

50 Ré-ingénierie de l application ViewerSIG32 Les étapes de re-ingénierie de l application présente ont été réalisées dans l annexe du mémoire. Les étapes de cette étude se sont révélées assez difficile. Même si la première prise en main du logiciel c est réalisée relativement rapide en tant qu utilisateur, la documentation de l architecture de l application c est présentée tout à fait complexe et à induit de longues investigations. En effet, de multiples difficultés se sont mêlées à la grosseur importante de l application : D une part, il est nécessaire pour comprendre une application cartographique, de comprendre en détail la façon dont les données sont traitées, et représentées. D autre part, l écriture en langage C de la presque totalité du logiciel et le caractère peu lisible de ce langage fonctionnel n ont pas facilité le travail de documentation du code source. L utilisation d un langage orienté objet aurait permis en effet de faciliter le travail de compréhension, de part sa structure mais aussi par l utilisation de logiciels de reverse engineering, très nombreux dans le monde objet. Enfin, dans la phase de correction des bugs, il nous a été longtemps difficile de parvenir à compiler la totalité du code source, de part la vieillesse des bibliothèques utilisées et par certains trous et codes perdus ou incomplets. Ainsi, même s il nous sommes, par notre persévérance, finalement parvenu à re-documenter la majeure partie de l application, nous avons seulement ouvert la première étape de ce travail de réingénierie. En effet, la grande complexité de l application nous interdisait dans les temps impartis d effectuer la totalité de ce travail. La documentation présentée n offre qu une première étape de l entrée dans un processus industriel Il ouvre les voies vers des processus de travail élaborés. Si nous avions fait des documents exhaustifs, seul une parcelle minime de l étude aurait pu être présenté. En effet, seul le document de conception, le cahier des charges et les spécifications fonctionnelles de l application aurait pu combler notre temps. Nous avons souhaité dans ce mémoire montrer une plus large vue de l activité d ingénierie logiciel en générale, et tenté de parcourir et présenter l intégralité d un processus de développement élaboré, tel qu il est conduit en équipe dans l industrie. Pourquoi avoir choisi ce sujet: Après une expérience professionnelle de près de trois ans dans le domaine du développement logiciel, je commence à avoir une vue globale des méthodes de développement pratiquée dans l industrie de l édition logiciel. J ai été assez frappé par le manque de rigueur, de méthode lors des phases de développements, qui conduisaient souvent à de constants remaniements, corrections d urgence, et finalement au mécontentement constant des clients. Pour toutes ces raisons, je n ai pas choisi dans mon mémoire de développer une nouvelle petite application et montré mon savoir-faire de codeur, mais préféré mètre l accent sur l importance de suivi de processus de développement élaborés, dans la construction et la maintenance de produits logiciels industriels. D autre part, j ai choisi l étude d une application qui m était totalement inconnue, l informatique géographique. En effet, l application SIG32 illustrait idéalement la mise en application des méthodes d ingénierie citées dans le mémoire. Depoortere Franck

51 Chapitre 8 : Conclusion Solution pour une maintenance moins coûteuse des applications : Il faut s'imposer des processus formels de développement : processus d'assurance qualité, existence de points de contrôle, la méthode doit être structurée, phasée, avoir des produits finis en fin de phase : inspection et validation après chaque phase du développement être automatisée, être adaptable, avoir un processus formel et exhaustif de tests utiliser de préférence une technologie à jour (objets, Java, AGL, etc.) Suivre une méthode de gestion de projet, phasée. Les techniques de suivi de projet informatique sont lourdes, adaptées aux gros projets. Le respect d'une méthode est pourtant indispensable pour maîtriser toute activité de programmation, même élémentaire. Bien documenter le code source : en effet, même si l on a l impression de perdre du temps, on en gagne beaucoup par la suite. Attention lors de modifications de code, à la cohérence du code source. Avoir un processus de liaison de la documentation au code Peut être que finalement, il est dans la marche normale des choses d avoir une procédure d amélioration lors de phases de réutilisation du code, ou de réingénierie. Le code est souvent amélioré lors de revues de code. L auteur doit avoir un regard extérieur sur son code pour se rendre compte de ses erreurs, de ses omissions Un processus de compréhension est composé de l addition de différentes techniques. Il n y a pas de solution toute faite, de solution miracle. Depuis le début des années 90, beaucoup de recherches ont été faites sur les outils d ingénierie, de réingénierie, de maintenance. On ne compte plus les conférences sur la maintenance des logiciels, Morris (1989) a suggéré qu'avoir la maintenance en vue pendant la phase de conception et d'implémentation pourrait favoriser une maintenance efficiente dans avenir. Depoortere Franck

52 Réflexion finale : ``Le génie logiciel est l'ensemble des activités de conception et de mise en oeuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi'' (arrêté du 30 déc. 83) Autrement dit, le génie logiciel est l'art de produire de bons logiciels, au meilleur rapport qualité/prix. Il utilise pour cela des principes d'ingénierie et comprend des aspects à la fois techniques et non techniques: le génie logiciel est basé sur des méthodologies et des outils qui permettent de formaliser et même d'automatiser partiellement la production de logiciels, mais il est également basé sur des concepts plus informels, et demande des capacités de communication, d'interprétation et d'anticipation. De fait, la «crise du logiciel» n'est toujours pas résolue. Le génie logiciel reste un art qui demande de la part de l'informaticien une bonne formation aux différentes techniques (le «savoir»), mais également un certain entraînement et de l'expérience (le «savoir-faire»). L expérience de l auteur durant ces trois années de service auprès de sociétés d édition logiciels, à travers tous les cycles de vie d un logiciel, de sa conception, à son développement puis de sa maintenance, a mis en évidence que l établissement de processus de suivi, de méthodes sont des fondements essentiels dans l ingénierie logiciels, sans lesquels on risque souvent l échec. Il ne doit pas y avoir de différence entre les procédures industrielles traditionnelles et l ingénierie logiciel et ses nouvelles technologies. Seul l aspect immatériel, impalpable du soft rend l illusion d une liberté possible dans les processus de développement. Constatant que la majorité des développeurs est affectée à des tâches de maintenance, constatant l explosion du nombre d applications mises en service, leur complexité croissante, la variété des langages et des composants utilisés, la pression sur les coûts et sur la qualité, on comprend que les solutions présentées ici ont un bel avenir car, en économisant quelques pour-cent du temps, elles ont un effet de levier important et immédiat sur les budgets informatiques et sur la qualité. Ces solutions sont les premiers instruments de la lente industrialisation du développement et de la gestion des patrimoines logiciels qui seront décisifs dans les compétitions qui se jouent en ce début de XXIème siècle. Les projets de recherche sur les activités de maintenance sont rares. Les applications en exploitation constituent pourtant le patrimoine informatique de l'entreprise dont il faut chercher à tirer le meilleur parti. La maintenance, en gérant au mieux ce capital, doit être vécue comme une période de retour sur l'investissement consenti lors de la phase de développement initial. L auteur est convaincu que l application de méthodes formelles de maintenance permettent d'obtenir, à terme, des gains de productivité substantiels. L'avantage de cette solution est de libérer les ressources humaines des équipes informatiques de l'entreprise pour pouvoir participer à la phase de développement et limiter leurs interventions au strict nécessaire dans les actions de maintenance. Depoortere Franck

53 Références : [1]. SIR, logiciel de redocumentation de la société NGSET. [2]. SEI : Software Engineering Institute (SEI : est un centre de recherchedéveloppement financé par le gouvernement fédéral des Etats Unis. Il a été créée en 1984, par le ministère de la défense, qui lui a confié le vaste mandat d assurer la transition de la technologie du génie logiciel. Le SEI fait partie intégrante de l Université Carnegie Mellon et est commandité par le bureau de sous-secrétaire à la défense chargé de l acquisition de la technologie. Le SEI a conçu une série de modèles d évaluation et d amélioration de processus appelés des «modèles de la maturité de la capacité» (CMM) qui sont des guides précieux et qui obtenu un large consensus de la part de la communauté logiciel. [3]. ICMS2000SV 2000 ICSM '2000 SV International Conférence on Software Maintenance 2000, October [4]. ISE : (Interactive Software Engineering) : L ISE se consacre à l amélioration de la qualité des logiciels et de la productivité à travers des méthodes avancées, des outils et des langages, basés sur des principes scientifiques et sur l application des technologies objet. La compagnie promouvoir un éventail complet d outils de développements, tels que consultation sur site service des développement de librairies, et programmes didacticiels sur les technologies orientées objets : analyse, design, techniques d implémentation. L ISE est le créateur de la méthode et du langage Eiffel. [5]. est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP, Sun, Unisys, American Airlines, Philips...). Aujourd'hui, l'omg fédère plus de 850 acteurs du monde informatique. Son rôle est de promouvoir des standards qui garantissent l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes. [6]. Eiffel ( est un environnement de développement orienté objet. ISE Eiffel fournit une solution complète pour les développeurs de logiciels avec de pures méthodes orientées objet, de l'analyse et de la conception à la génération de code, la maintenance et la rétro-ingénierie. Les composants d'ise Eiffel sont : EiffelBench, EiffelBase, EiffelBuild, EiffelVision, EiffelLex, EiffelParse, EiffelNet, EiffelStore, ObjEdit, EiffelCase, EiffelMath, EiffelWeb, DLE (édition de liens dynamique avec Eiffel) et SCOOP (mécanisme de distribution/concurrence). [7]. RISE : The Research Institute for Software Evolution. Le RISE est un centre de recherche sur la maintenance logicielle qui a été igauguré en avril 1987, à l université de Durham, en Grande Bretagne. C est un acteur majeur à travers le monde dans l évolution des techniques d ingénierie et de maintenance des applications informatiques. Depoortere Franck

54 Articles et publications sur la rétro-ingénierie : Reverse Engineering and System Renovation, excellently organized, from Univ of Amsterdam ( Understanding Software Systems, from Univ of Victoria Reengineering Bibliography, from IEEE/TCSE ( Organisations et sites dédiés au reverse engineering Centre for Software Maintenance at University of Durham ( Centre for Software Maintenance at University of Queensland ( Distributed Systems Group at Technical University of Vienna Georgia Tech's Reverse Engineering Group (Georgia Institute of Technology) ( SEI Reengineering Center (Software Engineering Institute) ( Software Technology Support Center at Hill AFB (US Air Force) ( UCSD Software Evolution Group (University of California - San Diego) ( Committee on Reverse Engineering and Reengineering (IEEE Technical Council on Software Engineering) ( REF - Reengineering Forum Articles E.J. Chikofsky, J.H. Cross, "Reverse Engineering and Design Recovery: A Taxonomy", IEEE Software, Vol. 7, No. 1, Jan 1990, pp D.L. Parnas, "Software Aging", Proc. of International Conference on Software Engineering, Y.F. Chen; "Reverse Engineering", Chapitre 6 du livre "Practical Reusable UNIX Software", Edite par B. Krishnamurthy, AT&T Bell Laboratories, A. Mendelzon, J. Sametinger. "Reverse Engineering by Visualizing and Querying" Depoortere Franck

55 Bibliographie : Patrick Jaulent. Génie Logiciel : les méthodes. Armand Colin, Paris, Jean Pierre Martin. Du bricolage à l'industrialisation : La qualité du logiciel. Afnor Gestion. Afnor, Paris, W. Curtis, Management and experimentation in software engineering''. Proceedings of the IEEE, 68(9), Sommerville, Software Engineering. 5th Edition, Addison-Wesley, 1996 Richard Basque, Le modèle CMM pour améliorer notre façon de faire du logiciel Centre de génie logiciel appliqué (CGLA) Mots clés: CMM, processus, modèle, évaluation, maturité, amélioration, qualité, logiciel Marc Frappier, professeur, Gestion de la maintenabilité Département de mathématique et d'informatique, Université de Sherbrooke, Sherbrooke Mots clés: Maintenabilité, coûts de maintenance, réingénierie Armstrong A Takang, Penny A Grubb, Software Maintenance, Concepts and Practice Thomson Computer Press B.W.Boehm, "Software Engineering", in IEEE Transactions on Computers, Vol.25, No.12, December M.Cl Gaudel, B. Marre, F. SCHLIENGER & G. Bernot, Précis de Génie Logiciel, Masson, P. Sallis, G. Tate & S. MacDonell, Software Engineering, Addison-Wesley, D.A. Lamb, Software Engineering: Planning for Change. Prentice-Hall, R. Fairley, Software Engineering Concepts. Mac Graw Hill, B.W. Boehm, Software Engineering Economics. Prentice-Hall, 1981 B.W. Boehm et al, Characteristics of Software Quality. North-Holland, 1978 Martin Fowler, Refactoring : Improving The Design of Existing Code Depoortere Franck

56 «Reengineering is like looking at a Picasso and trying to come up with a photography of the subject» Isabelle Merly Depoortere Franck