[Escriba texto]

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

[Escriba texto]

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.

[Escriba texto]

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.
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

[Escriba texto]

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

[Escriba texto]

que el desarrollo de un sistema de informacin debiera ir

transcurriendo en el tiempo (ver Ilustracin I).
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:

[Escriba texto]

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 ser
una fase bastante prolongada en el tiempo y con varios
recursos de distinta naturaleza destinados a su finalizacin.

[Escriba texto]

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

[Escriba texto]

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 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.

[Escriba texto]

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.

[Escriba texto]

Sin embargo, presumir por ello que son capaces de

describir a cabalidad lo que un sistema automtico debiera
resolver no es tan exacto.
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

[Escriba texto]

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.
Lo ms grave es que esta desvinculacin entre las
distintas funciones que cumplen los principales actores del
proceso

de

desarrollo,

genera

comprensin entre los mismos.

[Escriba texto]

serios

problemas

de

Dados

los

precedentes,

si

conceptos

vertidos

bien

es

no

en

imposible

los

prrafos

(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.

[Escriba texto]

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.
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.

[Escriba texto]

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.
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.

[Escriba texto]

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
programadores

de

diseo

(de

utilizada),

preferencia

el

distinto

equipo
al

de

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

[Escriba texto]

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.

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

[Escriba texto]

software. Revisemos los tipos de prueba de software segn

Ian Sommerville [SOM-88]:

PRUEBA

DE

someter

entrada)

MDULOS:

esta prueba consiste en

distintos

escenarios

cada

una

de

(variables
las

de

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.

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
[Escriba texto]

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.

[Escriba texto]

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 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.

[Escriba texto]

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

mantenimiento

en

la

construccin

necesitar una correccin

el
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. [MCC-00]

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].

[Escriba texto]

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

que

funcionalidades

el

usuario

descubre

implementadas

que,

variantes

en

las

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

[Escriba texto]

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

comprometidos

incorporados,

(probablemente

nuevos

alcanzando

el

plazos
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.

[Escriba texto]

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

[Escriba texto]

travs

de

sus

opiniones

observaciones

sobre

los

prototipos, la evolucin de los mismos, esto es, delinear el

siguiente incremento.
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.

[Escriba texto]

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.
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

ms

riesgos

encuentran controlados.

[Escriba texto]

hasta

que

finalmente

todos

se

Ilustracin 3: Modelo en espiral segn Jos Juan

Pazos Arias [WEB-06]

[Escriba texto]