Please enable JavaScript.
Coggle requires JavaScript to display documents.
management SI : CH3, :check: Processus séquentiel et contrôlé, 👉…
management SI : CH3
1.pourquoi la maintenance
Débute dès la livraison du logiciel
Le logiciel ≠ uniquement du code
→ inclut aussi documentation, manuels, configurations
Types de maintenance (raisons principales)
Maintenance corrective : Correction des erreurs détectées après livraison
Maintenance perfective : Amélioration des performances / Ajout de nouvelles fonctionnalités demandées par le client
Maintenance adaptative : Adaptation du logiciel à un changement d’environnement
(OS, matériel, normes, plateformes, etc.)
2.Compétences du mainteneur
importance stratégique
67 % du coût total d'un logiciel est consacré à la maintenance
La maintenance touche toutes les phases du cycle de vie logiciel
: analyse / conception / implémentation et tests
Difficultés du métier
Phase la plus délicate du cycle de vie
Travail souvent : * sous pression (clients insatisfaits) / sur un code mal écrit / sans documentation fiable
Problèmes causés par d’autres développeurs
Rôle souvent peu valorisé par rapport au développement
Compétences requises
analyse : comprendre un système complexe existant
conception : identifier l'impact des modifications
implémentation : corriger / modifier sans introduire de nouveaux défauts
Diagnostic : trouver la cause d'une panne dans un grand logiciel
Autonomie : travailler sans documentation adéquate
3.Gestion de la maintenance
Objectif générale : organiser / prioriser et contrôler les modifications du logiciel
3.1 Suivi des demandes de modification
Rapports de défauts (maintenance corrective)
Préparés par l’utilisateur
Doivent contenir :
description précise du défaut
contexte d’apparition
effets observés
Classification des défauts (par gravité)
Critique : bloque totalement le système
Majeur : fonctionnalité essentielle affectée
Normal : défaut important mais contournable
Mineur : impact limité
Trivial : défaut cosmétique ou négligeable
suite de la partie suivi des demandes de modifications
Le mainteneur : identifie la cause du défaut + propose une solution (manière de le traiter)
Les conclusions sont ajoutées au rapport d’anomalie (ou des défauts)
Le responsable maintenance : consulte régulièrement les rapports + définit les priorités + traite d’abord la demande la plus critique
=> Le même fichier de suivi peut contenir : maintenance corrective / maintenance adaptative / maintenance perfective
3.2 Traitement d'une demande de modification
principe : Une décision est prise concernant l’exécution de la maintenance
(corrective / adaptative / perfective)
Rôle du programmeur de maintenance :
Identifier la faute à l’origine du problème
Corriger la faute
Tester le nouveau code
Mettre à jour la documentation, en précisant : ce qui a été modifié / pourquoi / par qui / quand
:pencil2: même tache pour maintenance corrective / perfective / adaptative
Démarche globale de traitement
Demande de modification
Analyse et évaluation
Réalisation de la modification
Test de la modification
Mise à jour de la documentation
3.3 Assurer la maintenabilité
le logiciel est facile à maintenir si :
documentation
est complète / correcte / à jour +
code lisible
: nm des vars significatifs et structure claire
Les règles de maintenabilité définies en développement doivent être respectées aussi en maintenance
👉 La maintenabilité se préserve, elle ne s’improvise pas.
explica : (On ne peut pas rendre un logiciel facile à maintenir par magie :
il faut le garder propre et clair dès le début et à chaque modification.)
3.4 Eviter les opérations de maintenance répétitives
Problèmes causés par des changements fréquents
Dégradation de la qualité du logiciel
Augmentation des coûts
Éloignement de la conception initiale
Changements futurs plus difficiles
Documentation de moins en moins fiable
5. Autres moyens d'aide à la maintenance
5.1 rétro-Conception
: Absence de documentation
cas fréquent : seul le code source est disponible
Techniques utilisées
Restructuration : améliorer la structure du code sans changer le comportement
Rétro-conception (Reverse Engineering) :
reconstruire la documentation
retrouver la conception et les spécifications
Forward Engineering :
modifier conception/spécifications
puis ré-implémenter le logiciel
5.2 Outils CASE pour la maintenance
Outils de suivi des anomalies
Suivent l’état des erreurs :ouverte / en cours / corrigée
Exemples : IBM Rational CkearQuest / Bugzilla
Outils de rétro-conception / ré-ingénierie
Génèrent des représentations graphiques
Aident à comprendre la structure du logiciel
Exemples : IBM Rational Rose / Together / Doxygen
5.3. Métriques pour la maintenance
Activités concernées :
Analyse
Conception
Implémentation
Tests
Documentation
exemples de métriques
Métriques de complexité :
code complexe ⇒ plus d’erreurs potentielles
Métriques basées sur les défauts :
nombre d’erreurs
classification par gravité
type de maintenance
Conclusion :
La maintenance est coûteuse, critique et complexe
Elle nécessite :
compétences élevées
gestion rigoureuse
documentation et tests solides
Des outils, métriques et techniques (rétro-conception) sont indispensables
4. Place des tests
Contraintes :
pression des délais
manque de documentation
Problématique
Une modification peut :
affecter d’autres artefacts
impacter tout le système
Importance des tests : tests de régression essentiels
vérifier que les fonctionnalités existantes fonctionnent toujours
Bonne pratique
Enregistrer :tous les cas de test / résultats attendus dans un format lisible par machine
Après chaque modification : certains tests doivent être adaptés
:check: Processus séquentiel et contrôlé
👉 Objectif : limiter les modifications inutiles et mal contrôlées
👉 Toute métrique liée à ces activités est pertinente
