Le document aborde la maintenance logicielle, soulignant son importance et sa nécessité dans l'évolution des systèmes logiciels. Il mentionne notamment la prévalence du COBOL dans les applications et les coûts associés à la maintenance, tout en décrivant les défis de la rétro-ingénierie logicielle. La maintenance est présentée non seulement comme une tâche corrective, mais aussi comme un signe de succès et d'adaptation des logiciels à leur environnement.

1. Les pourquois et les comments de la
Maintenance logicielle
Nicolas Anquetil
(Nicolas.Anquetil@inria.fr)

2. Sommaire
● Évangélisation : Maintenance logicielle
– C'est quoi ?
– Importance ?
– Ça existe encore !?!
● Recherche : rétro ingénierie logicielle
– But
– Les difficultés

3. C'est quoi ?
● Un programme pour aller dans le bureau voisin:

debout

tourne à gauche de 45º

avance 2 pas

tourne à droite de 45º

avance 3 pas

tourne à droite de 30º

avance 5 pas

…

4. C'est quoi ?
● Maintenance = modification d'un programme
existant pour :
– corriger une erreur
(“tourne gauche” au lieu de “tourne droite”)
– l'adapter à un changement d'environnement
(faire un détour quand une rue est bloquée)
– prévenir une maintenance future
(corriger une erreur pas encore perçue)
– apporter une amélioration ou une extension
(passer devant la maison de la culture pour aller au
travail)

5. C'est quoi ?
● Maintenance = modification d'un programme
existant pour :
– corriger une erreur
(“tourne gauche” au lieu de “tourne droite”)
– l'adapter à un changement d'environnement
(faire un détour quand une rue est bloquée)
– prévenir une maintenance future
(corriger une erreur pas encore perçue)
– apporter une amélioration ou une extension
(passer devant la maison de la culture pour aller au
travail)
21%
4%
25%
50%

6. Et concrètement ?

7. Et concrètement ?
● Cobol représente > 60% des logiciels au
monde
● 70% des applications commerciales
(“business applications”) sont écrites en
Cobol
● Les applications Cobol traitent 85% des
données commerciales
● Cobol croit de 5 milliards de LOC par an
[eWeeks, 2001]

8. Et concrètement ?
● Cobol - 1959

9. Et concrètement ?
● Cobol – 1959
– Maintenir un programe Cobol c'est comme
faire rouler une voiture comme celle-ci tous
les jours

10. Et concrètement ?
1 feuille 60 lignes de code (LOC)≃
recto/verso = 120 LOC
→ de mon bureau au bas du batiment

11. Et concrètement ?
10 feuilles = 1200 LOC (1.2 KLOC)
→ de mon bureau au café du coin

12. Et concrètement ?
Windows NT 3.1 (1993)
4 à 5 MLOC
→ de mon bureau à la
mosquée Sainte Sophie

13. Et concrètement ?
Windows NT 3.1 (1993)
4 à 5 MLOC
→ de mon bureau à la
mosquée Sainte Sophie
3,75 m 3,20 m
Encyclopedia Britanica
(15 ed., 32 volumes)

14. Et concrètement ?
Windows NT 3.1 (1993)
4 à 5 MLOC
Windows server 2003
50 MLOC
→ de mon bureau à celui de mon
voisin en passant
successivement par :
- New York
- Rio de Janeiro
- Dakar

15. Et concrètement ?
Windows NT 3.1 (1993)
4 à 5 MLOC
Windows server 2003
50 MLOC
41,7 m 46 m

16. Et concrètement ?
Correction de bug =
Trouver la feuille avec
la ligne qui est
erronée …

17. Et concrètement ?
Correction de bug =
Trouver la feuille avec
la ligne qui est
erronée …
→ une instruction erronée
et …

18. Importance ?

19. Importance ?
● 1990 → 120 milliards LOC en maintenance
(Ulrich, 1990).
NB : pile de 100 km de papier
● 2000 → 250 milliards LOC en maintenance
(Sommerville, 2000).
● La quantité de code maintenu double tous les
7 ans (Müller et al., 1994).

20. Importance ?
● Cout annuel aux USA >$70 milliards
(Sutherland, 1995; Edelstein, 1993)
● Nokia a dépensé $90 millions avec le bug de
l'an 2000
● Gouvernement fédéral aux USA a dépensé
$8,38 milliards en 5 ans avec le bug de l'an
2000

21. Importance ?
70s début 80s fin 80s 90s 2000s
0
10
20
30
40
50
60
70
80
90
100
● Estimation du pourcentage de la maintenance
dans le cout total d'un logiciel

22. Ça existe encore !?!

23. Ça existe encore !?!
● On a :
– Langages évolués (OO, AOP)
– Processus modernes (RUP, Agiles)
– Normes de qualité (CMMi)
– Modèles de développement (MDE, SOA)

24. Ça existe encore !?!
● On a :
– Langages évolués (OO, AOP)
– Processus modernes (RUP, Agiles)
– Normes de qualité (CMMi)
– Modèles de développement (MDE, SOA)
C'est quoi le
problème ?!?

25. Il était une fois ...

Un marchand de moules construit un magasin
à Dunkerque ...

26. Il était une fois ...

Les affaires marchent bien

27. Il était une fois ...

Vraiment bien

28. Il était une fois ...

Les employés veulent un restaurant

29. Il était une fois ...

Les directeurs, une terrasse

30. Il était une fois ...

La loi impose une sortie de secours

31. Il était une fois ...

La concurrence offre des goodies aux clients,
l'entreprise … une piscine !

32. Il était une fois ...

etc …

33. Il était une autre fois ...

Avec le logiciel, ça serait possible

En fait c'est comme ça que beaucoup de
systèmes évoluent

34. Il était une autre fois ...

Avec le logiciel, ceci est possible

En fait c'est comme ça que beaucoup de
systèmes évoluent
Un logiciel utilisé dans un
environnement réel doit évoluer sinon
il devient de moins en moins utile dans
cet environnement
1ère loi de l'évolution de
logiciel [Lehman, 1980]:

35. Ça existe encore !?!

La maintenance n'est pas une question de
choix (ni une question de bug)

Les évolutions sont imposées :
– Pression de la concurrence ; Nouvelles lois ;
Nouvelles nécessitées ; Opportunités de marché ;
Evolution des autres systèmes (bibliothèques,
système opérationnel) ; …

36. Ça existe encore !?!

La maintenance est un signe de succès !!!

1ère loi de Lehman
– « Un logiciel utilisé dans un environnement réel doit
évoluer sinon il devient de moins en moins utile
dans cet environnement »

On ne maintient que les systèmes utiles et qui
en valent la peine

37. Ça existe encore !?!

La maintenance résulte de facteurs externes au
logiciel

Les meilleurs processus, environnements,
langages, …
ne peuvent pas diminuer significativement la
maintenance

38. Ça existe encore !?!

Élever le niveau d'abstraction (assembleur,
langages procéduraux, langages à objets,
composants, modèles)
– Ne simplifie pas la maintenance,
– Autorise seulement à faire des programmes plus
riches

39. Rétro-ingénierie logicielle

40. Rétro-ingénierie logicielle

Aider à
– Maintenir les systèmes
(trouver la feuille que l'on doit changer)
– Réorganiser les systèmes
(diviser la pile de feuilles en plusieurs et créer un
indexe)
– Migrer/ré-implémenter les systèmes
(traduire d'un langage à un autre)

41. Rétro-ingénierie logicielle

Difficultés :
– Taille des données
– Abstraire les détails pour comprendre
– Identifier des tâches répétitives, importantes,
automatisables

42. Conclusion
● La maintenance c'est important
– Pas lié à un mauvais développement
– Pas solubles dans les modèles (ou autre)
● Nous avons des solutions
– Nicolas.Anquetil@inria.fr