Roger S.

Presuman
Ingeniera de Software un Enfoque practico
PARADIGMAS DE LA INGENIERIA DEL SOFTWARE
La crisis del software no desaparecer de la noche a la maana. El reconocimiento de los
problemas y sus causas, as como el desenmascaramiento de los mitos del software son los
primeros pasos hacia las soluciones. Luego, las soluciones deben dar asistencia prctica al
que desarrolla el software, mejorar la calidad del software y finalmente permitir al mundo
del software emparejarse con el mundo del hardware.
No hay un mtodo nico mejor que solucione la crisis del software. Sin embargo, puede
lograrse una disciplina para el desarrollo del software una disciplina llamada ingeniera
del software, combinando mtodos para todas las fases de desarrollo del software
mejores herramientas para automatizar estos mtodos; construccin mas poderosa de
bloques para la implementacin del software y una filosofa predominante de coordinacin,
control y gestin.
Ingeniera del software: una definicin
Una primera definicin de ingeniera del software fue propuesta por Fritz Bauer en la
primera conferencia importante [NAU69] dedicada al tema:
El establecimiento y uso de principios de ingeniera robustos, orientados a obtener
econmicamente software que sea fiable y funcione eficientemente sobre mquinas reales.
Aunque se han propuesto muchas ms definiciones globales, todas refuerzan la importancia
de una disciplina de ingeniera para el desarrollo del software.
La ingeniera del software surge, sobrepasndola, de la ingeniera de sistemas y del
hardware. Abarca un conjunto de tres elementos claves mtodos, herramientas y
procedimientos que facilitan al gestor controlar el proceso del desarrollo del software y
suministrar a los que practiquen dicha ingeniera las bases para construir software de alta
calidad de una forma productiva. En los prrafos que siguen, examinaremos brevemente
cada uno de estos elementos.
Los mtodos de la ingeniera del software suministran el cmo construir tcnicamente el
software. Los mtodos abarcan un amplio espectro de tareas que incluyen: planificacin y
estimacin de proyectos; anlisis de los requerimientos del sistema y del software; diseo
de estructuras de datos, arquitectura de programas y procedimientos algortmicos;
codificacin; prueba y mantenimiento. Los mtodos de la ingeniera del software
introducen frecuentemente una notacin especial orientada a lenguaje o grfica y un
conjunto de criterios para la calidad del software.
Las herramientas de la ingeniera del software suministran un soporte automtico o
semiautomtico para los mtodos. Hoy, existen herramientas para soportar cada uno de los
mtodos mencionados anteriormente. Cuando se integran las herramientas de forma que la
informacin creada por una herramienta pueda ser usada por otra, se establece un sistema
para el soporte del desarrollo del software, llamado ingeniera del software asistido por
computadora (CASE: acrnimo en ingls de computer-aided software engineering). CASE

Roger S. Presuman
Ingeniera de Software un Enfoque practico
combina el software, hardware y bases de datos de la ingeniera del software (una
estructura de datos que contenga la informacin relevante sobre el anlisis, diseo,
codificacin y prueba) para crear un entorno de ingeniera del software (por ejemplo,
[HEN84]) anlogo al diseo/ingeniera asistida por computadora, CAD/CAE (del ingls:
computer-aided design/engineering), para el hardware.
Los procedimientos de la ingeniera del software son la cola que pega a los mtodos y
herramientas y facilita un desarrollo racional y oportuno del software de computadora. Los
procedimientos definen la secuencia en la que se aplican los mtodos, las entregas
(documentos, informes, formas, etc.) que se requieren, los controles que ayudan a asegurar
la calidad y coordinar los cambios, y las guas que facilitan a los gestores del software
establecer su desarrollo.
La ingeniera del software est compuesta de pasos que abarcan los mtodos, herramientas
y procedimientos tratados anteriormente. Estos pasos se denominan frecuentemente
paradigmas de la ingeniera del software. Un paradigma para la ingeniera del software se
elige basndose en la naturaleza del proyecto y de la aplicacin, los mtodos y herramientas
a usar y los controles y entregas requeridos. Se han tratado ampliamente (y debatido) tres
paradigmas que se describen en las siguientes secciones.
El ciclo de vida clsico
La Figura 2.15 ilustra el paradigma del ciclo de vida clsico para la ingeniera del software.
Algunas veces llamado el modelo en cascada, el paradigma del ciclo de vida exige un
enfoque sistemtico, secuencial, del desarrollo del software que comienza en el nivel del
sistema y progresa a travs del anlisis, diseo, codificacin, prueba y mantenimiento.
Modelado despus del ciclo convencional de una ingeniera, el paradigma del ciclo de vida
abarca las siguientes actividades:
Ingeniera y anlisis del sistema. Debido a que el software es siempre parte de un sistema
mayor, el trabajo comienza estableciendo los requerimientos de todos los elementos del
sistema y luego asignado algn subconjunto de estos requerimientos al software. Esta
visin del sistema es esencial cuando el software debe interrelacionarse con otros elementos
tales como hardware, personas; bases de datos. La ingeniera y anlisis del sistema abarca
los requerimientos globales a nivel del sistema con una pequea cantidad de anlisis y
diseo a nivel superior.
Anlisis de los requerimientos del software. El proceso de recogida de los requerimientos se
centra e intensifica especialmente en el software. Para comprender la naturaleza de los
programas que hay que construir, el ingeniero de software (analista) debe comprender el
dominio de la informacin del software, as como la funcin, rendimiento e interfaces
requeridas. Los requerimientos tanto del sistema como del software se documentan y
revisan con el cliente.
Diseo. El diseo del software es realmente un proceso multipaso que se enfoca sobre tres
atributos distintos del programa: estructura de datos, arquitectura del software y detalle

Roger S. Presuman
Ingeniera de Software un Enfoque practico

procedimental. El proceso de diseo traduce los requerimientos en una representacin del

software que pueda ser establecida de forma que obtenga la calidad requerida antes de que
comience la codificacin. Como los requerimientos, el diseo se documenta y forma parte
de la configuracin del software.
Codificacin. El diseo debe traducirse en una forma legible para la mquina. El paso de la
codificacin ejecuta esta tarea. Si el diseo se ejecuta de una manera detallada, la
codificacin puede realizarse mecnicamente.
Prueba. Una vez que se ha generado el cdigo, comienza la prueba del programa. La
prueba se enfoca sobre la lgica interna del software, asegurando que todas las sentencias
se han probado, y sobre las funciones externas, esto es, realizando pruebas para asegurar
que la entrada definida producir los resultados que realmente se requieren.
Mantenimiento. El software sufrir indudablemente cambios despus de que se entregue al
cliente (una posible excepcin es el software empotrado). Los cambios ocurrirn debido a
que se han encontrado errores, debido a que el software debe adaptarse por cambios del
entorno externo (por ejemplo, un cambio solicitado debido a que se tiene un nuevo sistema
operativo o dispositivo perifrico), o debido a que el cliente requiere aumentos funcionales
o del rendimiento. El mantenimiento del software se aplica a cada uno de los pasos
precedentes del ciclo de vida a un programa existente en vez de a uno nuevo.
El ciclo de vida clsico es el ms viejo y ms ampliamente usado paradigma en la
ingeniera del software. Sin embargo, con el paso de unos cuantos aos, se han producido
crticas al paradigma, incluso por seguidores activos que cuestionan su aplicabilidad a todas
las situaciones. Entre los problemas que se presentan algunas veces, cuando se aplica el
paradigma del ciclo de vida clsico se encuentran:

Roger S. Presuman
Ingeniera de Software un Enfoque practico
1. Los proyectos reales raramente siguen el flujo secuencial que propone el modelo.
Siempre ocurren iteraciones y se crean problemas en la aplicacin del paradigma.
2. Normalmente es difcil para el cliente establecer explcitamente al principio todos los
requerimientos. El ciclo de vida clsico requiere esto y tiene dificultades en acomodar
posibles incertidumbres que pueden existir al comienzo de muchos proyectos.
3. El cliente debe tener paciencia. Una versin funcionando del programa no estar
disponible hasta las etapas finales del desarrollo del proyecto. Un error importante no
detectado hasta que el programa est funcionando puede ser desastroso.
Cada uno de estos problemas es real. Sin embargo, el paradigma clsico del ciclo de vida
tiene un lugar definido e importante en el trabajo sobre ingeniera del software. Suministra
una templeta en la que puede colocarse los mtodos para el anlisis, diseo, codificacin,
prueba y mantenimiento. Adems, veremos que los pasos del paradigma clsico del ciclo de
vida son muy similares a los pasos genricos aplicables a todos los paradigmas de
ingeniera del software. El ciclo de vida clsico permanece como el modelo procedimental
ms ampliamente usado por los ingenieros de software. A pesar de sus inconvenientes, es
significativamente mejor que desarrollar sin rumbo el software.
Construccin de prototipo
Normalmente un cliente definir un conjunto de objetivos generales para el software, pero
no identificar los requerimientos detallados de entrada, procesamiento o salida. En otros
casos el programador puede no estar seguro de la eficiencia de un algoritmo, la
adaptabilidad de un sistema operativo o la forma en que debe realizarse la interaccin
hombre-mquina. En estas y muchas otras situaciones, puede ser mejor mtodo de
ingeniera del software realizar un prototipo.
La construccin del prototipo es un proceso que facilita al programador la creacin de un
modelo del software a construir. El modelo tomar una de las tres formas siguientes: un
prototipo en papel que describa la interaccin hombre-mquina de forma que facilite al
usuario la comprensin de cmo se producir tal interaccin; un prototipo que funcione que
implementa algunos subconjuntos de la funcin requerida al software deseado; o un
programa existente que ejecute parte o toda la funcin deseada, pero que tenga otras
caractersticas que deban ser mejoradas en el nuevo trabajo de desarrollo.
La secuencia de sucesos para el paradigma de construccin de prototipos se muestra en la
Figura 2.16. Como en todos los mtodos de desarrollo de software, la construccin de
prototipos comienza con la recoleccin de los requerimientos. El tcnico y el cliente se

Roger S. Presuman
Ingeniera de Software un Enfoque practico

renen y definen los objetivos globales para el software, identifican todos los
requerimientos conocidos y perfilan las reas en donde ser necesario una mayor
definicin. Luego se produce un diseo rpido. El diseo rpido se enfoca sobre la
representacin de los aspectos del software, visibles al usuario (por ejemplo, mtodos de
entrada y formatos de salida). El diseo rpido conduce a la construccin de un prototipo.
El prototipo es evaluado por el cliente/usuario y se utiliza para refinar los requerimientos
del software a desarrollar. Se produce un proceso interactivo en el que el prototipo es
afinado para que satisfaga las necesidades del cliente, al mismo tiempo que facilita al que
lo desarrolla una mejor comprensin de lo que hay que hacer. Idealmente, el prototipo sirve
como un mecanismo para identificar los requerimientos del software. Si se construye un
prototipo que funciona, el realizador intenta hacer uso de fragmentos de programas
existentes o aplica herramientas (por ejemplo, generadores de informes, gestores de
ventana, etc.) que faciliten la rpida generacin de programas que funcionen.
Pero qu debemos hacer con el prototipo cuando ya ha servido para el propsito descrito
anteriormente? Brooks [BR075] da una respuesta:
En la mayora de los proyectos, el primer sistema construido apenas es utilizable. Puede ser
demasiado lento, demasiado grande, difcil de usar o las tres cosas. No hay mas alternativa que
comenzar de nuevo y construir una versin rediseada que resuelva los problemas que se
presenten... Cuando se utiliza un nuevo concepto de sistemas o tecnologa, hay que construir un
sistema para desecharlo, porque incluso la mejor planificacin no puede asegurar que vaya a ser
bueno la primera vez.
Por tanto, la pregunta de gestin no es si hay que construir un sistema piloto y tirarlo. Lo tirar.
La nica pregunta es si planificar de antemano la construccin de algo que se va a desechar, o
prometer entregar el desecho a los clientes...

Roger S. Presuman
Ingeniera de Software un Enfoque practico
El prototipo puede servir como el primer sistema aqul que Books recomienda que
tiremos. Pero esto puede ser una visin idealizada. Como en el ciclo de vida clsico, la
construccin de prototipos como paradigma para la ingeniera del software, puede ser
problemtico por las siguientes razones:
1. El cliente ve funcionando lo que parece ser una versin del software, ignorando que el
prototipo se ha hecho con chicle y alambres, ignora que por las prisas en hacer que
funcione, no hemos considerado los aspectos de calidad o mantenimiento a largo plazo
del software. Cuando se le informa que el producto debe ser reconstruido, el cliente
grita horrible y solicita que se apliquen cuantas mejoras sean necesarias para hacer
del prototipo un producto final que funcione. Demasiadas veces el gestor del desarrollo
del software cede.
2. El tcnico de desarrollo realiza frecuentemente ciertos compromisos de implementacin
en orden a obtener un prototipo que funcione rpidamente. Puede utilizarse un sistema
operativo o lenguaje de programacin inapropiado simplemente porque est disponible
y es conocido; un algoritmo ineficiente puede implementarse de forma sencilla para
demostrar su capacidad. Despus de pasar algn tiempo en el que el tcnico estaba
familiarizado con estas elecciones, olvida las razones por las que eran inapropiadas. La
eleccin menos ideal forma ahora parte integral del sistema.
Aunque se pueden presentar problemas, la construccin de prototipos es un paradigma
efectivo para la ingeniera del software. La clave est en definir al comienzo las reglas del
juego; esto es, el cliente y tcnico deben estar de acuerdo en que el prototipo se construya
para servir slo como un mecanismo de definicin de los requerimientos. Posteriormente ha
de ser descartado (al menos en parte) y debe construirse el software real, con los ojos
puestos en la calidad y mantenimiento.
Tcnicas de la cuarta generacin
El trmino tcnicas de la cuarta generacin (T4G) abarca un amplio espectro de
herramientas software que tienen una cosa en comn: todas facilitan al que desarrolla el
software especificar algunas caractersticas del software a alto nivel. Luego, la herramienta
genera automticamente el cdigo fuente basndose en la especificacin del tcnico. Existe
cierto debate sobre cunto puede aumentar- se la rapidez en la construccin de un programa
respecto a cunto ha de elevar- se el nivel en el que se especifique el software para una
mquina. El paradigma T4G para la ingeniera del software se orienta hacia la habilidad de
especificar software a un nivel que sea ms prximo al lenguaje natural o en una flotacin
que proporcione funciones significativas.
Actualmente, un entorno para el desarrollo del software que soporte el paradigma T4G
incluye algunas o todas de las siguientes herramientas: lenguajes no / procedimentales para
consulta a base de datos, generacin de informes, manipulacin de datos, interaccin y
definicin de pantallas y generacin de cdigo; capacidades grficas de alto nivel; y
capacidad de hoja de clculo. Cada una de estas herramientas existen, pero slo para
dominios de aplicacin muy especficas. No existe hoy disponible un entorno T4G que
pueda aplicarse con igual facilidad a todas las categoras de aplicaciones del software.

Roger S. Presuman
Ingeniera de Software un Enfoque practico
El paradigma T4G para la ingeniera del software se describe en la Figura 2.17. Como otros
paradigmas, T4G comienza con el paso de recoleccin de requerimientos. Idealmente, el
cliente debe describir los requerimientos y estos deben traducirse directamente en un
prototipo operacional; pero ste no funciona. El cliente puede no estar seguro de lo que
necesita, puede ser ambiguo en la especificacin de hechos que son conocidos y puede ser
incapaz o no desear especificar la informacin en la forma que una herramienta T4G puede
consumirla. Adems las herramientas actuales T4G no son lo suficientemente sofisticadas
para acomodar realmente el lenguaje natural y no lo sern por algn tiempo. En este
momento el dilogo c1iente-tcnico descrito por los otros paradigmas permanece como una
parte esencial del enfoque T4G.
Para aplicaciones pequeas, puede ser posible ir directamente desde el paso de
establecimiento de los requerimientos a la implementacin, usando un lenguaje de la
cuarta generacin no procedimental (T4G). Sin embargo, es necesario un mayor esfuerzo
para desarrollar una estrategia de diseo para el sistema, incluso si se utiliza un L4G.

El uso de T4G sin diseo (para grandes proyectos) causar las mismas dificultades (poca
calidad, pobre mantenimiento, mala aceptacin por el cliente) que se encuentra cuando se
desarrolla software usando los mtodos convencionales.
La implementacin usando L4G facilita al que desarrolla el software, la descripcin de los
resultados deseados, los cuales se traducen automticamente en cdigo fuente para producir
dichos resultados. Obviamente, debe existir una estructura de datos con informacin
relevante y debe estar rpidamente accesible al L4G.
El ltimo paso de la Figura 2.17 contiene la palabra producto. Para transformar una
implementacin T4G en un producto, el que lo desarrolla debe dirigir una prueba completa,

Roger S. Presuman
Ingeniera de Software un Enfoque practico
desarrollar una documentacin con sentido y ejecutar todas las otras actividades de
transicin requeridas en los otros paradigmas de la ingeniera del software. Adems, el
software desarrollado con T4G debe ser construido de forma que facilite que el
mantenimiento pueda ser ejecutado de una forma expeditiva.
Ha existido mucha hiprbole y un considerable debate alrededor del uso del paradigma
T4G (por ejemplo, [COB85], [GRA85]). Los defensores aducen reducciones dramticas en
el tiempo de desarrollo del software y una mejora significativa en la productividad de la
gente que construye el software. Los detractores aducen que las herramientas actuales de
T4G no son ms fciles de utilizar que los lenguajes de programacin, que el cdigo fuente
producido por tales herramientas es ineficiente, y que el mantenimiento de grandes
sistemas de software, desarrollado usando T4G, est abierto a discusin.
Hay algunos mritos en las razones de cada parte. Aunque es algo difcil separar los hechos
de las suposiciones (existen pocos estudios controlados hasta el momento), es posible
resumir el estado actual de los mtodos T4G:
1. Con muy pocas excepciones, el dominio de aplicacin actual de los T40 est limitado a
las aplicaciones de sistemas de informacin comerciales, especficamente, ci anlisis de
informacin y la obtencin de informes en grandes bases de datos. Hasta la fecha, T4G
se ha usado muy poco en productos de ingeniera y reas de aplicacin de sistemas.
2. La recoleccin de datos preliminares que acompaa al uso de T4G parece indicar que el
tiempo requerido para producir software, se reduce mucho para aplicaciones pequeas y
de tamao medio y, que la cantidad de anlisis y diseo para las aplicaciones pequeas,
tambin se reduce.
3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software, exige el
mismo o ms tiempo de anlisis, diseo y prueba (actividades de ingeniera del
software), perdindose as un tiempo sustancial que se ahorra mediante la eliminacin
de la codificacin.
Para resumir, las tcnicas de la cuarta generacin se convertirn probablemente en una
parte importante del desarrollo de software durante la siguiente dcada. Como muestra la
Figura 2.18, la demanda de software continuar creciendo durante el resto de este siglo,
pero los mtodos y paradigmas convencionales, contribuirn probablemente cada vez
menos al desarrollo del mismo. Las tcnicas de la cuarta generacin rellenarn el hueco que
existe hasta que sean practicables los mtodos de JA de la quinta generacin.
Combinacin de paradigmas
Frecuentemente se describe a los paradigmas de la ingeniera del software tratados en as
secciones anteriores como mtodos alternativos para la ingeniera del software en vez de
mtodos complementarios. En muchos casos, los paradigmas pueden y deben combinarse
de forma que puedan utilizarse las ventajas de cada uno en un nico proyecto. No tienen
por qu existir relaciones contrapuestas!

Roger S. Presuman
Ingeniera de Software un Enfoque practico

La Figura 2.19 muestra cmo pueden combinarse los tres paradigmas mencionados durante
un trabajo de desarrollo de software. En todos los casos el trabajo comienza con la
recoleccin de requerimientos. El mtodo puede seguir el ciclo de vida clsico (ingeniera
de Sistemas y anlisis de requerimientos del software) o puede ser la definicin menos
formal del problema usada en la construccin de un prototipo. Independientemente, debe
producirse la comunicacin cliente-realizador del software.
La naturaleza de la aplicacin dictar la aplicabilidad del mtodo de construccin de
prototipos. Si los requerimientos para la funcin y rendimiento del software estn
razonablemente bien comprendidos, pueden ser aplicables los mtodos de especificacin
recomendados para el ciclo de vida clsico. Por otra parte, si la aplicacin del software
exige una fuerte interaccin hombre- mquina o requiere algoritmos no probados o tcnicas
de control de salidas, puede realizarse un prototipo. En tales casos puede usarse a veces un
L4G para desarrollar rpidamente el prototipo. Una vez que se haya evaluado y refinado el
prototipo, pueden aplicarse los pasos de dise e implementacin del ciclo de vida clsico
para desarrollar el software formalmente.

Roger S. Presuman
Ingeniera de Software un Enfoque practico
No hay necesidad de ser dogmtico en la eleccin de los paradigmas para la ingeniera del
software; la naturaleza de la aplicacin debe dictar el mtodo a elegir. Mediante la
combinacin de paradigmas, el todo puede ser mejor que la suma de las partes.