Modelos de Proceso o Ciclo de Vida

Para cada una las fases o etapas listadas en el tem anterior, existen sub-etapas (o
tareas). El Modelo de Proceso o Modelo de Ciclo de Vida utilizado para el desarrollo
define el orden para las tareas o actividades involucradas, tambin definen la
coordinaci!n entre ellas, enlace " realimentaci!n entre las mencionadas etapas. Entre
los m#s conocidos se puede mencionar$ Modelo en Cascada o secuencial, Modelo
Espiral, Modelo %terativo %ncremental. &e los antedic'os 'a" a su vez al(unas
variantes o alternativas, m#s o menos atractivas se()n sea la aplicaci!n re*uerida "
sus re*uisitos.
Modelo Cascada
Este, aun*ue es m#s com)nmente conocido como Modelo en cascada es tambin
llamado +Modelo Cl#sico+, +Modelo ,radicional+ o +Modelo -ineal .ecuencial+.
El Modelo en cascada puro difcilmente se utilice tal cual, pues esto implicara un
previo " absoluto conocimiento de los re*uisitos, la no volatilidad de los mismos (o
ri(idez) " etapas subsi(uientes libres de errores/ ello s!lo podra ser aplicable a
escasos " pe*ue0os desarrollos de sistemas. En estas circunstancias, el paso de una
etapa a otra de las mencionadas sera sin retorno, por e1emplo pasar del &ise0o a la
Codificaci!n implicara un dise0o exacto " sin errores ni probable modificaci!n o
evoluci!n$ +codifi*ue lo dise0ado *ue no 'abr#n en absoluto variantes ni errores+. Esto
es ut!pico/ "a *ue intrnsecamente el soft2are es de car#cter evolutivo, cambiante "
difcilmente libre de errores, tanto durante su desarrollo como durante su vida
operativa.
3i(. 4 - Modelo Cascada Puro o .ecuencial para el Ciclo de Vida del .oft2are
5l()n cambio durante la e1ecuci!n de una cual*uiera de las etapas en este modelo
secuencial implicara reiniciar desde el principio todo el ciclo completo, lo cual
redundara en altos costos de tiempo " desarrollo. -a fi(ura 4 muestra un posible
es*uema de el modelo en cuesti!n.
.in embar(o, el modelo cascada en algunas de sus variantes es uno de los
actualmente ms utilizados, por su eficacia " simplicidad, m#s *ue nada en soft2are
de pe*ue0o " al(unos de mediano porte/ pero nunca (o mu" rara vez) se lo usa en su
forma pura, como se di1o anteriormente. En lu(ar de ello, siempre se produce al(una
realimentaci!n entre etapas, *ue no es completamente predecible ni r(ida/ esto da
oportunidad al desarrollo de productos soft2are en los cuales 'a" ciertas incertezas,
cambios o evoluciones durante el ciclo de vida. 5s por e1emplo, una vez capturados
(elicitados) " especificados los re*uisitos (primera etapa) se puede pasar al dise0o del
sistema, pero durante esta )ltima fase lo m#s probable es *ue se deban realizar
a1ustes en los re*uisitos (aun*ue sean mnimos), "a sea por fallas detectadas,
ambi(6edades o bien por *ue los propios re*uisitos 'an cambiado o evolucionado/ con
lo cual se debe retornar a la primera o previa etapa, 'acer los pertinentes rea1ustes
" lue(o continuar nuevamente con el dise0o/ esto )ltimo se conoce como
realimentaci!n. -o normal en el modelo cascada ser# entonces la aplicaci!n del
mismo con sus etapas realimentadas de al(una forma, permitiendo retroceder de una
a la anterior (e incluso poder saltar a varias anteriores) si es re*uerido.
&e esta manera se obtiene un +Modelo Cascada Realimentado+, *ue puede ser
es*uematizado como lo ilustra la fi(ura 7.
3i(. 7 - Modelo Cascada 8ealimentado para el Ciclo de Vida
-o dic'o es, a (randes ras(os, la forma " utilizaci!n de este modelo, uno de los m#s
usados " populares. El modelo Cascada 8ealimentado resulta mu" atractivo, 'asta
ideal, si el pro"ecto presenta alta ri(idz (pocos o nin()n cambio, no evolutivo), los
re*uisitos son mu" claros " est#n correctamente especificados.
9a" m#s variantes similares al modelo$ refino de etapas (m#s estapas, menores " m#s
especficas) e incluso mostrar menos etapas de las indicadas, aun*ue en tal caso la
faltante estar# dentro de al(una otra. El orden de esas fases indicadas en el tem
previo es el l!(ico " adecuado, pero advirtase, como se di1o, *ue normalmente 'abr#
realimentaci!n 'acia atr#s.
El modelo lineal o en Cascada es el paradi(ma m#s anti(uo " extensamente utilizado,
sin embar(o las crticas a l ( ver desventa1as) 'an puesto en duda su eficacia. Pese a
todo tiene un lu(ar mu" importante en la %n(eniera de soft2are " contina siendo el
ms utilizado/ " siempre es me1or *ue un enfo*ue al azar.
Desventajas del Modelo Cascada:
-os cambios introducidos durante el desarrollo pueden confundir al e*uipo
profesional en las etapas tempranas del pro"ecto. .i los cambios se producen
en etapa madura (codificaci!n o prueba) pueden ser catastr!ficos para un
pro"ecto (rande.
:o es frecuente *ue el cliente o usuario final explicite clara " completamente
los re*uisitos (etapa de inicio)/ " el modelo lineal lo re*uiere. -a incertidumbre
natural en los comienzos es lue(o difcil de acomodar.
El cliente debe tener paciencia "a *ue el soft2are no estar# disponible 'asta
mu" avanzado el pro"ecto. ;n error detectado por el cliente (en fase de
operaci!n) puede ser desastroso, implicando reinicio del pro"ecto con altos
costos.
Modelos volutivos
El soft2are evoluciona con el tiempo. -os re*uisitos del usuario " del producto suelen
cambiar conforme se desarrolla el mismo. -as fec'as de mercado " la competencia
'acen *ue no sea posible esperar a poner en el mercado un producto absolutamente
completo, por lo *ue se debe introducir una versi!n funcional limitada de al(una forma
para aliviar las presiones competitivas.
En esas u otras situaciones similares los desarrolladores necesitan modelos de
pro(reso *ue estn dise0ados para acomodarse a una evoluci!n temporal o
pro(resiva, donde los re*uisitos centrales son conocidos de antemano, aun*ue no
estn bien definidos a nivel detalle.
En el modelo Cascada " Cascada 8ealimentado no se tiene en cuenta la naturaleza
evolutiva del soft2are, se plantea como est#tico con re*uisitos bien conocidos "
definidos desde el inicio.
-os evolutivos son modelos iterativos, permiten desarrollar versiones cada vez m#s
completas " comple1as, 'asta lle(ar al ob1etivo final deseado/ incluso evolucionar m#s
all#, durante la fase de operaci!n.
-os modelos <%terativo %ncremental= " <Espiral= (entre otros) son dos de los m#s
conocidos " utilizados del tipo evolutivo.
Modelo !terativo !ncremental
En trminos (enerales, podemos distin(uir, en la fi(ura >, los pasos (enerales *ue
si(ue el proceso de desarrollo de un producto soft2are. En el modelo de ciclo de vida
seleccionado, se identifican claramente dic'os pasos. -a &escripci!n del .istema es
esencial para especificar " confeccionar los distintos incrementos 'asta lle(ar al
Producto (lobal " final. -as actividades concurrentes (Especificaci!n, &esarrollo "
Validaci!n) sintetizan el desarrollo pormenorizado de los incrementos, *ue se 'ar#
posteriormente.
3i(. > - &ia(rama (enrico del &esarrollo Evolutivo %ncremental
El dia(rama > nos muestra en forma mu" es*uem#tica, el funcionamiento de un Ciclo
%terativo %ncremental, el cual permite la entre(a de versiones parciales a medida *ue
se va constru"endo el producto final. Es decir, a medida *ue cada incremento definido
lle(a a su etapa de operaci!n " mantenimiento. Cada versi!n emitida incorpora a los
anteriores incrementos las funcionalidades " re*uisitos *ue fueron analizados como
necesarios.
El Incremental es un modelo de tipo evolutivo que est basado en varios ciclos
Cascada realimentados aplicados repetidamente, con una filosofa iterativa.
En la fi(ura ? se muestra un refino del dia(rama previo, ba1o un es*uema temporal,
para obtener finalmente el es*uema del Modelo de ciclo de vida %terativo %ncremental,
con sus actividades (enricas asociadas. 5*u se observa claramente cada ciclo
cascada *ue es aplicado para la obtenci!n de un incremento/ estos )ltimos se van
inte(rando para obtener el producto final completo. Cada incremento es un ciclo
Cascada 8ealimentado, aun*ue, por simplicidad, en la fi(ura ? se muestra como
secuencial puro.
3i(. ? - Modelo %terativo %ncremental para el ciclo de vida del soft2are
.e observa *ue existen actividades de desarrollo (para cada incremento) *ue son
realizadas en paralelo o concurrentemente, as por e1emplo, en la fi(ura, mientras se
realiza el dise0o detalle del primer incremento "a se est# realizando en an#lisis del
se(undo. -a fi(ura ? es s!lo es*uem#tica, un incremento no necesariamente se
iniciar# durante la fase de dise0o del anterior, puede ser posterior (incluso antes), en
cual*uier tiempo de la etapa previa. Cada incremento conclu"e con la actividad de
<@peraci!n " Mantenimiento= (indicada +@peraci!n+ en la fi(ura), *ue es donde se
produce la entre(a del producto parcial al cliente. El momento de inicio de cada
incremento es dependiente de varios factores$ tipo de sistema/ independencia o
dependencia entre incrementos (dos de ellos totalmente independientes pueden ser
f#cilmente iniciados al mismo tiempo si se dispone de personal suficiente)/ capacidad "
cantidad de profesionales involucrados en el desarrollo/ etc.
Aa1o este modelo se entre(a soft2are <por partes funcionales m#s pe*ue0as= , pero
reutilizables, llamadas incrementos. En (eneral cada incremento se constru"e sobre
a*uel *ue "a fue entre(ado.
Como se muestra en la fi(ura ?, se aplican secuencias Cascada en forma escalonada,
mientras pro(resa el tiempo calendario. Cada secuencia lineal o Cascada produce un
incremento " a menudo el primer incremento es un sistema b#sico, con muc'as
funciones suplementarias (conocidas o no) sin entre(ar.
El cliente utiliza inicialmente ese sistema b#sico intertanto, el resultado de su uso "
evaluaci!n puede aportar al plan para el desarrollo delBlos si(uientes incrementos (o
versiones). 5dem#s tambin aportan a ese plan otros factores, como lo es la
priorizaci!n (ma"or o menor ur(encia en la necesidad de cada incremento) " la
dependencia entre incrementos (o independencia).
-ue(o de cada inte(raci!n se entre(a un producto con ma"or funcionalidad *ue el
previo. El proceso se repite 'asta alcanzar el soft2are final completo.
.iendo iterativo, con el modelo Incremental se entrega un producto parcial pero
completamente operacional en cada incremento, " no una parte *ue sea usada para
rea1ustar los re*uerimientos (como si ocurre en el Modelo de Construcci!n de
Prototipos).
El enfo*ue %ncremental resulta mu" )til con ba1a dotaci!n de personal para el
desarrollo/ tambin si no 'a" disponible fec'a lmite del pro"ecto por lo *ue se
entre(an versiones incompletas pero *ue proporcionan al usuario funcionalidad b#sica
(" cada vez ma"or). ,ambin es un modelo )til a los fines de evaluaci!n.
:ota$ Puede ser considerado " )til, en cual*uier momento o incremento incorporar
temporalmente el paradi(ma MCP como complemento, teniendo as una mixtura de
modelos *ue me1oran el es*uema " desarrollo (eneral.
jemplo$
;n procesador de texto *ue sea desarrollado ba1o el paradi(ma %ncremental
podra aportar, en principio, funciones b#sicas de edici!n de arc'ivos "
producci!n de documentos (al(o como un editor simple). En un se(undo
incremento se le podra a(re(ar edici!n m#s sofisticada, " de (eneraci!n "
mezcla de documentos. En un tercer incremento podra considerarse el
a(re(ado de funciones de correcci!n orto(r#fica, es*uemas de pa(inado "
plantillas/ en un cuarto capacidades de dibu1o propias " ecuaciones
matem#ticas. 5s sucesivamente 'asta lle(ar al procesador final re*uerido. 5s,
el producto va creciendo, acerc#ndose a su meta final, pero desde la entre(a
del primer incremento "a es )til " funcional para el cliente, el cual observa una
respuesta r#pida en cuanto a entre(a temprana/ sin notar *ue la fec'a lmite
del pro"ecto puede no estar acotada ni tan definida, lo *ue da mar(en de
operaci!n " alivia presiones al e*uipo de desarrollo.
Como se di1o, el %terativo %ncremental es un modelo del tipo evolutivo, es decir donde
se permiten " esperan probables cambios en los re*uisitos en tiempo de desarrollo/ se
admite cierto mar(en para *ue el soft2are pueda evolucionar. 5plicable cuando los
re*uisitos son medianamente bien conocidos pero no son completamente est#ticos "
definidos, cuesti!n esa *ue si es indispensable para poder utilizar un modelo Cascada.
El modelo es aconse1able para el desarrollo de soft2are en el cual se observe, en su
etapa inicial de an#lisis, *ue posee #reas bastante bien definidas a cubrir, con
suficiente independencia como para ser desarrolladas en etapas sucesivas. ,ales
#reas a cubrir suelen tener distintos (rados de apremio por lo cual las mismas se
deben priorizar en un an#lisis previo, es decir, definir cual ser# la primera, la se(unda,
" as sucesivamente/ esto se conoce como <definici!n de los incrementos= en base a
priorizaci!n. Pueden no existir prioridades funcionales por parte del cliente, pero el
desarrollador debe fi1arlas de todos modos " con al()n criterio, "a *ue en base a ellas
se desarrollar#n " entre(ar#n los distintos incrementos.
El 'ec'o de *ue existan incrementos funcionales del soft2are lleva inmediatamente a
pensar en un es"uema de desarrollo modular, por tanto este modelo facilita tal
paradi(ma de dise0o.
En resumen, un modelo %ncremental lleva a pensar en un desarrollo modular, con
entre(as parciales del producto soft2are denominados <incrementos= del sistema, *ue
son esco(idos en base a prioridades predefinidas de al()n modo. El modelo permite
una implementaci!n con refinamientos sucesivos (ampliaci!n "Bo me1ora). Con cada
incremento se a(re(a nueva funcionalidad o se cubren nuevos re*uisitos o bien se
me1ora la versi!n previamente implementada del producto soft2are.
Este modelo brinda cierta flexibilidad para *ue durante el desarrollo se inclu"an
cambios en los re*uisitos por parte del usuario, un cambio de re*uisitos propuesto "
aprobado puede analizarse e implementarse como un nuevo incremento o,
eventualmente, podr# constituir una me1oraBadecuaci!n de uno "a planeado. 5un*ue
si se produce un cambio de re*uisitos por parte del cliente *ue afecte incrementos
previos "a terminados (detecci!nBincorporaci!n tarda) se debe evaluar la factibilidad y
realizar un acuerdo con el cliente, ya que puede impactar fuertemente en los costos.
-a selecci!n de este modelo permite realizar entregas funcionales tempranas al
cliente (lo cual es beneficioso tanto para l como para el (rupo de desarrollo). .e
priorizan las entre(as de a*uellos m!dulos o incrementos en *ue sur1a la necesidad
operativa de 'acerlo, por e1emplo para car(as previas de informaci!n, indispensable
para los incrementos si(uientes.
El modelo %terativo %ncremental no obli(a a especificar con precisi!n " detalle
absolutamente todo lo *ue el sistema debe 'acer, (" c!mo), antes de ser construido
(como el caso del cascada, con re*uisitos con(elados). .!lo se 'ace en el incremento
en desarrollo. Esto torna m#s mane1able el proceso " reduce el impacto en los costos.
Esto es as, por*ue en caso de alterar o re'acer los re*uisitos, solo afecta una parte
del sistema. 5un*ue, l!(icamente, esta situaci!n se a(rava si se presenta en estado
avanzado, es decir en los )ltimos incrementos. En definitiva, el modelo facilita la
incorporacin de nuevos requisitos durante el desarrollo.
Con un paradi(ma %ncremental se reduce el tiempo de desarrollo inicial, "a *ue se
implementa funcionalidad parcial. ,ambin provee un impacto venta1oso frente al
cliente, *ue es la entre(a temprana de partes operativas del soft2are.
El modelo proporciona todas las ventajas del modelo en cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento.
El modelo %ncremental no es recomendable para casos de sistemas de tiempo real,
de alto nivel de se(uridad, de procesamiento distribuido, "Bo de alto ndice de ries(os.
Modelo spiral #editar$
El Modelo Espiral fue propuesto inicialmente por Aarr" Aoe'm. Es un modelo evolutivo
*ue con1u(a la naturaleza iterativa del modelo MCP con los aspectos controlados "
sistem#ticos del Modelo Cascada. Proporciona potencial para desarrollo r#pido de
versiones incrementales. En el modelo Espiral el soft2are se constru"e en una serie
de versiones incrementales. En las primeras iteraciones la versi!n incremental podra
ser un modelo en papel o bien un prototipo. En las )ltimas iteraciones se producen
versiones cada vez m#s completas del sistema dise0ado
El modelo se divide en un n)mero de 5ctividades de marco de traba1o, llamadas
+regiones de tareas+. En (eneral existen entre tres " seis re(iones de tareas ('a"
variantes del modelo). En la fi(ura C se muestra el es*uema de un Modelo Espiral con
C re(iones. En este caso se explica una variante del modelo ori(inal de Aoe'm,
expuesto en su tratado de DEFF/ en DEEF expuso un tratado m#s reciente.
3i(. C - Modelo Espiral para el ciclo de vida del soft2are
-as re(iones definidas en el modelo de la fi(ura son$
8e(i!n D - ,areas re*ueridas para establecer la comunicaci!n entre el cliente "
el desarrollador.
8e(i!n 4 - ,areas in'erentes a la definici!n de los recursos, tiempo " otra
informaci!n relacionada con el pro"ecto.
8e(i!n 7 - ,areas necesarias para evaluar los ries(os tcnicos " de (esti!n del
pro"ecto.
8e(i!n > - ,areas para construir una o m#s representaciones de la aplicaci!n
soft2are.
8e(i!n ? - ,areas para construir la aplicaci!n, instalarla, probarla "
proporcionar soporte al usuario o cliente (E1. documentaci!n " pr#ctica).
8e(i!n C - ,areas para obtener la reacci!n del cliente, se()n la evaluaci!n de
lo creado e instalado en los ciclos anteriores.
-as ctividades enunciadas para el marco de trabajo son generales y se aplican a
cualquier proyecto, (rande, mediano o pe*ue0o, comple1o o no. -as re(iones *ue
definen esas actividades comprenden un +con1unto de tareas+ del traba1o$ ese con1unto
si se debe adaptar a las caractersticas del pro"ecto en particular a emprender. :!tese
*ue lo listado en los tems de D a C son con1untos de tareas, al(unas de las ellas
normalmente dependen del pro"ecto o desarrollo en si.
Pro"ectos pe*ue0os re*uieren ba1a cantidad de tareas " tambin de formalidad. En
pro"ectos ma"ores o crticos cada re(i!n de tareas contiene labores de m#s alto nivel
de formalidad. En cual*uier caso se aplican actividades de protecci!n (por e1emplo,
(esti!n de confi(uraci!n del soft2are, (aranta de calidad, etc.).
5l inicio del ciclo, o proceso evolutivo, el e*uipo de in(eniera (ira alrededor del espiral
(metaf!ricamente 'ablando) comenzando por el centro (marcado con en la fi(ura C)
" en el sentido indicado/ el primer circuito de la espiral puede producir el desarrollo de
una especificaci!n del producto/ los pasos si(uientes podran (enerar un prototipo "
pro(resivamente versiones m#s sofisticadas del soft2are.
Cada paso por la re(i!n de planificaci!n provoca a1ustes en el plan del pro"ecto/ el
coste " planificaci!n se realimentan en funci!n de la evaluaci!n del cliente. El (estor
de pro"ectos debe a1ustar el n)mero de iteraciones re*ueridas para completar el
desarrollo.
El modelo espiral puede ir adapt#ndose " aplicarse a lo lar(o de todo el ciclo de vida
del soft2are (en el modelo cl#sico, o cascada, el proceso termina a la entre(a del
soft2are).
;na visi!n alternativa del modelo puede observarse examinando el +e1e de punto de
entrada de pro"ectos+. Cada uno de los circulitos () fi1ados a lo lar(o del e1e
representan puntos de arran*ue de los distintos pro"ectos (relacionados)/ a saber$
;n pro"ecto de +&esarrollo de Conceptos+ comienza al inicio de la espiral, 'ace
m)ltiples iteraciones 'asta *ue se completa, es la zona marcada con verde.
.i lo anterior se va a desarrollar como producto real, se inicia otro pro"ecto$
+&esarrollo de nuevo Producto+. Gue evolucionar# con iteraciones 'asta
culminar/ es la zona marcada en color azul.
Eventual " an#lo(amente se (enerar#n pro"ectos de +Me1oras de Productos+ "
de +Mantenimiento de productos+, con las iteraciones necesarias en cada #rea
(zonas ro1a " (ris, respectivamente).
Cuando la espiral se caracteriza de esta forma, est# operativa %asta "ue el soft&are
se retira, eventualmente puede estar inactivo (el proceso), pero cuando se produce un
cambio el proceso arranca nuevamente en el punto de entrada apropiado (por
e1emplo, en +Me1ora del Producto+).
El modelo espiral da un enfo*ue realista, *ue evoluciona i(ual *ue el soft2are/ se
adapta mu" bien para desarrollos a (ran escala.
El Espiral utiliza el MCP para reducir ries(os " permite aplicarlo en cual*uier etapa de
la evoluci!n. Mantiene el enfo*ue cl#sico (cascada) pero incorpora un marco de
traba1o iterativo *ue refle1a me1or la realidad.
Este modelo requiere considerar riesgos t!cnicos en todas las etapas del pro"ecto/
aplicado adecuadamente debe reducirlos antes de *ue sean un verdadero problema.
El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de
.istemas @perativos (comple1os)/ tambin en sistemas de altos ries(os o crticos (E1.
nave(adores " controladores aeron#uticos) " en todos a*uellos en *ue sea necesaria
una fuerte (esti!n del pro"ecto " sus ries(os, tcnicos o de (esti!n.
Desventajas importantes$
8e*uiere muc'a experiencia " 'abilidad para la evaluaci!n de los ries(os, lo
cual es re*uisito para el xito del pro"ecto.
Es difcil convencer a los (randes clientes *ue se podr# controlar este enfo*ue
evolutivo.
Este modelo no se 'a usado tanto, como el Cascada (%ncremental) o MCP, por lo *ue
no se tiene bien medida su eficacia, es un paradi(ma relativamente nuevo " difcil de
implementar " controlar.
Modelo spiral 'in ( 'in
;na variante interesante del Modelo Espiral previamente visto (3i(. C) es el +Modelo
Espiral Hin-Hin+ (Aarr" Aoe'm). El Modelo Espiral previo (cl#sico) su(iere la
comunicaci!n con el cliente para fi1ar los re*uisitos, en *ue simplemente se pre(unta
al cliente *u necesita " l proporciona la informaci!n para continuar/ pero esto es en
un contexto ideal *ue rara vez ocurre. :ormalmente cliente " desarrollador entran en
una ne(ociaci!n, se ne(ocia coste frente a funcionalidad, rendimiento, calidad, etc.
"Es as que la obtencin de requisitos requiere una negociacin, que tiene !#ito
cuando ambas partes ganan".
-as me1ores ne(ociaciones se fuerzan en obtener +Victoria I Victoria+ (Hin I Hin), es
decir *ue el cliente (ane obteniendo el producto *ue lo satisfa(a, " el desarrollador
tambin (ane consi(uiendo presupuesto " fec'a de entre(a realista. Evidentemente,
este modelo re*uiere fuertes 'abilidades de ne(ociaci!n.
El modelo Hin-Hin define un con1unto de actividades de ne(ociaci!n al principio de
cada paso alrededor de la espiral/ se definen las si(uientes actividades$
D - %dentificaci!n del sistema o subsistemas clave de los directivos(J) (saber
*u *uieren).
4 - &eterminaci!n de +condiciones de victoria+ de los directivos (saber *u
necesitan " los satisface)
7 - :e(ociaci!n de las condiciones +victoria+ de los directivos para obtener
condiciones +Victoria I Victoria+ (ne(ociar para *ue ambos (anen).
(J) &irectivo$ Cliente esco(ido con inters directo en el producto, *ue puede ser
premiado por la or(anizaci!n si tiene xito o criticado si no.
El modelo Hin I Hin 'ace nfasis en la ne(ociaci!n inicial, tambin introduce 7 'itos
en el proceso llamados +puntos de fi1aci!n+, *ue a"udan a establecer la completitud de
un ciclo de la espiral, " proporcionan 'itos de decisi!n antes de continuar el pro"ecto
de desarrollo del soft2are.