Pourquoi la maintenance est elle difficile et coûteuse ?

De nombreux facteurs techniques et non techniques s’ajoutent et rendent la maintenance particulièrement difficile et coûteuse.

Gestion de projets et aspects humains...

Au cours du développement d’un logiciel, de nombreuses personnes assurent le déroulement correct de chaque phase. Chaque personne tient un rôle particulier correspondant à ces compétences. Par la suite les effectifs affectés à la maintenance sont naturellement réduits car il s’agit d’un travail moins intensif.

Les tâches qui incombent aux chargés de maintenance sont les plus diverses, surtout dans les organisations de faible taille. Pour mener à bien toutes ces tâches le chargé de maintenance doit donc posséder de solides compétences dans différents domaines, surtout en l’absence de réelle planification comme c’est souvent le cas lors de la maintenance. La polyvalence, la patience, la flexibilité, la capacité à se motiver soi-même, la capacité d’organisation, la responsabilité sont des qualités nécessaires à un tel rôle. Le profil du chargé de maintenance s’avoisine à celui de la perle rare (Dans on parle de “mouton a 5 pattes”[Stei95]). Malgré cela, ce sont les personnes les moins qualifiées qui sont souvent affectées aux postes de maintenance [GlasNois81] [DartCB93]! La maintenance se caractérise souvent par un manque d’intérêt flagrant. Il en résulte évidemment des coûts élevés mais aussi une détérioration de la qualité du logiciel.

En fait une partie des problèmes de la maintenance vient du fait que celle-ci est sous-estimée par les chefs de projets[GlasNois81] [Schn87]. Les équipes de maintenance travaillent souvent dans de mauvaises conditions et le personnel se sent lésé par rapport aux équipes de développement

[DartCB93].

La maintenance n’est pas toujours prise au sérieux et les chefs de projets préfèrent parfois des solutions bâclées [Wein83]. Weinberg a déterminé expérimentalement la probabilité d’introduire une erreur en fonction du nombre de lignes de code modifiées. Il apparaît que les modifications

figure 14 L’iceberg

Développement

les plus simples sont celles ayant le plus de chances d’introduire des erreurs (tableau 1).

Cela est dû au fait qu’elles semblent si simples qu’aucune attention ne leur est consacrée. Ce phénomène est rapporté par différents auteurs [Buss&al94]. L’application de tous les tests de qualité est souvent omise après de telles modifications. Les 3 erreurs de programmation les plus coûteuses (respectivement $1.600.000.000, $900.000.000 et $245.000.000) sont dues à la modification d’une seule ligne de code![Wein83]. De quoi faire réfléchir...

Facteur temps : de courts délais...

Le temps est une contrainte forte lors du développement de logiciels. La pression correspondant à des délais de livraisons courts font que les logiciels passent souvent en phase de maintenance avant qu’ils ne soient réellement achevés. Tout au long de la maintenance, on observe aussi une telle pression ; avec des délais parfois plus courts encore[DartCB93].

Ce peut être le cas lors du portage de logiciels. S’il existe sur le marché des logiciels concurrents, être le premier à proposer des implémentations pour une nouvelle plate-forme peut être important pour un producteur de logiciels[TilbCroo92].

Rappelons également que le système est en service lors de la maintenance. Des solutions immédiates doivent être apportées si l’on détecte certains dysfonctionnements. C’est le cas par exemple pour les systèmes embarqués. Ce peut être également le cas pour des applications plus “classiques”. Par exemple, la détection d’une erreur dans un système de cartes bancaires peut impliquer des corrections urgentes.

Bien évidemment cette pression au niveau du temps rend la maintenance difficile. D’une part il faut élaborer des solutions en peu de temps, d’autre part les solutions apportées tendent à déstructurer le logiciel.

Facteur temps : de longues périodes...

Le facteur temps joue aussi un rôle inverse. Les durées de vie s’évaluent en années, voire en décennies. La longueur de ces périodes n’est pas sans conséquence.

La mobilité importante du personnel en informatique fait que tout au long de la durée de vie d’un logiciel un grand nombre de personnes différentes interviennent.

Au fur et à mesure que le temps passe, le nombre de personnes “connaissant” le logiciel diminue. Au bout de quelques années il est courant qu’aucune personne n’ayant participé au développement ne soit présente. La mauvaise réputation de la maintenance accentue aussi ce phénomène car une personne affectée à un poste de maintenance a tendance à en changer le plus tôt possible[DartCB93]. Le problème est qu’avec le départ de ces personnes “s’envole” aussi une masse importante de connaissances. Souvent seul le code source reste[Arno93].

La diversité des styles et des méthodes employés par chaque intervenant constitue également un problème important. Il en résulte un produit logiciel peu homogène et difficile à comprendre.

TABLEAU 1 Probabilité d’introduire une erreur par nombre de lignes modifiées[Wein83]

Nombre de lignes de code modifiées 1 2 3 4 5 10 20

De longues durées de vies impliquent aussi de très nombreuses modifications. Chaque année différentes plates-formes matérielles et services logiciels apparaissent, d’autres disparaissent. Les besoins en terme d’application informatique changent également à cause de l’évolution de la société.

Notons aussi le caractère incrémental des modifications apportées lors de la maintenance.

Au début du développement, l’élaboration du cahier des charges a pour but de fixer un ensemble de besoins. Il est alors possible de construire un système de qualité répondant à ces besoins. Par contre, au cours de la maintenance ce n’est que peu à peu que les demandes de modifications sont faites. En l’absence d’une vision globale de ce que va être l’évolution du logiciel il est difficile de proposer directement des solutions générales. Souvent chaque modification est implémentée pour résoudre un problème spécifique et ce n’est qu’avec le temps et l’expérience que l’on découvre a posteriori comment apporter des solutions générales[SchwStra93].

Finalement, pour conclure avec les conséquences néfastes du facteur temps, notons qu’au cours des années les techniques informatiques utilisées changent. Il en résulte des produits logiciels hétérogènes [AikeMR94], où l’on peut par exemple trouver simultanément des parties en assembleurs, en cobol ou utilisant des bases de données relationnelles. Une fois encore, le chargé de maintenance est supposé avoir des compétences polyvalentes...

Remarquons que la plate-forme sur lequel le logiciel est maintenu peut, elle aussi, être obsolète. Des ressources matérielles de mauvaise qualité ne simplifient évidemment pas les activités de maintenance. De plus les équipes de maintenance doivent aussi se contenter des outils périmés fonctionnant sur une plate-forme âgée. Face aux équipes de développement se dotant plus souvent d’outils correspondant à l’état de l’art, les chargés de maintenance se sentent souvent frustrés et abandonnés[DartCB93].

Des logiciels complexes...

La complexité des logiciels à maintenir est évidemment la raison principale expliquant les difficultés de la maintenance car bien entendu pour modifier un logiciel il est tout d’abord nécessaire de bien le comprendre. Obtenir une vision globale d’un logiciel complexe est une tâche très difficile. Comprendre le fonctionnement d’un composant peut l’être aussi, tout comme comprendre quelles sont les interactions entre les différents composants.

Des logiciels de mauvaise qualité...

Actuellement et depuis longtemps, les logiciels que l’on doit maintenir sont, non seulement complexes mais en plus de mauvaise qualité ; tout au moins en ce qui concerne la facilité de maintenance.

En fait la plupart des logiciels existant aujourd’hui ont été conçus sans prendre en compte la facilité de maintenance. Dans les premières décennies de l’informatique, qualité du logiciel et efficacité étaient d’ailleurs synonymes. Les ressources matérielles étaient chères et les logiciels étaient conçus pour en optimiser l’utilisation. Maintenant au contraire c’est l’utilisation des ressources humaines que l’on cherche à optimiser.

L’un des problèmes primordiaux et que la documentation des systèmes en phase de maintenance n’est pas à jour. D’ailleurs les statistiques montrent que les équipes de maintenance se plaignent avant tout de l’absence ou de la mauvaise qualité de la documentation[Schn87] [DartCB93].