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

É 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!

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.

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.

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

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.

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.

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.