Como configurar uma pesquisa individual sobre a diferença entre o BDD e o Waterfall?

5

Anteriormente, fiz uma pergunta sobre como medir a qualidade de um projeto. O resultado dessa pergunta foi que a qualidade do projeto pode ser dividida em duas partes:

  • Qualidade interna (qualidade do código, mensurável pelas métricas de qualidade do código)
  • Qualidade externa (Teste de aceitação, como o software atende aos requisitos)

Portanto, com base nisso, quero criar algumas pesquisas e validar o resultado do projeto. O problema é que eu conduzirei essa pesquisa sozinho, então não é possível executar o projeto uma vez no estilo BDD e o outro em cascata sozinho. Também não é possível comparar projetos de BDD e cascata em uma escala maior, devido ao fato de que não há projetos de BDD suficientes que possam ser medidos por causa da idade do BDD.

Então, minha pergunta é: alguém enfrentou esse problema? Como eu poderia executar o meu experimento de tal forma que é de valor científico?

    
por Martijn van der Maas 12.03.2012 / 00:14
fonte

6 respostas

4

É impossível gerar conjuntos de dados suficientemente grandes em um laboratório de pesquisa, quanto mais sozinho, para validar os processos de desenvolvimento. Suas opções são:

  1. Parceria com o setor. Para começar, você precisará treiná-los no BDD no início do projeto e eles devem estar dispostos a adotá-lo - uma tarefa difícil! Você também precisará de alguns anos para realizar seus experimentos em vários projetos e possíveis em várias empresas, possivelmente abrangendo diferentes indústrias! Para os projetos de controle do Waterfall, você pode confiar apenas nos dados existentes.

  2. Usando projetos de alunos. Esta opção é prática, mas não é tão confiável quanto a escala de projetos tem que ser pequena. Ei, você tem que fazer o que tem que fazer! Talvez se você tiver acesso a alunos de pós-graduação - pode ser melhor.

Se você precisar continuar, a opção 2 parece ser a única opção prática. No entanto, você pode querer reconsiderar seu tópico de pesquisa!

Boa sorte!

    
por 22.04.2012 / 01:00
fonte
2

Você definiu uma tarefa muito difícil para você!

Cada projeto de software é basicamente único, um conjunto diferente de pessoas que implementam um conjunto diferente de requisitos para um cliente diferente em um ambiente diferente.

Além disso, as organizações comerciais não tornarão públicos quaisquer dados internos sobre os custos, esforços ou até mesmo sucesso ou fracasso do projeto. Na verdade, quase todos os projetos para empresas são bem-sucedidos porque o "sucesso" é redefinido como o que foi entregue.

As organizações governamentais, por outro lado, devem operar em público e os números sobre custos, recursos e sucesso / fracasso são publicados. Pelo menos no início dos projetos eles tendem a ser bastante abertos sobre o que estão fazendo e como, então entre press releases, relatórios de auditoria e contas publicadas (e solicitações de Liberdade de Informação em um último recurso) você deve ser capaz de construir um bom corpo de dados para analisar.

A advertência é que os projetos do governo (pelo menos aqueles pelos quais meus impostos pagam) têm um longo e sórdido histórico de falhas e geralmente seguem estilos de gerenciamento de projetos únicos e unicamente incoerentes.

    
por 04.04.2012 / 08:22
fonte
1

Waterfall é um ALM , BDD-1 / O BDD-2 é um método para testes de aceitação contínua. TDD é um método para testes unitários em andamento.

Os dois cobrem diferentes aspectos e são não mutuamente exclusivos.

Por exemplo Você poderia qualquer um desses ALMs {Waterfall, UP, SCRUM} com ou sem BDD.

    
por 08.05.2012 / 17:27
fonte
0

O valor real do BDD está em descobrir as situações complicadas em que os cenários não são óbvios - os desconhecidos desconhecidos de um projeto.

Como todo projeto envolve fazer algo novo (do contrário, você poderia simplesmente comprá-lo na prateleira ou usar código aberto), geralmente há algumas dessas descobertas. Eles são o que mais demoram nos projetos. ("Se um projeto não tem riscos, não faça isso" - Waltzing with Bears).

Portanto, eu me desespero em comparar um projeto a outro, especialmente se você usa o BDD para ajudá-lo a fazer essas descobertas, porque elas serão radicalmente diferentes para cada projeto - e se você tentar refazer um projeto, terá encontrei todas as descobertas já e ser tendenciosa de acordo. (Essas descobertas são por que a Waterfall não funciona tão bem, a propósito.)

Em vez disso, gostaria de perguntar às principais partes interessadas como elas estavam felizes com a qualidade interna e externa do software que receberam de vários projetos do BDD e do Waterfall em uma escala de 1 a 10 e comparar os resultados. Isso é o mais objetivo possível, e deve funcionar em vários projetos.

    
por 08.05.2012 / 15:01
fonte
0

Eu estou indo apenas para o que eu li aqui . Por que você não compara o BDD ao TDD? Pegue um grupo de majores do primeiro ano do CS e compare sua capacidade de usar o teste de unidade com e sem o BDD. Eles desenvolvem uma melhor compreensão do processo?

Há mérito em tentar obter alguns dados sobre métodos ágeis para cascatas, mas isso está além da tese de pós-graduação IMHO.

    
por 08.05.2012 / 15:40
fonte
0

Acho que a segunda opção da rrufai pode ser a melhor opção a seguir. No entanto, eu mudaria um pouco.

Encontre aulas de programação de nível médio a sênior e divida os alunos em dois grupos - cascata e BDD. Dependendo do tamanho da turma, você pode facilmente ter várias equipes para cada abordagem.

Em seguida, enfrente desafios específicos do projeto CodeJam do Google. Atribua as equipes para que você tenha pelo menos uma equipe em cascata e uma equipe do BDD por desafio. Adicione requisitos adicionais, como documentação, indicadores de progresso, rastreamento / registro, etc ... para aumentar o número de recursos que devem ser projetados e incorporados ao projeto.

O benefício de usar os Atolamentos é que você possui uma validação interna para o código deles. Você terá que determinar os critérios de avaliação para os requisitos adicionais.

O ideal é que você faça com que cada equipe aborde alguns dos desafios em seu estilo designado. Então você pode mudar as metodologias de design e fazer com que elas resolvam mais alguns desafios.

    
por 08.05.2012 / 17:12
fonte