Model de desenvolupament en cascada
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
[modifica]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.[1]
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,[2] 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,[3] 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.[4] 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ú.[5]
El primer ús del terme "cascada" pot haver estat un document de 1976 per Bell i Thayer.[6]
Model
[modifica]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.[7]
Arguments a favor
[modifica]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.[8] 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.[9]
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.[10]
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
[modifica]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:[11]
"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.
La idea darrere el model en cascada pot ser "mesurar dues vegades, tallar una vegada", i els qui s'oposen a aquest model argumenten que aquesta idea tendeix a enfonsar-se quan el problema canvia constantment a causa de les modificacions de requisits i noves realitzacions sobre el problema en si. Una possible solució per un dissenyador amb experiència és passar davant en el temps la refacció per consolidar el programari, i per preparar-lo per a una possible actualització, independentment de si està planejada o no. Un altre enfocament és utilitzar una modularitat de disseny amb interfície per incrementar la flexibilitat del programari pel que fa al disseny.
A causa de les crítiques esmentades anteriorment, algunes organitzacions, com ara el Departament de Defensa dels Estats Units, ara tenen una preferència en contra de metodologies de tipus cascada, com ara la norma MIL-STD-498 "encoratjant clarament adquisició evolutiva i IID".[12]
Models Modificats
[modifica]En resposta als problemes que s'observen en el model en cascada pur, s'han introduït molts models en cascada modificats. Aquests models poden abordar alguns o la totalitat de les crítiques al model en cascada pur. Molts d'aquests models diferents estan coberts per Steve McConnell en el capítol "Lifecycle Planning" (Planificació del cicle de vida) del seu llibre Rapid Development: Taming Wild Software Schedules.[13]
Mentre que tots els models de desenvolupament de programari tenen certa similitud amb el model en cascada, o tots els models de desenvolupament de programari incorporen almenys algunes fases similars a les utilitzades en el model en cascada, aquesta secció s'ocupa dels més propers al model en cascada. Per als models en que s'apliquen altres mètodes diferents al model en cascada, o per diferents models de desenvolupament cal buscar informació general sobre el procés de desenvolupament de programari.
Controvèrsia
[modifica]Encara que hi ha moltes referències al model en cascada, i mentre moltes metodologies podrien ser qualificades com a cascada 'modificada', l'aspecte clau de la cascada és ser un procés no repetitiu. La manca de cites relacionades amb l'ús real d'una cascada com a model no iteratiu han provocat moltes crítiques,[14] entre altres, plantejar la tesi que el model en cascada en si, com a metodologia de desenvolupament no iteratiu, és de fet un mite i un argument per als dissenyadors a utilitzar metodologies de desenvolupament alternatiu.
Fases del model
[modifica]Anàlisi de requeriments
[modifica]En aquesta fase s'analitzen les necessitats dels usuaris finals del programari per a determinar quins objectius ha de cobrir. D'aquesta fase sorgeix una memòria anomenada SRD (document d'especificació de requisits), que conté l'especificació completa del que ha de fer el sistema sense entrar en detalls interns. És important assenyalar que en aquesta etapa s'ha de consensuar tot el que es requereix del sistema i serà allò que seguirà en les següents etapes, no es pot requerir nous resultats a mitjan procés d'elaboració del programari.
Disseny del Sistema
[modifica]Es descompon i organitza el sistema en elements que es puguin elaborar per separat, aprofitant els avantatges del desenvolupament en equip. Com a resultat sorgeix el SDD (Document de Disseny del Software), que conté la descripció de l'estructura relacional global del sistema i l'especificació del que ha de fer cadascuna de les seves parts, així com la manera en què es combinen les unes amb les altres.
És convenient distingir entre disseny d'alt nivell o arquitectònic i disseny detallat. El primer d'ells té com a objectiu definir l'estructura de la solució (una vegada que la fase d'anàlisi ha descrit el problema) identificant grans mòduls (conjunts de funcions que estaran associades) i les seves relacions. Amb això es defineix l'arquitectura de la solució escollida. El segon defineix els algoritmes empleats i l'organització del codi per començar la implementació.
Disseny del Programa
[modifica]És la fase on es realitzen els algorismes necessaris per al compliment dels requeriments de l'usuari i també les anàlisis necessàries per saber quines eines utilitzar en l'etapa de Codificació.
Codificació
[modifica]És la fase de programació d'ordinadors o implementació pròpiament dita. Aquí s'implementa el codi font, fent ús de prototips i proves i assajos per corregir errors. Depenent del llenguatge de programació i la seva versió es creen les biblioteques i components reutilitzables dins del mateix projecte per fer que la programació sigui un procés molt més ràpid.
Proves
[modifica]Els elements, ja programats, es munten per compondre el sistema i es comprova que funciona correctament i que compleix amb els requisits.
Implantació
[modifica]El programari obtingut es posa en producció. S'implanten els nivells programari i maquinari que componen el projecte. La implantació és la fase amb més durada i amb més canvis en el cicle d'elaboració d'un projecte. És una de les fases finals del projecte.
Durant l'explotació del sistema de programari poden sorgir canvis, bé per corregir errors o bé per introduir millores. Tot això es recull en els Documents de Canvis.
Vegeu també
[modifica]- Enginyeria de programari
- Model V
- Metodologia àgil
- Refacció
- Interfície
- Model de desenvolupament iteratiu i incremental
- Programació orientada a objectes
- Rapid Application Development
- Model espiral
Referències
[modifica]- ↑ Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs" Arxivat 2011-07-18 a Wayback Machine.. 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.
- ↑ 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
- ↑ 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.
- ↑ Royce, Winston (1970), Managing the Development of Large Software Systems Arxivat 2016-03-15 a Wayback Machine., Proceedings of IEEE WESCON 26 (August): 1–9
- ↑ Conrad Weisert, Waterfall methodology: there's no such thing!
- ↑ 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.
- ↑ Royce, Winston. "Managing the Development of Large Software Systems Arxivat 2016-03-15 a Wayback Machine.". Retrieved 11 August 2014.
- ↑ 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".
- ↑ «Arcisphere technologies». Tutorial: The Software Development Life Cycle (SDLC), 2012. Arxivat de l'original el 2019-02-17 [Consulta: 3 novembre 2014].
- ↑ «Comparing Traditional Systems Analysis and Design with Agile Methodologies» (en anglès). University of Missouri – St. Louis, 2009.
- ↑ "A Rational Design Process: How and Why to Fake It", David Parnas (PDF file)
- ↑ Iterative and Incremental Development: A Brief History, Craig Larman and Victor Basili, IEEE Computer, June 2003
- ↑ McConnell, Rapid Development: Taming Wild Software Schedules (1996), pp. 143–147, describes three modified waterfalls: Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with Risk Reduction.
- ↑ A Waterfall Systems Development Methodology … Seriously? Arxivat 2014-07-02 a Wayback Machine. David Dischave 2012
Bibliografia
[modifica]
Aquest article es basa en material extret de la Free On-line Dictionary of Computing abans de l'1 de novembre de 2008 i constituïda de conformitat amb els termes "relicensing" de la llicència GFDL, la versió 1.3 o posterior.
- McConnell, Steve (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. ISBN 0-7356-0535-1.
- McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
- McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
- David Parnas, A rational design process and how to fake it (PDF) An influential paper which criticises the idea that software production can occur in perfectly discrete phases.
- Royce, Winston (1970), Managing the Development of Large Software Systems Arxivat 2016-03-15 a Wayback Machine., Proceedings of IEEE WESCON 26 (August): 1–9.
- "Why people still believe in the waterfall model"
- The standard waterfall model for systems development NASA webpage, archived on Internet Archive March 10, 2005.
- Parametric Cost Estimating Handbook Arxivat 2010-01-20 a Wayback Machine., NASA webpage based on the waterfall model, archived on Internet Archive March 8, 2005.