Model espiral

El desenvolupament en espiral és un model de cicle de vida del programari definit per primera vegada per Barry Boehm el 1988, i utilitzat generalment en l'enginyeria de programari. Les activitats d'aquest model es conformen en una espiral, en la qual cada bucle o iteració representa un conjunt d'activitats. Les activitats no estan fixades a priori, sinó que les següents es trien en funció de l'anàlisi de risc, començant pel bucle interior.

Introducció

L'enginyeria de programari, es val i estableix a partir d'una sèrie de models que estableixen i mostren les diferents etapes i estats pel que passa un producte software, des de la seva concepció inicial, passant pel seu desenvolupament, posada en marxa i posterior manteniment, fins a la retirada del producte. A aquests models se'ls anomena models de cicle de vida del programari. El primer model concebut va ser el de Royce, més comunament conegut com a desenvolupament en cascada o desenvolupament lineal seqüencial. Aquest model estableix que les diverses activitats que es van realitzant en desenvolupar un producte programari se succeeixen de manera lineal.

Boehm, autor de diversos articles d'enginyeria del programari; models d'estimació d'esforç i temps que es consumeix a fer productes programari; i Models de Cicle de Vida; va idear i va promulgar un model des d'un enfocament diferent al tradicional en cascada: El Model Evolutiu Espiral. El seu Model de Cicle de Vida en Espiral té en compte fortament el risc que apareix a l'hora de desenvolupar programari. Per a això, es comença mirant les possibles alternatives de desenvolupament, s'opta per la de risc més assumible i es fa un cicle de l'espiral. Si el client vol seguir fent millores en el programari, es torna a avaluar les diferents noves alternatives i riscos i es realitza una altra volta de l'espiral, així fins que arribi un moment en què el producte programari desenvolupat sigui acceptat i no necessiti seguir millorant amb un altre nou cicle.

Aquest model va ser proposat per Boehm el 1986 en el seu article "A Espiral Model of Software Development and Enhancement". El 1988, Boehm va publicar un article similar destinat a una audiència més amplia. Bàsicament consisteix en una sèrie de cicles que es repeteixen en forma d'espiral, començant des del centre. Se sol interpretar com que dins de cada cicle de l'espiral se segueix un model Cascada, però no necessàriament ha de ser així. L'Espiral es pot veure com un model evolutiu que conjuga la naturalesa iterativa del model MCP amb els aspectes controlats i sistemàtics del Model Cascada, amb l'agregat de gestió de risc.

Cicles o Iteracions

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Model espiral

En cada volta o iteració s'ha de tenir en compte el següent:

Els Objectius: quina necessitat ha de garantir el producte.
Alternatives: les diferents formes d'aconseguir els objectius de forma satisfactòria, des de diferents punts de vista com poden ser els següents:
# Característiques: experiència del personal, requisits que s'han de cumplir, etc.
# Formes de gestió del sistema.
# Risc que s'assumeix amb cada alternativa.
Desenvolupar i Verificar: programar i testejar el software.

Si el resultat no és l'adequat o es necessita implementar millores o funcionalitats:

Es planificaran els següents passos i es comença un nou cicle de l'espiral. L'espiral té una forma de cargol de mar i es diu que manté dues dimensions, la radial i l'angular:
# Angular: Indica l'avanç del projecte del programari dins d'un cicle.
# Radial: Indica l'augment del cost del projecte, ja que amb cada nova iteració es passa més temps desenvolupant.

Aquest sistema és molt utilitzat en projectes grans i complexos com pot ser, per exemple, la creació d'un Sistema Operatiu.

Com que és un model de Cicle de Vida orientat a la gestió de risc es diu que un dels aspectes fonamentals del seu èxit rau en el fet que l'equip que l'apliqui tingui la necessària experiència i habilitat per detectar i catalogar correctament els riscos.

Tasques

Per cada cicle hi haurà quatre activitats:

Determinar objectius.
Anàlisi del risc.
Desenvolupar i testejar.
"Planificació".

Determinar o fixar objectius

Fixar també els productes definits a obtenir: requisits, especificació, manual d'usuari.
Fixar les restriccions.
Identificació de riscos del projecte i estratègies alternatives per evitar-los.
Hi ha una cosa que només es fa una vegada: planificació inicial.

Desenvolupar, verificar i validar (testejar)

Tasques de l'activitat pròpia i de prova.
Anàlisi d'alternatives i identificació resolució de riscos.
Depenent del resultat de l'avaluació dels riscos, es tria un model per al desenvolupament, podent ser qualsevol dels altres existents, com formal, evolutiu, cascada, etc. Així si per exemple si els riscos en la interfície d'usuari són dominants, un model de desenvolupament apropiat podria ser la construcció de prototips evolutius. Si els riscos de protecció són la principal consideració, un desenvolupament basat en transformacions formals podria ser el més apropiat.

Anàlisi del risc

Es porta a terme l'estudi de les causes de les possibles amenaces i probables esdeveniments no desitjats i els danys i conseqüències que aquestes puguin produir. S'avaluen alternatives. S'ha de tenir un prototip abans de començar a desenvolupar i provar.

En resum, és per tenir en compte dels riscos de cadascun dels àmbits.

Mecanismes de control

La dimensió radial mesura el cost.
La dimensió angular mesura el grau d'avenç del projecte.

Variacions del Model Espiral

Model espiral típic de sis regions

El model espiral pot adaptar-se i aplicar-se al llarg de la vida del software, a diferència del model de procés clàssic que s'acaba quan s'entrega el software.

Les 6 regions que componen aquest model són les següents:

Comunicació amb el client. - Tasques necessàries per a plantejar la comunicació entre el desenvolupador i el client.
Planificació. - Tasques inherents a la definició de recursos, el temps i altres informacions relacionades amb el projecte. Són tots els requisits.
Anàlisi de riscos. - Tasques per a avaluar els riscos tècnics i altres informacions relacionades amb el projecte.
Enginyeria. - Tasques per a construir una o més representacions de l'aplicació.
Construcció i adaptació. - Tasques necessàries per a construir, provar, instal·lar i proporcionar suport als usuaris.
Avaluació del client. - Tasques necessàries per a obtenir la reacció del client segons l'avaluació de les representacions del software creades durant l'etapa d'enginyeria i implementació durant l'etapa d'instal·lació.

Model espiral WIN-WIN

El model Win-Win és una adaptació del model espiral que s'emfatitza en la participació del client en el procés de desenvolupament d'un producte de software. En un cas ideal, el desenvolupador simplement pregunta al client el que es requereix i el client proporciona suficient informació i detalls per a procedir. No obstant, això no sol ocórrer en la majoria de casos i és necessari que s'estableixin negociacions significatives entre ambdues parts per a equilibrar la funcionalitat i rendiment amb els costos i temps de sortida al mercat del producte. El model Win-Win deriva el seu nom de l'objectiu d'aquestes negociacions, és a dir, "guanyar-guanyar". El client rep el producte que satisfà la majoria de les seves necessitats, i el desenvolupador treballa per a assolir pressupostos i dates d'entrega. Per a aconseguir aquest objectiu, es realitzen diverses activitats de negociació al principi de cada pas a cada volta de l'espiral.

Avantatges

L'anàlisi de risc es fa de manera explícita i amb claredat. Uneix els millors elements dels models restants.

Redueix riscos del projecte.
Incorpora objectius de qualitat.
Integra el desenvolupament amb manteniment, etc.

A més és possible tenir en compte millores i nous requeriments sense trencar amb la metodologia, ja que aquest cicle de vida no és rígid ni estàtic.

Desavantatges

Genera molt temps en el desenvolupament del sistema.
Model costós.
Requereix experiència en la identificació de riscos.

Inconvenients

Planificar un projecte amb aquesta metodologia és sovint impossible a causa de la incertesa en el nombre d'iteracions que seran necessàries. En aquest context l'avaluació de riscos és de la major importància i, per a grans projectes, aquesta avaluació requereix la intervenció de professionals de gran experiència.

L'IEEE classifica el model espiral com a model no operatiu en les seves classificacions de MCV.

Vegeu també

Enllaços externs

A Spiral Model of Software Development and Enhancement article original de Barry Boehm en el qual proposava el model de desenvolupament en espiral (en anglès).