Quali metodologie di sviluppo software possono essere viste come basi

Sto scrivendo un piccolo documento di ricerca che coinvolge la metodologia di sviluppo del software. Stavo esaminando tutte le metodologie disponibili e mi chiedevo, da tutte le metodologie, ce ne sono alcune che hanno fornito le basi per gli altri?

Ad esempio, esaminando le seguenti metodologie:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD.

Possiamo dire che:
prototipazione, iterativo, spirale e cascata sono le "basi" per gli altri?

O non esistono "fondamenti" e ogni metodologia ha la sua storia unica?

Vorrei naturalmente descrivere tutte le metodologie contenute nel mio documento di ricerca, ma semplicemente non ho il tempo di farlo ed è per questo che vorrei sapere quali metodologie possono essere viste come rappresentanti.

I nomi nel tuo elenco non sono tutte metodologie e si adattano a diversi livelli:

• L'iterativo è una caratteristica, un tratto condiviso da diversi metodi e tecniche. Scrum è una metodologia iterativa, TDD è una tecnica iterativa.
• Vedo Agile come un superset metodologico che rimane a livello concettuale / filosofico. Nella programmazione orientata agli oggetti potresti descriverlo come astratto: è un insieme di valori e principi che non possono essere istanziati e devono essere derivati ​​e implementati. Questo è ciò che fanno Scrum e XP.
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model sono metodologie appropriate, cioè processi di sviluppo software (sebbene Scrum affermi di essere un "framework" leggero anziché un processo pesante)
• Il prototipo e il TDD sono tecniche, attività. TDD è una pratica XP.

Distinguere quale è il fondamento di cui è un lavoro difficile. Ovviamente puoi tracciare una linea storica, ma raramente una metodologia si basa direttamente su un'altra. Si sovrappongono piuttosto, si mutuano l'uno dall'altro, a volte rispondono l'un l'altro ... Non riesco a vedere una classificazione chiaramente definita, anche se probabilmente potresti delineare alcune grandi famiglie.

Un altro modo di vederlo è dal punto di vista della generazione. In termini di software aziendale direi che abbiamo conosciuto 2 generazioni di metodologie. I primi, tra cui Waterfall e V-Model, erano principalmente processi preesistenti di altre discipline ingegneristiche applicate al software. La seconda generazione (puoi chiamarla Agile ma è iniziata molto prima che il termine Agile fosse coniato) è stata avviata in risposta alla pesantezza dei processi di prima generazione, quando le persone hanno iniziato a rendersi conto che il software era un animale completamente diverso e che i criteri che lo rendono buono il software e i passaggi che possono garantire che questi criteri fossero davvero specifici e che dovevano ancora essere esplorati.

Infine, dovresti notare che, nel software forse anche più che in altre discipline, le metodologie non sono ricette che puoi semplicemente applicare per far funzionare le cose. Lo sviluppo del software ha tanti aspetti umani quanto gli aspetti tecnici e un team o un manager che escogita una metodologia di proiettile d'argento e una lista di controllo di cose da applicare alla cieca possono aspettarsi alcune sorprese. Solo osservando gli studi sui tassi di successo dei progetti software come il Rapporto sul caos anno dopo anno, puoi dire che la storia delle metodologie software ha più a che fare con una serie di tentativi falliti che con la regola di processi solidi, scientificamente stabiliti e ripetibili.

Ce ne sono tre:

1. nessuno (alias codifica cowboy)
2. cascata
3. rapido sviluppo di applicazioni (RAD o spirale)

il resto sono varianti e combinazioni di questi

si noti che gli artefatti di cascata (inizio, requisiti, specifiche funzionali, specifiche di progetto, specifiche di test, specifiche di controllo di qualità, ecc.) coprono tutte le cose importanti per il progetto, la maggior parte se non tutte sono coperte da altre metodologie ma in modi molto diversi. Ad esempio, in TDD le caratteristiche, le storie degli utenti e le descrizioni dei test coprono i requisiti, le specifiche funzionali e le specifiche di test da cascata. In RUP vengono aggiunti anche più artefatti che interrompono un pezzo delle specifiche della cascata (il documento Stakeholder, ad esempio, è un pezzo del documento Inception) ma procede in modo a spirale

per favore pubblica un link ai tuoi risultati quando fatto, sembra un articolo interessante!

Forse vuoi solo menzionare metodologie antiche (non "metodologie") come:

1. elaborazione batch: invia un mazzo di carte e recupera l'output il giorno successivo. Svantaggi: troppo tempo tra le presentazioni; per il debug, studiare un dump principale.

2. metodi cli - usa vi o emacs, quindi compila; tutto dalla riga di comando, proprio come avviene in una shell Linux fino ad oggi. Svantaggi: difficile da eseguire il debug (gdb? Mi stai prendendo in giro?), Oscuri comandi della shell di 40 anni.

Solo un pensiero.

Puoi menzionare tre approcci di base: prototipazione, spirale e cascata. Non considererei Lean, TDD o Cleanroom come una metodologia, ma piuttosto un processo che può far parte della metodologia.