Chapitre 2 : Crise Logiciel :

Constat, sources et solutions

Rania MZID
Institut Supérieur d’Informatique (ISI Ariana)
Crise du logiciel : Constat
Historiquement, il y a eu une prise de conscience dans les
années 70, appelée la crise du logiciel, dû à un tournant décisif
: c’est à cette époque que le coût de construction du logiciel est
devenu plus important que celui de la construction du matériel.

Deux constatations :
Le logiciel n’était pas fiable
Il était incroyablement difficile de réaliser dans des délais
prévus des logiciels satisfaisant leurs cahiers des charges

2
Crise du logiciel : Constat
Le logiciel n’était pas fiable

La première sonde Mariner vers Venus qui s’est perdue dans

l’espace à cause d’une erreur dans un programme Fortran

Fusée Ariane 5 qui s’est explosé : Passage de Ariane 4 vers Ariane

5 sans prendre en compte le changement de la vitesse maximale

Les bugs de l’an 2000 : à l’époque, la plupart des logiciels

traitaient les dates avec deux chiffres . Quand l’an 2000 fut sur le
point d’arriver, personne ne pouvait vraiment prédire ce qui allait
se passer.

Dans la nuit du 15 au 16 décembre 1990, les abonnés de ATT de la

côte Est des Etats-Unis furent privés de tout appel longue distance
à cause d’ un changement brusque du version logiciel du réseau
3
Crise du logiciel : Constat
Il était incroyablement difficile de réaliser dans des délais
prévus des logiciels satisfaisant leurs cahiers des charges

Certains projets n’aboutissent jamais

Compilateur PL1 chez Control Data dans les années 70

D’autres aboutissent avec des retards importants et des

remises en cause dramatiques
SNCF a rencontré des difficultés importantes à la mise
en service du système Socrate
OS-360 d’IBM (OS pour la série System/360, annoncée
en 1964) fut livré en retard, il nécessitait plus de
mémoire que prévu, son prix de revient dépassait de
beaucoup les estimations, et ses premières versions
comportaient des erreurs
4
Crise du logiciel : Constat
Les symptômes les plus caractéristiques de cette crise sont :

Les logiciels réalisés ne correspondent souvent pas aux besoins

des utilisateurs
Les logiciels contiennent trop d’erreurs (qualité du logiciel
insuffisante)
Les coûts de développement sont rarement prévisibles
La maintenance des logiciels est une tâche complexe et coûteuse
Les délais de réalisation sont généralement dépassés
Les logiciels sont rarement portables

5
Crise du logiciel : Constat
Le développement logiciel n’est pas une opération facile
Le taux de succès des projets (Standish Group)

6
Crise du logiciel : Constat
D’autres statistiques:

➢Plus de 30 % de tous les projets logiciels sont abandonnés

avant la fin.
➢Equipe de MEP du projet non compétente
➢Dépassement du budget et/ou du temps
➢Ne cadre pas les besoins des utilisateurs, …
➢Plus de 70 % du reste échouent à la livraison des
caractéristiques attendues.
➢Le logiciel ne répond pas aux besoins des utilisateurs, …
➢Le projet moyen dépasse par un facteur de 189 % (en moyenne
mais ce dépassement peut atteindre le 400%)
➢son budget et
➢son échéancier.

7
Crise du logiciel : Sources
La taille et la complexité du logiciel :
La complexité fonctionnelle
On demande de plus en plus de fonctionnalités
Les utilisateurs sont de plus en plus exigeants

Les technologies en évolution croissante…

Matériel
Technologie

Une complexité architecturale

Architecture répartie en réseaux (client/serveur, …)
Sites distants, …

8
Crise du logiciel : Sources
La taille croissante des équipes :

Des compétences de plus en plus variées

Les fonctionnalités des logiciels sont de plus en plus
complexes, une seule personne ne peut pas maîtriser toutes
les exigences des utilisateurs (on ne peut pas être bon dans
toutes les disciplines)

Communication entre les membres d’équipes

9
Crise du logiciel : Sources

Des spécifications du logiciel sont peu précises

Les spécifications des besoins

sont les fondements d’un projet informatique ,
sont une interface difficile entre le domaine métier et
l’informatique.

Des spécifications qui peuvent changer

Si elles sont mal expliquées, tout le projet peut échouer.

10
Crise du logiciel : Sources
Des spécifications du logiciel sont peu précises

11
Crise du logiciel : Sources
Des processus peu adaptés
C’est quoi un processus?
Ensemble d'étapes partiellement ordonnées, qui concourent à
l'obtention d'un système logiciel ou à l'évolution d'un système
existant
Pour décrire qui fait quoi à quel moment et de quelle façon pour
atteindre un certain objectif
Objectif : produire des logiciels
▪De qualité (qui répondent aux besoins de leurs utilisateurs)
▪Dans des temps et des coûts prévisibles
Crise du logiciel : Sources
Des processus peu adaptés
 14

Crise du logiciel : Sources

Les approches classiques

Modèles de cycles de vie linéaire
▪Un processus de type séquentiel :
développement organisé en phases
▪Les phases se suivent dans l’ordre et
sans retour en arrière

• Le cycle en cascade
▪Amélioration du cycle linéaire
▪Un retour possible à la phase en amont
 15

Crise du logiciel : Sources

Les approches classiques

Cycle en V
▪Variante du modèle linéaire
▪Les tests bien structurés : définition des
plans de tests tôt dans le cycle de
développement
 16

Crise du logiciel : Sources

Problèmes des approches classiques

•Le risque diminue avec le temps
•Risques élevés et non contrôlés
▪Identification tardive des problèmes
▪Preuve tardive de bon fonctionnement
• Décisions stratégiques prise au moment où le système est le
moins bien connu
• Non-prise en compte de l’évolution des besoins pendant le
cycle
 17

Crise du logiciel : Solutions

Nouvelles Approches
• Les nouvelles approches du génie logiciel doivent remédier aux
problèmes des approches classiques

▪La rigueur
▪La construction itérative
▪La séparation des préoccupations
▪Abstraction
 18

La rigueur

•Les principales sources de défaillances d’un logiciel sont

d’origine humaine
Automatiser le développement logiciel
▪Réduire les interventions humaines
Des outils de vérification accompagnant le
développement peuvent aider à réduire les erreurs (AGL
Ateliers du génie logiciel (AGL)
o Un logiciel intégrant un ensemble d’outils aidant à la
production d'un logiciel. Il assiste la démarche de génie
logiciel poursuivie.
o Le mot en anglais est plus explicite
▪ CASE tools : Computer Aided Software Engineering
o Un AGL est basé sur des méthodologies pour formaliser : Le
processus logiciel et chacune des phases qui le
composent.
Automatiser tout ou une partie du processus de
développement du logiciel
Ateliers du génie logiciel (AGL)
o L’objectif est d’aider l'utilisateur dans l'application de la
méthode de développement afin de :
• Faciliter l'utilisation des techniques de modélisation
• Faciliter la production des documents
• Accélérer la production des systèmes
• Contrôler la cohérence et la complétude des systèmes produits

o Aider au déroulement des activités techniques de

l'analyse, la conception, la réalisation et la maintenance
 Ateliers du génie logiciel (AGL)
🞂 Objectifs d’un AGL

Communication Qualité Productivité

• Langage • Automatiser • Automatiser
commun les contrôles et les tâches
• Support à la les manuelles
production des vérifications
documents
Ateliers du génie logiciel (AGL)
🞂 Classification des AGL
• Les outils horizontaux
• Les outils verticaux
Ateliers du génie logiciel (AGL)
🞂 Classification des AGL : Les outils horizontaux
Ateliers du génie logiciel (AGL)
🞂 Classification des AGL : Les outils verticaux

Orienté
conception
Upper CAS E
tools

Orienté réalisation
Lower CAS E
tools
Ateliers du génie logiciel (AGL)
🞂 Les ateliers orientés conception : Upper CASE
tools
🞂 Assistent la phase initial du projet de développement
🞂 Proposent des outils d'éditions graphiques et peuvent
proposer un outil de prototypage et éventuellement de
reverse engineering
🞂 Exemples : PowerDesigner de Sybase (Basés sur Merise et
UML) , Rational Rose (Basé sur UML), Eclipse (Plug-in UML :
Papyrus)
🞂
Ateliers du génie logiciel (AGL)
🞂 Les ateliers orientés réalisation: Lower CASE tools
🞂 Assistent la phase finale du projet de développement
🞂 Outils de développement ou Environnements de
DéveloppementIntégré (IDE). Exemple : Code-Blocks
(C++) ou Eclipse
🞂 Autres Exemples : PowerBuilder de Sybase, Oracle
Developer de Oracle Corporation (applications BD), etc.
 27

Construction itérative
Un développement logiciel a plus de chances d’aboutir si il suit
un cheminement incrémental
 28

La séparation des préoccupations

« Seperation of concerns » en anglais

Décorreler les problèmes pour n’en traiter qu’un seul à la fois
Deux exemples d’approches
▪ MVC : Model –View-Controller
▪ MDA : Model Driven Architecture
 29

Abstraction
Raisonner sur des concepts généraux, puis raffiner ces concepts pour
ajouter plus de détails
Fixer la bonne granularité de détails permet de
▪Raisonner plus efficacement
▪Cerner le problème traité à chaque niveau d’abstraction
▪Trouver des solutions/ résoudre des problèmes progressivement
 30

Nouvelles approches

• Plusieurs méthodes de développement , processus…

▪ Méthodes agiles , Exemple: eXtreme Programming (XP), SCRUM
▪ UP (Unified Process), Exemple : Rational Unified Process (RUP)
 31

Choix d’un processus –Pour conclure

Crise du logiciel (sources de la crise)

Interpréter
Si les spécifications du logiciel à réaliser changent continuellement, cela ne
pose pas de problème, puisque le logiciel est un produit souple
=> Faux : des changements de spécifications peuvent se révéler coûteux
et prolonger les délais
Si la réalisation du logiciel prend du retard par rapport aux délais prévus, il
suffit d’ajouter plus de programmeurs afin de finir dans les délais.
=> Faux : si l’on ajoute des gens à un projet, il faut compter une période
de familiarisation. Le temps passé à communiquer à l’intérieur du groupe
augmente également, lorsque la taille du groupe augmente.

32
Crise du logiciel (sources de la crise)

Interpréter
Une idée grossière du logiciel à réaliser est suffisante pour commencer à
écrire un programme (il est assez tôt de se préoccuper des détails plus tard).

=> Faux : une idée imprécise du logiciel à réaliser est la cause

principale d’échecs

Une fois que le programme est écrit et fonctionne, le travail est terminé.

=> Faux : la maintenance du logiciel représente un travail

important : le coût de la maintenance représente plus du 50 % du
coût total d’un logiciel

33