Quais metodologias de desenvolvimento de software podem ser vistas como fundações

Estou escrevendo um pequeno trabalho de pesquisa que envolve metodologias de desenvolvimento de software. Eu estava analisando todas as metodologias disponíveis e me perguntei, de todas as metodologias, há alguma que tenha fornecido as bases para as outras?

Por exemplo, analisando as seguintes metodologias:
Ágil, Prototipagem, Sala Limpa, Iterativa, RAD, RUP, Espiral, Cachoeira, XP, Lean, Scrum, Modelo V, TDD.

Podemos dizer que:
Prototipagem, Iterativa, Espiral e Cachoeira são a "base" para os outros?

Ou não existem fundamentos e cada metodologia tem sua própria história?

É claro que gostaria de descrever todas as metodologias em meu trabalho de pesquisa, mas simplesmente não tenho tempo para fazê-lo e é por isso que gostaria de saber quais metodologias podem ser vistas como representantes.

Os nomes na sua lista não são todas metodologias e são dimensionados em diferentes níveis:

• Iterativa é uma característica, uma característica compartilhada por vários métodos e técnicas. Scrum é uma metodologia iterativa, TDD é uma técnica iterativa.
• Eu vejo o Agile como um superconjunto de metodologia que permanece em um nível conceitual / filosófico. Na programação orientada a objetos, você pode descrevê-la como abstrata - é um conjunto de valores e princípios que não podem ser instanciados e precisam ser derivados e implementados. Isso é o que Scrum e XP fazem.
• Salas limpas, RAD, RUP, Espiral, Cachoeira, XP, Lean, Scrum, V-Model são metodologias apropriadas, ou seja, processos de desenvolvimento de software (embora o Scrum afirme ser uma "estrutura" leve em oposição a um processo pesado)
• Prototipagem e TDD são técnicas, atividades. TDD é uma prática XP.

Distinguir qual é a base da qual é um trabalho difícil. Você pode traçar uma linha histórica, obviamente, mas uma metodologia raramente se baseia diretamente em outra. Eles se sobrepõem, tomam emprestado um do outro, às vezes respondem um ao outro ... Não vejo uma classificação claramente definida, embora você provavelmente possa delinear algumas famílias grandes.

Outra maneira de ver isso é da perspectiva de uma geração. Em termos de software corporativo, eu diria que conhecemos duas gerações de metodologias. Os primeiros, entre os quais o Waterfall e o V-Model, eram principalmente processos preexistentes de outras disciplinas de engenharia aplicadas ao software. A segunda geração (você pode chamá-lo de Agile, mas começou muito antes do termo Agile ser cunhado) foi iniciada em reação ao peso dos processos de primeira geração, quando as pessoas começaram a perceber que o software era um animal totalmente diferente e que os critérios que fazem bem software e as etapas que podem garantir esses critérios eram realmente específicos e ainda precisavam ser explorados.

Finalmente, você deve observar que, no software talvez até mais do que em outras disciplinas, as metodologias não são receitas que você pode aplicar apenas para fazer as coisas funcionarem. O desenvolvimento de software tem tantos aspectos humanos quanto aspectos técnicos e uma equipe ou um gerente que cria uma metodologia de bala de prata e uma lista de verificação para aplicar cegamente podem esperar algumas surpresas. Observando estudos sobre as taxas de sucesso de projetos de software como o Chaos Report ano após ano, você pode contar que a história das metodologias de software tem mais a ver com uma série de tentativas fracassadas do que a regra de processos sólidos, cientificamente estabelecidos e repetíveis.

Há três:

1. nenhum (também conhecido como codificação de cowboy)
2. cascata
3. rápido desenvolvimento de aplicativos (RAD ou espiral)

o resto são variantes e combinações destes

observe que os artefatos de cascata (início, requisitos, especificação funcional, especificação de design, especificação de teste, especificação de controle de qualidade etc.) cobrem tudo que é importante para o projeto, a maioria, se não todos, são cobertos por outras metodologias, mas em maneiras muito diferentes. Por exemplo, no TDD, os recursos, histórias do usuário e descrições de teste cobrem os requisitos, as especificações funcionais e as especificações de teste da cascata. No RUP, são adicionados ainda mais artefatos que quebram um pedaço das especificações em cascata (o documento Stakeholders, por exemplo, é um pedaço do documento Inception), mas prossegue de maneira espiralada

publique um link para seus resultados quando estiver pronto, parece um artigo interessante!

Talvez você queira apenas mencionar metodologias antigas (não 'metodológicas) como:

1. processamento em lote: envie um baralho de cartas e recupere a saída no dia seguinte. Desvantagens: muito tempo entre envios; para depuração, estude um dump principal.

2. métodos cli - use vi ou emacs e compile; tudo a partir da linha de comando, assim como é feito em um shell linux até hoje. Desvantagens: difíceis de depurar (gdb? Você está brincando comigo?), Comandos obscuros do shell de 40 anos de idade.

Apenas um pensamento.

Você pode mencionar três abordagens básicas: prototipagem, espiral e cascata. Eu não consideraria Lean, TDD ou Cleanroom como uma metodologia, mas um processo que pode fazer parte da metodologia.