Introduction sur la maintenance des logiciels

La maintenance est la dernière phase du cycle de vie d’un logiciel. Elle est définie comme étant le processus de modification d’un logiciel en opération pour lui permettre de toujours satisfaire aux spécifications actuelles et futures [IEEE, 1993] , elle représente la phase la plus importante et la plus coûteuse, 60% à 80% du coût total du cycle de vie du logiciel est dépensé durant la phase de maintenance [Munro, 1998]. Ceci est dû entre autres :
• Au personnel inexpérimenté, non familier avec l’application et parfois peu motivé,
• Aux programmes non structurés, n’obéissant pas aux standards,
• Aux modifications qui génèrent des fautes,
• A la dégradation de la structure du système suite aux modifications non planifiées apportées au système par des gens différents sur des plates-formes différentes sans documentation de leurs tâches,
• A une documentation obsolète, inadéquate, voire inexistante.

Plusieurs techniques, méthodes et outils destinés à cette phase ont vu le jour. On cite comme exemple : la réingénierie, la rétro ingénierie, la compréhension de programme, l’analyse d’impact, les tests de régression, la gestion de configuration de logiciel, la maintenance via le Web, etc.

Le cycle de vie d’un logiciel 

Le cycle de vie d’un logiciel est l’ensemble des étapes du développement d’un logiciel, de la définition des besoins du client jusqu’à l’achèvement du logiciel en tant que produit commercial. L’objectif d’un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement du logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, où encore l’adéquation des méthodes mises en œuvre. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.

Le cycle de vie du logiciel comprend généralement les activités suivantes :

➤ Phase de spécification des besoins : déterminer les besoins du logiciel (spécifications générales, spécifications fonctionnelles, spécifications d’interface). Les spécifications des besoins servent à définir ce que doit faire le logiciel et non comment il doit être fait.
➤ Phase de conception du système et du logiciel : En partant de la spécification des besoins, on décompose le système en deux parties : matériel et logiciel. C’est le processus qui consiste à présenter les diverses fonctions du système d’une manière qui permettra d’obtenir rapidement un ou plusieurs programmes réalisant ces fonctions.
➤ Phase de réalisation et tests unitaires : Lors de cette étape, on réalise un ensemble d’unités de programme écrites dans un langage de programmation exécutable. Les tests unitaires permettent de vérifier que ces unités répondent à leurs spécifications.
➤ Phase de test du système : On intègre les unités de programme et on réalise des tests globaux pour être sûre que les besoins logiciels ont été satisfaits. Le système est alors livré au client.
➤ Phase de maintenance : Une fois que le produit est accepté, il passe en phase de maintenance jusqu’à son retrait. Normalement (mais pas nécessairement) ceci est la plus longue étape du cycle de vie, l’activité de maintenance consiste à corriger les erreurs qui n’ont pas été découvertes lors des étapes antérieures du cycle de vie, à améliorer la réalisation des unités du système et à augmenter les fonctionnalités du produit au fur et à mesure que de nouveaux besoins apparaissent.

Maintenance des applications

La compréhension d’un programme représente l’une des tâches les plus importantes du processus de maintenance. Les personnes chargées de la maintenance épuisent 40 à 60% de leurs temps à lire le code et à essayer de comprendre sa logique. C’est une activité laborieuse qui augmente le coût de la maintenance [Pigoski, 1997]. En effet, l’équipe qui a développé le système n’est pas toujours celle qui assure sa maintenance, les documents de spécifications sont parfois incomplets et le code source constitue souvent la seule source d’informations fiable. La plupart des problèmes associés à la maintenance du logiciel sont causés par la méthode utilisée pour concevoir et développer le système. De plus, la maintenabilité est un facteur de qualité qui n’est pas incorporé dans le processus de développement. Pour faciliter la maintenance et augmenter la maintenabilité des systèmes logiciels, il faut, entre autres, définir des standards de codage, de documentation et d’outils de tests dans la phase de développement du logiciel [Swebok, 2004], documenter l’évolution du logiciel et utiliser les techniques destinées à la maintenance.

Les types de maintenance 

Généralement, on considère qu’il existe trois types de maintenance, dépendant de la nature de la modification : corrective, adaptative et perfective. Nous décrivons ces différents types de maintenance dans le paragraphe suivant :

Maintenance corrective : C’est le type de maintenance le plus évident. On s’assure qu’un logiciel en opération continue à satisfaire ses spécifications. En pratique, c’est l’activité de corriger les erreurs résiduelles qui auraient dues être découvertes lors de la phase de test. Comme on ne pourra jamais découvrir toutes les erreurs lors de la phase de test, ce type de maintenance est inévitable. Il ne constitue toutefois qu’environ 17% de l’effort total de maintenance [Lientz, 1978].

Maintenance adaptative : Ce type de maintenance consiste à modifier un logiciel en réponse à un changement intervenu dans son environnement logiciel ou matériel. Le standard IEEE la définit comme suit [IEEE, 1993] : »modification of a software product performed after delivery to keep a computer program usable in a changed or changing environnement ». Ainsi, la portabilité d’un logiciel d’une plate-forme (système d’exploitation ou processeur) à une autre relève de cette catégorie de maintenance. La maintenance adaptative compte pour environ 18% de l’effort total de maintenance [Lientz, 1978].

Maintenance perfective : La maintenance perfective fait référence aux modifications d’un programme en vue d’augmenter ses performances ou ses fonctionnalités. Ce type de maintenance s’effectue généralement à la demande des utilisateurs qui veulent toujours avoir plus de fonctionnalités. C’est la principale activité de maintenance, elle constitue entre 60 à 70% de l’effort total de maintenance [Lientz, 1978] .

Table des matières

Introduction Générale
1. Contexte
2. Problématique
3. Motivation
4. Organisation du mémoire
Chapitre I Introduction sur la maintenance des logiciels
1. Introduction
2. Cycle de vie d’un logiciel
3. Maintenance des applications
3.1. Les types de maintenance
3.2. Activité de maintenance
3.3. Problèmes de maintenance
3.4. Techniques de maintenance
4. Conclusion
Chapitre II Analyse d’impact de changement
1. Introduction
2. Impact de changement
2.1. Analyse d’impact
2.2. Intérêts d’une analyse d’impact de changement
2.3. Travaux de recherche sur l’analyse d’impact
2.4. Approches et modèles
2.5. Notion d’impact
2.6. Relations indirectes entre classes
2.7. Firewall de classe
3. Modèle d’impact de changement
3.1. Objectifs
3.2. Modèle conceptuel
3.2.1. Changements
3.2.2. Liens
3.2.3. Impact
3.2.4. Adaptation du modèle à JAVA
4. Conclusion
Chapitre III Les systèmes multi agents (SMA)
1. Introduction
2. Définition et propriétés d’un agent
3. La typologie des agents
3.1. Les agents réactifs
3.2. Les agents cognitifs
3.3. Architecture hybride ou mixte
3.4. Architecture BDI (Beliefs Desires and Intentions)
4. Les avantages des agents
5. Les systèmes multi agents (SMA)
5.1. Les caractéristiques des environnement SMA
5.2. Les différentes formes d’intéraction
5.2.1. La coordination
5.2.2. La coopération
5.2.3. La négociation
5.3. La communication entre les agents
5.3.1. Les tableaux noirs
5.3.2. Transfert de plan ou de message
5.3.3. Communication via KQML (Knowledge Query and Manipulatioin Langage)
6. Domaines d’application des SMA
7. Conclusion
Chapitre IV Conception et réalisation
1. Introduction et contribution
2. Architecture proposée
2.1. Extraction des composants du système
2.2. Matrice des liens
2.3. Présentation graphique
2.4. Table d’impact selon le modèle
2.5. Changement proposé
2.6. Calcul de la table d’impact après changement
2.7. Représentation de changement
2.8. Confrontation des résultats
3. Structure des agents
3.1. Agent Analyseur
3.2. Agent Héritage, Association, Agrégation, Invocation
3.3. Agent Impact
4. Communication entre agents
4.1. Le langage ACL (Agent Communication Language)
4.2. Structure des messages envoyés
5. Coopération et Coordination entre les agents
6. Réalisation
6.1. Outils de développement
6.1.1. Eclipse
6.1.2. AST (Abstract Syntax Tree) Parser
6.1.3. Plateforme JADE pour l’implémentation du SMA
6.2. Le système test
6.3. Mise en œuvre de l’outil
7. Conclusion
Conclusion générale

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *