Maintenance des logiciels

Maintenance des logiciels

Contexte

La maintenance est la phase la plus coûteuse du cycle de vie du logiciel. Ceci peut, entre autres, s’expliquer par le fait qu’elle est la phase la plus longue qui ne s’ach ve qu’avec le retrait du logiciel. Par ailleurs, le ratio du coût de la maintenance par rapport au coût total du logiciel est passé de 40 à 60 % dans les années 80 à plus de 80% au d but de l’an 2000 [52]. Le coût élevé de la maintenance pousse les chercheurs et les industriels à se focaliser sur cette phase du cycle de vie d’un syst me afin d’essayer de la comprendre pour mieux la contrôler. Pour y arriver, il existe des techniques telles que la visualisation qui sert à montrer les tendances g n r ales du syst me d’une fa on intuitive [41]. Par ailleurs selon les lois d’ volution des logiciels, comme indiqu dans [ 44], un syst me doit tre continuellement changé. Autrement, il apportera moins de satisfaction dans son environnement. En effet, durant la phase de maintenance, les programmeurs sont amenés à faire des changements aux systèmes pour de multiples raisons. Par exemple, les changements réalisés peuvent permettre de répondre à de nouveaux besoins des utilisateurs. On parle dans ce cas, de maintenance perfective. La maintenance peut aussi consister à apporter des changements afin de prévenir les bogues (pr ventive), de s’adapter un nouvel environnement (adaptative), ou pour corriger des erreurs (corrective). Ainsi, les logiciels doivent subir plusieurs changements pour prolonger la durée de leur vie.

Origine et Définition de la rétro-ingénierie

D’après [4], la rétro-ingénierie revient aux années de la révolution industrielle. Elle est semblable à la recherche scientifique où les chercheurs essayent d’inventer des plans et des cartes aux phénomènes naturels. La seule différence est que la rétro-ingénierie concerne les objets créés par l’homme (des appareils mécanique, des composants électronique, des programmes informatique, …). D’une façon générale, la rétro-ingénierie est le processus d’extraction de connaissances ou de concevoir des représentations à partir de tout ce qui est construit par l’homme. Dans le contexte de l’ingénierie logicielle, le terme rétro-ingénierie a été défini en 1990 par Chikofsky et Cross dans [3] comme le processus d’analyse d’un système pour (1) identifier les composants du système et leurs interrelations, et (2) créer des représentations du logiciel dans une autre forme ou dans un niveau d’abstraction plus élevé.

La rétroingénierie a été traditionnellement vue comme un processus en deux étapes : l’extraction des informations et l’abstraction. L’étape d’extraction des informations analyse les artefacts du logiciel pour recueillir des données brutes, tandis que l’étape d’abstraction crée des vues et documents orientés utilisateur à partir des données brutes [25]. Chikofsky et Cross ont présenté une structure de base pour les outils implémentant la rétro-ingénierie . Le logiciel étudié est analysé et les résultats de cette analyse sont stockés dans une base d’informations. Par la suite, ces informations sont utilisées pour produire différentes vues du logiciel, comme les diagrammes, les rapports, et les métriques.[34] La rétro-ingénierie est très utile aux développeurs des logiciels. En effet, ils l’utilisent comme un moyen de coopération et collaboration autour des logiciels qui ne disposent pas[36] (ou qui disposent partiellement) de la documentation. Ils peuvent l’utiliser aussi pour étudier et améliorer les logiciels concurrents. De plus, la rétro-ingénierie permet d’évaluer la qualité et la robustesse d’un logiciel. Elle est également le moyen essentiel dans les différentes taches de l’étape de maintenance qui représente une étape très importante dans le cycle de vie de logiciel. En effet, une enquête effectuée aux USA en 1986 auprès de 55 entreprises a révélé que 53% du budget total d’un logiciel est affecté à la maintenance [27]. La rétro-ingénierie facilite les taches de maintenances car elle permet de proposer aux personnes intervenant dans la maintenance des représentations plus abstraites qui leur permet de comprendre le logiciel pour le tenir à jour en fonction des nouveaux besoins des utilisateurs.

Impact de changement

La modification des systèmes est une tâche à la fois difficile et porteuse de conséquence sur la suite de l’évolution de ces systèmes. Les effets des changements subis par le système doivent donc être pris en considération. La motivation de notre travail est d’améliorer la maintenance des systèmes orientés objet, et d’intervenir plus précisément dans la tâche de l’analyse de l’impact de changement[40]. Nous visons principalement la réduction de l’effort ainsi que le coût de la maintenance. La réduction de cet effort peut être accomplie par la réduction du temps entre la proposition du changement, son implantation et sa réalisation, tout en assurant la qualité du système. L’effort peut être aussi réduit si on peut prédire le comportement du système face à d’éventuels changements. Notre travail se situe beaucoup plus dans cet axe de recherche. Plus l’analyse et la prédiction d’impact de changement est systématique, plus la réduction d’effort est à notre avis optimale. Ainsi les bonnes décisions peuvent être prises avant d’initier les changements. En identifiant l’impact potentiel d’une modification, on réduit le risque de s’embarquer dans des changements coûteux et imprévisibles. Plus un changement affecte de classes, plus le coût de sa réalisation n’est élevé. L’analyse des impacts de changement permettra ainsi d’évaluer le coût d’un changement et de faire un compromis entre les différents changements suggérés.

Un impact, dans son sens le plus large est l’effet ou l’influence d’une chose sur une autre. Dans notre étude, l’impact est la conséquence d’un changement. L’analyse d’impact est l’étude de la portée de cet impact. L’analyse d’impact du changement est l’estimation des conséquences d’un changement sur le reste du système. Elle a été pratiquée de différentes manières pendant des années. Pfleeger et Bohner [78] définissent l’analyse d’impact du changement comme : “the evaluation of the many risks associated with the change, including effects on resources, effort, and schedule estimates”. Arnold et Bohner [78] définissent l’analyse d’impact par : “impact analysis is the activity of identifying what to modify to accomplish a change or of identifying the potential consequences of a change”. Le développement des logiciels consomme beaucoup de temps et de ressources. Mais, les coûts de développement sont de loin inférieurs aux coûts de maintenance. En fait, ces coûts de maintenance représentent un souci majeur, même pour systèmes conçus avec des techniques avancées telle que l’orienté objet[41]. Dans les systèmes, un flot continu de changements doit être pris en compte sinon ces systèmes risquent de devenir désuets ou même d’être abandonnés. Il devient donc nécessaire que les systèmes objets développés soient évolutifs et capables d’absorber facilement tout changement. Une analyse d’impact permet en général d’évaluer les conséquences d’une modification avant de l’implémenter et d’estimer ainsi les coûts et risques associés à la modification.

Conclusion générale et perspectives

Réduire le coût de la maintenance nécessite de se procurer les moyens nécessaires pour l’accomplir. L’analyse de l’impact du changement est l’une des techniques qui a connu de l’importance dans le domaine de la maintenance ces dernières années. Le but de cette technique est de permettre aux gens responsables de la maintenance d’évaluer le coût du changement à priori, i.e., avant d’entamer l’implémentation du changement. Cette évaluation se fait de deux façons : technique et gestion. La première, évaluation technique, se base sur la compréhension du logiciel en modification et sur l’identification du changement, son impact et ses effets de propagation sur tout le système. Suite à cette analyse technique, l’équipe de maintenance est en mesure de conclure sur la faisabilité technique du changement et proposer des solutions optimales qui ne compromettent pas les fonctionnalités du système existant. La deuxième, évaluation du point de vue gestion (ressources humaines et financières), est établie habituellement par les gestionnaires. Ces derniers peuvent choisir parmi les solutions proposées celle qui satisfait les besoins ou décider de réétudier le changement pour des solutions plus sûres. L’analyse d’impact du changement a été étudiée de différentes manières par différents utilisateurs, en se basant sur un ensemble de concepts.

Notre approche d’aide à la décision pour la gestion des projets de maintenance logicielle utilise l’analyse d’impact de changement dans les programmes à objets à base des métriques qui mesurent une propriété architecturale des logiciels qui est le couplage. En premier lieu, nous avons procéder à l’extraction de certaines métriques relatives à la propriété architecturale que l’on veut évaluer ; il s’agit du couplage. Nous avons développé un outil sous la plate-forme ECLIPSE qui permet d’analyser un programme orienté objet Java et d’extraire les métriques nécessaires. Cette étape s’est avérée importante pour mener notre expérience. Notre approche aide le manager de maintenance à choisir une solution parmi plusieurs en tenant en compte de deux aspect : la nature de changement et sa propagation dans le reste du système.

Table des matières

Introduction générale
1.1 Contexte
1.2 Problématique
1.3 Contribution
1.4 structure du mémoire
Chapitre I : Maintenance des logiciels
1.Introduction
2.Les logiciels
2.1 L’évolution des logiciels
2.2 Le génie logiciel
2.3 Qualité des logiciels
3.Cycle de vie d’un logiciel
4.Modèles de cycle de vie d’un logiciel
4.1. Modèle en cascade
4.2. Modèle en V
4.3. Modèle en spirale
4.4. Modèle par incrément
5.Maintenance des applications
5.1. Types de maintenance
5.2. Activités de maintenance
5.3. Problèmes de maintenance
5.4. Techniques de maintenance
1.Rétro-ingénieurie
2.Réeingenieurie
3.Analyse d’impact
Chapitre II : Retro-ingénierie des logiciels
1.Introduction
2.Origine et définition de la rétro-ingénierie
3.Apporte la rétro-ingenieurie logicielle
4.Demarche de la rétro-ingenieurie logicielle
5.La démarche de la retro*ingenieurie des logicielle orienté objet
Conclusion
Quelques Outils pour la Rétro-ingénierie
I.ptidej
présentation de ptidej
Fonctionnalités de la solution : PEPS, Ptidej for EcliPSe
3.Création d’ une extension pour Peps
Argo uml
Introduction
Caractéristiques
Intégration de l’outil Argo uml a netbeans pour la retro-ingénierie
III.Entreprise Architect
représentation entreprise architect
Chapitre III : Impact de changement
Introduction
Définition l’impact de changement
Intérêt de l’Impact de changement orienté objet
Impact de changement orienté objet
4.1 Objectif
4.2 Model conceptuel
4.2.1. Changement
4.2.2. Liens
4.3 Firewall de classe
Adaptation de model en java
Conclusion
ChapitreI V : Approche proposé
Introduction et contribution
Approche proposé
2.1. Extraction des composants
2.3. Présentation graphique
Réalisation
3.1. Outil de développement
3.2 :mise en oeuvre de l’outil
Conclusion
Conclusion générale et perspective
Bibliographie
ANNEXE

Télécharger le rapport complet