El model de desenvolupament en cascada en el context de l' enginyeria de programari es un proces de disseny sequencial, d'us frequent en els processos de desenvolupament de programari, en que el progres flueix constantment cap avall (com una cascada) a traves de les fases de concepcio, iniciacio, analisi, disseny, construccio, proves, produccio/realitzacio, i manteniment. Aquest enfocament metodologic ordena rigorosament les etapes del cicle de vida del programari , de tal manera que l'inici de cada etapa ha d'esperar la finalitzacio de la immediatament anterior.

Un exemple d'una metodologia de desenvolupament en cascada es seguir aquests passos: Analisi de requisits, Disseny del Sistema, Disseny del Programa, Codificacio, Proves, Implantacio i Manteniment. D'aquesta manera, qualsevol error de disseny detectat en l'etapa de prova condueix necessariament al redisseny i nova programacio del codi afectat, augmentant els costos del desenvolupament. La paraula cascada suggereix, mitjancant la metafora de la forca de la gravetat, l'esforc necessari per introduir un canvi en les fases mes avancades d'un projecte. Si be ha estat ampliament criticat des de l'ambit academic i la industria, segueix sent el paradigma mes seguit avui dia.

Historia [ modifica ]

El model de desenvolupament en cascada s'origina en les industries manufactureres i de la construccio; entorns fisics altament estructurats en els quals els canvis despres dels fets son prohibitivament costos, si no impossible. Ates 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 referencia que descriu l'us de fases similars en l'enginyeria de programari es de Herbert D. Benington al Simposi sobre metodes avancats de programacio per a ordinadors digitals el 29 de juny de 1956, ^[2] en una presentacio sobre el desenvolupament de programari per SAGE. El 1983 es va tornar a publicar el document amb un proleg de Benington assenyalant que el proces no va ser, de fet, realitzada en un estricte de dalt a baix, sino que depenia d'un prototip .

La primera descripcio 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] Aixo, de fet, es com s'utilitza generalment el terme per escrit sobre el desenvolupament de programari de descriure una visio critica d'una practica de desenvolupament de programari d'us comu. ^[5]

El primer us del terme "cascada" pot haver estat un document de 1976 per Bell i Thayer . ^[6]

Model [ modifica ]

En el model original de Royce, les seguents fases es succeien en el seguent ordre:

1. Especificacio dels requisits resultant en el document de requisits del producte .
2. Disseny resultant en l' arquitectura de programari .
3. Construccio ( implementant o codificant) resultant en el programari actual.
4. Integracio.
5. Provant i depurant .
6. Instal·lacio .
7. Manteniment .

Aixi el model de desenvolupament en cascada mante que un s'ha de moure cap a una etapa nomes quan l'etapa que el precedeix es revisada i verificada. Tot i aixo, diversos models de desenvolupament en cascada modificats (incloent el model final de Royce) poden incloure variacions mes grans o mes petites en el proces. ^[7]

Arguments a favor [ modifica ]

El temps que s'ha gastat anteriorment en el cicle de produccio de programari pot desencadenar en una millor economia en etapes posteriors. McConnell mostra que un error trobat a les etapes inicials (com ara l'especificacio dels requeriments o el disseny) es mes barat en termes de diners, esforc i temps que solucionar-lo en una etapa posterior del proces. ^[8] Agafant un exemple extrem, si el disseny d'un programa resulta ser impossible d'implementar, es mes facil de solucionar a l'etapa de disseny que adonar-se'n mesos despres, 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 practiques comunes, el resultat de l'organitzacio 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'organitzacio del projecte actual necessita ser molt mes 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 es 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 es correcte estalvia molt de temps i esforc despres. Aixi, el pensament dels que segueixen el model de desenvolupament en cascada es que s'asseguren que cada etapa esta totalment acabada i absolutament correcte abans de seguir amb la seguent 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 es treball perdut). El disseny del programa ha de ser perfecte abans es comenci la implementacio d'aquest, ja que si s'implementa un disseny incorrecte es malgastar temps i feina, etc.

Un altre argument a favor del model de desenvolupament en cascada es que aquest posa emfasi en la documentacio (com ara els documents de requeriments o de disseny) com al mateix codi font . En metodologies menys dissenyades i documentades a consciencia, els coneixements es perden si els membres de l'equip abandonen abans d'acabar el projecte, i sol ser dificil per un projecte recuperar-se d'aquesta perdua. Si un document de disseny totalment funcional es present (com es la intencio del Big Design Up Front i el model de desenvolupament en cascada), nous membres de l'equip o fins i tot nous equips seran capacos 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'argumentacio mes disciplinada. El model de desenvolupament en cascada proporciona un enfocament estructurat; el model per si mateix progressa linealment a traves d'etapes discretes, facils d'entendre i explicables i aixi es facil d'entendre; tambe proporciona fites facilment identificables en el proces de desenvolupament. Potser es la rao per la qual el model de desenvolupament en cascada es 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 es possible que els dissenyadors siguin capacos de predir les arees problematiques del sistema i produir un disseny correcte abans de comencar la implementacio. El model de desenvolupament en cascada requereix que els implementadors segueixin el disseny complet i ben fet, assegurant-se que la integracio amb el sistema es produeix de forma suau.

La critica [ modifica ]

Els defensors de la Metodologia Agil sostenen que el model en cascada es una mala idea en la practica. Creuen que es impossible finalitzar correctament la fase de vida d'un producte programat de qualsevol projecte no trivial abans de passar a les seguents 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 revisio d'un prototip de treball i comentar sobre ell mateix. Els requisits poden canviar constantment, i els dissenyadors i programadors tenen poc control sobre aixo. Si canvien les necessitats dels clients despres que el disseny estigui finalitzat, aquest ha de ser modificat per adaptar-se a les noves exigencies. Aixo 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'aplicacio poden ser desconegudes pels dissenyadors quan es descriu un disseny per a un producte sense haber-lo aplicat previament. Es a dir, tenir previst clarament en la fase d'implementacio totes les funcionalitats del programa es extraordinariament dificil. En aquest cas, el millor es retirar el disseny i no persistir en un disseny basat en prediccions erronies que no te en compte problemes recentment descoberts.

En Code Complete (un llibre que critica l'us 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 finalitzacio. Aixo implica la impossibilitat de perfeccionar la fase de desenvolupament del programa, que no es 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) nomes son coneguts per nosaltres a mesura que avancem en l'execucio. 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 tecnic) poden no ser plenament conscients de les capacitats de la tecnologia que s'esta implementant. Aixo 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. Aixo pot provocar canvis substancials en els requisits de l'aplicacio una vegada que les parts interessades siguin mes conscients de la funcionalitat disponible en la nova tecnologia. Un exemple es quan una organitzacio migra d'un proces basat en paper a un proces electronic. Mentre que els lliuraments de treball s'han de mantenir, els beneficis de la validacio en temps real d'entrada de dades, tracabilitat, i d'enrutament, no poden ser anticipats en les primeres etapes de planificacio del projecte. Un altre exemple es el canvi dels sistemes fora de linia o autonoms a linia 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 solucio per un dissenyador amb experiencia es passar davant en el temps la refaccio per consolidar el programari, i per preparar-lo per a una possible actualitzacio, independentment de si esta planejada o no. Un altre enfocament es utilitzar una modularitat de disseny amb interficie per incrementar la flexibilitat del programari pel que fa al disseny.

A causa de les critiques esmentades anteriorment, algunes organitzacions, com ara el Departament de Defensa dels Estats Units, ara tenen una preferencia en contra de metodologies de tipus cascada, com ara la norma MIL-STD-498 "encoratjant clarament adquisicio evolutiva i IID". ^[12]

Models Modificats [ modifica ]

En resposta als problemes que s'observen en el model en cascada pur, s'han introduit molts models en cascada modificats . Aquests models poden abordar alguns o la totalitat de les critiques al model en cascada pur. Molts d'aquests models diferents estan coberts per Steve McConnell en el capitol "Lifecycle Planning" (Planificacio 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 seccio s'ocupa dels mes propers al model en cascada. Per als models en que s'apliquen altres metodes diferents al model en cascada, o per diferents models de desenvolupament cal buscar informacio general sobre el proces de desenvolupament de programari .

Controversia [ modifica ]

Encara que hi ha moltes referencies al model en cascada, i mentre moltes metodologies podrien ser qualificades com a cascada 'modificada', l'aspecte clau de la cascada es ser un proces no repetitiu. La manca de cites relacionades amb l'us real d'una cascada com a model no iteratiu han provocat moltes critiques, ^[14] entre altres, plantejar la tesi que el model en cascada en si, com a metodologia de desenvolupament no iteratiu, es de fet un mite i un argument per als dissenyadors a utilitzar metodologies de desenvolupament alternatiu.

Fases del model ^{[ cal citacio ]} [ modifica ]

Analisi 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 memoria anomenada SRD (document d'especificacio de requisits), que conte l'especificacio completa del que ha de fer el sistema sense entrar en detalls interns. Es important assenyalar que en aquesta etapa s'ha de consensuar tot el que es requereix del sistema i sera allo que seguira en les seguents etapes, no es pot requerir nous resultats a mitjan proces d'elaboracio 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 conte la descripcio de l'estructura relacional global del sistema i l'especificacio del que ha de fer cadascuna de les seves parts, aixi com la manera en que es combinen les unes amb les altres.

Es convenient distingir entre disseny d'alt nivell o arquitectonic i disseny detallat. El primer d'ells te com a objectiu definir l'estructura de la solucio (una vegada que la fase d'analisi ha descrit el problema) identificant grans moduls (conjunts de funcions que estaran associades) i les seves relacions. Amb aixo es defineix l'arquitectura de la solucio escollida. El segon defineix els algoritmes empleats i l'organitzacio del codi per comencar la implementacio.

Disseny del Programa [ modifica ]

Es la fase on es realitzen els algorismes necessaris per al compliment dels requeriments de l'usuari i tambe les analisis necessaries per saber quines eines utilitzar en l'etapa de Codificacio.

Codificacio [ modifica ]

Es la fase de programacio d'ordinadors o implementacio propiament dita. Aqui s'implementa el codi font , fent us de prototips i proves i assajos per corregir errors . Depenent del llenguatge de programacio i la seva versio es creen les biblioteques i components reutilitzables dins del mateix projecte per fer que la programacio sigui un proces molt mes rapid.

Proves [ modifica ]

Els elements, ja programats, es munten per compondre el sistema i es comprova que funciona correctament i que compleix amb els requisits.

Implantacio [ modifica ]

El programari obtingut es posa en produccio. S'implanten els nivells programari i maquinari que componen el projecte. La implantacio es la fase amb mes durada i amb mes canvis en el cicle d'elaboracio d'un projecte. Es una de les fases finals del projecte.

Durant l'explotacio del sistema de programari poden sorgir canvis, be per corregir errors o be per introduir millores. Tot aixo es recull en els Documents de Canvis.

Vegeu tambe [ modifica ]

• Enginyeria de programari
• Model V
• Metodologia agil
• Refaccio
• Interficie
• Model de desenvolupament iteratiu i incremental
• Programacio orientada a objectes
• Rapid Application Development
• Model espiral

Referencies [ modifica ]

Bibliografia [ modifica ]

A Wikimedia Commons hi ha contingut multimedia relatiu a: Model de desenvolupament en cascada

Aquest article es basa en material extret de la Free On-line Dictionary of Computing abans de l'1 de novembre de 2008 i constituida de conformitat amb els termes "relicensing" de la llicencia GFDL , la versio 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.