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 forma
de vida ms que sta.
Shunryu Suzuki, Mente Zez, Mente de Principiante

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 proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 1 de 1

En trminos generales, es aqu donde aparece una primera falencia, propia de

cualquier modelo terico, esto es, la inflexibilidad de las componentes del modelo.
sta inflexibilidad se presenta en la forma de frases similares a para poder
comenzar la fase n es necesario haber concluido la salida de la fase n-1, la cual es
entrada de la que sigue.
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 existente 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 n-1 es
fundamental para el xito de la fase n, sin embargo es en su aplicacin real cuando se
percibe que tal cabalidad en el cumplimiento no es tal.
A continuacin, y como una forma de ilustrar con claridad lo expresado 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 xito comercial o las decisiones
basadas en la poltica interna de la organizacin.

I.2. EL MODELO CASCADA DEL DESARROLLO DEL SOFTWARE

Este modelo, ampliamente difundido en el mbito de las tecnologas de la
informacin para el desarrollo de software, 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 Ilustracin I).

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 2 de 1

El modelo de cascada es el primero en establecer el proceso de desarrollo

como la ejecucin de un conjunto de actividades. En su concepcin bsica, cada una de
las actividades generan como salidas productos y modelos que son utilizados como
entradas para el proceso subsiguiente. Lo cual supone que una actividad debe
terminarse (por lo menos, en algn grado) para empezar la siguiente [WEB-04].
A continuacin se entrega una descripcin de cada una de las etapas y los
quiebres que se producen en su aplicacin prctica:
Ilustracin 1: El ciclo de vida clsico segn Jos Juan Pazos Arias [WEB-06]

I.2.1. Planificacin del Sistema

Es la etapa en la que se determina si el proyecto es o no factible de realizar y
se determinan tiempos y costos aproximados [WEB-01].
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 proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 3 de 1

ser una fase bastante prolongada en el tiempo y con varios recursos de distinta
naturaleza destinados a su finalizacin.
Sin embargo, en la realidad genrica que se da para esta etapa encontramos dos
escenarios distintos, aunque igualmente incorrectos.
En unos casos, la Planificacin del Sistema es desarrollada por el rea de
negocios/operaciones 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.
Ambas formas de enfrentar el problema son, evidentemente, incorrectas. Por
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. Por 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.
Otro 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 (arreglados?) para generar determinados resultados convenientes
para satisfacer, por ejemplo, una ecuacin de rentabilidad.
Si 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.
Si bien lo anterior es una visin un tanto catastrofista del tema, es destacable
mencionar que en muchas organizaciones se desarrollan proyectos adecuadamente
planificados y cubicados, los cuales resultan usualmente altamente exitosos, con un

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 4 de 1

elevado grado de satisfaccin por parte de todos los actores al momento de obtener el
producto final.
Ahora 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 ha descrito, y lo que es peor, se seguir
haciendo. Ello a pesar de las experiencias positivas que se tengan.

I.2.2. Anlisis
Esta etapa existe porque es indispensable comprender perfectamente los
requisitos del software, para que ste no fracase [WEB-01].
En esta etapa se deben capturar las necesidades de los usuarios (clientes
internos al rea de tecnologa o informtica).
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
exactamente que quieren, o mejor dicho, que tienen una idea de cmo debiera ser el
sistema que necesitan.
Los usuarios son los verdaderos expertos 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.
Sin embargo, presumir por ello que son capaces de describir a cabalidad lo que
un sistema automtico debiera resolver no es tan exacto.

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 5 de 1

Esta es una falacia muy comn 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.
Mientras 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 hacer
negocios y fruto de su propia formacin profesional o bien de aos de experiencia en el
desempeo de sus actividades, situacin que en muchas ocasiones resulta ms valiosa
que la formacin acadmica).
Pero este no es la nica diferencia. Existe una clarsima diferencia de objetivos.
Mientras el primero quiere disear y construir un producto de software, el segundo
necesita imperiosamente vender o resolver la necesidad de negocio especfica.
Las 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.
Otro bemol de esta relacin usuario/informtico 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 proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 6 de 1

Lo 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.
Dados 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.
Ms an, basado en la propia experiencia 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.2.3. Diseo
El proceso de diseo traduce los requisitos en una representacin del software
que pueda ser establecida de forma que obtenga la calidad requerida antes de que
comience la codificacin [WEB-01].
Teniendo como entrada para esta etapa una especificacin de requerimientos o
anlisis incompleto, es evidente que la salida de esta fase ser igualmente incompleta.
Como 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 arreglar el problema (en una segunda versin, por ejemplo),
momento que usualmente no llega con la prontitud esperada por el usuario.

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 7 de 1

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.
Los problemas tpicos de esta etapa se basan en la costumbre, profundamente
enraizada en las organizaciones de que el mismo equipo que hizo el diseo ser el que
continuar con la actividad de codificacin (aunque la teora recomiende lo contrario).
Cabe mencionar, eso s, que en muchas ocasiones mas que de un problema de malas
costumbres de desarrollo se trata mas bien de una problemtica de racionalizacin de
recursos humanos, 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.
De 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 final.
Si 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
exigua especificacin de requerimientos.

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 8 de 1

Por si lo anterior fuese poco, es ms comn de lo que se deseara que los

informes de diseo se construyan basndose en el cdigo ya elaborado o en pleno
proceso de elaboracin.

I.2.4. Codificacin y test unitario

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.
Si el diseo se realiza de una manera detallada, la codificacin puede
realizarse mecnicamente [WEB-01].
Sin embargo, como fue mencionado en el punto anterior relativo al diseo, en
muchas 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 ortodoxo (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 haga lo que se espera que haga en la forma en que se
espera que lo haga, 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 consideraciones
ajenas a la teora ponen en entredicho su validez como mtodo estricto del seguimiento
de la vida de un producto de software.

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 9 de 1

I.2.5. Prueba
La prueba se centra en la lgica interna del software, asegurando que todas
las sentencias se han probado, y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se requieren
[WEB-01].
Esta etapa que, a la luz del prrafo de Roger Pressman que antecede a ste,
tiene un alto grado de criticidad en lo que debiera ser el resultado final, suele ser una
etapa de sacrificio o un comodn en caso de tener que empatar una planificacin
retrasada.
Veamos primero en qu debiera consistir esta etapa.

I.2.5.1. Las pruebas en la teora

Primero que nada hay que mencionar los tipos de prueba que se deben realizar
sobre un producto de software. Revisemos los tipos de prueba de software segn Ian
Sommerville [SOM-88]:

PRUEBA

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 software que constituyen la
aplicacin, de tal forma de verificar que cada uno de los mdulos entrega
los resultados esperados en forma aislada.

PRUEBA

DE SUBSISTEMA :

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 proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 10 de 1

PRUEBA

DEL SISTEMA (INTEGRACIN):

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 2000 se aplica el
concepto de prueba de integracin, 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.

PRUEBA

DE ACEPTACIN :

si bien Sommerville no lo menciona en forma

explcita, actualmente esta prueba consiste en la verificacin por parte del

usuario de que el nuevo sistema hace efectivamente lo que se espera que
haga (sobre la base de la especificacin de requerimientos de la etapa de
anlisis).

I.2.5.2. Realidad de las pruebas

Claramente se puede concluir que una adecuada aplicacin de un plan de
pruebas sobre un nuevo producto de software, 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.
Sin embargo la realidad de las pruebas es otra muy distinta.
Por una cuestin propia del modelo cascada que estamos analizando, las
pruebas son una etapa completa, realizada inmediatamente despus de la codificacin
del sistema. De 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 proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 11 de 1

hecho indiscutible de que la complejidad de una rutina suele desconocerse hasta 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.
Teniendo 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
chivo expiatorio de los pecados de las etapas anteriores.
Cunto cuesta no encontrar un defecto?

Cada hora que se emplea en las actividades de control de calidad, como

son las revisiones de diseo, ahorra de 3 a 10 horas en el costo total.

Un defecto en los requerimientos que no se detecta hasta en la

construccin o el mantenimiento necesitar una correccin que costar de
50 a 200 veces ms que si se hubiera hecho en la fase de requerimientos.

De forma ms general, un defecto que no se detecta al inicio (durante la

fase de requerimientos o de diseo) necesitar para su correccin de 10 a
100 veces ms esfuerzo al encontrarlo al final (durante la prueba) de lo
que habra costado corregirlo al principio. Al detectar un error, cuanto
ms tiempo haya pasado desde el inicio, ms costar corregirlo. [MCC00]

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 12 de 1

I.2.6. Mantenimiento
Los cambios ocurrirn debido a que se hayan encontrado errores, a que el
software deba adaptarse a posibles cambios [WEB-01].
Esta etapa, en teora, consiste en la operacin normal del producto ya en
produccin por parte de los satisfechos usuarios. Algunos problemas menores debieran
surgir, los cuales el equipo de desarrollo debiera, en un tiempo breve, resolver para que
el producto contine prestando el servicio esperado.
En esta ocasin la teora previene que algunos problemas menores se han 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 hacer de la labor algo mucho mas productivo.
Si 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 contexto 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 hay 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 han estado exentas de problemas, y en
general sus productos han resultado truncos. Esto hace prcticamente imposible que el
producto final se asemeje a lo que el usuario realmente esperaba.
Por 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,

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

nuevos

plazos

comprometidos

Pgina 13 de 1

(probablemente alcanzando el mismo tiempo o menor quizs, si se hubiese 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.3. LOS PROBLEMAS EN OTROS MODELOS DE DESARROLLO

Similar situacin es la que se vive en los otros modelos de desarrollo de
proyectos de tecnologas de informacin.
Sin entrar en mayores detalles, se har una revisin somera de otros modelos
conocidos de desarrollo de proyectos.
Se har una breve revisin del modelo de desarrollo incremental por prototipos
y del modelo de desarrollo en espiral.
Sin embargo, cabe mencionar que existen numerosos modelos de desarrollo,
limitndonos para este trabajo en los tres ms difundidos.

I.3.1. Desarrollo incremental por prototipos

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.
La forma de validar los prototipos es mediante las pruebas de los usuarios. As
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 proyectos TI: una visin emprica
Marco Antonio Rossel

Pgina 14 de 1

Ilustracin 2: El Prototipado Evolutivo segn Jos Juan Pazos Arias [WEB-06]

I.3.2. Desarrollo en espiral

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. Y as sucesivamente.
Es un modelo altamente aconsejable para desarrollar sistemas con un elevado
nivel de complejidad o de gran tamao. Del mismo modo se desaconseja su uso para
sistemas pequeos.

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 15 de 1

Este es un modelo orientado al riesgo, esto es que se pretende minimizar el

riesgo en el proceso de desarrollo de productos de software a travs de la generacin de
miniproyectos, en donde cada miniproyecto se centra en uno o ms riesgos hasta que
finalmente todos se encuentran controlados.

Ilustracin 3: Modelo en espiral segn Jos Juan Pazos Arias [WEB-06]

El ciclo de vida de los proyectos TI: una visin emprica

Marco Antonio Rossel

Pgina 16 de 1