Un bogue est quelque chose qui est cassé dans une exigence dont la mise en œuvre a déjà été approuvée.

Une demande de changement doit passer par un cycle dans lequel l'impact et l'effort doivent être estimés pour ce changement, puis il doit être approuvé pour la mise en œuvre avant que le travail puisse commencer.

Les deux sont fondamentalement différents sous CMM.

Mon hypothèse est-elle alors incorrecte selon laquelle les demandes de modification doivent être générées à partir de bogues ? Je suis confus parce que je ne pense pas que tous les bogues devraient être automatiquement approuvés pour la mise en œuvre - ils peuvent être triviaux et au moins dans notre cas passeront par le même processus d'examen qu'une demande de modification avant d'être attribués à un développeur.

Généralement, bien que je ne puisse pas parler au nom de CMM, les demandes de modification et les bogues sont traités et pris en compte différemment car ils font généralement référence à différentes parties du cycle de vie de votre application.

Un bogue est un défaut dans l'implémentation de votre programme. Par exemple, si vous concevez votre programme pour pouvoir additionner deux nombres et donner la somme à l'utilisateur, un défaut serait qu'il ne gère pas correctement les nombres négatifs, et donc un bogue.

Une demande de modification correspond à un défaut de conception. Par exemple, vous avez peut-être spécifiquement dit que votre programme ne devrait pas gérer les nombres négatifs. Une demande de modification est alors déposée afin de reconcevoir et donc de réimplémenter cette partie. Le défaut de conception n'est peut-être pas intentionnel, mais peut facilement être dû au fait que vous n'avez tout simplement pas pris en compte cette partie lors de la conception initiale de votre programme, ou que de nouveaux cas qui n'existaient pas au moment de la création de la conception originale ont été inventés ou découverts. depuis.

En d'autres termes, un programme peut fonctionner exactement comme prévu, mais doit être modifié. Ceci est une demande de modification.

@Luc

Je ne suis pas en désaccord avec vous, mais cette différence est généralement l'explication donnée pour expliquer pourquoi il existe deux processus différents disponibles pour traiter les deux types de problèmes.

Je dirais que si la couleur de la page d'accueil a été conçue à l'origine pour être rouge, et pour une raison quelconque, elle est bleue, c'est facilement une solution rapide et n'a pas besoin d'impliquer beaucoup de personnes ou d'heures de travail pour le faire le changement. Vérifiez simplement le fichier, changez la couleur, réarchivez-le et mettez à jour le bogue.

Cependant, si la couleur de la page d'accueil a été conçue pour être rouge, et qu'elle est rouge, mais que quelqu'un pense qu'elle doit être bleue, c'est, pour moi en tout cas, un autre type de changement. Par exemple, quelqu'un a-t-il pensé à l'impact que cela pourrait avoir sur d'autres parties de la page, comme les images et les logos superposés sur le fond bleu ? Pourrait-il y avoir des frontières de choses qui semblent mauvaises ? Le soulignement des liens est bleu, cela s'affichera-t-il ?

Par exemple, je suis daltonien rouge/vert. Pour moi, changer la couleur de quelque chose n'est pas quelque chose que je prends à la légère. Il y a suffisamment de pages Web sur le Web qui me posent des problèmes. Juste pour souligner que même le changement le plus insignifiant peut être non négligeable si vous considérez tout.

Le changement de mise en œuvre final réel est probablement sensiblement le même, mais pour moi, une demande de changement est une bête différente, précisément parce qu'elle doit être réfléchie davantage pour s'assurer qu'elle fonctionnera comme prévu .

Un bug, cependant, est que quelqu'un a dit Voici comment nous allons procéder, puis quelqu'un l'a fait différemment.

Une demande de changement ressemble plus à mais nous devons également tenir compte de cette autre chose... hmm....

Il y a bien sûr des exceptions, mais laissez-moi démonter vos exemples.

Si le serveur a été conçu pour gérer plus de 300 000 000 000 pages vues, alors oui, c'est un bogue qu'il ne fait pas. Mais concevoir un serveur pour gérer autant de pages vues, c'est plus que dire notre serveur doit gérer 300 000 000 000 pages vues, il doit contenir une spécification très détaillée sur la façon dont il peut le faire, n'est-ce pas jusqu'aux garanties de temps de traitement et aux temps moyens d'accès au disque. Si le code est ensuite implémenté exactement comme prévu et incapable de fonctionner comme prévu, alors la question devient : l'avons-nous mal conçu ou l'avons-nous mal implémenté ?.

Je conviens que dans ce cas, qu'il s'agisse d'un défaut de conception ou d'un défaut de mise en œuvre dépend de la raison réelle pour laquelle il ne répond pas aux attentes. Par exemple, si quelqu'un supposait que les disques étaient 100 fois plus rapides qu'ils ne le sont réellement, et que cela est considéré comme la raison pour laquelle le serveur ne fonctionne pas comme prévu, je dirais qu'il s'agit d'un bogue de conception et que quelqu'un doit reconcevoir . Si l'exigence initiale d'autant de pages vues doit toujours être respectée, une refonte majeure avec plus de données en mémoire et similaires devra peut-être être entreprise.

Cependant, si quelqu'un vient de ne pas tenir compte du fonctionnement des disques raids et de la façon de tirer correctement parti des médias entrelacés, il s'agit d'un bogue et il se peut qu'il n'y ait pas besoin d'un changement aussi important pour le corriger.

Encore une fois, il y aura bien sûr des exceptions.

Dans tous les cas, la différence initiale que j'ai indiquée est celle que j'ai trouvée vraie dans la plupart des cas.