PORQU LA TEORA ES INSUFICIENTE

La prctica del zazn es la expresin directa de nuestra

verdadera naturaleza. Estrictamente hablando, para un ser
humano no hay otra prctica ms que sta. No hay otra orma
de vida ms que sta.!
"hunryu "uzu#i, $ente %ez, $ente de &rincipiante
En el captulo anterior ya se esbozaron varias ideas asociadas al porqu la teora
entregada resulta insuficiente al momento de desempearse en la realidad del trabajo
cotidiano. En esta parte vamos a profundizar con un nivel mayor de detalle en esta idea.
I.1. LOS MODELOS TERICOS
Numerosas son las teoras que se pueden encontrar en la literatura especializada
respecto de cmo debiera conducirse un proyecto informtico para poder lograr los
objetivos planteados para l en el tiempo planificado.
stos modelos tericos definen fases y etapas por las que debieran atravesar los
proyectos en forma natural! teniendo cada una sus entradas y salidas.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 1 de 1
Ma!co A&#o&io Rossel
En trminos generales! es aqu donde aparece una primera falencia! propia de
cualquier modelo terico! esto es! la inlexibilidad de las componentes del modelo.
sta infle"ibilidad se presenta en la forma de frases similares a para poder
comenzar la ase n es necesario haber concluido la salida de la ase n-1, la cual es
entrada de la que si'ue!.
En el mundo real! con la enorme dinmica en la que se vive dentro de las
organizaciones! en donde las presiones de parte de las reas usuarias tanto las
comerciales como las operativas por contar con los productos comprometidos! reflejadas
en el trabajo del personal de informtica principalmente a travs de los ejecutivos del
rea! la situacin de condicionalidad e"istente entre una etapa y la anterior generada por
las interfaces entre ambas! suele ser violentada en la forma de retrasos! excepciones
#debidamente autorizadas$! o simples omisiones.
Es en este momento cuando cualquier modelo terico se ve resentido! ya que en
el estudio de los mismos es fcil percibir cmo el cumplimiento cabal de la fase &,1 es
fundamental para el "ito de la fase &! sin embargo es en su aplicacin real cuando se
percibe que tal cabalidad en el cumplimiento no es tal.
% continuacin! y como una forma de ilustrar con claridad lo e"presado en los
prrafos precedentes! se repasar uno de los ms difundidos modelos tericos para el
desarrollo de sistemas de informacin! entregando algunos puntos clave respecto del
momento en que estas teoras se rompen en aras del "ito comercial o las decisiones
basadas en la poltica interna de la organizacin.
I.-. EL MODELO CASCADA DEL DESARROLLO DEL SOFT.ARE
Este modelo! ampliamente difundido en el mbito de las tecnologas de la
informacin para el desarrollo de soft&are! permite visualizar en trminos generales y
como fases claramente diferenciadas las diferentes etapas por las que el desarrollo de un
sistema de informacin debiera ir transcurriendo en el tiempo #ver (lustracin ($.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a - de 1
Ma!co A&#o&io Rossel
)El modelo de cascada es el primero en establecer el proceso de desarrollo
como la e*ecucin de un con*unto de actividades. En su concepcin bsica, cada una de
las actividades 'eneran como salidas productos y modelos que son utilizados como
entradas para el proceso subsi'uiente. Lo cual supone que una actividad debe
terminarse (por lo menos, en algn grado) para empezar la siguiente '(E)*+,-.
% continuacin se entrega una descripcin de cada una de las etapas y los
quiebres que se producen en su aplicacin prctica.
Il%s#!aci'& 1$ El ciclo de vida cl*sico se+/& 0os1 0%a& Pa2os A!ias 3.E4,567
I.-.1. Pla&i8icaci'& del Sis#e(a
)Es la etapa en la que se determina si el proyecto es o no actible de realizar y
se determinan tiempos y costos aproximados+ '(E)*+/-.
Esta etapa considera la realizacin de estudios de costos! anlisis de
rentabilidad! tiempos de desarrollo! alcances legales! etc.! todo lo cual indica que debiera
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 9 de 1
Ma!co A&#o&io Rossel
ser una fase bastante prolongada en el tiempo y con varios recursos de distinta
naturaleza destinados a su finalizacin.
0in embargo! en la realidad genrica que se da para esta etapa encontramos dos
escenarios distintos! aunque igualmente incorrectos.
En unos casos! la &laniicacin del "istema es desarrollada por el rea de
negocios1operaciones de la organizacin interesada en conseguir el financiamiento para
desarrollar su proyecto. En otros casos! es el rea de tecnologa o informtica quien
realiza todo el trabajo por s sola.
%mbas formas de enfrentar el problema son! evidentemente! incorrectas. 2or
una parte el rea de negocios tiene como objetivo el llevar adelante su proyecto #obvio$
pero no considera factores tecnolgicos como la factibilidad! el riesgo! etc. 2or el otro
lado! el rea de informtica se va a centrar en la factibilidad tecnolgica del proyecto!
dejando! en general! de lado consideraciones de ndole comercial. En las dos situaciones
se le resta objetividad al trabajo! y se evidencian falencias de visin dadas por la
unilateralidad del estudio.
3tro factor que aflora dentro de ste tipo de evaluaciones unilaterales es el a
veces abusivo uso de estimaciones. Estas estimaciones generalmente consisten en
parmetros adecuados #4arreglados5$ para generar determinados resultados convenientes
para satisfacer! por ejemplo! una ecuacin de rentabilidad.
0i a ello sumamos que el estudio generalmente es desarrollado en un periodo
definitivamente breve para cualquier tipo de proyecto! el producto de la etapa no
cumplir con las caractersticas esperadas de dar una visin clara de la factibilidad del
proyecto.
0i bien lo anterior es una visin un tanto catastrofista del tema! es destacable
mencionar que en muc6as organizaciones se desarrollan proyectos adecuadamente
planificados y cubicados! los cuales resultan usualmente altamente e"itosos! con un
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a : de 1
Ma!co A&#o&io Rossel
elevado grado de satisfaccin por parte de todos los actores al momento de obtener el
producto final.
%6ora bien! lo anterior resulta contradictorio al comprobar que en la misma
organizacin se pueden estar desarrollando en el mismo instante otros numerosos
proyectos de la mala forma en que aqu se 6a descrito! y lo que es peor! se seguir
6aciendo. Ello a pesar de las e"periencias positivas que se tengan.
I.-.-. A&*lisis
Esta etapa e"iste porque 7es indispensable comprender perectamente los
requisitos del sot,are, para que ste no racase+ '(E)*+/-.
En esta etapa se deben capturar las necesidades de los usuarios #clientes
internos al rea de tecnolo'-a o inormtica$.
El modelo indica que a travs del seguimiento estricto de esta fase se generar
un documento maestro del sistema! en el cual estarn reflejadas a cabalidad las
necesidades de los usuarios del futuro sistema de informacin. Este documento maestro
es la entrada para la siguiente etapa! que corresponde al diseo.
Es aqu en donde surge una debilidad! y esta es asumir que los usuarios saben
e"actamente que quieren! o mejor dic6o! que tienen una idea de cmo debiera ser el
sistema que necesitan.
8os usuarios son los verdaderos e"pertos del negocio de la empresa! y son! por
lo tanto! las personas ms autorizadas para definir la forma en que el mismo debe ser
conducido de tal forma de alcanzar las metas y objetivos establecidos por la alta
administracin.
0in embargo! presumir por ello que son capaces de describir a cabalidad lo que
un sistema automtico debiera resolver no es tan e"acto.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a ; de 1
Ma!co A&#o&io Rossel
Esta es una falacia muy com9n en el mundo de la tecnologa! y surge a raz de
que las estructuras mentales de las personas que se desempean en las reas de
informtica de una organizacin #tpicamente ingenieros! tcnicos! analistas!
programadores! etc.$ versus las de personas que se desempean! por ejemplo! en el rea
comercial de un banco #ingenieros comerciales! ejecutivos de negocios! personal
administrativo! etc.$! son evidentemente distintas.
:ientras uno es eminentemente estructurado! sistemtico y abstracto #requisitos
necesarios para la construccin de sistemas de informacin y fruto de la formacin
profesional$ el otro es procedural! comunicativo e intuitivo #necesario para 6acer
negocios y fruto de su propia formacin profesional o bien de aos de e"periencia en el
desempeo de sus actividades! situacin que en muc6as ocasiones resulta ms valiosa
que la formacin acadmica$.
2ero este no es la 9nica diferencia. E"iste una clarsima diferencia de objetivos.
:ientras el primero quiere disear y construir un producto de sot,are! el segundo
necesita imperiosamente vender o resolver la necesidad de negocio especfica.
8as reas de informtica suelen mal interpretar las necesidades del usuario!
centrando las discusiones en cuadros de dilogo! tipos de letra! combinaciones de
colores! etc.! mientras ste solo necesita datos! informacin! reportes! etc.
3tro bemol de esta relacin usuario1informtico es la falta de conocimiento de
la labor del otro! situacin generada por la segregacin funcional propia de las
organizaciones modernas. El usuario tiene necesidades que le corresponde a informtica
resolver! cmo se resuelvan no es relevante para l! slo importa el tiempo que les tome
resolverlas. El informtico debe satisfacer las necesidades de sus clientes internos! pero
a diferencia del criterio del usuario! para l resulta tremendamente relevante el cmo
resolverlo! y por lo general el factor tiempo estimado para llegar al resultado va a ser
mayor al requerido por el usuario.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 6 de 1
Ma!co A&#o&io Rossel
8o ms grave es que esta desvinculacin entre las distintas funciones que
cumplen los principales actores del proceso de desarrollo! genera serios problemas de
comprensin entre los mismos.
;ados los conceptos vertidos en los prrafos precedentes! si bien no es
imposible #depender fundamentalmente del tamao del sistema en discusin! de la
cantidad de usuarios involucrados y de los montos asociados a la inversin$! es
tremendamente dificultoso llegar a una buena especificacin de requerimientos para un
sistema! especialmente si es nuevo.
:s a9n! basado en la propia e"periencia del autor! queda demostrado que una
especificacin de requerimientos completa! que logre una plena satisfaccin en trminos
de resolver el problema a cabalidad! en los plazos requeridos y con la calidad del
producto final esperada es una utopa prcticamente inalcanzable.
I.-.9. Dise<o
)El proceso de dise.o traduce los requisitos en una representacin del
sot,are que pueda ser establecida de orma que obten'a la calidad requerida antes de
que comience la codiicacin+ '(E)*+/-.
<eniendo como entrada para esta etapa una especificacin de requerimientos o
anlisis incompleto! es evidente que la salida de esta fase ser igualmente incompleta.
=omo argumento se podr esgrimir que el modelo de cascada considera
retroalimentacin entre etapas #algo as como refinamiento sucesivo$! sin embargo esta
iteracin no puede ser eterna y las condicionantes de mercado provocan cortes bruscos
de la iteracin! dejando resultados evidentemente truncos con la generalizada conviccin
de que ms adelante se arre'lar el problema #en una se'unda versin! por ejemplo$!
momento que usualmente no llega con la prontitud esperada por el usuario.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a = de 1
Ma!co A&#o&io Rossel
Entrando propiamente en lo que es el diseo! es en esta etapa en la que se debe
generar la documentacin y las definiciones necesarias para que el equipo de
codificacin construya el sistema.
8os problemas tpicos de esta etapa se basan en la costumbre! profundamente
enraizada en las organizaciones de que el mismo equipo que 6izo el diseo ser el que
continuar con la actividad de codificacin #aunque la teora recomiende lo contrario$.
=abe mencionar! eso s! que en muc6as ocasiones mas que de un problema de malas
costumbres de desarrollo se trata mas bien de una problemtica de racionalizacin de
recursos 6umanos! lo que obliga a que la misma persona o personas participen en todas
las etapas del ciclo de vida! independientemente de cual sea el modelo que se est
siguiendo.
;e esta forma! como la definicin de requerimientos tom ms tiempo del
presupuestado dado que la interaccin con los usuarios result ms compleja de lo
esperado! entonces se llega a la etapa de diseo ya con un retraso! en ocasiones bastante
considerable.
En teora ste retraso no debiera ser considerado! sino que el plan original
debiera modificarse para reflejar la nueva situacin! sin embargo! las condicionantes
propias de un entorno comercial competitivo y las consideraciones de imagen
profesional de los involucrados provoca que el plan se mantenga inalterable!
sacrificando aquello que se tiene ms a mano como intangible! esto es! la calidad del
producto inal.
0i a esto sumamos que en el diseo no intervienen terceros #est circunscrito al
rea de informtica$! la situacin se maneja de forma tal que se genera una
especificacin de diseo incompleta! sin todas las consideraciones establecidas en la ya
e"igua especificacin de requerimientos.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a > de 1
Ma!co A&#o&io Rossel
2or si lo anterior fuese poco! es ms com9n de lo que se deseara que los
informes de diseo se co&s#!%"a& ?as*&dose e& el c'di+o "a ela?o!ado o e& le&o
!oceso de ela?o!aci'&.
I.-.:. Codi8icaci'& " #es# %&i#a!io
En esta etapa la teora indica que! a partir del informe de diseo detallado #en
un formato que depender de la metodologa de diseo utilizada$! el equipo de
programadores #de preferencia distinto al anterior$ comenzar a codificar los diferentes
mdulos que a la larga constituirn el sistema.
)"i el dise.o se realiza de una manera detallada, la codiicacin puede
realizarse mecnicamente+ '(E)*+/-.
0in embargo! como fue mencionado en el punto anterior relativo al diseo! en
muc6as ocasiones esta etapa sufre un traslape con la anterior! por lo tanto! ya se parte de
una precisin errnea en la aplicacin de la metodologa terica.
No se discutir en este trabajo las consideraciones relativas a la calidad de los
productos generados a partir de un mtodo tan poco ortodo"o #aunque a la vez tan
ampliamente difundido$ de trabajar! la cual obviamente es pobre! no en trminos de que
se trate de un producto slido del punto de vista del cdigo involucrado #el cual suele ser
bueno$ sino ms bien de que 6aga lo que se espera que 6aga en la orma en que se
espera que lo 6aga! y de paso generando un producto mantenible en el tiempo en forma
independiente del equipo de trabajo que lo construy originalmente.
En esta ocasin ms bien se quiere establecer que nuevamente co&side!acio&es
a@e&as a la #eo!)a ponen en entredic6o su validez como mtodo estricto del seguimiento
de la vida de un producto de soft&are.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a A de 1
Ma!co A&#o&io Rossel
I.-.;. P!%e?a
)La prueba se centra en la l'ica interna del sot,are, ase'urando que todas
las sentencias se han probado, y en las unciones externas, realizando pruebas que
ase'uren que la entrada deinida produce los resultados que realmente se requieren+
'(E)*+/-.
Esta etapa que! a la luz del prrafo de >oger 2ressman que antecede a ste!
tiene un alto grado de criticidad en lo que debiera ser el resultado final! suele ser una
etapa de sacriicio o un comod-n en caso de tener que empatar una planificacin
retrasada.
?eamos primero en qu debiera consistir esta etapa.
@.A.B./. 8as pruebas en la teora
2rimero que nada 6ay que mencionar los tipos de prueba que se deben realizar
sobre un producto de soft&are. >evisemos los tipos de prueba de soft&are seg9n @an
0ommerville '03:*CC-.
PRUE4A DE MDULOS. esta prueba consiste en someter a distintos
escenarios #variables de entrada$ a cada una de las funciones
implementadas en cada una de las piezas de soft&are que constituyen la
aplicacin! de tal forma de verificar que cada uno de los mdulos entrega
los resultados esperados en forma aislada.
PRUE4A DE SU4SISTEMA. en esta prueba los distintos mdulos se integran
para constituir cada uno de los subsistemas del producto final. Es en esta
prueba en donde se validan las interfaces entre los distintos mdulos
construidos.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 15 de 1
Ma!co A&#o&io Rossel
PRUE4A DEL SISTEMA BINTECRACIND. en esta prueba el sistema deja de
funcionar como un conjunto aislado de mdulos para pasar a comportarse
como una pieza integral de una plataforma computacional de una
organizacin. En la antigua literatura sta prueba se restringa a reunir
todos los subsistemas componentes de la aplicacin y probarlos como un
todo! sin embargo! a partir de la problemtica del ao A+++ se aplica el
concepto de prueba de inte'racin! en donde se debe considerar la
generacin y recepcin de interfaces en tiempo real #por supuesto en un
ambiente de produccin simulado$ para verificar que el sistema no solo
opera correctamente como un todo! sino que adems no afecta a su entorno
con los resultados generados.
PRUE4A DE ACEPTACIN. si bien 0ommerville no lo menciona en forma
e"plcita! actualmente esta prueba consiste en la ve!i8icaci'& o! a!#e del
%s%a!io de que el nuevo sistema 6ace efectivamente lo que se espera que
6aga #sobre la base de la especificacin de requerimientos de la etapa de
anlisis$.
@.A.B.A. >ealidad de las pruebas
=laramente se puede concluir que una adecuada aplicacin de un plan de
pruebas sobre un nuevo producto de soft&are! en el cual se cubran todos los tipos de
prueba descritos! y en forma casi independiente de la metodologa de pruebas aplicada!
permitira la obtencin de un producto consolidado y estable en el futuro.
0in embargo la realidad de las pruebas es otra muy distinta.
2or una cuestin propia del modelo cascada que estamos analizando! las
pruebas son una etapa completa! realizada inmediatamente despus de la codificacin
del sistema. ;e ms est decir que la anterior etapa de codificacin suele sufrir
alteraciones en su planificacin! producto de numerosos factores. Entre otros est el
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 11 de 1
Ma!co A&#o&io Rossel
6ec6o indiscutible de que la complejidad de una rutina suele desconocerse 6asta el
momento mismo en que es codificada! esto sumado a los problemas con ese tope el
programador al intentar seguir un diseo poco riguroso.
Esta situacin de retraso viene a plantear una disyuntiva a la que se ven
enfrentados los tomadores de decisiones de un equipo de desarrollo. Esto es! realizar un
conjunto de pruebas riguroso sobre el sistema codificado! asumiendo ante los superiores
el retraso! o bien realizar pruebas modulares! ensamblar el sistema y entregarlo a la
produccin! dejando! la resolucin de los problemas para la etapa posterior de
mantenimiento.
<eniendo enfrente la tentacin de salir bien parado ante los superiores
mostrando diligencia en el cumplimiento de los plazos o simplemente no declarar lo que
podra ser un nuevo retraso! es altamente probable que la etapa de pruebas sirva como
c6ivo e"piatorio de los pecados de las etapas anteriores.
)/0unto cuesta no encontrar un deecto1
0ada hora que se emplea en las actividades de control de calidad, como
son las revisiones de dise.o, ahorra de 2 a 34 horas en el costo total.
5n deecto en los requerimientos que no se detecta hasta en la
construccin o el mantenimiento necesitar una correccin que costar de
64 a 744 veces ms que si se hubiera hecho en la ase de requerimientos.
8e orma ms 'eneral, un deecto que no se detecta al inicio 9durante la
ase de requerimientos o de dise.o: necesitar para su correccin de 34 a
344 veces ms esuerzo al encontrarlo al inal 9durante la prueba: de lo
que habr-a costado corre'irlo al principio. ;l detectar un error, cuanto
ms tiempo haya pasado desde el inicio, ms costar corre'irlo+. ':==*
++-
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 1- de 1
Ma!co A&#o&io Rossel
I.-.6. Ma&#e&i(ie&#o
)Los cambios ocurrirn debido a que se hayan encontrado errores, a que el
sot,are deba adaptarse a posibles cambios+ '(E)*+/-.
Esta etapa! en teora! consiste en la operacin normal del producto ya en
produccin por parte de los satisechos usuarios. %lgunos problemas menores debieran
surgir! los cuales el equipo de desarrollo debiera! en un tiempo breve! resolver para que
el producto contin9e prestando el servicio esperado.
En esta ocasin la teora previene que algunos problemas menores se 6an de
presentar en la nueva creacin informtica! principalmente fallas! producto de la
aparicin de casos no considerados en las pruebas o bien debido a que el usuario
descubre variantes en las funcionalidades implementadas que! incorporadas al producto!
podran 6acer de la labor algo muc6o mas productivo.
0i bien los considerandos son correctos! la realidad supera nuevamente a la
teora en algo bastante bsico en sistemas informticos! esto es! la dimensin del cambio
requerido.
Esto se debe entender en el conte"to del anlisis ya realizado sobre las etapas
anteriores! en donde se pueden apreciar las deficiencias de arrastre que parten desde la
planificacin inicial del sistema! en donde no 6ay un adecuado dimensionamiento del
sistema ni tampoco una evaluacin multidisciplinaria que cubra todos los aspectos
involucrados en el futuro sistema.
En definitiva! las etapas previas no 6an estado e"entas de problemas! y en
general sus productos 6an resultado truncos. Esto 6ace prcticamente imposible que el
producto final se asemeje a lo que el usuario realmente esperaba.
2or esto esta fase de operacin y mantencin! suele transformarse en una
sucesiva generacin de versiones del sistema originalmente construido! en donde! con
nuevos recursos econmicos incorporados! y nuevos plazos comprometidos
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 19 de 1
Ma!co A&#o&io Rossel
#probablemente alcanzando el mismo tiempo o menor quizs! si se 6ubiese considerado
toda la funcionalidad desde el comienzo$ se inicia un nuevo proyecto y por lo tanto un
nuevo ciclo completo de vida del sistema.
I.9. LOS PRO4LEMAS EN OTROS MODELOS DE DESARROLLO
0imilar situacin es la que se vive en los otros modelos de desarrollo de
proyectos de tecnologas de informacin.
0in entrar en mayores detalles! se 6ar una revisin somera de otros modelos
conocidos de desarrollo de proyectos.
0e 6ar una breve revisin del modelo de desarrollo incremental por prototipos
y del modelo de desarrollo en espiral.
0in embargo! cabe mencionar que e"isten numerosos modelos de desarrollo!
limitndonos para este trabajo en los tres ms difundidos.
I.9.1. Desa!!ollo i&c!e(e&#al o! !o#o#ios
Es el modelo de desarrollo incremental combinado con cascada! en donde cada
incremento tiene como resultado un prototipo! es cual es desarrollado como un ciclo de
vida #cascada$ semi*completo de un sistema.
Este esquema de desarrollo debe utilizarse en sistemas en los que no es posible
determinar inicialmente la especificacin! de esta forma la especificacin evoluciona
junto con los prototipos que se desarrollan.
8a forma de validar los prototipos es mediante las pruebas de los usuarios. %s
como los usuarios no tienen plena claridad respecto de la totalidad de sus
requerimientos! son ellos los responsables de dirigir! a travs de sus opiniones y
observaciones sobre los prototipos! la evolucin de los mismos! esto es! delinear el
siguiente incremento.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 1: de 1
Ma!co A&#o&io Rossel
Il%s#!aci'& -$ El P!o#o#iado Evol%#ivo se+/& 0os1 0%a& Pa2os A!ias 3.E4,567
I.9.-. Desa!!ollo e& esi!al
En el desarrollo en espiral! que nace como consecuencia de la unin de las
ventajas del modelo incremental con el de cascada! se establece una relacin entre cada
giro de la espiral y una fase del proceso de desarrollo.
En el primer giro se establecen los objetivos! alternativas! restricciones! etc.!
para el sistema. En el segundo giro se desarrolla la especificacin de requerimientos. En
el tercero se desarrolla el diseo. D as sucesivamente.
Es un modelo altamente aconsejable para desarrollar sistemas con un elevado
nivel de complejidad o de gran tamao. ;el mismo modo se desaconseja su uso para
sistemas pequeos.
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 1; de 1
Ma!co A&#o&io Rossel
Este es un modelo orientado al riesgo! esto es que se pretende minimizar el
riesgo en el proceso de desarrollo de productos de soft&are a travs de la generacin de
miniproyectos! en donde cada miniproyecto se centra en uno o ms riesgos 6asta que
finalmente todos se encuentran controlados.
Il%s#!aci'& 9$ Modelo e& esi!al se+/& 0os1 0%a& Pa2os A!ias 3.E4,567
El ciclo de vida de los !o"ec#os TI$ %&a visi'& e()!ica P*+i&a 16 de 1
Ma!co A&#o&io Rossel