Maintenance et

évolution des
logiciels
Introduction
Les changements

 Le développement de logiciels mené à terme

avec succès, se termine par la livraison d’un
logiciel qui devrait satisfaire les exigences
initiales du client.
 après sa mise en service, le logiciel devra subir
des modifications ou changements pour
répondre aux nouveaux besoins,,
 le cycle de
 vie de la maintenance ne devrait exister tout au
long du processus de développement
 Le cycle de vie du logiciel :
Le développement initial
La maintenance
 Les modifications sont
inévitables
Nouveaux besoins lors de l’utilisation
Nouvelles technologies
L’environnement d’affaires change
Les erreurs et anomalies doivent être réparées
Nouveau équipement ..
La performance ou la fiabilité du systèmes
peuvent nécessiter des améliorations..
Importance et impact

Ces changements aux systèmes existants

représentent un problème critique pour
les organisations
Les systèmes représentent un bien
commerciale critique
Nécessite de maintenir la valeur de ces
bien
Possibilité de plus grand budget pour la
maintenance que le développement
Définitions
 Logiciel
Programmes

la documentation de toutes les facettes du

programme
la spécification,
 la conception,
 le système
et les manuels d'utilisation et maintenance,,,
Maintenance
le fait de garder une entité dans un état de
réparation actuel, d'efficacité ou de
validité, pour préserver de l'échec ou du
déclin.
Maintenance
Maintenabilité

la facilité avec laquelle la maintenance

peut être effectuée.
Evolution
 un processus de changement continu
d'un niveau inférieur, plus simple, à un
état supérieur, plus complexe, ou mieux.
ÉCOLES DE DÉFINITION DE
L’ÉVOLUTION
1.la maintenance
englobe l’évolution
Lehman
la maintenance du logiciel comme toute
activité de changement d'un logiciel

alors que l'évolution du logiciel signifie

analyse de la dynamique d'un logiciel via
des mesures.
 2.l’évolution
englobe la maintenance
Chaplin et al
le terme évolution est utilisé pour tout
changement dans les besoins qui aboutit à une
nouvelle version du système à partir de
l’ancienne
utilisent le terme maintenance pour toute activité
de changement post-livraison qui est la
préservation de la qualité et correction des
défauts ;
3.la maintenance
équivaut l’évolution
« Maintenance » au sens de la norme ISO
12207
(toutes les activités de modification d’un
logiciel)
 Sommerville affirme que la maintenance
signifie l`évolution de logiciels.
Différence entre la
maintenance et le nouveau
développement
Différence entre la
maintenance et le nouveau
développement :
Les contraintes du système existant.
nécessite des délais plus courts.
Les données de test disponibles.
possède un certain nombre de processus et
d’activités qui ne sont pas effectués par
les groupes de développement du logiciel.
La maintenance du logiciel fait aussi
appel à des processus et à des activités du
développement du logiciel
 Différence entre la maintenance
et le nouveau développement :
Les requêtes de modifications (RM)
parviennent d’une manière plus ou moins
aléatoire et ne peuvent pas être planifiées
individuellement
 Les RM sont évaluées et classées par
ordre de priorité,
La charge de travail de la maintenance
n’est pas gérée par des techniques de
gestion de projet, mais plutôt par
l’utilisation des techniques de gestion des
files d’attente
Evaluation des RM

tient compte de la taille estimée de la

modification et de la capacité à la réaliser
à l’intérieur des contraintes de coûts et de
qualité de fonctionnalité.
Nécessité et Types de
maintenance
 Nécessité de la maintenance
 Assurer la continuité du service :
Les systèmes doivent continuer à fonctionner
 Soutenir les mises à jour obligatoires :
Ce type de changement serait nécessaire à cause de
modifications à la réglementation gouvernementale
 Répondre aux demandes d’amélioration des
utilisateurs
 Faciliter les futurs travaux de maintenance :
 Il est souvent financièrement et commercialement
justifié d'initier le changement uniquement pour
faire l'entretien futur plus facile.
Types de maintenances

Maintenance Corrective
Maintenance perfective
Maintenance Adaptative
Maintenance Préventive
 Maintenance Corrective
Modifications dues aux défauts du logiciel.
Ces défauts peuvent résulter d’erreur de
spécifications,
de choix d’architecture
 d’erreur de programmation,
 ou de tests invalides ou incomplets.
problèmes de performances ou de traitements de
données.
« erreurs résiduelles », empêchant le logiciel
d’être conforme aux spécifications.
 La maintenance perfective
comprend tous les changements faits sur un
système afin de satisfaire aux besoins de
l’utilisateur.
L’ajout de nouvelles fonctionnalités
la redéfinition de fonctions existantes,
 la suppression, de fonctions inutiles
Durant les diverses étapes, le système évolue
grâce à l’ajout de petits programme, ou
modules, facilement intégrable, aisément
maintenable
 La maintenance adaptative

fixe les différents changements qui doivent être faits

afin de suivre l’environnement du système en
perpétuelle évolution.
Exemple,
les règles fiscales,
les changements de stratégies commerciales,
les changements de législation,
les changements de plates-formes, ou de
matériel.
 La maintenance préventive
A pour but d'anticiper tous les problèmes
possibles.
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
MODÈLES DU PROCESSUS DE
MAINTENANCE
Modèles de maintenances

Modèles non-standards
Le modèle de Boehm
Le modèle de rehaussement itératif
Le modèle orienté réutilisation
….
Modèles standards
 IEEE 1219
 ISO/IEC 14764
IEEE Standard for Software
Maintenance

En 1993, l’IEEE sur une idée de

Schneidewind a publié un processus
itératif standard pour la gestion et
l’exécution des activités de maintenance
logicielle
Processus de maintenance
selon IEEE
Classification et Identification
Le processus démarre par la soumission
d’une requête de modification (MR).
L’entreprise de maintenance détermine
tout d’abord le type de requête dont il
s’agit (corrective, perfective ou
adaptative).
Une priorité est ensuite assignée à cette
requête ainsi qu’un numéro unique.
Toutes ces informations sont entrées
automatiquement dans une base de
données qui pourra être consultée tout au
long du cycle.
 Analyse
Une étude de faisabilité ainsi qu’une analyse
détaillée sont effectuées durant cette phase.
Le mainteneur prêtera attention aux impacts des
modifications, il proposera plusieurs solutions
alternatives et définira les coûts.
L’analyse détaillée fournira différentes
informations telles que des plans
d’implémentation, des stratégies de test ou
encore des identifications de fonctionnalités.
A la fin de cette période d’analyse, l’ensemble
des changements doit être totalement planifié.
Conception

l’ensemble des informations collectées

pendant la phase précédente sont
rassemblées et utilisées afin de construire
le design de l’application.

En fin de conception, la documentation du

logiciel doit être mise à jour (plans de
tests, design, analyse et exigences).
Implémentation

Comprend l’ensemble des processus de

codage, de tests unitaires, d’intégration,
…

Toutes les documentations concernant le

logiciel sont mises à jour.
Test système
permet de s’assurer que le nouveau
produit
est toujours satisfaisant
et que les nouveaux changements ont été
implémentés correctement.
Test d’acceptation

Les testeurs ont pour objectif de rapporter

les erreurs et de déterminer si les
fonctionnalités du système sont en accord
avec les exigences du client et des
besoins des utilisateurs.
Livraison

le fournisseur livre le nouveau système

aux utilisateurs.
 Il effectue la configuration du système et
la formation des utilisateurs.
 Après cette phase, le système est prêt à
fonctionner de manière autonome.
Quelques problématiques
de la maintenance
Problèmes techniques
Compréhension limitée
la rapidité avec laquelle quelqu’un peut
comprendre ou faire un changement ou
une correction dans un logiciel.

un effort non négligeable doit être fait

pour accroitre la compréhension du
logiciel.
Essai

Réaliser un essai complet sur un morceau

majeur de logiciel est généralement
significatif en terme de temps et de coûts.
 Analyse d’impact

 Une analyse d’impact décrit comment mener, à un coût

efficace, une analyse complète des impacts d’un
changement dans un logiciel existant.

connaissance de la structure et du contenu d’un

logiciel,
identifier tous les produits des systèmes et des
logiciels affectés par une demande de modification
établissent une estimation des ressources
nécessaires au changement
L’analyse de coûts/bénéfices du changement
demandé
Communication aux autres de la complexité d’un
changement donné.
 Maintenabilité
L’aisance avec laquelle un logiciel peut être
maintenu, amélioré, adapté ou corrigé pour
satisfaire aux exigences spécifiées.

Ces sous-caractéristiques de maintenabilité

doivent être spécifiées, revues et contrôlées
durant les activités de développement logiciel
pour réduire les coûts de maintenance.
Difficile à atteindre
Estimation des coûts de la
maintenance
Le coût d’un projet de maintenance est:
Ressources: personnel, machines
 Temps
Argent
 L’estimation du coût peut être faite :
 Soit à partir des données historiques
Soit à travers des modèles
mathématiques
Mesure de la maintenance
du logiciel
 La maintenabilité est le degré d'efficacité
avec lequel un produit ou un système peut
être modifié par les mainteneurs prévus.

 Maintenabilité n’est pas restreinte au code,

c’est un attribut d’un nombre de différents
produits logiciels, incluant les spécifications,
documents de conception, document du plan
de test..
APPROCHES DE MESURE

Il existe deux approches pour mesurer la

maintenabilité, reflétant les vues internes
et externes de l’attribut.
Vue externe de la Maintenabilité
Vue interne de la Maintenabilité
Vue externe de la Maintenabilité
Maintenabilité dépend
du produit
personne performant la maintenance,
la documentation
 les outils supports.
L’approche la plus directe de mesure de la
maintenabilité est de mesurer le processus
de maintenance.
 Vue externe de la Maintenabilité

la vitesse d’implémentation du changement

est une caractéristique clé de la
maintenabilité.

La mesure de la maintenabilité est définie

par: MTTR: Mean Time To Repear: c‘est
le temps moyen qu’une équipe de
maintenance prend pour implémenter un
changement et restaurer l’ordre de
fonctionnement du système.
MTTR

Pour calculer cette mesure, nous avons

besoin parmi d’autres de :
Temps d’analyse du problème
Temps de collection des outils de
maintenance
Temps de spécification changement
Temps de changement (incluant test et
revue)
VUE INTERNE DE LA
MAINTENABILITÉ

L’approche interne consiste à identifier les

attributs de produit interne
 ceux relatifs à la structure du produit
Etabli qui sont prédictifs des mesures de
processus.
VUE INTERNE DE LA
MAINTENABILITÉ
Plusieurs mesures d’attributs interne ont
été proposées comme indicateurs de
maintenabilité:
Complexité
 LOC…
 LOC
Pour quantifier la complexité d’un logiciel, les
mesures les plus utilisées sont les lignes de code
(LOC acronyme de « lines of code »)
Quelles sont les limites acceptables ?
La longueur des fonctions devrait être de 4 à
40 lignes de programme
La longueur des fonctions devrait être de 4 à
40 lignes de programme
La complexité
La complexité de programme recouvre
plusieurs notions telles que :
Structure de programme, flux de
contrôle, flux de données et complexité
algorithmique..
La complexité peut être utilisée pour
estimer l’effort requis pour faire un
changement au programme.
Plus de 100 mesures de complexité ont
été proposées dans la littérature:
McCabe’s cyclomatic complexity
Halstead mesure de difficulté….ETC.
 GRAPHE DE FLUX DE
CONTRÔLE
Montre quelles instructions seront exécutées en
fonction de la valeur d’une expression dans le
programme.
 Un nœud représente une instruction ou prédicat
Pour deux nœuds p et q, un arc va de p vers q si la
valeur de l’expression p a un impact sur le fait que
l’instruction q soit exécutée ou non.
GRAPHE DE FLUX DE
CONTRÔLE
 Graphe de flux de données

Avoir l’information sur l’utilisation des

variables dans le
temps.

Exemple:
L’ensemble des variables utilisées et
celui des variables modifiées pour
chaque instruction du programme.
Graphe de flux de données
 La complexité
Cyclomatique
La complexité Cyclomatique (complexité de
McCabe), introduite par Thomas McCabe en 1976,
est le calcul le plus largement répandu des
métriques statiques.
Conçue dans le but d’être indépendante du
langage, la métrique de McCabe indique le nombre
de chemins linéaires indépendants dans un
module de programme,
 La complexité Cyclomatique

Le nombre cyclomatique évalue le nombre de

chemins d’exécution dans la fonction et ainsi
donne une indication sur l’effort nécessaire pour
les tests du logiciel.
Pour un programme qui consiste en seulement
des états séquentiels, la valeur pour v(G) est 1.

v(G)=e-n+2 Où n= le nombre de noeuds ; e= le

nombre d’arcs ; et v(G) est la complexité
cyclomatique.
Exemple
 Quelles sont les limites
acceptables pour le nombre
cyclomatique v(G) ?
Une fonction devrait avoir un nombre
cyclomatique inférieur à 15.

Si une fonction a plus que 15 chemins

d'exécution il est difficile à comprendre et à
tester.

Pour un fichier le nombre cyclomatique ne

devrait pas dépasser 100.
Les Métriques de Halstead

Les métriques de complexité de Halstead

qui procurent une mesure quantitative de
complexité ont été introduites par
l’américain Maurice Halstead.
Ils sont basées sur l’interprétation du code
comme une séquence de marqueurs,
classifiés comme un opérateur ou une
opérande.
Les Métriques de Halstead

 Toutes les métriques de Halstead sont dérivées du

nombre d’opérateurs et d’opérandes :
 • nombre total des opérateurs uniques (n1)
 • nombre total des opérateurs (N1)
 • nombre total des opérandes uniques (n2)
 • nombre total des opérandes (N2)
 Sur la base de ces chiffres on calcule :
 • La Longueur du programme(N) : N = N1 + N2.
 • La Taille du vocabulaire(n) : n = n1 + n2
 Les Métriques de Halstead

le Volume du Programme(V) : V = N * log2(n).

Le Niveau de difficulté (D) ou propension
d'erreurs du programme : D = ( n1 / 2 ) * ( N2 /
n2 )
L'Effort à l’implémentation (E) : E = V * D
Halstead a découvert que diviser l'effort par 18
donne une approximation pour le Temps pour
implémenter (T) un programme en secondes :T =
E / 18
Systèmes hérités
 Systèmes hérités
(Legacy Systems)
 Les systèmes hérités comprennent le matériel ,
logiciels, bibliothèques, …

 Sont des systèmes plus anciens qui reposent sur des

langages et des technologies qui ne sont plus
utilisés pour le développement de nouveaux
systèmes

 Peuvent dépendre d’équipements ancien, tels que

les ordinateurs , serveurs etc.
Les éléments des systèmes
hérités
 Composants 1/2
Matériel du system
Matériel plus disponible

Logiciel de support
 peuvent être obsolète

Logiciel d’application
Services métiers
Composants 2/2

Données d’application
peuvent devenir incohérents

Processus métier
Peut se retrouver limité

Politiques et règles métiers

Le logiciel peut apparaitre comme
contrainte
Coûts des systèmes hérités

 Les systèmes hérités deviennent plus coûteux à

maintenir avec l’âge
Dépendance sur la technologie ancienne•

Documentation inadéquate ou dépassée •

Structure corrompue par plusieurs années

de maintenance adhoc •

Les données peuvent être incohérentes,

dupliquées, etc.
 Remplacement des
systèmes hérité

Les risques:
Il n’existe généralement pas de
spécification du système entier sur
laquelle se baser pour développer un
nouveau système •
Le processus d’affaire est souvent
étroitement relié aux logiciels utilisés•
Développer un nouveau système comporte
des risques de retards, coûts plus élevés
que prévu.
 Problématique

Le dilemme des systèmes hérités

Continuer à utiliser le système accroît

invariablement les coûts

Remplacer le système coûte cher, et le

nouveau système peut être moins
efficace que l’ancien
Options possibles: 1/2

1. Abandonner le système complètement

2. Remplacer le système hérité par un

nouveau

3. Continuer à maintenir le système

4. Transformer le système pour faciliter la

maintenance
Options possibles: 2/2
Évaluation de la valeur
d’affaires
 L’évaluation devrait prendre en compte plusieurs
points de vues:

Utilisateurs finaux

Clients de l’entreprise

Les gestionnaires hiérarchiques (financiers)

Les directeurs informatiques

…
Paramètres d’évaluation

L’utilisation du système

Les processus métiers pris en charge

La fiabilité du système

Evaluation de la qualité

Evaluation du processus d’affaire

Évaluation de l’environnement

Évaluation du logiciel d’application

 Évaluation de l’environnement
Stabilité des fournisseurs
Nombre de fautes matérielles pour une
période donnée
Âge du matériel et des logiciels
Interopérabilité
Maintenance
Quels sont les coûts de maintenance& du
matériel et de support des licences?
Évaluation du logiciel
d’application
Compréhension du code
Documentation complète , cohérente et à
jour?
Données (modèle de données)
Performance
Langage de programmation
Rétro-ingénierie
Définition

Processus de production automatique de

spécification manquante à partir du
code source et / ou des données d’un
système
Intérêt

comprendre le système

Souvent utilisée avant la réingénierie

Permet de faciliter la maintenance

Techniques
 Code
Analyse statique et dynamique du code
Reconstruction de l’architecture

 Données
Production de modèle précis et complet
des données

 Les utilisateurs

 La documentation
Ré-ingénierie
Définition

Modification et transformation du
système existant dans l’objectif de les
moderniser
Avantage

Réduit les risques

Réduit les couts

Réduit les délais

Activités 1/2
Traduction de code :
Traduction automatique ou semi-
automatqiue d’un langage a un autre
Amélioration de la structure
Pour faciliter la lecture et les
modifications
Modularisation
Réorganisation du code en modules
Semi-Manuel
Activités 2/2

Réingénierie des données

Analyse et réorganisation des
structures de données
Semi-manuel

Evolution de l’architecture
Les architectures Client/serveur sont
plus rentables que les architectures
centralisées
Démarche de ré-ingenierie
Bibliographie

 Bounour N , Cours Maintenance des logiciels:

Techniques et outils, Ingénierie des logiciels
Complexes Master 2, Université de Annaba.

 Boudaa B, Génie logiciel, Cours Master 1, Université

Ibn khaldoun Tiaret , Algérie.