Discussion :

[Sophis123]

bonjour
j'aimerai savoir s'il existe une/des méthode pour mesurer le niveau de qualité d un développement
le nombre de bug trouve par l'équipe de test par rapport aux lignes de code ou quelque chose comme ça
merci pour votre aide

[Heziva]

Bonjour,

Je ne sais pas quelle vont être tes réponses. J'ai uniquement l'expérience d'une mesure : le nombre de fiches d'incidents ouverts et réouverts, en fonction de leur importance. Le résultat est que les développeurs appellent les testeurs, et évitent un maximum la création de fiche. Cela réduit d'autant la traçabilité. De plus, cela génère des négociations interminables sur la criticité d'un bug, et sur le fait de créer ou non une nouvelle fiche pour une nouvelle problématique.

Solution à éviter selon mes expériences. Ou du moins à ne pas monitorer à la fiche pret.

[souviron34]

je ne crois pas qu'il y ait des outils "tout fait" pour ça, mais un simple petit coup d'Excel ou de machine à calculer avec d'un côté un suivi correct de bug report (par exemple des choses comme la suite Clear de IBM, bien utilisée, ou même cvs ou svn ou ...) , associé de l'autre côté à un comptage brut ou plus ou moins sophisitiqué te donnera une évaluation très correcte..

[Heziva]

Il y a peut être quelque chose à chercher du côté de Lean

[Sophis123]

Merci bcq pour vos réponses
j'ai le comptage de bugs, de ligne de codes
ce que je n'arrive pas à dire c'est si par exemple 50 bugs dans un dev de 1000 lignes de code si c'est acceptable ou pas
je n'ai pas de bench
est ce qu'il existe des normes/pratiques/références dans l'industrie du dev logiciel ?
Cordialement

[souviron34]

ce que je n'arrive pas à dire c'est si par exemple 50 bugs dans un dev de 1000 lignes de code si c'est acceptable ou pas

lol non certainement pas...

5% de bugs, c'est très nettement trop....


Sans mesure précise, serais-tu contente si ta voiture tombait en panne 50 fois en 1000 kms ??


A mon aune, 50 bugs pour 1000 lignes c'est du code cra-cra, bon pour la poubelle ou un débutant... En tous cas certainement pas un code professionnel...

je n'ai pas de bench
est ce qu'il existe des normes/pratiques/références dans l'industrie du dev logiciel ?
Cordialement

Je ne sais pas, mais je dirais à vue de nez au max 1/1000... 1 bug pour 1000 lignes..

Mais ça c'est le max..

En industrie normale, c'est plutôt entre 1/10 000 et 1/100 000, voire 1/1 000 000 ou 1/10 000 000 .ou plus pour les systèmes très critiques...

Une fois qu'un satellite est lancé, ou qu'un sous-marin nucléaire est dans l'eau ou un avion en l'air, vaut mieux que le nombre de bugs soit restreint .. Et vu qu ces softs font au minimum dans les 2 à 10 millions de lignes, juste 1 bug c'est souvent déjà trop...


Je ne sais pas si des barêmes existent vraiment, mais déjà le bon sens (voir mon premier exemple plus haut) est un bon guide... L'exemple de la voiture, ou d'une erreur médicale par exemple : aimerais-tu que le médecin se trompe de diagnostic ou le chirurgien d'organe à opérer 50 fois pour 1000 patients (soit, avec une faible moyenne de 10 patients par jour, une fois tous les 2 jours) ??

[Sophis123]

on avance c'est tres bien merci bcq 50 bugs par ligne de code ct juste un exemple.
maintenant je te l'accorde pour le dev d'une sonde d'un airbus c'est trop mais pour un soft financier pour un marche de niche il y a peut être une tolérance différente.
je ne suis pas sûr qu'on puisse appliquer les mêmes ratios quelque soit le contexte

[souviron34]

on avance c'est tres bien merci bcq 50 bugs par ligne de code ct juste un exemple.
maintenant je te l'accorde pour le dev d'une sonde d'un airbus c'est trop mais pour un soft financier pour un marche de niche il y a peut être une tolérance différente.
je ne suis pas sûr qu'on puisse appliquer les mêmes ratios quelque soit le contexte

lol je n'ai pas dis 50 bugs par ligne de code.. ça c'est vraiment à revoir de toute urgence

Mais même pour un truc financier, ça m'étonnerais qu'on soit au dessus d'un bug pour 100 000 lignes...


Exemple : une erreur d'arrondi sur les millièmes d'euros, multiplié par 1 seule journée de transaction dans le monde, ça doit bien faire quelques millards d'euros...

A ce tarif-là, si on retire du salaire des programmeurs un pro-rata par erreur, ils auront pas de quoi manger...


Moi (de manière personnelle et tout à fait intuitive) c'est à peu près ma tolérance : de 2 à 3 bugs (non critiques) pour environ 500 000 à 700 000 ligne de code...

Maintenant, je suis certain qu'il existe une évaluation pour le domaine financier... Mais, niche ou pas niche, ça ne change rien.. Un financier se fait de l'argent grâce aux transactions...

Donc j'aurais tendance à dire, comme pour tout soft : tendre vers le zéro absolu.. Au max 1/100 000 à 1/ 1 000 000 (en bug/lignes).

[hugo123]

de mon expérience perso il y a plein d'indicateurs possible pour la qualité du code mais ca dépend du contexte dans lequel tu veux les appliquer :

- dans un cadre contractuel, pour mesurer la qualité d'un fournisseur, j'ai déjà eu l'occasion d'utiliser des indicateurs de qualité :

tu définis des seuils classiques : mineur, majeur, critique etc... et un poids associé à chacune, par exemple mineur = 1, majeur = 5, critique = 10 et tu définis un seul mensuel à ne pas dépasser.
Qui dit cadre contractuel dit lutte commercial pour revoir la criticité d'une anomalie. Mais c'est assez normal a mon avis de challenger une maintenance applicative par des objectifs de résultat mesurable.

- dans un cadre de développement et d'intégration continue, dans chaque language t'as des outils pour mesurer la qualité d'un code : maccabe, findbugs, etc... tu peux trouver quelques articles la dessus sur developpez.com. Ce sont de bons indicateurs journaliers, à ne pas confondre avec un audit de code. Pour la plupart de ces outils tu peux forcer des seuils au dela duquel tu estimes que c'est un code de mauvaise qualité. Les paramétrages par défaut sont souvent pas mal pour un premier départ.

- et justement après je citerais tout simplement l'audit qualité effectué par un expert technique. Ce type d'audit va balayer le code sur un ensemble de critères et rapporter les problèmes rencontrés.

[Sophis123]

donc on a
1bug critique/100000 lignes de code.

combien de personne on met derrière les 100M lignes de code?

[souviron34]

lol ça dépend des projets : 1, 5, 50, 100, 20 000....

Que cherches-tu exactement ??

[Patriarch24]

Il existe de très nombreuses métriques pour mesurer la qualité d'un code :
- les métriques d'architecture (couplage de classes, abstraction, etc), de dépendances
- la couverture des tests
- les mesures de performances
- les métriques de qualité de texte (convention de codage)
- les vérifications d'idiomes et anti-patterns
- etc, etc

Bref, c'est un sujet très très vaste.

[Invité]

Le nombre de bugs déclarés, ca va un peu dépendre du testeur, et parfois de ses relations avec le développeur si c'est l'indicateur de mesure de sa performance.

Le nombre de lignes, il faut aussi s'en méfier. Le même code, (avec le même nombre de bugs) sera généralement meilleur si écrit avec moins de lignes (plus évolutif, plus propre), mais il sera moins bon du point de vue de l'indicateur.... Dans une grosse société, cela mènerait les programmeurs a écrire du code très bavard.

Personnellement, j'aime bien le temps moyen passé pour diagnostiquer et fermer un bug (régressions possibles comprises). Cela demande une classification des bugs et un bon outil de suivi, mais cela permet de tester deux choses :

- la solidité du développement : un logiciel où le moindre changement pose des problèmes et entraine des tas de régressions, c'est un gros problème, même s'il n'a que très peu de bugs
- le sérieux des développeurs : je n'ai aucune difficulté avec les tête en l'air, qui laissent des petits bugs qu'ils savent vite corriger (c'est pour cela qu'on a des testeurs), j'ai du mal avec ceux qui ne maîtrisent pas ce qu'ils font (même quand ca marche)

L'intérêt de cette démarche est qu'on peut l'appliquer assez tôt dans le processus de développement (dès qu'on commence des tests unitaires, en fait).

Francois

[Jojo K-ri]

@souviron34
Bonjour
excuse-moi mais au lieu de balancer des chiffres comme ça qui n'ont aucun sens tu ferais mieux de te renseigner un petit peu et surtout de citer tes sources...

Ce genre de propos à l'emporte pièce sur le web est préjudiciable pour toute la communauté des développeurs car elle ancre des ordres de grandeur totalement fantaisistes dans la tête des décideurs et donc des exigences démesurées in fine.
Propos d'autant plus dangereux que tu te permets de les signer avec des titres impérieux "Programmation grosses applications critiques".

Pour avoir personnellement bosser sur des logiciels critiques et embarqués je peux te dire que l'on est tres tres loin du zero bug pour 1000 ou même 100 lignes de codes.
D'une part parce qu'il existe des anomalies "bloquantes" et "non-bloquantes" et d'autres part parce que ce qui est exigé au final n'est pas que le logiciel ne comporte aucune erreur (utopie contre-productive et dangereuse), mais que aucune erreur ne puisse engendrer de comportement critique.
En d'autres termes une erreur qui au final laisse le logiciel dans un état sécurisé n'est pas une erreur irrémissible.

Par exemple rien que dans le noyau de linux

The study identified 0.17 bugs per 1,000 lines of code in the Linux kernel. Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash, 100 were security holes, and 33 of the bugs could result in less-than-optimal system performance.

Et la moyenne pour un logiciel commercial est bien de 20 à 30 bugs pour 1000 lignes de code....

Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code.

http://www.wired.com/software/coolap.../2004/12/66022

[souviron34]

@souviron34
Bonjour

Ce genre de propos à l'emporte pièce sur le web est préjudiciable pour toute la communauté des développeurs car elle ancre des ordres de grandeur totalement fantaisistes dans la tête des décideurs et donc des exigences démesurées in fine.
Propos d'autant plus dangereux que tu te permets de les signer avec des titres impérieux "Programmation grosses applications critiques".

Pour avoir personnellement bosser sur des logiciels critiques et embarqués je peux te dire que l'on est tres tres loin du zero bug pour 1000 ou même 100 lignes de codes.

Nous ne devons pas alors avoir la même notion de "critique"..

En informatique, un système est dit "critique" quand il met la vie d'humains en jeu.. : guidage de train, systèmes pour avions, pour centrales nucléaires, pour aéroports, pour machines médicales, etc etc...

Je m'excuse, mais une version du Kernel de Linux n'est pas, dans ma compréhension, "criitque".. au sens où, si jamais elle était intégrée dans un système critique, elle serait tellement vérifiée, corrigée, tc, que ce ne srait pas la version dispo pour tout le monde, et que donc la version "tout le monde" n'est pas "critique"..

D'autre part, je signe "grosses applications critiques" car c'est ce sur quoi j'ai travaillé.. La plus petite faisait 700 000 lignes, les autres entre 2.5 et 6 millions de lignes, avec des vies en jeu (et/ou des centaines de millions de dollars)...

D'une part parce qu'il existe des anomalies "bloquantes" et "non-bloquantes" et d'autres part parce que ce qui est exigé au final n'est pas que le logiciel ne comporte aucune erreur (utopie contre-productive et dangereuse), mais que aucune erreur ne puisse engendrer de comportement critique.
En d'autres termes une erreur qui au final laisse le logiciel dans un état sécurisé n'est pas une erreur irrémissible.

Par exemple rien que dans le noyau de linux



Et la moyenne pour un logiciel commercial est bien de 20 à 30 bugs pour 1000 lignes de code....

http://www.wired.com/software/coolap.../2004/12/66022

Et ?

Que ce soit une constatation n'empêche pas que c'est une abomination, et qu'il faut, autant que faire se peut, trouver des moyens pour abaisser le plus possible ce nombre (et le contrôler) ce qui était la question du thread... (que tu fais quand même remonter de plus de 2 ans 1/2 !!!)

Il n'y a stictement rien de "préjudiciable pour toute la communauté des développeurs car elle ancre des ordres de grandeur totalement fantaisistes dans la tête des décideurs et donc des exigences démesurées in fine." dans mes propos, mes collègues ici-présents (dont pas mal de CP) m'auraient déjà fait la remarque...

D'après tes remarques, tu es un développeur, et tu n'apprécies pas qu'on te demande de monter le niveau de la qualité du code que tu produis...

Donc va jouer ailleurs stp...



PS: et, pour la satistique de "Wired", j'aimerais savoir : a) ce qu'ils appellent "bug", b) auprès de qui ils ont eu ces infos, et c) si ils sont toujours d'accord avec "100 lignes de code testés et documentés par personne et / mois", tel que c'était le cas il y a 20 ans... ou si ils ont quand même un peu augmenté (et suivi) les mesures et normes..


Enfin, c'est manifestement une pub pour "linux", et la statistique sur "les autres" est plus que peu argumentée...

Mais, même en prenant leurs chiffres, j'avoue être sceptique :

The study identified 0.17 bugs per 1,000 lines of code in the Linux kernel.

ce qui, si mes comptes sont bons, font 17 bug / 100 000..

ce qui est, de mon point de vue, déjà très élevé....

[Jojo K-ri]

Bonjour
ouioui je te parle bien d'informatique critique comme tu la définis et c'est bien dans les domaines que tu cites que j'ai travaillé.
Les ordres de grandeur que tu cites sont totalement fantaisistes je maintiens et on attends donc (toujours) tes sources....

Je ne vois pas d'ailleurs qui (ou quoi) sur cette planete est capable de certifier un zero bug dans 1 million ou 10 millions de lignes de code comme tu le prétends ça relève carrément du non-sens...