Qué metodologías de desarrollo de software pueden verse como fundamentos

Estoy escribiendo un pequeño trabajo de investigación que involucra metodologías de desarrollo de software. Estaba investigando todas las metodologías disponibles y me preguntaba, de todas las metodologías, ¿hay alguna que haya proporcionado las bases para las demás?

Por ejemplo, observando las siguientes metodologías:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD.

¿Podemos decir que:
la creación de prototipos, iterativa, espiral y cascada son la "base" para los demás?

¿O no existen los "fundamentos" y cada metodología tiene su propia historia única?

Por supuesto, me gustaría describir todas las metodologías en mi trabajo de investigación, pero simplemente no tengo tiempo para hacerlo y es por eso que me gustaría saber qué metodologías pueden verse como representantes.

Los nombres en su lista no son todas metodologías y se escalan en diferentes niveles:

• La iterativa es una característica, un rasgo compartido por varios métodos y técnicas. Scrum es una metodología iterativa, TDD es una técnica iterativa.
• Veo Agile como un superconjunto de metodología que permanece en un nivel conceptual / filosófico. En la programación orientada a objetos, podría describirlo como abstracto: es un conjunto de valores y principios que no se pueden instanciar y deben derivarse e implementarse. Eso es lo que hacen Scrum y XP.
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model son metodologías adecuadas, es decir, procesos de desarrollo de software (aunque Scrum afirma ser un "marco" ligero en lugar de un proceso pesado)
• La creación de prototipos y TDD son técnicas, actividades. TDD es una práctica XP.

Distinguir cuál es la base de lo cual es un trabajo difícil. Obviamente, puede trazar una línea histórica, pero una metodología rara vez se basa directamente en otra. Más bien se superponen, se toman prestados unos de otros, a veces se responden entre sí ... No puedo ver una clasificación claramente definida, aunque probablemente podría describir algunas familias grandes.

Otra forma de verlo es desde una perspectiva de generación. En términos de software empresarial, diría que hemos conocido 2 generaciones de metodologías. Los primeros, entre los cuales Waterfall y V-Model, fueron en su mayoría procesos preexistentes de otras disciplinas de ingeniería aplicadas al software. La segunda generación (puede llamarse Ágil pero comenzó mucho antes de que se acuñara el término Ágil) se inició en reacción a la pesadez de los procesos de primera generación, cuando las personas comenzaron a darse cuenta de que el software era un animal totalmente diferente y que los criterios que lo hacen bueno El software y los pasos que pueden garantizar que estos criterios sean realmente específicos y aún deben explorarse.

Finalmente, debe tener en cuenta que, en el software, tal vez incluso más que en otras disciplinas, las metodologías no son recetas que solo puede aplicar para que las cosas funcionen. El desarrollo de software tiene tantos aspectos humanos como técnicos, y un equipo o un gerente que presenta una metodología de bala de plata y una lista de verificación de las cosas que se aplicarán a ciegas puede esperar algunas sorpresas. Simplemente observando estudios sobre las tasas de éxito de proyectos de software como el Informe del Caos año tras año, se puede ver que la historia de las metodologías de software tiene más que ver con una serie de intentos fallidos que la regla de procesos sólidos, científicamente establecidos y repetibles.

Hay tres:

1. ninguno (también conocido como codificación de vaquero)
2. cascada
3. Desarrollo rápido de aplicaciones (RAD o espiral)

el resto son variantes y combinaciones de estos

tenga en cuenta que los artefactos de la cascada (inicio, requisitos, especificaciones funcionales, especificaciones de diseño, especificaciones de prueba, especificaciones de control de calidad, etc.) abarcan todo lo que es importante para el proyecto, la mayoría, si no todos, que están cubiertos por otras metodologías, pero en formas muy diferentes Por ejemplo, en TDD las características, historias de usuarios y descripciones de prueba cubren los requisitos, las especificaciones funcionales y las especificaciones de prueba de la cascada. En RUP, se añaden aún más artefactos que separan una parte de las especificaciones de la cascada (el documento de partes interesadas, por ejemplo, es una parte del documento de inicio), pero procede de forma espiral.

publique un enlace a sus resultados cuando haya terminado, ¡suena como un artículo interesante!

Tal vez solo desee mencionar metodologías antiguas (no 'metodologías') como:

1. procesamiento por lotes: envíe una baraja de cartas y obtenga la salida al día siguiente. Inconvenientes: demasiado tiempo entre presentaciones; para la depuración, estudie un volcado de núcleo.

2. métodos cli: use vi o emacs, luego compile; todo desde la línea de comandos al igual que se hace en un shell de Linux incluso hasta el día de hoy. Inconvenientes: difícil de depurar (gdb? ¿Me estás tomando el pelo?), Oscuros comandos de shell de 40 años.

Solo un pensamiento.

Puede mencionar tres enfoques básicos: creación de prototipos, espiral y cascada. No consideraría Lean, TDD o Cleanroom como una metodología, sino un proceso que puede ser parte de la metodología.