Discussion :

[Ricky81]

Bonjour,

Klaus Lambertz décrit dans cet article les grandes métriques permettant d'évaluer la qualité d'un projet par l'analyse du code source.
Il y introduit également la notion d'index de maintenabilité, évaluation de l'état qualitatif du code devant permettre aux décideurs d'identifier si la situation n'est pas à tel point mal engagée qu'une réécriture complète s'avérera plus économique et saine qu'une maintenance palliative.
Enfin, il présente une certains nombre d'outil commerciaux permettant de traiter toutes ces problématiques.

Qu'en pensez vous ?
Avez vous eu l'occasion de mener (ou subir) un audit qualité portant sur la qualité / maintenabilité du code source ?

[souviron34]

Bonjour,

Klaus Lambertz décrit dans cet article les grandes métriques permettant d'évaluer la qualité d'un projet par l'analyse du code source.
Il y introduit également la notion d'index de maintenabilité, évaluation de l'état qualitatif du code devant permettre aux décideurs d'identifier si la situation n'est pas à tel point mal engagée qu'une réécriture complète s'avérera plus économique et saine qu'une maintenance palliative.
Enfin, il présente une certains nombre d'outil commerciaux permettant de traiter toutes ces problématiques.

Qu'en pensez vous ?
Avez vous eu l'occasion de mener (ou subir) un audit qualité portant sur la qualité / maintenabilité du code source ?

j'ai eu l'occasion de mener un audit sur un très très très gros projet, et la métrique utilisée n'était pas du tout celles-là, qui étaient plus ou moins celles suivies par les Chefs du Projet..

Ma "métrique" était "agile", ou plutôt ergonomique et user-centered..

Mesurer (fimer et comptabiliser) le temps mis par un utilisateur pour remplir sa tâche (complexe) avec le logiciel, et comparer avec la même chose faite à la main.

La conclusion étant sans appel, le diagnostic du pourquoi était sans métrique : la base de l'architecture était mauvaise.

Donc la seule solution était de tout reprendre depuis le départ..

Pour convaincre le Conseil d'Administration, le film comparatif logiciel/main, plus l'évaluation de ce que le projet avait coûté depuis le départ et une estimation du surcoût, plus une certaine liste des investissements dans le domaine par les concurrents, a permis de donner le feu vert.


Je ne crois pas aux formules mathématiques de complexité, de maintenance, etc..

Je crois à l'expérience de gens expérimentés, polyvalents, ayant évolués sur des projets divers dans des environnements variés..



Projet : système d'informatisation des hopitaux
Cout : 80 millions de dollars
Durée : 14 ans
Nombre de personnes : 60
Lignes de code : 2 millions

Audit : 2 mois
Estimation du surcout : 1.5 millions
Délai : 1 an
Nombre de personnes : 6
Lignes de code : 150 000


Concurrence :
3M : 450 millions de dollars
Association des assurances de la Californie du Nord : 1 milliard de dollars


Toutes les métriques "mathématiques" utilisées (ainsi que les gestions de projet et méthodologie) que j'ai vue utilisées se sont soldées par des échecs..

[hugo123]

Ca reste a des niveaux différents. Démontrer de l'usabilité d'un logiciel et démontrer qu'une conception est mauvaise n'empêche pas d'utiliser ces métriques au jour le jour. Je pense que les deux démarches sont complémentaires.

Deux exemples pour illustrer mon propos:

1) J'ai bossé sur un projet ou le client final imposait la livraison des métriques avec le code. Effectivement c'était dans ce cas précis inutile puisqu'il n'y a pas eu adoption des métriques et surtout qu'elle paraissait obscure à toute l'équipe. Du coup on utilisait des astuces pour respecter les normes mais sans aucune logique. Clairement les métriques étaient respectés mais cela ne reflétait pas la qualité du code.

2) A l'inverse, j'ai bossé sur un autre projet ou l'utilisation de métriques avait été murement réfléchi et intégré dans l'architecture d'intégration continue. Chaque métrique utilisé a été expliqué et donc adopté. Et surtout, les méthodes pour les respecter correspondaient vraiment à quelque chose.
Cela ne garantit pas une bonne architecture, mais ca prévient de certaines dérives qui nuise à la maintenance par la suite.

En bref, pour moi, dire qu'on peut s'en passer et réaliser des audits manuels c'est effectivement vrai. De la même façon qu'on peut se passer de tests unitaires et ne réaliser que des tests d'intégration manuellement. Il y a des sociétés qui fonctionnent comme ça et ça marche.
Mais utiliser des tests unitaires ou des métriques c'est se donner les moyens de réagir avant, car bugs ou métriques mal respectés, plus tard c'est détecté et plus ca coute cher à réparer.
Maintenant, on peut mal utiliser les métriques comme on peut mal utiliser les tests unitaires, c'est sur.

public void testNothing()
{
try
{
doTreatment();
}
catch (Throwable e)
{
// do nothing
}
assertTrue (true);
}

[souviron34]

je te citerais un autre exemple.. Il y a un an 1/2, j'ai travaillé sur un projet utilisant des métriques LOC.

totalement hors de propos...


Maintenance et améliorations d'un code industriel critique d'environ 1 million de ligne, 14 programmeurs.

Bug report => analyse => 1/4 ligne à changer <=> 2 semaines de boulot et paperasse

Bug report => analyse => 2 lignes à changer <=> 2 mois de boulot

New Feature => analyse => 100 lignes à créer <=> 3 jours de boulot