Quali metodologie di sviluppo del software possono essere viste come basi

I nomi nel tuo elenco non sono tutti metodologie e sono scalabili su diversi livelli:

• Iterativo è una caratteristica, una caratteristica condivisa da diversi metodi e tecniche. Scrum è una metodologia iterativa, TDD è una tecnica iterativa.
• Vedo Agile come un superset di metodologia che rimane a livello concettuale / filosofico. Nella programmazione orientata agli oggetti potresti descriverla come astratta: è un insieme di valori e principi che non possono essere istanziati e devono essere derivati e implementati. Questo è ciò che Scrum e XP fanno.
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model sono metodologie appropriate, ovvero processi di sviluppo del software (sebbene Scrum affermi di essere un "framework" leggero rispetto a un processo pesante)
• La prototipazione e il TDD sono tecniche, attività. TDD è una pratica XP.

Distinguere quale è la base di ciò è un lavoro difficile. È possibile tracciare una linea storica ovviamente, ma una metodologia è raramente direttamente basata su un'altra. Piuttosto si sovrappongono, si prendono in prestito gli uni dagli altri, a volte si rispondono l'un l'altro ... Non vedo una classificazione chiaramente definita, anche se potresti probabilmente delineare alcune grandi famiglie.

Un altro modo di guardarlo è da una prospettiva di generazione. In termini di software aziendale direi che abbiamo conosciuto 2 generazioni di metodologie. I primi, tra cui Waterfall e V-Model, erano per lo più processi preesistenti da altre discipline ingegneristiche applicate al software. La seconda generazione (si può chiamare Agile ma è iniziata molto tempo prima che il termine Agile venisse coniato) è stata avviata in reazione 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 rendono software e i passaggi che possono garantire che questi criteri fossero davvero specifici e che dovessero essere ancora esplorati.

Infine dovresti notare che, nel software forse anche più che in altre discipline, le metodologie non sono ricette che puoi applicare solo 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 proiettili d'argento e una lista di cose da applicare ciecamente possono aspettarsi delle sorprese. Basta osservare gli studi sulle percentuali di successo dei progetti software come il Chaos Report anno dopo anno, è possibile dire che la storia delle metodologie software ha più a che fare con una serie di tentativi falliti rispetto alla regola di processi solidi, scientificamente stabiliti e ripetibili.

Ce ne sono tre:

1. none (aka codifica cowboy)
2. cascata
3. sviluppo rapido 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 progettazione, specifiche di test, specifiche di controllo qualità, ecc.) coprono tutti gli aspetti importanti del progetto, la maggior parte se non tutti sono coperti da altri metodologie ma in modi molto diversi. Ad esempio, in TDD le caratteristiche, le User story e le descrizioni dei test coprono i requisiti, le specifiche funzionali e le specifiche di test di waterfall. In RUP vengono aggiunti anche altri artefatti che interrompono una parte delle specifiche di cascata (il documento Stakeholders, ad esempio, è un pezzo del documento Inception) ma procede a spirale

per favore pubblica un link ai tuoi risultati quando hai finito, sembra un documento interessante!

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

1. elaborazione in batch: invia un mazzo di carte e recupera l'output il giorno successivo. Svantaggi: troppo tempo tra un invio e l'altro; per il debug, studia un core dump.

2. metodi cli - usa vi o emacs, quindi compila; tutto dalla riga di comando proprio come è fatto in una shell Linux ancora oggi. Svantaggi: difficile da 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.