Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Candidat au Club
    Inscrit en
    novembre 2009
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 5
    Points : 2
    Points
    2

    Par défaut mesure du niveau de qualite d'un dev

    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

  2. #2
    Membre régulier
    Inscrit en
    novembre 2008
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 76
    Points : 84
    Points
    84

    Par défaut

    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.
    Des gens comme vous vous parlent de leurs journées. Leurs problèmes, leurs solutions sont ils les mêmes que les vôtre ?

  3. #3
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 592
    Détails du profil
    Informations personnelles :
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 592
    Points : 17 247
    Points
    17 247
    Billets dans le blog
    2

    Par défaut

    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..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  4. #4
    Membre régulier
    Inscrit en
    novembre 2008
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : novembre 2008
    Messages : 76
    Points : 84
    Points
    84

    Par défaut

    Il y a peut être quelque chose à chercher du côté de Lean
    Des gens comme vous vous parlent de leurs journées. Leurs problèmes, leurs solutions sont ils les mêmes que les vôtre ?

  5. #5
    Candidat au Club
    Inscrit en
    novembre 2009
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 5
    Points : 2
    Points
    2

    Par défaut

    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

  6. #6
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 592
    Détails du profil
    Informations personnelles :
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 592
    Points : 17 247
    Points
    17 247
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Sophis123 Voir le message
    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...



    Citation Envoyé par Sophis123 Voir le message
    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) ??
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  7. #7
    Candidat au Club
    Inscrit en
    novembre 2009
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 5
    Points : 2
    Points
    2

    Par défaut

    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

  8. #8
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 592
    Détails du profil
    Informations personnelles :
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 592
    Points : 17 247
    Points
    17 247
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Sophis123 Voir le message
    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).
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  9. #9
    Rédacteur

    Homme Profil pro
    Geek entrepreneur
    Inscrit en
    novembre 2004
    Messages
    1 224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Geek entrepreneur

    Informations forums :
    Inscription : novembre 2004
    Messages : 1 224
    Points : 2 379
    Points
    2 379

    Par défaut

    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.

  10. #10
    Candidat au Club
    Inscrit en
    novembre 2009
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 5
    Points : 2
    Points
    2

    Par défaut

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

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

  11. #11
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 592
    Détails du profil
    Informations personnelles :
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 592
    Points : 17 247
    Points
    17 247
    Billets dans le blog
    2

    Par défaut

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

    Que cherches-tu exactement ??
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  12. #12
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 047
    Points : 1 620
    Points
    1 620

    Par défaut

    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.
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  13. #13
    Invité
    Invité(e)

    Par défaut

    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
    Dernière modification par Invité ; 28/11/2009 à 11h02.

  14. #14
    Membre régulier
    Profil pro
    Inscrit en
    novembre 2006
    Messages
    68
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 68
    Points : 116
    Points
    116

    Par défaut

    @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

  15. #15
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 592
    Détails du profil
    Informations personnelles :
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 592
    Points : 17 247
    Points
    17 247
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Jojo K-ri Voir le message
    @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)...


    Citation Envoyé par Jojo K-ri Voir le message
    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é....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  16. #16
    Membre régulier
    Profil pro
    Inscrit en
    novembre 2006
    Messages
    68
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 68
    Points : 116
    Points
    116

    Par défaut

    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...

Discussions similaires

  1. Réponses: 5
    Dernier message: 01/04/2014, 10h01
  2. Réponses: 0
    Dernier message: 21/10/2013, 15h36
  3. Traitement d'image : mesure de niveau (liquide)
    Par zicos dans le forum Traitement d'images
    Réponses: 11
    Dernier message: 18/11/2008, 21h04
  4. Mesurer les effets de la qualité de code
    Par Mischka dans le forum NetBeans
    Réponses: 6
    Dernier message: 08/04/2008, 17h28
  5. Mesure de qualité d'un code Cobol
    Par vezz dans le forum Cobol
    Réponses: 2
    Dernier message: 05/08/2007, 15h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo