La metodologia di sviluppo del software Waterfall è ancora praticabile?


14

Nella mia esperienza, sembra che il modello Waterfall abbia dimostrato di essere troppo inflessibile e non rispondente alle modifiche dei requisiti per essere considerato un metodo praticabile nel moderno mondo dello sviluppo del software. La crescita e la comprovata esperienza di metodi più agili e iterativi sembrano indicare che non vi è alcun motivo per cui qualcuno dovrebbe seguire un processo di blocchi rigidi che presuppone cambiamenti minimi o nulli dall'avvio del progetto alla consegna del prodotto.

La metodologia di sviluppo della cascata è ancora praticabile per la fornitura di sistemi software, in termini di tempo, costi e qualità?


3
Quindi, se non l'hai sperimentato e non vuoi provarlo, questo lo rende morto? Non che io lo stia sostenendo, ma sembra una strana premessa.
giovedì giovedì

9
Non è morto Non è solo l'attuale moda / tendenza / "accettabile"
Paul

2
@GrandmasterB Per "morto" intendevo "sufficientemente dimostrato di non essere il modo migliore"
CFL_Jeff

3
@ Rachel Non continuare a leggere il tag di sviluppo del software. È un metatag che è previsto per la pulizia futura .
Thomas Owens

3
Non è morto, sta solo riposando. Pining per i fiordi. ;)
FrustratedWithFormsDesigner

Risposte:


20

Il modello a cascata a cui ti riferisci non è mai stato inteso come un modello di processo utilizzato in un progetto reale. Invece, è un pagliaccio. Identifica le fasi e le attività chiave esistenti nei progetti software e il flusso più basilare tra di essi. Questa semplificazione eccessiva di come sviluppare software è imperfetta, e fu persino presentata in quel modo.

Dall'articolo di Wikipedia:

La prima descrizione formale del modello a cascata è spesso citata come un articolo del 1970 da Winston W. Royce, sebbene Royce non abbia usato il termine "cascata" in questo articolo. Royce ha presentato questo modello come esempio di un modello difettoso e non funzionante.

L'articolo discusso si intitola Gestione dello sviluppo di grandi sistemi software . In esso, Royce presenta quel modello nella seconda pagina. Tuttavia, il testo immediatamente sotto la rappresentazione pittorica continua a leggere:

Credo in questo concetto, ma l'implementazione sopra descritta è rischiosa e invita al fallimento.

Segue una discussione sui problemi con i test a seguito del "completamento" della fase di sviluppo e su come i fallimenti qui possono portare a importanti riprogettazioni e modifiche al codice e come questi possono portare a grandi sovraccarichi di costi e pianificazione. In tutto il documento, affina il modello originale a uno che è effettivamente praticabile su un progetto. Alla fine, finisce con un modello che introduce la prototipazione, l'interazione con il cliente e il perfezionamento dei manufatti - idee che alla fine sarebbero diventate fondamentali per il movimento agile iniziato alla fine degli anni '90 e all'inizio degli anni 2000.

Per rispondere alla tua domanda: The Waterfall di cui stai chiedendo non è, e non è mai stato, un metodo praticabile per fornire progetti software con una ragionevole quantità di qualità in termini di tempo e budget. Tuttavia, ci sono altre metodologie basate sul piano che sono opposte all'agile che possono e lavorano su progetti.


Molti articoli sull'agile usano "metodi tradizionali" per menzionare la cascata, e quella cascata implicita è stata usata nel XX secolo per tutto il tempo. Ora so di sbagliarmi.
Ming-Tang,

@ThomasOwens Ti dispiacerebbe citarne un paio other plan-driven methodologies that lie opposite of agile that can and do work on project?
Laiv

@Laiv Il modello Spiral tende ad essere più guidato dai piani rispetto agli approcci agili: fai più pianificazione e analisi prima di sviluppare software funzionante. Cap Gemini SDM è un altro esempio, sebbene le revisioni successive siano state aggiunte in un ciclo plan-do-check-act, ma ha di nuovo una discreta quantità di pianificazione e analisi iniziali integrate nel processo. È probabile che molte siano una variante di una cascata, ma con un qualche tipo di loop di feedback integrato. Se si dispone di una solida conoscenza del dominio e requisiti relativamente stabili, potrebbe non essere necessario il loop di feedback stretto dei metodi agili e pianificare meglio.
Thomas Owens

9

Le persone non usano il modello a cascata del libro di testo e probabilmente non lo hanno mai fatto.

È un costrutto idealizzato e teorico il cui scopo è farti pensare ai passi nello sviluppo dei sistemi. Il punto principale è che vuoi che i cambiamenti più grandi avvengano il più presto possibile, perché non avrai mai il tempo o i soldi per fare un grande cambiamento una volta che è stato costruito un sacco di codice.

Nonostante sia più un modo di pensare che un processo, è ancora il modo in cui molti - probabilmente la maggior parte delle organizzazioni si occupa di costruire software (o case, sottomarini o qualsiasi altra cosa ...).

Nel mondo reale, non hai interruzioni totalmente rigide tra le fasi e talvolta ritorni alle fasi precedenti per piccoli sottoprogetti. Ciò che la metodologia ti dice non è che "queste cose non sono consentite". Ciò che ti dice è "queste cose ti costano denaro e / o tempo", quindi cerca di evitarlo in futuro.

Va bene per Agile Snobs (TM) guardare in fondo agli sviluppatori "vecchio stile" e alla loro metodologia a cascata insolita, non praticabile, ma il fatto è che Agile non è nemmeno una panacea. Alcuni progetti non possono essere realizzati utilizzando Agile e molti team che pensano di essere Agile sono in realtà solo sciatti e disorganizzati.

La metodologia non è il punto. Il punto è pensare a cosa stai facendo e perché lo stai facendo in questo modo - e ottenere il massimo valore per il cliente nel più breve tempo ragionevole.


Ovviamente hai avuto un'esperienza molto diversa di "persone" per me. Negli ultimi 30 anni ho lavorato in una serie di aziende che utilizzavano (e usano ancora) il metodo a cascata dei libri di testo. Non sorprende che non funzioni.
David Arno,

@DavidArno Il più vicino che abbia mai visto "allo stato brado" al libro di testo Waterfall in un contesto software era in una società che costruiva software che controllava il cambio di treno. La motivazione non era quella di far morire letteralmente qualcuno a causa di un bug. Immagino che potrebbe accadere anche in luoghi che fanno programmazione integrata in cui non si vuole costruire un milione di qualcosa solo per scoprire che fallisce a causa di un bug. Tendo a pensare che anche in questi casi, Waterfall sia più un ideale che una pratica che si ottiene con la perfezione. Come fai notare - i risultati sono inevitabilmente un fallimento ad un certo livello.
Joel Brown,

8

Il mitico processo a cascata che viene spesso confrontato con l'agile non è mai esistito e quindi non può essere considerato morto. I processi a cascata reali sono ancora vivi e ineccepibili ed eccellono nel fornire in tempo il software economico che soddisfa le aspettative degli utenti.


5
Non sono sicuro di quale sia la differenza tra il processo a cascata "mitico" e quello "reale". Puoi spiegarlo per favore?
CFL_Jeff

6
Spesso il processo a cascata descritto dai sostenitori di Agile è un uomo di paglia en.wikipedia.org/wiki/Straw_man
jfrankcarr

11
Questa sarebbe una risposta migliore se spiegassi nella tua risposta come i sostenitori di Agile creano un processo da uomo di paglia che non funzionerà, ma che non è propriamente Waterfall.
Robert Harvey,

4
-1 per l'affermazione "Stanno eccellendo nel consegnare ..." La verità è che è una lavata. Come tutte le metodologie software, a volte funziona, a volte no. Ho visto entrambi nel caso del vero metodo a cascata.
riwalk

2
Devo dire che [citazione necessaria] su questa risposta. E -1 fino a quando non viene fornito. Soprattutto l '"eccellenza nel consegnare in tempo il software economico che soddisfa le aspettative degli utenti" Il rapporto CHAOS non è d'accordo con te.
Malfist,

5

Forse un modo migliore per chiedere a cosa stai arrivando è "quando è meglio meno iterativo e più formale?"

Ci sono situazioni in cui questo è il caso:

  • Quando i requisiti non cambieranno.

  • Quando si soddisfano nuovi requisiti è meno importante che colpire il 100% di quelli originali.

  • Quando tutti i componenti tecnologici sono maturi e ben compresi.

In un certo senso puoi prendere il contrario di ciò che potrebbe spingerti ad essere agile.

Pochissime tecniche sono applicabili ovunque. Pochissimi non servono.


1
Che cosa nel mondo è "meno scrivente" o "morenformale"?
Aaronaught il

1
@Aaronaught - "meno iterativo" e "più formale" digitato dai pollici grassi su un iPhone. :-)
MathAttack

1
Non ho mai lavorato in un progetto che abbia soddisfatto anche uno di questi prerequisiti. :)
Theodor,

3

Sì, è molto vivo, sebbene oggi sia utilizzato il " modello V " più comune .

In entrambi i casi, il problema che Agile ha è che la soluzione non finisce quasi mai, il cliente può continuare a richiedere modifiche e lo sviluppo continuerà a risolverle in modo iterativo. Per un progetto basato sul tempo e sui costi dei materiali, questo funziona molto bene. Per un progetto che ha un costo fisso, non lo è.

Per questi progetti a costo fisso, il cliente si aspetta quasi sempre che le pietre miliari predefinite dimostrino progressi, tuttavia, si tratta più della varietà scritta formale che del codice di lavoro. Per i clienti come questo, le specifiche scritte diventano il progetto, quello in cui lo sviluppo del software è una considerazione secondaria (poiché presumono, se si dispone di un progetto ben definito, il software dovrebbe essere facile da sviluppare). Queste aziende sono anche quelle che fanno largo uso di risorse di sviluppo economiche e in outsourcing.

Pertanto, se si dispone di una somma di denaro o di tempo fissi, non aspettarsi che i requisiti cambino o non sia consentito cambiarli e ci si aspetta che forniscano una solida serie di documentazione scritta, quindi i modelli a cascata sono gli unici che ha senso.

Agile può essere introdotto nel mezzo di questi progetti per fare lo sviluppo, ma hai ancora una fase di accelerazione in cui le specifiche vengono create dai requisiti e una fase di accelerazione in cui il software viene installato e testato in loco. Agile non risponde bene a questi casi.


Agile può funzionare molto bene con un piatto fisso di tempo o denaro, a condizione che anche l'ambito non sia fisso. L'altro punto è che il cliente / appaltatore può scegliere il tipo di contratto (T&M, costo fisso o qualcosa nel mezzo) per essere coerente con una particolare metodologia di sviluppo (agile o a cascata) - non è predeterminato.
DNA,

1

A chi? La maggior parte dei gestori con cui ho avuto a che fare utilizza ancora il processo di sviluppo del software Waterfall per la pianificazione, e sembra che i livelli più alti lo apprezzino per una facile programmazione.

In pratica, pochissimi sviluppatori che conosco credono che funzioni o siano addirittura validi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.