Qual é a diferença entre um bug e uma solicitação de alteração no MSF for CMMI?

votos
6

Atualmente estou avaliando o MSF for CMMImodelo de processo sob TFS para uso em minha equipe de desenvolvimento, e eu estou tendo dificuldade para entender a necessidade de bug separado e solicitação de mudança tipos de item de trabalho.

Eu entendo que é benéfico para ser capaz de diferenciar entre bugs (erros) e solicitações de mudança (mudanças de requisitos) ao gerar relatórios.

Em nosso sistema atual, no entanto, só temos um único tipo de solicitação de mudança e usar apenas um campo para indicar se se trata de um erro, mudança exigência, etc (este campo pode ser usado para construir consultas de relatório).

Quais são os benefícios de ter um fluxo de trabalho separado para bugs?

Eu também estou confuso com o fato de que os desenvolvedores podem submeter trabalhos contra um bug ou uma solicitação de mudança, eu pensei que o fluxo de trabalho pretendido era de bugs para gerar solicitações de mudança que são o que as referências de desenvolvedor ao fazer alterações.

Publicado 07/08/2008 em 22:17
fonte usuário
Em outras línguas...                            


5 respostas

votos
12

@Luke

Eu não discordo com você, mas esta diferença é normalmente a explicação dada para porque é que há dois processos diferentes disponíveis para lidar com os dois tipos de problemas.

Eu diria que, se a cor da home page foi originalmente concebido para ser vermelho, e por alguma razão ele é azul, que é facilmente uma solução rápida e não precisa de envolver muitas pessoas ou horas-homem para fazer a mudança. Basta verificar o arquivo, mudar a cor, verificá-lo de volta e atualizar o bug.

No entanto, se a cor da página inicial foi projetado para ser vermelho, e é vermelho, mas alguém pensa que ele precisa ser azul, isto é, para mim de qualquer maneira, um tipo diferente de mudança. Por exemplo, se alguém pensou sobre o impacto que isso pode ter sobre outras partes da página, como imagens e logotipos que cobrem o fundo azul? Poderia haver fronteiras de coisas que parece ruim? Fazer a ligação sublinhado é azul, isso vai aparecer?

Como exemplo, eu sou vermelho daltônico / verde, mudando a cor de alguma coisa é, para mim, algo que eu não tomar de ânimo leve. Há páginas suficientes na web que me dá problemas. Só para fazer um ponto que até mesmo a alteração mais trivial pode ser trivial se você considerar tudo.

A mudança real implementação final é provavelmente muito mais do mesmo, mas para mim um pedido de mudança é uma besta diferente, precisamente porque ele precisa ser pensado mais para ter certeza de que vai funcionar como esperado.

Um erro, porém, é que alguém disse isto é como nós vamos fazê-lo e, em seguida, alguém fez isso de forma diferente.

A solicitação de mudança é mais como , mas temos de considerar essa outra coisa bem ... hmm ... .

Há exceções, é claro, mas deixe-me tomar seus exemplos separados.

Se o servidor foi projetado para lidar com mais de 300,000,000,000 pageviews, então sim, é um bug que isso não acontece. Mas a concepção de um servidor para lidar com que muitos pageviews é mais do que simplesmente dizer o nosso servidor deve lidar com 300,000,000,000 pageviews , deve conter uma muito especificação detalhada de como ele pode fazer isso, até garantias de tempo de processamento e de acesso ao disco tempos médios. Se o código é então implementado exatamente como projetado, e incapaz de funcionar como esperado, então a pergunta é: que nós projetá-lo de forma incorreta ou nós implementá-lo de forma incorrecta? .

Concordo que, neste caso, o tempo deve ser considerada uma falha de projeto ou uma falha de implementação depende da verdadeira razão por que ele não consegue viver de acordo com as expectativas. Por exemplo, se alguém assumiu discos foram 100x vezes mais rápido que eles realmente são, e isso é considerado a razão por que o servidor não funcionar como esperado, eu diria que este é um bug design, e alguém precisa redesenhar . Se o requisito original do que muitos pageviews ainda está a ser realizada, uma grande reformulação com mais dados na memória e similares pode ter que ser realizada.

No entanto, se alguém acabou de não ter tido em conta a forma como discos RAID operar e como se beneficiar corretamente a partir da mídia listrado, isso é um erro e pode não precisar tão grande de uma mudança de corrigir.

Novamente, não será, naturalmente, exceções.

Em qualquer caso, a diferença original eu disse é o que eu encontrei para ser verdade na maioria dos casos.

Respondeu 07/08/2008 em 23:17
fonte usuário

votos
4

Tenha em mente que uma parte de uma definição de tipo de item de trabalho para TFS é a definição do que é "Fluxo de trabalho", que significa os estados do item de trabalho pode ser e as transições entre os estados. Isto pode ser assegurado por função de segurança.

Então - em geral - a "Solicitação de Mudança" seria iniciado e aprovado por alguém relativamente alto de uma organização (alguém com direitos "patrocínio" relacionados com a gastar os recursos para fazer uma (possivelmente muito grande mudança) para o sistema última análise, isso. pessoa seria o único a aprovar que a alteração foi feita com sucesso.

Para um "Bug" No entanto, qualquer usuário do aplicativo deve ser capaz de iniciar um Bug.

Em uma organização que implementou TFS em apenas chefes de departamento podem ser os criadores de uma "Solicitação de Mudança" - mas "Bugs" foram criados a partir de "Help Desk" bilhetes (não automatizado, apenas através do processo ...)

Respondeu 07/09/2008 em 14:36
fonte usuário

votos
3

Geralmente, embora eu não posso falar por CMM, solicitações de mudança e os erros são tratados e considerados de forma diferente porque eles normalmente se referem a diferentes partes do seu ciclo de vida da aplicação.

Um bug é um defeito na sua implementação do programa. Por exemplo, se você projetar seu programa para ser capaz de adicionar dois números e dar ao usuário a soma, um defeito seria a de que ele não controla números negativos corretamente, e, portanto, um erro.

A solicitação de mudança é quando você tem um defeito design. Por exemplo, você poderia ter dito especificamente que o seu programa não deve lidar com números negativos. A solicitação de mudança é então arquivado, a fim de redesenhar e, assim, reimplementar essa parte. O defeito de design pode não ser intencional, mas poderia facilmente ser porque você simplesmente não considerou que parte quando você originalmente concebido seu programa, ou novos casos que não existia no momento em que o projeto original foi criado foram inventados ou descobertos Desde a.

Em outras palavras, um programa pode funcionar exatamente como projetado, mas precisam de ser alterados. Esta é uma solicitação de mudança.


Normalmente, a fixação de um bug é considerado uma ação muito mais barato do que a execução de uma solicitação de mudança, como o bug nunca foi destinado a ser parte de seu programa. O projeto, no entanto, foi.

E, assim, um fluxo de trabalho diferente pode ser necessária para lidar com os dois cenários diferentes. Por exemplo, você pode ter uma forma diferente de confirmar e arquivamento erros do que você tem para solicitações de mudança, o que pode exigir mais trabalho de colocar para fora as conseqüências da mudança.

Respondeu 07/08/2008 em 22:54
fonte usuário

votos
2

Um bug é algo que está quebrado em uma exigência que já foi aprovado para implementação.

A solicitação de mudança precisa passar por um ciclo no qual o impacto e esforço tem que ser estimado para essa mudança, e então ele tem que ser aprovado para implementação antes do trabalho sobre ele pode começar.

Os dois são fundamentalmente diferentes sob CMM.

Respondeu 07/08/2008 em 22:21
fonte usuário

votos
1

É minha suposição incorreta depois que as solicitações de mudança deve ser gerada a partir de bugs? Estou confuso porque eu não acho que todos os erros devem ser automaticamente aprovado para implementação - que pode ser trivial e, pelo menos no nosso caso vai passar pelo mesmo processo de revisão como um pedido de alteração antes de ser atribuído a um desenvolvedor.

Respondeu 07/08/2008 em 22:26
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more