0% ont trouvé ce document utile (0 vote)
102 vues14 pages

Critères de réussite en génie logiciel

Transféré par

kivoc
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
102 vues14 pages

Critères de réussite en génie logiciel

Transféré par

kivoc
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

Chapitre 1 : Introduction

Plan :
 Préliminaires
 Critères de réussite d’un projet informatique
 Approches du génie logiciel
 Processus de développement logiciel

I. Préliminaires
1. Définitions

Un Système informatique est l’ensemble composé de matériels et de logiciels nécessaires pour réaliser des
traitements de l’information.
Depuis quelques années, la fabrication du matériel est assurée par quelques fabricants seulement.

 Le matériel est relativement fiable


 Le marché est standardisé
Les problèmes liés à l’informatique sont essentiellement des problèmes de Logiciel !!!!
Un logiciel est un ensemble d’entités nécessaires au fonctionnement d’un processus de traitement automatique
de l’information.

 Des programmes (en format code source ou exécutables) ;


 Documentations d’utilisation ;
 Informations de configurations
Un logiciel est en général un sous-système d’un système englobant.
 Il interagit avec son environnement:
 Des opérateurs humains (utilisateurs, administrateurs, . . . ) ;
 D’autres logiciels;
 Des contrôleurs matériels.
 Il réalise une spécification :
Son comportement vérifie un ensemble de critères qui régissent ses interactions avec son environnement.
Difficultés spécifiques du logiciel :

1
 Support immatériel
 Un objet technique fortement contraint:
 Structure complexe
 Relatif au métier du domaine traité (gestion, automobile, aéronautique,)
 Difficile de mesurer la qualité
 Conséquences critiques causées par des modifications infimes
 Défaillances logicielles et principalement humaines

2. Bugs informatiques (Bugs célèbres)


 Sonde Mariner 1, 1962 (coût : $18,5 millions)
La sonde Mariner qui devait effectuer un passage à 5000km de venus s'est perdue a 5 000 000km de ladite planète
à cause d'une erreur de programme fortran. Le point avait remplacé par une virgule
 Accidents d’irradiation de Therac 25 (1985-87):
 Fautes de conception dans le matériel et le logiciel d’un appareil de traitement médical par irradiation
 La mort de plusieurs personnes
 Le projet TAURUS,1993.
En mars 1993, la bourse de Londres a renoncé au projet informatique Taurus qui devait assurer complètement le
suivi de l'exécution des transactions. Le system avait couté directement 60 millions de livres et les opérateurs sur
le marché avait dépensé 400 millions de livres pour y adapter leurs propres logiciels.
 Ariane V vol 501, 1996 (coût : $370 millions)
Le 4 juin 1996 lors du premier lancement de la fusée Ariane V, celle-ci explose en vol. La cause : un logiciel
utilise sous Ariane IV et intègre sans nouvelle validation dans Ariane V. Ariane V ayant des moteurs plus
puissants s'incline plus rapidement que Ariane IV pour récupérer l'accélération due à la rotation de la Terre. Les
capteurs ont bien détecté cette inclinaison d'Ariane V, mais logiciels l’a jugé non conforme à son plan de tir et a
provoqué l'ordre d'autodestruction alors que tout se passait bien
 Bug de l'an 2000 (coût : $600 millions)
 Les dates se faisaient uniquement sur les deux derniers chiffres de l'année
 Une centenaire (106ans) s'est retrouvée convoquée à l'école la cause ? le codage de l'année de naissance
sur deux caractères
Raisons principales :

 Erreurs humaines
 Taille et complexité des logiciels
 Taille des équipes de conception/développement
 Faible communication entre les parties prenantes
 Manque des méthodes de conception
 Spécifications incomplètes: phase d'analyse des besoins du client incomplet.
 Mauvaise gestion des changements
 Négligence et manque de méthodes et d'outils des phases de validation/vérification

2
3. Quelques statistiques

En 1979, une étude du gouvernement américaine, basée sur neuf projets logiciels, fait apparaitre les symptômes
suivants : beaucoup de logiciels ne sont pas livrés, pas utilisés ou abandonnes. Plus précisément, le coût se répartit
de la façon suivante :

Selon une autre étude, réalisée aux Etats-Unis en 1995, le coût se répartit de la façon suivante :

Enquête sur des milliers de projets, de toutes tailles et de tous secteurs

3
(Standish Group, Chaos Report 2015)

 Projets réussis : achevés dans les délais et pour le budget impartis, avec toutes les fonctionnalités
demandées
 Projets mitigés : achevés et opérationnels, mais livrés hors délais, hors budget ou sans toutes les
fonctionnalités demandées
 Projets ratés : abandonnés avant la fin ou livrés mais jamais utilisés

4. Génie Logiciel

Les pères du génie logiciel se prénomment Friedrich Bauer et Louis Bolliet. Cette spécialité a en effet vu le jour
en 1968 sous le parrainage de l'OTAN. Elle avait pour objectif de répondre a 2 constations :

 D'une part, le logiciel n'était pas fiable


 D'autre part, il était difficile à réaliser dans les délais et budgets prévus et en satisfaisant le cahier des
charges
On constat que :

 Le coût de construction du logiciel est devenu plus important que celui de la construction du matériel.
 Délais de livraison non respectés
 Budgets non respectés.
 Le logiciel ne répond pas aux besoins de l'utilisateur ou du client
 Difficile à utiliser, maintenir, et faire évoluer.

4
Introduction de l’expression : « Génie Logiciel » (Software Engineering)
Comment faire des logiciels de qualité ? Qu’attend-on d’un logiciel ? Quels sont les critères de qualité pour un
logiciel ?
Le Génie Logiciel a toutefois amélioré la situation même si ce domaine est moins avancé que les autres
domaines de l'ingénierie tel que le génie civil. Cette avancé à pas de tortue est due à plusieurs raisons
différentes :

 Le logiciel étant un objet immatériel, il est très facilement modifiable.


 Les défauts d'un logiciel résultent principalement des erreurs de manipulation effectuées par les
Hommes. Ce qui rend le contrôle très difficile.

Le génie logiciel est un domaine des sciences de l’ingénieur dont l’objet d’étude est la conception, la
fabrication, et la maintenance des systèmes informatiques complexes.
Le génie logiciel vise à garantir :

 La spécification répond aux besoins réels de ses clients ;


 Le logiciel respecte sa spécification ;
 Les coûts alloués pour sa réalisation sont respectés ;
 Les délais de réalisation sont respectés.
Appliquer des méthodes fiables qui vont guider le développement du logiciel, de sa conception à sa livraison.

II. Critères de réussite d’un projet informatique


1. Piliers de réussite

Le Génie Logiciel se préoccupe des procédés de fabrication des logiciels de façon à s’assurer les 3 critères
suivants soient satisfaits :

2. Loi de Hofstadter (Loi de glissement de planning)

La loi de Hofstadter (ou Loi de glissement de planning) est une loi empirique concernant la difficulté de
la planification dans le domaine de la recherche et du développement (par exemple la methode extreme
programming) elle affirme que :

« Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter »
C’est à dire qu’il est impossible de prévoir le temps qui sera nécessaire à l'accomplissement d'une tâche complexe.

5
3. Qualités attendues d’un logiciel

La norme ISO 9126 définit six groupes d'indicateurs de qualité des logiciels

 Validité : réponse aux besoins des utilisateurs


 Facilité d’utilisation : prise en main et robustesse
 Performance : temps de réponse, débit, fluidité...
 Fiabilité : tolérance aux pannes
 Portabilité : changement d'environnement matériel ou logiciel
 Maintenabilité : facilité à corriger ou transformer le logiciel

a. Validité :
Adéquation entre le besoin effectif du client et les fonctions offertes par le logiciel
Solutions :

 Analyse exhaustive des besoins


 Améliorer la communication entre les intervenants
 Travailler avec rigueur

b. Facilité d’utilisation :
Efficacité et satisfaction avec laquelle des utilisateurs accomplissent leurs objectifs selon leur environnement
Facilité de compréhension : comprendre ce que l’on peut faire avec le logiciel.
Facilité d’apprentissage : savoir comment travailler avec le logiciel
Facilité d’exploitation : effort nécessaire pour utiliser le logiciel
Solutions :

 Analyse du mode opératoire des utilisateurs.


 Adapter l’ergonomie des logiciels aux utilisateurs.

c. Performance
Rapport entre les ressources dédiées (temps, matériel, utilisateurs) et la quantité des résultats produit. Autrement,
le logiciel doit pouvoir utiliser efficacement les ressources matérielles. Par exemple la mémoire, la puissance de
l’U.C., etc
Solutions :

 Logiciels plus simples


 Veiller à la complexité des algorithmes
 Machines plus performantes

d. Fiabilité
C’est l'aptitude du logiciel à fonctionner en continu et même dans des conditions anormales.

6
Justesse et conformité: le logiciel retourne des résultats corrects quelles que soient les conditions d’exploitation.
Robustesse et sureté: le logiciel fonctionne raisonnablement en toutes circonstances (utilisation intensive),
même en dehors des conditions d’utilisation prévues (tolérance aux pannes)

Mesures :
∑(𝑑𝑢𝑟é𝑒 𝑑𝑒 𝑓𝑜𝑛𝑐𝑡𝑖𝑜𝑛𝑛𝑒𝑚𝑒𝑛𝑡−𝑑𝑢𝑟é𝑒 𝑑𝑒 𝑝𝑎𝑛𝑛𝑒)
 MTBF: Mean Time Between Failures 𝑛𝑜𝑚𝑏𝑟𝑒 𝑑𝑒 𝑝𝑎𝑛𝑛𝑒
 Disponibilité (pourcentage du temps pendant lequel le système est utilisable) et Taux d’erreur (nombre
d’erreurs par KLOC)
En moyenne on trouve entre 10 et 20 erreurs par 1000 lignes de code lors des premières versions d'un projet
et 0.5 erreur par KLOC (KLOC = 1000 lignes de code) dans la version finale d'un produit.
Solutions :

 Utiliser des méthodes formelles, des langages et des méthodes de programmation de haut niveau
 Vérifications, tests

e. Portabilité
Un logiciel doit pouvoir fonctionner sur plusieurs machines et qu’il doit s'exécuter sous plusieurs environnements
différents. C’est-à-dire la facilité à être porté sur de nouveaux environnements matériels et/ou logiciels.
Facilité d'adaptation à des changements d'environnements opérationnels (matériel ou logiciel)

Facilité d'installation
Coexistence avec d’autres logiciels
Solutions :

 Rendre le logiciel indépendant de son environnement d’exécution.


 Machines virtuelles.

f. Maintenabilité
L'effort nécessaire à corriger ou transformer le logiciel. En effet, La maintenance consiste à effectuer des
modifications du logiciel après sa livraison. Ainsi qu’il doit pouvoir accepter l'ajout de nouvelles fonctionnalités.

Solutions:

 La conception par sous-ensembles faciles à démonter et à interchanger.


 Une parfaite communication entre opérateur et technicien de maintenance.

III. Approches du génie logiciel


1. Introduction

Le génie logiciel est un domaine en pleine évolution qui offre une grande palette d’outils et de méthodes pour
parvenir à construire du logiciel de qualité.
Aucune de ces méthodes ne s’est imposée à ce jour : il faut donc prendre du recul sur les concepts et les conseils
qu’elles préconisent et utiliser son bon sens pour les adapter à chaque situation.

7
Ces méthodes se distinguent principalement par :

 Leur degré de formalisme ;


 Leur champ d’application ;
 Les contraintes de qualité qu’elles ambitionnent.

2. Approches formelles

Les approches formelles utilisent des outils mathématiques et des méthodes de preuve pour construire un
logiciel correct par construction dont la vérification est automatisée ou assistée.
Exemple (approches formelles)
Méthodes : méthode B, model-checking, logique de Hoare, . . .
Outils et notations : Coq, Z, Atelier B, Why, Frama-C, . . .
Ces méthodes sont utilisées pour développer des logiciels critiques.
Elles correspondent au niveau le plus élevé de certification.
e.g. applications de la méthode B pour développer le logiciel embarqué des lignes de métro 14 (1998) et 1 à Paris

3. Approches semi-formelles

Les approches semi-formelles visent à introduire un langage normalisé pour décrire le logiciel et sa spécification.
Cependant, la sémantique du langage de spécification n’est pas formalisée.
Bien que ces approches précisent le discours du concepteur si on le compare à celui décrit à l’aide du langage
naturel, elles contiennent certaines ambiguïtés et n’offrent aucune garantie sur la qualité des résultats.
Exemple (approches semi-formelles)
Méthodes : Rationale Unified Process, Merise, . . .
Outils et notations : UML, AnalyseSI, . . .
Ces méthodes sont utilisées aujourd’hui par l’industrie du logiciel.

4. Approches empiriques

Les approches empiriques mettent en avant un ensemble de “bonnes pratiques” qui ont fait leur preuve par
l’expérience.
Exemple (approches empiriques)
Méthodes : unit testing ([Link]. la famille xUnit), peer review, relecture de Code, extreme programming,
programmation défensive...
Outils : plates-formes de test, gestionnaire de versions ([Link]. Git), outil de documentation automatique ([Link].
Doxygen) / literate programming, . . .

5. Les grands principes du génie logiciel

Un certain nombre de grands principes (de bon sens) se retrouvent dans toutes ces méthodes. (C. Ghezzi.
Fundamentals of Software Engineering. Prentice Hall, 2nd edition, 2002. )

 La rigueur;

8
 La décomposition des problèmes en sous-problèmes;
 La modularité;
 L’abstraction
 L’anticipation des évolutions;
 La généricité;
 La construction incrémentale

a. La rigueur :
Les principales sources de défaillances d’un logiciel sont d’origine humaine. La production de logiciel est une
activité créative, mais qui doit se conduire avec une certaine rigueur. Par exemple, le résultat d'une activité de
création pure peut être évalué rigoureusement, avec des critères précis.
À tout moment, il faut se questionner sur la validité de son action. Des outils de vérification accompagnant le
développement peuvent aider à réduire les erreurs.

Exemples
Générateurs de code, assistants de preuves, générateurs de tests, profileurs, test coverage, outil d’intégration
continue, fuzzer, . . .
b. Décomposition des problèmes
C’est un aspect de la stratégie générale du « diviser pour régner ». C’est à dire C’est une règle qui consiste à
considérer séparément différents aspects d’un problème afin d’en maîtriser la complexité.

 Simplifier les problèmes (temporairement) pour aborder leur complexité progressivement.


 Décorréler les problèmes pour n’en traiter qu’un seul à la fois.

Exemple
Comment créer dynamiquement une page internet pour visualiser et modifier le contenu d’une base donnée sans
la corrompre ?

 Décomposition en trois composants :


 Modèle: son rôle est gérer le stockage des données.
 Vue: son rôle est de formater les données.
Contrôleur: son rôle est de n’autoriser que les modifications correctes.

 Comment acheminer un email de façon sûr à travers un réseau?


 Décomposition en couches utilisée sur Internet : SMP TCP ..
c. Modularité
C’est une instance cruciale du principe de décomposition des problèmes.
Il s’agit de partitionner le logiciel en modules qui :

 Ont une cohérence interne (des invariants) ;


 Possèdent une interface ne divulguant sur le contenu du module que ce qui est strictement nécessaire aux
modules clients.
 L’évolution de l’interface est indépendante de celle de l’implémentation du module.
 Les choix d’implémentation sont indépendants de l’utilisation du module.

9
d. Abstraction
C’est encore une instance du principe de décomposition des problèmes. Il s’agit d’exhiber des concepts généraux
regroupant un certain nombre de cas particuliers et de raisonner sur ces concepts généraux plutôt que sur chacun
des cas particuliers.
Le fait de fixer la bonne granularité de détails permet:

 De raisonner plus efficacement ;


 De factoriser le travail en instanciant le raisonnement général sur chaque cas particulier.
Exemple (Support dans les langages de programmation)

 Les classes abstraites dans les langages à objets (FormeGéométrique, Carrée, rectangle, Triangle)
Anticipation des évolutions
Un logiciel a un cycle de vie plus complexe que l’habituel
Commande → spécification → production → livraison
La caractéristique essentielle du logiciel, par rapport à d’autres produits, est qu’il est presque toujours soumis à
des changements continuels (Ex corrections et évolutions en fonctions des besoins qui changent).
La maintenance est la gestion des évolutions du logiciel.
Il est primordial de prévoir les évolutions possibles d’un logiciel pour que la maintenance soit la plus efficace
possible. Pour cela, il faut s’assurer que les modifications à effectuer soient le plus locales possibles. Ces
modifications ne devraient pas être intrusives car les modifications du produit existant remettent en cause ses
précédentes validations.

e. Généricité
Il est parfois avantageux de remplacer la résolution d’un problème spécifique par la résolution d’un problème
plus général. Puisqu’un logiciel réutilisable à beaucoup plus de valeur qu’un composant dédié. Un composant est
générique lorsqu’il est adaptable.
Exemple :
Plutôt que d’écrire une identification spécifique à un écran particulier, écrire (ou réutiliser) un module générique
d’authentification (saisie d’une identification et éventuellement d’un mot de passe).

f. Construction incrémentale
Un développement logiciel a plus de chances d’aboutir s’il suit un cheminement incrémental (baby-steps).
Exemple Laquelle de ses deux méthodes de programmation est la plus efficace ?
Écrire l’ensemble du code source d’un programme et compiler.
Écrire le code source d’une fonction ou module, le compiler, et passer à la suivante.

IV. Processus de développement logiciel


1. Introduction

Les méthodes de développement, ont pour but de faciliter la communication avec les utilisateurs, de réduire la
complexité en proposant des vues à différents niveaux d’abstraction, de guider la construction du logiciel et de
documenter les différents choix de conception.

10
Un processus de développement logiciel est un ensemble (structuré) d’activités que conduisent à la production
d’un logiciel
« La qualité du processus de fabrication est garante de la qualité du produit »

 Pour obtenir un logiciel de qualité, il faut en maîtriser le processus d’élaboration


 La vie d’un logiciel est composée de différentes étapes
 La succession de ces étapes forme le cycle de vie du logiciel
 Il faut contrôler la succession de ces différentes étapes
En pratique:

 Il n’existe pas de processus idéal.


 La plupart des entreprises adapte les processus existants à leurs besoins.
 Ces besoins varient en fonction du domaine, des contraintes de qualité, des personnes impliquées.

2. Activités du développement logiciel

L'ensemble des étapes ou des phases qui interviennent dans le développement d'un logiciel constitue le cycle de
vie de celui-ci. Lorsque le découpage est ainsi effectué, la détection des erreurs se fait beaucoup plus tôt. Ce qui
implique que nous maîtrisons non seulement la qualité du logiciel mais aussi les délais et les coûts. Les étapes ou
Activités du développement d’un logiciel

 Analyse des besoins


 Spécification
 Conception
 Programmation
 Validation et vérification
 Livraison
 Maintenance
Chaque Activité:

 Possède des entrées et des sorties


 Les livrables font parties des sorties (Documents, Planning, code source)

1. Analyse des besoins

Objectif :
Comprendre les besoins du client c'est dans cette étape que l'on définit la finalité du projet. Nous discutions avec
le client et les futurs utilisateurs afin de comprendre de quoi ils ont besoin
Objectifs généraux, environnement du futur système, ressources disponibles, contraintes de performance...
Entrée : Fournie par le client
Expert du domaine d'application, futur utilisateur
Documents produits : Cahier des charges (+ manuel d'utilisation préliminaire)
2. Spécification

Objectif :

11
Établir une description claire de ce que doit faire le logiciel (fonctionnalités détaillées, exigences de qualité,
interface...). Dans cette étape de spécification que nous pourrons affiner ce qui a été défini dans l’étape
précédente. En détaillant davantage le fonctionnement interne du futur logiciel.
Une fois que l'on a recueilli ces besoins, on réalise une étude de la faisabilité de ces besoins. C’est-à-dire on doit
clarifier le cahier des charges (ambiguïtés, contradictions)
Entrée : Cahier des charges + considérations de faisabilité
Document produit : Cahier des charges fonctionnel
3. Conception

Objectif :
Ici, on élabore les spécifications de l’architecture générale du logiciel et on spécifie de façon détaillée chaque
sous-ensemble du logiciel que l'on va construire. Description architecturale en composants (avec interface et
fonctionnalités)

 Réalisation des fonctionnalités par les composants (algorithmes, organisation des données)
 Réalisation des exigences non-fonctionnelles (performance, sécurité...)
Entrée : Cahier des charges fonctionnel
Document produit : Dossier de conception
Par exemple on propose de solution au problème spécifié dans l’étape précédente on organise l’application en
modules et interface des modules (architecture du logiciel)
4. Programmation

Objectif :
On implémente les fonctionnalités définies pendant la conception. C’est-à-dire la réalisation de logiciel à l’aide
de langages de programmation, de systèmes de gestion de bases de données, etc.
Entrée : Dossier de conception
Documents produits : Code documenté + manuel d'utilisation
5. Validation et vérification

Objectifs :
Validation : assurer que les besoins du client sont satisfaits (au niveau de la spécification, du produit fini...)
Vérification : assurer que le logiciel satisfait sa spécification
Durant les tests, les informaticiens vérifient que le logiciel fonctionne et répond aux besoins définis en début du
projet. Cette phase de tests peut intégrer des validations du logiciel avec le client ou avec les utilisateurs.

12
Donc il faut essayer le logiciel sur des données d’exemple pour s’assurer qu’il fonctionne correctement

 Tests unitaires : faire tester les parties du logiciel par leurs développeurs
 Tests d’intégration : tester pendant l’intégration
 Tests de validation : pour acceptation par l’acheteur
 Tests système : tester dans un environnement proche de l’environnement de production
 Tests Alpha : faire tester par le client sur le site de développement
 Tests Bêta : faire tester par le client sur le site de production
 Tests de régression : enregistrer les résultats des tests et les comparer à ceux des anciennes versions afin
de vérifier le taux de compatibilité

 Méthodes de validation :
o Revue de spécification, de code
o Prototypage rapide
o Développement de tests exécutables

 Méthodes de vérification :
o Test (à partir de la spécification) : exécution d'un programme sur des données choisies dans le
but de détecter des non-conformités par rapport à la spécification
o Preuve de programmes : preuve mathématique qu'un programme satisfait sa spécification en
termes de pré- et post-conditions
o Model-checking: analyse d'un modèle du programme dans le but de prouver mathématiquement
qu'il vérifie certaines propriétés dynamiques
6. Livraison
Fournir au client une solution logicielle qui fonctionne correctement Installation :

 Rendre le logiciel opérationnel sur le site du client


 Formation: enseigner aux utilisateurs comment se servir du logiciel
 Assistance : répondre aux questions des utilisateurs

7. Maintenance
La maintenance correspond à la période qui suit l’installation et pendant laquelle les anomalies et problèmes
doivent être corrigés. Elle comporte toutes les corrections et toutes les évolutions sur le logiciel. Comme le

13
logiciel est modifié, il devient plus en plus complexe à moins que le travail soit effectué pour réduire la
complexité.
Lois de Belady et Lehman :
Un logiciel est en constante évolution
La livraison n’est pas une fin en soi, après sa livraison un logiciel peut être modifié. Lorsqu’un logiciel évolue,
il devient:

 Moins structuré
 Plus complexe
On distingue trois types de maintenance:
Maintenance Corrective : L’objectif de la maintenance corrective est de localiser les spécifications originelles
afin de déterminer ce que le système était initialement sensé faire. Donc il faut identifier et corriger des erreurs
trouvées après la livraison:

 Identifier la défaillance;
 Le fonctionnement Localiser la partie du code responsable;
 Corriger et estimer l’impact d’une modification
Il faut faire attention que :

 La majorité des corrections introduisent de nouvelles erreurs


 Les coûts de correction augmentent considérablement avec le délai de détection
La maintenance corrective donne lieu à des nouvelles livraisons
Maintenance Adaptative : Adapter le logiciel afin qu’il continue à fonctionner correctement en tenant compte
des changements enregistrés dans l'environnement c’est-à-dire modification d'un progiciel effectuée après
livraison pour qu'il reste utilisable dans un environnement qui change ou a changé.

 Format des données,


 Environnement d'exécution,
 Changement de SGBD,
Par exemple, le système d’exploitation peut être mis à jour et des modifications peuvent être nécessaires afin de
s’accommoder à ce nouveau système d’exploitation:
Maintenance Perfective : c’est la modification d'un progiciel effectuée après livraison pour en améliorer
l'efficacité ou la maintenabilité et de comprend tous les changements faits sur un système afin de satisfaire aux
besoins de l’utilisateur.

 Améliorer la performance,
 Ajouter des fonctionnalités,
 Améliorer la maintenabilité.

14

Vous aimerez peut-être aussi