El model de desenvolupament en cascada en el context de l'enginyeria de programari és un procés de disseny seqüencial, d'ús freqüent en els processos de desenvolupament de programari, en què el progrés flueix constantment cap avall (com una cascada) a través de les fases de concepció, iniciació, anàlisi, disseny, construcció, proves, producció/realització, i manteniment. Aquest enfocament metodològic ordena rigorosament les etapes del cicle de vida del programari, de tal manera que l'inici de cada etapa ha d'esperar la finalització de la immediatament anterior.
Un exemple d'una metodologia de desenvolupament en cascada és seguir aquests passos: Anàlisi de requisits, Disseny del Sistema, Disseny del Programa, Codificació, Proves, Implantació i Manteniment. D'aquesta manera, qualsevol error de disseny detectat en l'etapa de prova condueix necessàriament al redisseny i nova programació del codi afectat, augmentant els costos del desenvolupament. La paraula cascada suggereix, mitjançant la metàfora de la força de la gravetat, l'esforç necessari per introduir un canvi en les fases més avançades d'un projecte. Si bé ha estat àmpliament criticat des de l'àmbit acadèmic i la indústria, segueix sent el paradigma més seguit avui dia.
Història El model de desenvolupament en cascada s'origina en les indústries manufactureres i de la construcció; entorns físics altament estructurats en els quals els canvis després dels fets són prohibitivament costos, si no impossible. Atès que no existien metodologies de desenvolupament de programari formals en el moment, aquest model simplement es va adaptar pel desenvolupament de programari.Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs" . IEEE Annals of the History of Computing (IEEE Educational Activities Department) 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.
La primera referència que descriu l'ús de fases similars en l'enginyeria de programari és de Herbert D. Benington al Simposi sobre mètodes avançats de programació per a ordinadors digitals el 29 de juny de 1956,United States. Navy Mathematical Computing Advisory Panel. (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738 en una presentació sobre el desenvolupament de programari per SAGE. El 1983 es va tornar a publicar el document amb un pròleg de Benington assenyalant que el procés no va ser, de fet, realitzada en un estricte de dalt a baix, sinó que depenia d'un prototip.
La primera descripció formal del model de cascada se cita sovint com un article de 1970 per Winston W. Royce,Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Retrieved on 2007-11-28 from http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html . encara Royce no va utilitzar el terme "cascada" en aquest article. Royce presenta aquest model com un exemple d'un model erroni que no funciona.Royce, Winston (1970), Managing the Development of Large Software Systems , Proceedings of IEEE WESCON 26 (August): 1–9 Això, de fet, és com s'utilitza generalment el terme per escrit sobre el desenvolupament de programari de descriure una visió crítica d'una pràctica de desenvolupament de programari d'ús comú.Conrad Weisert, Waterfall methodology: there's no such thing!
El primer ús del terme "cascada" pot haver estat un document de 1976 per Bell i Thayer.Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem? Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976.
Model En el model original de Royce, les següents fases es succeïen en el següent ordre: Especificació dels requisits resultant en el document de requisits del producte. Disseny resultant en l'arquitectura de programari. Construcció (implementant o codificant) resultant en el programari actual. Integració. Provant i depurant. Instal·lació. Manteniment. Així el model de desenvolupament en cascada manté que un s'ha de moure cap a una etapa només quan l'etapa que el precedeix és revisada i verificada. Tot i això, diversos models de desenvolupament en cascada modificats (incloent el model final de Royce) poden incloure variacions més grans o més petites en el procés.Royce, Winston. "Managing the Development of Large Software Systems ". Retrieved 11 August 2014.
Arguments a favor El temps que s'ha gastat anteriorment en el cicle de producció de programari pot desencadenar en una millor economia en etapes posteriors. McConnell mostra que un error trobat a les etapes inicials (com ara l'especificació dels requeriments o el disseny) és més barat en termes de diners, esforç i temps que solucionar-lo en una etapa posterior del procés.McConnell (1996), p. 72, estimates that "...a requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would have cost to fix at requirements time". Agafant un exemple extrem, si el disseny d'un programa resulta ser impossible d'implementar, és més fàcil de solucionar a l'etapa de disseny que adonar-se'n mesos després, quan els components del programa estan sent integrats, que tot el treball fet fins llavors es perdi a causa d'un disseny mal fet.
A les pràctiques comunes, el resultat de l'organització de les metodologies de desenvolupament en cascada sol ser d'un 20-40% del temps invertit en les primeres dues fases, un 30-40% del temps en codificar i la resta es dedica a provar i implementar. L'organització del projecte actual necessita ser molt més ben estructurada. La majoria dels projectes de dimensions mitjanes o grosses inclouen un conjunt detallat de procediments i controls, que regulen cada un dels processos del projecte.
Aquesta és la idea rere el Big Design Up Front i el model de desenvolupament en cascada: passar-se el temps al principi assegurant-se que els requeriments i el disseny és correcte estalvia molt de temps i esforç després. Així, el pensament dels que segueixen el model de desenvolupament en cascada és que s'asseguren que cada etapa està totalment acabada i absolutament correcte abans de seguir amb la següent etapa. Els requeriments del programa han d'estar completament clars abans que el disseny comenci (de manera que el treball fet en un disseny basat en uns requeriments incorrectes és treball perdut). El disseny del programa ha de ser perfecte abans es comenci la implementació d'aquest, ja que si s'implementa un disseny incorrecte és malgastar temps i feina, etc.
Un altre argument a favor del model de desenvolupament en cascada és que aquest posa èmfasi en la documentació (com ara els documents de requeriments o de disseny) com al mateix codi font. En metodologies menys dissenyades i documentades a consciència, els coneixements es perden si els membres de l'equip abandonen abans d'acabar el projecte, i sol ser difícil per un projecte recuperar-se d'aquesta pèrdua. Si un document de disseny totalment funcional és present (com és la intenció del Big Design Up Front i el model de desenvolupament en cascada), nous membres de l'equip o fins i tot nous equips seran capaços de familiaritzar-se amb el treball fet llegint els documents.
Alguns defensors del model de desenvolupament en cascada prefereixen aquest model pel seu enfocament simple i l'argumentació més disciplinada. El model de desenvolupament en cascada proporciona un enfocament estructurat; el model per si mateix progressa linealment a través d'etapes discretes, fàcils d'entendre i explicables i així és fàcil d'entendre; també proporciona fites fàcilment identificables en el procés de desenvolupament. Potser és la raó per la qual el model de desenvolupament en cascada és utilitzar com un dels primers exemples de models de desenvolupament en molts articles i cursos d'enginyeria de programari.
Es discuteix que el model de desenvolupament en cascada i el Big Design up Front en general es poden aplicar en projectes estables (especialment aquells projectes sense canvis de requeriments) i on és possible que els dissenyadors siguin capaços de predir les àrees problemàtiques del sistema i produir un disseny correcte abans de començar la implementació. El model de desenvolupament en cascada requereix que els implementadors segueixin el disseny complet i ben fet, assegurant-se que la integració amb el sistema es produeix de forma suau.
La crítica Els defensors de la Metodologia Àgil sostenen que el model en cascada és una mala idea en la pràctica. Creuen que és impossible finalitzar correctament la fase de vida d'un producte programat de qualsevol projecte no trivial abans de passar a les següents fases, ja que no es pot aprendre d'elles.
Per exemple, els clients no poden saber exactament quins requisits es necessiten abans de fer la revisió d'un prototip de treball i comentar sobre ell mateix. Els requisits poden canviar constantment, i els dissenyadors i programadors tenen poc control sobre això. Si canvien les necessitats dels clients després que el disseny estigui finalitzat, aquest ha de ser modificat per adaptar-se a les noves exigències. Això significa que queden invalidades una bona quantitat d'hores de treball, el que significa un augment dels costos, especialment si una bona part dels recursos del projecte ja s'han invertit en Big Design Up Front.
Algunes futures dificultats de l'aplicació poden ser desconegudes pels dissenyadors quan es descriu un disseny per a un producte sense haber-lo aplicat prèviament. És a dir, tenir previst clarament en la fase d'implementació totes les funcionalitats del programa és extraordinàriament difícil. En aquest cas, el millor és retirar el disseny i no persistir en un disseny basat en prediccions errònies que no té en compte problemes recentment descoberts.
En Code Complete (un llibre que critica l'ús generalitzat del model en cascada), Steve McConnell es refereix al disseny com un "problema pervers", ja que un problema de requisits i limitacions no pot ser del tot conegut abans de la seva finalització. Això implica la impossibilitat de perfeccionar la fase de desenvolupament del programa, que no és possible si s'utilitza el model en cascada.
David Parnas, en A Rational Design Process; How and Why to Fake It, escriu:"A Rational Design Process: How and Why to Fake It", David Parnas (PDF file)
"Molts dels detalls (del sistema) només són coneguts per nosaltres a mesura que avancem en l'execució. Algunes de les coses que aprenem invalida el nostre disseny i hem de donar marxa enrere."
Ampliant el concepte anterior, els interessats en el projecte (personal no tècnic) poden no ser plenament conscients de les capacitats de la tecnologia que s'està implementant. Això pot conduir a definir expectatives i requisits erronis, i pot acabar en un disseny que no utilitza tot el potencial que la nova tecnologia pot oferir. Això pot provocar canvis substancials en els requisits de l'aplicació una vegada que les parts interessades siguin més conscients de la funcionalitat disponible en la nova tecnologia. Un exemple és quan una organització migra d'un procés basat en paper a un procés electrònic. Mentre que els lliuraments de treball s'han de mantenir, els beneficis de la validació en temps real d'entrada de dades, traçabilitat, i d'enrutament, no poden ser anticipats en les primeres etapes de planificació del projecte. Un altre exemple és el canvi dels sistemes fora de línia o autònoms a línia o sistemes complets.