que rapporte le respect des métriques et des guideline sur la maintenance ?

[elekis]

Bonjour,

Aujourd'hui, 80% du temps d'un projet est de la maintenance.

Je cherche a savoir quelle serait l'impacte du respect de guideline et de métrique
(genre par exemple convention de nom, NOC par methode, etc. etc...Etc...)
Sur la maintenance du logiciel.

Attention, je ne cherche pas le point de vue developpers (ce que je suis) et qui sait qu'un logiciel mal ecrit est inmaintenable, mais le point de vue economique ou manager.

En fait, il m'a été demandé une petite étude d'impact dans le cas ou obligerait les développers,chef de projet a suivre les guidelines et obliger l'utilisation de guideline (et metrique) avant de passer en production.

PS : je cherche idéalement des études, des papiers avec des chiffres de cout, etc...Etc... pas des je pense que etc...etc... J'ai cherche sur internet, mais je n'ai pas trouver, peut etre n'ai je pas taper les bons mot dans google.

merci

a+

[gangsoleil]

Bonjour,

Tu ne trouveras probablement rien d'ecrit sur le sujet, car il est extremement difficile de mener ce genre d'etude : il faudrait comparer le meme projet dans deux cadres similaires, ce qui est presque impossible.

Ce que tu peux neanmoins avancer comme arguments se situe au niveau de l'analyse de bugs :
Le client a un soucis, et appelle le support niveau 1. Celui-ci applique les procedures, ce qui ne resoud pas le probleme. Il passe donc l'incident au niveau 2.
Le niveau 2 se connecte sur la machine, verifie logs et fichiers de conf, redemarre le logiciel, ... Mais ca ne fonctionne toujours pas, et il passe donc l'incident au support niveau 3 ou 4.
--> Jusqu'ici pas de changement.
Le support niveau 3/4 commence l'analyse du bug avec etude du code source. Que ce soit ou non l'equipe ayant developpe le logiciel, il est probable que cela fasse plusieurs mois, et que de toute maniere l'analyse soit d'abord globale avant de pouvoir identifier la partie du code posant probleme.
--> C'est ici que le gain est grand : avec de la doc et du code bien ecrit et standard, il est beaucoup plus facile, et rapide, de rentrer dans le code. Pour l'avoir fait un peu, j'estimerai le gain a un facteur 3 ou 4.

Une fois le bug trouve, le fait d'avoir un code propre et standard permet aux developpeurs de le corriger plus rapidement, meme si les fonctions ont ete ecrites il y a deja quelques temps.

L'ecriture des tests unitaires est egalement simplifiee, ainsi que la validation continue.

[elekis]

J'ai quand meme trouver 2 chiffres impressionnant.

1) 80 % de la vie d'un projet est de la maintenance (mais ca, je savais).
2) 21 % de temps perdu en plus a comprendre un code non ou mal documenté.

On peut prendre le probleme a l'envers alors, quelle sont les risque a ne pas respecter des guidelines. (risques de compréhension,etc...).

Je continue ma recherche.

a+

[elekis]

il y a une autre question que je me pause aussi

quelle est le surcout dans la partie developpement du logiciel pour respecter les guidelines. il y a probleement un surcout au developpement qui se repercutera a la maintenance, mais lequel ...

merci

a+

[gangsoleil]

Bonjour,

Le surcout pour respecter les guidelines, si celles-ci sont correctement faites, est negligeable.

Ce qui est beaucoup moins negligeable, c'est le temps d'adaptation des developpeurs : le changement est toujours difficile, et le temps d'adaptation sera probablement de deux ou trois mois.

2) 21 % de temps perdu en plus a comprendre un code non ou mal documenté.

Moui. Chiffre a relativiser par rapport a ce qu'on appelle un code documente : est-ce que specs techniques + commentaires rentrent dans ce cadre ?
Et il ne faut pas oublier que trop de documentation va aussi bloquer le developpeur, qui n'a pas forcement envie de se taper une doc de 100 pages avant de comprendre par ou commencer.

[QUOTE]Quelles sont les risques a ne pas respecter des guidelines./QUOTE]

Augmenter le temps necessaire a (re)rentrer dans le code
Necessite que ce soit le developpeur qui a ecrit le code qui suive le bug et le corrige
Augmentation du poids de l'historique, ce qui va conduire a terme (8 a 10 ans pour une moyenne application) a la non-maintenabilite de l'application, et donc a un besoin de re-ecriture complete.