El ciclo de vida de los proyectos TI: una visión empírica

PORQUÉ LA TEORÍA ES INSUFICIENTE
“La práctica del zazén es la expresión directa de nuestra
verdadera naturaleza. Estrictamente hablando, para un ser
humano no hay otra práctica más que ésta. No hay otra forma
de vida más que ésta.”
Shunryu Suzuki, Mente Zez, Mente de Principiante
En el capítulo anterior ya se esbozaron varias ideas asociadas al porqué la teoría
entregada resulta insuficiente al momento de desempeñarse 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 TEÓRICOS
Numerosas son las teorías que se pueden encontrar en la literatura especializada
respecto de cómo debiera conducirse un proyecto informático para poder lograr los
objetivos planteados para él en el tiempo planificado.
Éstos modelos teóricos 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 visión empírica
Marco Antonio Rossel
Página 1 de 16
En términos generales, es aquí donde aparece una primera falencia, propia de
cualquier modelo teórico, 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 dinámica 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 informática principalmente a través de los ejecutivos del
área, la situación 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 teórico se ve resentido, ya que en
el estudio de los mismos es fácil percibir cómo el cumplimiento cabal de la fase n-1 es
fundamental para el éxito de la fase n, sin embargo es en su aplicación real cuando se
percibe que tal cabalidad en el cumplimiento no es tal.
A continuación, y como una forma de ilustrar con claridad lo expresado en los
párrafos precedentes, se repasará uno de los más difundidos modelos teóricos para el
desarrollo de sistemas de información, entregando algunos puntos clave respecto del
momento en que estas teorías se rompen en aras del éxito comercial o las decisiones
basadas en la política interna de la organización.
I.2. EL MODELO CASCADA DEL DESARROLLO DEL SOFTWARE
Este modelo, ampliamente difundido en el ámbito de las tecnologías de la
información para el desarrollo de software, permite visualizar en términos generales y
como fases claramente diferenciadas las diferentes etapas por las que el desarrollo de un
sistema de información debiera ir transcurriendo en el tiempo (ver Ilustración I).
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 2 de 16
«El modelo de cascada es el primero en establecer el proceso de desarrollo
como la ejecución de un conjunto de actividades. En su concepción básica, 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 algún grado) para empezar la siguiente» [WEB-04].
A continuación se entrega una descripción de cada una de las etapas y los
quiebres que se producen en su aplicación práctica:
Ilustración 1: El ciclo de vida clásico según José Juan Pazos Arias [WEB-06]
I.2.1. Planificación 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].
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 3 de 16
Esta etapa considera la realización de estudios de costos, análisis de
rentabilidad, tiempos de desarrollo, alcances legales, etc., todo lo cual indica que debiera
ser una fase bastante prolongada en el tiempo y con varios recursos de distinta
naturaleza destinados a su finalización.
Sin embargo, en la realidad genérica que se da para esta etapa encontramos dos
escenarios distintos, aunque igualmente incorrectos.
En unos casos, la Planificación del Sistema es desarrollada por el área de
negocios/operaciones de la organización interesada en conseguir el financiamiento para
desarrollar su proyecto. En otros casos, es el área de tecnología o informática 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 tecnológicos como la factibilidad, el riesgo, etc. Por el otro
lado, el área de informática se va a centrar en la factibilidad tecnológica 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 visión 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
parámetros adecuados (¿arreglados?) para generar determinados resultados convenientes
para satisfacer, por ejemplo, una ecuación 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 características esperadas de dar una visión clara de la factibilidad del
proyecto.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 4 de 16
Si bien lo anterior es una visión 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
elevado grado de satisfacción 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
organización 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. Análisis
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 tecnología o informática).
El modelo indica que a través del seguimiento estricto de esta fase se generará
un documento maestro del sistema, en el cual estarán reflejadas a cabalidad las
necesidades de los usuarios del futuro sistema de información. Este documento maestro
es la entrada para la siguiente etapa, que corresponde al diseño.
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 cómo debiera ser el
sistema que necesitan.
Los usuarios son los verdaderos expertos del negocio de la empresa, y son, por
lo tanto, las personas más 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
administración.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 5 de 16
Sin embargo, presumir por ello que son capaces de describir a cabalidad lo que
un sistema automático debiera resolver no es tan exacto.
Esta es una falacia muy común en el mundo de la tecnología, y surge a raíz de
que las estructuras mentales de las personas que se desempeñan en las áreas de
informática de una organización (típicamente ingenieros, técnicos, analistas,
programadores, etc.) versus las de personas que se desempeñan, 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, sistemático y abstracto (requisitos
necesarios para la construcción de sistemas de información y fruto de la formación
profesional) el otro es procedural, comunicativo e intuitivo (necesario para hacer
negocios y fruto de su propia formación profesional o bien de años de experiencia en el
desempeño de sus actividades, situación que en muchas ocasiones resulta más valiosa
que la formación académica).
Pero este no es la única diferencia. Existe una clarísima diferencia de objetivos.
Mientras el primero quiere diseñar y construir un producto de software, el segundo
necesita imperiosamente vender o resolver la necesidad de negocio específica.
Las áreas de informática suelen mal interpretar las necesidades del usuario,
centrando las discusiones en cuadros de diálogo, tipos de letra, combinaciones de
colores, etc., mientras éste solo necesita datos, información, reportes, etc.
Otro bemol de esta relación usuario/informático es la falta de conocimiento de
la labor del otro, situación generada por la segregación funcional propia de las
organizaciones modernas. El usuario tiene necesidades que le corresponde a informática
resolver, cómo se resuelvan no es relevante para él, sólo importa el tiempo que les tome
resolverlas. El informático debe satisfacer las necesidades de sus clientes internos, pero
a diferencia del criterio del usuario, para él resulta tremendamente relevante el cómo
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 6 de 16
resolverlo, y por lo general el factor tiempo estimado para llegar al resultado va a ser
mayor al requerido por el usuario.
Lo más grave es que esta desvinculación entre las distintas funciones que
cumplen los principales actores del proceso de desarrollo, genera serios problemas de
comprensión entre los mismos.
Dados los conceptos vertidos en los párrafos precedentes, si bien no es
imposible (dependerá fundamentalmente del tamaño del sistema en discusión, de la
cantidad de usuarios involucrados y de los montos asociados a la inversión), es
tremendamente dificultoso llegar a una buena especificación de requerimientos para un
sistema, especialmente si es nuevo.
Más aún, basado en la propia experiencia del autor, queda demostrado que una
especificación de requerimientos completa, que logre una plena satisfacción en términos
de resolver el problema a cabalidad, en los plazos requeridos y con la calidad del
producto final esperada es una utopía prácticamente inalcanzable.
I.2.3. Diseño
«El proceso de diseño traduce los requisitos en una representación del
software que pueda ser establecida de forma que obtenga la calidad requerida antes de
que comience la codificación» [WEB-01].
Teniendo como entrada para esta etapa una especificación de requerimientos o
análisis incompleto, es evidente que la salida de esta fase será igualmente incompleta.
Como argumento se podrá esgrimir que el modelo de cascada considera
retroalimentación entre etapas (algo así como refinamiento sucesivo), sin embargo esta
iteración no puede ser eterna y las condicionantes de mercado provocan cortes bruscos
de la iteración, dejando resultados evidentemente truncos con la generalizada convicción
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 7 de 16
de que más adelante se arreglará el problema (en una segunda versión, por ejemplo),
momento que usualmente no llega con la prontitud esperada por el usuario.
Entrando propiamente en lo que es el diseño, es en esta etapa en la que se debe
generar la documentación y las definiciones necesarias para que el equipo de
codificación construya el sistema.
Los problemas típicos de esta etapa se basan en la costumbre, profundamente
enraizada en las organizaciones de que el mismo equipo que hizo el diseño será el que
continuará con la actividad de codificación (aunque la teoría 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 problemática de racionalización 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 definición de requerimientos tomó más tiempo del
presupuestado dado que la interacción con los usuarios resultó más compleja de lo
esperado, entonces se llega a la etapa de diseño ya con un retraso, en ocasiones bastante
considerable.
En teoría éste retraso no debiera ser considerado, sino que el plan original
debiera modificarse para reflejar la nueva situación, 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 más a mano como intangible, esto es, la calidad del
producto final.
Si a esto sumamos que en el diseño no intervienen terceros (está circunscrito al
área de informática), la situación se maneja de forma tal que se genera una
especificación de diseño incompleta, sin todas las consideraciones establecidas en la ya
exigua especificación de requerimientos.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 8 de 16
Por si lo anterior fuese poco, es más común de lo que se desearía que los
informes de diseño se construyan basándose en el código ya elaborado o en pleno
proceso de elaboración.
I.2.4. Codificación y test unitario
En esta etapa la teoría indica que, a partir del informe de diseño detallado (en
un formato que dependerá de la metodología de diseño utilizada), el equipo de
programadores (de preferencia distinto al anterior) comenzará a codificar los diferentes
módulos que a la larga constituirán el sistema.
«Si el diseño se realiza de una manera detallada, la codificación puede
realizarse mecánicamente» [WEB-01].
Sin embargo, como fue mencionado en el punto anterior relativo al diseño, en
muchas ocasiones esta etapa sufre un traslape con la anterior, por lo tanto, ya se parte de
una precisión errónea en la aplicación de la metodología teórica.
No se discutirá en este trabajo las consideraciones relativas a la calidad de los
productos generados a partir de un método tan poco ortodoxo (aunque a la vez tan
ampliamente difundido) de trabajar, la cual obviamente es pobre, no en términos de que
se trate de un producto sólido del punto de vista del código involucrado (el cual suele ser
bueno) sino más 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 ocasión más bien se quiere establecer que nuevamente consideraciones
ajenas a la teoría ponen en entredicho su validez como método estricto del seguimiento
de la vida de un producto de software.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 9 de 16
I.2.5. Prueba
«La prueba se centra en la lógica 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 párrafo 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 comodín en caso de tener que empatar una planificación
retrasada.
Veamos primero en qué debiera consistir esta etapa.
I.2.5.1. Las pruebas en la teoría
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 según Ian
Sommerville [SOM-88]:

PRUEBA
DE MÓDULOS:
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
aplicación, de tal forma de verificar que cada uno de los módulos entrega
los resultados esperados en forma aislada.

PRUEBA DE SUBSISTEMA: en esta prueba los distintos módulos 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 módulos
construidos.

PRUEBA
DEL SISTEMA (INTEGRACIÓN):
en esta prueba el sistema deja de
funcionar como un conjunto aislado de módulos para pasar a comportarse
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 10 de 16
como una pieza integral de una plataforma computacional de una
organización. En la antigua literatura ésta prueba se restringía a reunir
todos los subsistemas componentes de la aplicación y probarlos como un
todo, sin embargo, a partir de la problemática del año 2000 se aplica el
concepto de prueba de integración, en donde se debe considerar la
generación y recepción de interfaces en tiempo real (por supuesto en un
ambiente de producción simulado) para verificar que el sistema no solo
opera correctamente como un todo, sino que además no afecta a su entorno
con los resultados generados.

PRUEBA
DE ACEPTACIÓN:
si bien Sommerville no lo menciona en forma
explícita, actualmente esta prueba consiste en la verificación por parte del
usuario de que el nuevo sistema hace efectivamente lo que se espera que
haga (sobre la base de la especificación de requerimientos de la etapa de
análisis).
I.2.5.2. Realidad de las pruebas
Claramente se puede concluir que una adecuada aplicación 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 metodología de pruebas aplicada,
permitiría la obtención de un producto consolidado y estable en el futuro.
Sin embargo la realidad de las pruebas es otra muy distinta.
Por una cuestión propia del modelo cascada que estamos analizando, las
pruebas son una etapa completa, realizada inmediatamente después de la codificación
del sistema. De más está decir que la anterior etapa de codificación suele sufrir
alteraciones en su planificación, producto de numerosos factores. Entre otros está el
hecho indiscutible de que la complejidad de una rutina suele desconocerse hasta el
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 11 de 16
momento mismo en que es codificada, esto sumado a los problemas con ese tope el
programador al intentar seguir un diseño poco riguroso.
Esta situación 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
producción, dejando, la resolución de los problemas para la etapa posterior de
mantenimiento.
Teniendo enfrente la tentación de salir bien parado ante los superiores
mostrando diligencia en el cumplimiento de los plazos o simplemente no declarar lo que
podría ser un nuevo retraso, es altamente probable que la etapa de pruebas sirva como
chivo expiatorio de los pecados de las etapas anteriores.
«¿Cuánto cuesta no encontrar un defecto?

Cada hora que se emplea en las actividades de control de calidad, como
son las revisiones de diseño, ahorra de 3 a 10 horas en el costo total.

Un defecto en los requerimientos que no se detecta hasta en la
construcción o el mantenimiento necesitará una corrección que costará de
50 a 200 veces más que si se hubiera hecho en la fase de requerimientos.

De forma más general, un defecto que no se detecta al inicio (durante la
fase de requerimientos o de diseño) necesitará para su corrección de 10 a
100 veces más esfuerzo al encontrarlo al final (durante la prueba) de lo
que habría costado corregirlo al principio. Al detectar un error, cuanto
más tiempo haya pasado desde el inicio, más costará corregirlo». [MCC00]
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 12 de 16
I.2.6. Mantenimiento
«Los cambios ocurrirán debido a que se hayan encontrado errores, a que el
software deba adaptarse a posibles cambios» [WEB-01].
Esta etapa, en teoría, consiste en la operación normal del producto ya en
producción 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 continúe prestando el servicio esperado.
En esta ocasión la teoría previene que algunos problemas menores se han de
presentar en la nueva creación informática, principalmente fallas, producto de la
aparición de casos no considerados en las pruebas o bien debido a que el usuario
descubre variantes en las funcionalidades implementadas que, incorporadas al producto,
podrían hacer de la labor algo mucho mas productivo.
Si bien los considerandos son correctos, la realidad supera nuevamente a la
teoría en algo bastante básico en sistemas informáticos, esto es, la dimensión del cambio
requerido.
Esto se debe entender en el contexto del análisis ya realizado sobre las etapas
anteriores, en donde se pueden apreciar las deficiencias de arrastre que parten desde la
planificación inicial del sistema, en donde no hay un adecuado dimensionamiento del
sistema ni tampoco una evaluación 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 prácticamente imposible que el
producto final se asemeje a lo que el usuario realmente esperaba.
Por esto esta fase de operación y mantención, suele transformarse en una
sucesiva generación de versiones del sistema originalmente construido, en donde, con
nuevos
recursos
económicos
incorporados,
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
y nuevos
plazos
comprometidos
Página 13 de 16
(probablemente alcanzando el mismo tiempo o menor quizás, 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 situación es la que se vive en los otros modelos de desarrollo de
proyectos de tecnologías de información.
Sin entrar en mayores detalles, se hará una revisión somera de otros modelos
conocidos de desarrollo de proyectos.
Se hará una breve revisión del modelo de desarrollo incremental por prototipos
y del modelo de desarrollo en espiral.
Sin embargo, cabe mencionar que existen numerosos modelos de desarrollo,
limitándonos para este trabajo en los tres más 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 especificación, de esta forma la especificación 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 través de sus opiniones y
observaciones sobre los prototipos, la evolución de los mismos, esto es, delinear el
siguiente incremento.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 14 de 16
Ilustración 2: El Prototipado Evolutivo según José Juan Pazos Arias [WEB-06]
I.3.2. Desarrollo en espiral
En el desarrollo en espiral, que nace como consecuencia de la unión de las
ventajas del modelo incremental con el de cascada, se establece una relación 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 especificación de requerimientos. En
el tercero se desarrolla el diseño. Y así sucesivamente.
Es un modelo altamente aconsejable para desarrollar sistemas con un elevado
nivel de complejidad o de gran tamaño. Del mismo modo se desaconseja su uso para
sistemas pequeños.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 15 de 16
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 través de la generación de
miniproyectos, en donde cada miniproyecto se centra en uno o más riesgos hasta que
finalmente todos se encuentran controlados.
Ilustración 3: Modelo en espiral según José Juan Pazos Arias [WEB-06]
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 16 de 16