Quelle quantité de temps faut-il consacrer aux bogues par rapport au développement original? [fermé]

Cette question est un peu abstraite mais j'espère que quelqu'un pourra m'orienter dans la bonne direction.

Ma question est de savoir combien de temps peut-on s'attendre à consacrer aux bogues d'un projet logiciel par rapport au temps de développement d'origine. Je me rends compte qu'il existe un grand nombre de facteurs déterminants, mais j'espérais une ventilation typique ou moyenne.

Par exemple, si le projet A prend 40 heures pour terminer et 10 autres bogues de correction, alors ce projet aurait un rapport de 4: 1.

Si un autre projet (B) prend 10 heures pour terminer, mais encore 8 sur les bogues, il aurait un rapport de 5: 4.

Est-ce un concept documenté / recherché?

MISE À JOUR

Merci pour toutes les réponses informatives. Je comprends qu'il est impossible de mettre une norme à ce type de métrique en raison de toutes les variables et facteurs environnementaux impliqués. Avant d'attribuer une réponse, j'aimerais savoir si cette métrique a un nom convenu afin que je puisse faire d'autres recherches. Je voudrais arriver à un point où je peux comprendre les mesures nécessaires pour générer les métriques moi-même et éventuellement trouver une norme de base pour mon projet.

Le pourcentage d'équilibre de la capacité totale allouée à la correction des défauts est égal au taux d'injection des défauts .

De nombreux facteurs peuvent affecter ce taux, parmi eux, bien sûr: quel type de produit l'équipe développe, quelles technologies et pratiques techniques ils utilisent, le niveau de compétence de l'équipe, la culture de l'entreprise, etc.

En considérant l'équipe B, s'ils créent en moyenne 8 unités de reprise pour 10 unités de travail terminées, le fait de travailler ces 8 unités créera 6,4 nouvelles unités de reprise. On peut estimer l'effort total qu'ils devront éventuellement consacrer comme la somme d'une progression géométrique:

10 + 8 + 6,4 + 5,12 + ...

Le nombre de bogues diminuera de façon exponentielle avec le temps, mais l'équipe B a un coefficient si élevé dans son exposant qu'il ira à zéro très lentement. En fait, la somme des trois premiers termes de la série ci-dessus n'est que de 24,4; des cinq premiers, 33,6; des 10, 45 premiers; de toute la série, 50. Donc, résumé de l'équipe B: taux d'injection de défauts, 0,8; développement de fonctionnalités, 10/50 = 20%; correction de défauts, 80%. 20/80 est leur allocation de capacité durable.

En revanche, l'équipe A est en bien meilleure forme. Leur progression ressemble à ceci:

40 + 10 + 2,5 + 0,625 + ...

La somme de cette série est de 53 1/3, donc l'allocation de développement de fonctionnalités de l'équipe A est de 40 / (53 1/3) = 75% et l'allocation de correction de défauts est de 25%, ce qui correspond à leur taux d'injection de défauts de 10/40 = 0,25 .

En fait, tous les termes de la série de l'équipe A après les trois premiers sont négligeables. Concrètement, cela signifie que l'équipe A peut probablement éliminer tous ses bogues avec quelques versions de maintenance, la deuxième version étant assez petite. Cela crée également l'illusion que n'importe quelle équipe peut le faire. Mais pas l'équipe B.

J'ai pensé à cette équivalence en lisant le nouveau livre de David Anderson, "Kanban" . (Le livre porte sur un sujet différent, mais aborde également les problèmes de qualité.) En discutant de la qualité des logiciels, Anderson cite ce livre, par Capers Jones, "Software Assessments, Benchmarks, and Best Practices" :

"... en 2000 ... la qualité logicielle mesurée pour les équipes nord-américaines ... variait de 6 défauts par point de fonction à moins de 3 pour 100 points de fonction, une plage de 200 à 1. Le point médian est d'environ 1 défaut par 0,6 à 1,0 points de fonction. Cela implique qu'il est courant pour les équipes de consacrer plus de 90% de leur effort à réparer les défauts. "Il cite un exemple fourni par l'un de ses collègues d'une entreprise qui passe 90% du temps à corriger ses bugs. .

La fluidité avec laquelle Anderson passe du taux d'injection de défauts à l'allocation de capacité de fixation de défaut (la demande de défaillance en est le terme) suggère que l'équivalence des deux choses est bien connue des chercheurs en qualité logicielle et est probablement connue depuis un certain temps. .

Les mots clés du raisonnement que j'essaie de présenter ici sont "équilibre" et "durable". Si nous supprimons la durabilité, il existe un moyen évident de tromper ces chiffres: vous effectuez le codage initial, puis passez au codage ailleurs et laissez la maintenance à d'autres. Ou vous accumulez la dette technique et la déchargez sur un nouveau propriétaire.

Évidemment, aucune allocation particulière ne conviendra à toutes les équipes. Si nous décrétons que 20% doivent être dépensés pour les bogues, alors, si une équipe a un taux d'injection de défauts ultra bas, elle n'aura tout simplement pas assez de bogues pour combler le temps, et si une équipe avait un taux très élevé, leurs bogues continuera à s'accumuler.

Le calcul que j'ai utilisé ici est bien simplifié. J'ai négligé des choses comme les coûts de transaction (réunions de planification et d'estimation, autopsies, etc.), ce qui affecterait quelque peu les pourcentages. J'ai également omis des équations simulant le maintien d'un produit et le développement d'un autre en même temps. Mais la conclusion est toujours valable. Faites ce que vous pouvez, en termes de pratiques techniques, comme les tests unitaires, l'intégration continue, les révisions de code, etc., pour réduire votre taux d'injection de défauts et, par conséquent, votre demande de défaillance. Si vous ne pouvez créer qu'un seul bug pour 10 fonctionnalités, vous aurez beaucoup de temps libre pour développer de nouvelles fonctionnalités et satisfaire vos clients.

Malheureusement, je pense que ce ratio est très variable dans un projet donné. Il sera considérablement affecté par votre environnement, votre langue, vos outils, la taille de votre équipe et votre expérience.

Vous ne devriez passer du temps sur un bug que si ce que vous gagnez avec le correctif est supérieur à ce que vous investissez.

Utilisez une matrice comme celle-ci (horizontale - temps requis pour corriger le bug, verticale - type de bug - impact sur les utilisateurs)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Exemple de problèmes:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

La matrice peut être plus complexe avec différents niveaux de gravité, d'effort, de risques, etc.

Vous pouvez même créer un classement pour chaque bug et les corriger en fonction du classement. Quelque chose comme:

Bug priority = Risk x Severity x Effort

* Peut être (1-x) pour certains opérandes, selon l'échelle que vous choisissez :)

Donc, pour répondre à votre question: dépend du type de bugs, du temps / budget disponible, etc.

C'est très variable, non seulement (bien sûr) sur l'expérience et la qualité de l'équipe, et sur la difficulté du projet (ce n'est pas la même chose de faire une autre application web standard qu'un nouveau noyau OS), mais aussi sur l'approche de gestion que vous vais utiliser.

Par exemple, sur un modèle en cascade, vous pouvez définir précisément le premier bogue lors de la première phase de test, mais dans un environnement agile, il peut être difficile de soulever une ligne disant "à partir de maintenant, nous corrigeons les bogues", car les fonctionnalités peuvent changer ( et pour moi ce n'est pas juste de compter un changement de fonctionnalité comme un bug)

Par expérience, je dis que c'est quelque chose qui est TOUJOURS sous-estimé et qui peut très facilement passer le même nombre d'heures que le "projet original".

La réponse vraiment correcte serait zéro heure sur les corrections de bugs car votre code est parfait. :-)

En réalité, je ne peux pas dire que j'ai jamais entendu quelqu'un demander ou offrir ce type de rapport. Cela ne veut pas dire que certaines entreprises ne suivent pas le temps de développement et de maintenance. Mais le développement d'une application est si court par rapport à la maintenance que la plupart des entreprises ne reviennent pas et ne calculent pas ce ratio. Ils sont probablement plus soucieux d'apprendre pourquoi une application nécessite une maintenance et d'appliquer ces résultats à de nouvelles applications.

Avoir un critère trop large pour ce qu'est un bug peut presque doubler votre temps. Un gestionnaire trop zélé qui pense que la demande d'un client pour agrandir un bouton (ils ont des problèmes de souris) est un excellent moyen d'augmenter le nombre de bugs que nous avons corrigés. La correction ne prendra que quelques secondes car il n'est pas nécessaire d'envisager, de tester, de recompiler et de distribuer un patch. Oh, et cela est compté comme une nouvelle fonctionnalité.

Le facteur déterminant le plus important est de savoir si vous travaillez avec une nouvelle technologie ou une technologie existante. Si vous travaillez avec quelque chose de nouveau et développez quelque chose qui n'a pas été fait ou a été fait plusieurs fois dans des circonstances différentes, vous allez passer beaucoup de temps à corriger les bogues et à faire fonctionner votre projet comme vous le souhaitez. . Souvent, les bugs seront le résultat de votre travail dans un coin, et vous devrez effectuer des travaux importants pour restructurer ce que vous avez fait. De plus, de nombreux bogues résulteront d'une compréhension incomplète des attentes des utilisateurs et de la méconnaissance des cas marginaux par le développeur.

Si vous travaillez sur une technologie établie, la plupart des problèmes auront été traités par les bibliothèques ou par les pratiques de la communauté, et vous devriez être en mesure de rechercher, d'acheter ou de demander à Google de sortir des bogues que vous rencontrez.

Sur les logiciels critiques, un rapport A 1: 1 n'est pas inhabituel. Pour les tests unitaires seuls, j'ai vu des indicateurs mentionner 1 jour de tests unitaires pour 10 lignes de code.

Je pense que cette question est biaisée: elle part du présupposé que la correction des bugs est une phase similaire à celle du développement de nouvelles fonctionnalités . Ce n'est pas le cas.

Un bon développeur ne passera pas beaucoup de temps à déboguer du code car son code sera exempt de bogues dès le départ. Un mauvais développeur passera beaucoup de temps à déboguer son code car il ne peut pas créer d'abstractions appropriées pour résoudre de vrais problèmes.

Notez que les développeurs doivent tester eux-mêmes leur propre code. Il leur incombe de fournir un code sans bogue. Il est donc difficile de séparer le codage du débogage.

C'est aussi une question de priorité. Lors du développement, le temps nécessaire pour corriger un bogue est lié de façon exponentielle au temps écoulé depuis le moment où vous avez inséré le bogue dans le code. La correction des bogues devrait donc être plus prioritaire que le développement de nouvelles fonctionnalités.

Donc au lieu de parler de "temps passé sur les bugs", vous devriez parler de "temps passé sur les tests" (tests d'intégration, tests d'acceptation des utilisateurs ...)

Je pense que vous avez raison - vous n'obtiendrez aucune métrique significative en raison du nombre considérable de facteurs d'influence.

Si cela peut vous aider, je peux vous dire que les projets sur lesquels je travaille (espace d'entreprise, grands systèmes complexes, beaucoup d'intégration à d'autres systèmes) ont un rapport d'environ 3: 2. La plupart d'entre eux ne sont pas des défauts avec le code - plus généralement des défauts avec les interfaces. Par exemple, les systèmes A et B se parlent via l'interface X. Les développeurs du système A interprètent l'interface X légèrement différemment des développeurs du système B. La comédie s'ensuit.

Une observation à faire est que le développement de code et la correction de test / bogue de code ne devraient pas être deux phases distinctes. Si vous testez au fur et à mesure que vous développez, le «coût» de la correction des bogues est moindre.

Je prends un point de vue purement pratique: qu'est-ce qui entrave le plus l'utilité pratique du projet? S'il s'agit de bogues dans les fonctionnalités existantes, vous devez corriger les bogues. S'il manque des fonctionnalités, vous devez faire le développement d'origine, puis revenir en arrière et corriger les bugs une fois que les fonctionnalités manquantes les plus graves sont implémentées. Cela nécessite une connaissance de vos cas d'utilisation. Un bogue qui bloque le programme dans un cas étrange peut être une priorité inférieure aux améliorations mineures d'utilisation qui affectent tout le monde. Un petit bogue nuisible dans la fonctionnalité la plus couramment utilisée peut être plus important qu'une fonctionnalité qui ne profite qu'aux personnes qui poussent votre logiciel à l'extrême.