Unidad 5.- Modelos de desarrollo de software.

Modelos prescriptivos.
Cualquier organización de ingeniería del software debe describir un conjunto único
de actividades dentro del marco de trabajo para el (los) proceso(s) de software que
adopte. También debe llenar cada actividad del marco de trabajo con un conjunto de
acciones de ingeniería del software, y definir cada acción en cuanto a un conjunto de
tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para
alcanzar las metas de desarrollo. Después, la organización debe adaptar el modelo de
proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas
que lo realizarán, y el ambiente en el que se ejecutará el trabajo. Sin importar el modelo
del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un
marco de trabajo genérico para el proceso, el cual incluye las siguientes actividades dentro
del marco: comunicación, planeación, modelado, construcción y desarrollo.

El modelo en cascada.

Existen ocasiones en que los requisitos de un problema se entienden de una

manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue
de una manera casi lineal. Esta situación se encuentra a veces cuando es necesario hacer
adaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, una
adaptación a un software contable debido a los cambios en las regulaciones del gobierno).
Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos,
pero sólo cuando los requerimientos están bien definidos y son estables en forma
razonable,

El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere un

enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la
especificación de requerimientos del cliente y que continúa con la planeación, el
modelado, la construcción y el despliegue para culminar en el soporte del software
terminado.

El modelo en cascada es el paradigma más antiguo para la ingeniería del software.

Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso han
ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia
[HAN95]. Entre los problemas que algunas veces se encuentran al aplicar el modelo en
cascada están:
 Modelos de desarrollo de software

1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el
modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta.
Como resultado, los cambios confunden mientras el equipo de proyecto actúa.

2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera
explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la
incertidumbre natural presente en el inicio de muchos proyectos.

3. El cliente debe tener paciencia. Una versión que funcione de los programas
estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso
si no se detecta antes de la revisión del programa.

En un análisis interesante de proyectos reales, Bradac [BRA94] concluyó que la

naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales
algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas
dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo
productivo. El estado de bloqueo tiende a ser más común al principio y al final del proceso
secuencial.

En la actualidad, el trabajo del software está acelerado y sujeto a una cadena

infinita de cambios (de características, funciones y contenido de la información). Con
frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo,
puede servir como un modelo de proceso útil en situaciones donde los requerimientos
están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal.

Modelos de proceso incrementales.

En muchas situaciones los requisitos iniciales del software están bien definidos en
forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso
puramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar de
manera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla y
expandirla en las entregas posteriores del software. En estos casos
se elige un modelo de proceso diseñado para producir el software en forma incremental.

El modelo incremental.

El modelo incrementa! combina elementos del modelo en cascada aplicado en

forma iterativa. Como se muestra en la figura, el modelo incremental aplica secuencias
lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada
secuencia lineal produce "incrementos" del software [MCD93]. Por ejemplo, el software
procesador de texto, desarrollado con el paradigma incremental en su primer incremento,
podría realizar funciones básicas de administración de archivos, edición y producción de
documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones
más complejas de producción de documentos; en el tercer incremento, funciones de
corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de
configuración de página. Se debe tener en cuenta que el flujo del proceso de cualquier

MC Genaro Alberto Gómez Chi Página 2 de 18

 Modelos de desarrollo de software

incremento puede incorporar el paradigma de construcción de prototipos que se expone

más adelante.

A menudo, al utilizar un modelo incremental el primer incremento es un producto

esencial. Es decir, se incorporan los requisitos básicos, pero muchas características
suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial
queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de
la evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la
modificación del producto esencial con el fin de satisfacer de mejor manera las
necesidades del cliente y la entrega de características y funcionalidades adicionales. Este
proceso se repite después de la entrega de cada incremento mientras no se haya
elaborado el producto completo.

El modelo de proceso incremental, al igual que la construcción de prototipos y otros

enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de
prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con
cada incremento. Los primeros incrementos son versiones “incompletas del producto final,
pero proporcionan al usuario la funcionalidad que necesita y una plataforma para
evaluarlo.

El desarrollo incremental es útil sobre todo cuando el personal necesario para una
implementación completa no está disponible. Los primeros incrementos se pueden
implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se
requiere) más personal para implementar el incremento siguiente. Además, los
incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un
sistema grande podría requerir la disponibilidad de un hardware nuevo que está en
desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros
incrementos de forma que se evite el uso de este hardware, lo que permitiría la entrega de
funcionalidad parcial a los usuarios finales sin retrasos desordenados.

El modelo DRA.

El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software

incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a
"alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido

MC Genaro Alberto Gómez Chi Página 3 de 18

 Modelos de desarrollo de software

mediante un enfoque de construcción basado en componentes. Si se entienden bien

los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un
equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy
corto (por ejemplo, de 60 a 90 días) [MAR91].

Como otros modelos de proceso, el enfoque DRA cumple con las actividades
genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para
entender el problema de negocios y las características de información que debe incluir el
software. La planeación es esencial porque varios equipos de software trabajan en
paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases —
modelado de negocios, modelado de datos y modelado del proceso— y establece
representaciones del diseño que sirven como base para la actividad de construcción del
modelo DRA. La construcción resalta el empleo de componentes de software existente y la
aplicación de la generación automática de código. Por último, el despliegue establece una
base para las iteraciones subsecuentes, si éstas son necesarias [KER94].

El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las

restricciones de tiempo impuestas sobre un proyecto DRA exigen un "ámbito de escalas"
[KER94]. Si una aplicación de
negocios se puede modular de
forma que cada gran función
pueda completarse en menos de
tres meses (mediante la aplicación
del enfoque ya descrito), ésta es
una candidata para el DRA. Cada
gran función se puede abordar
mediante un equipo de DRA por
separado, para después integrarlas
y formar un todo.

Como todos los modelos de

procesos, el enfoque DRA tiene
inconvenientes:

1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos

humanos para crear en número correcto de equipos DRA.
2) Si los desarrolladores y clientes no se comprometen con las actividades rápidas
necesarias para completar el sistema en un marco de tiempo muy breve, los
proyectos DRA fallarán.
3) Si un sistema no se puede modular en forma apropiada, la construcción de los
componentes necesarios para el DRA será problemática.
4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertir
interfaces en componentes del sistema, el enfoque DRA podría no funcionar.
5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo,
cuando una aplicación nueva aplica muchas nuevas tecnologías).

MC Genaro Alberto Gómez Chi Página 4 de 18

 Modelos de desarrollo de software

Modelos de proceso evolutivos.

El software, como todos los sistemas complejos, evoluciona con el tiempo. Los
requisitos de los negocios y productos a menudo cambian conforme se realiza el
desarrollo; por lo tanto, la ruta lineal que conduce a un producto final no será real; las
estrictas fechas tope del mercado imposibilitan la conclusión de un producto completo, por
lo que debe presentar una versión limitada para liberar la presión competitiva y de
negocios; se tiene claro un conjunto de requisitos del producto o sistema esencial, pero
todavía se deben definir los detalles de las extensiones del producto o sistema. En estas y
otras situaciones similares, los ingenieros de software necesitan un modelo de proceso
que haya sido diseñado de manera explicita para incluir un producto que evolucione con el
tiempo.

Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que
los ingenieros de software desarrollen versiones cada vez más completas del software.

Construcción de prototipos.

A menudo un cliente define un conjunto de objetivos generales para el software,

pero no identifica los requisitos detallados de entrada, procesamiento o salida. En otros
casos, el responsable del desarrollo del software está inseguro de la eficacia de un
algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la
interacción humano-máquina. En estas, y muchas otras situaciones, un paradigma de
construcción de prototipos puede ofrecer el mejor enfoque.

A pesar de que la construcción de prototipos se puede utilizar como un modelo de

proceso independiente, se emplea más comúnmente como una técnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos de proceso expuestos en
estos apuntes. Sin importar la forma en que éste se aplique, el paradigma de construcción
de prototipos ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cúal
será el resultado de la construcción cuando los requisitos estén satisfechos.

El paradigma de construcción de prototipos se

inicia con la comunicación. El ingeniero de software y el
cliente encuentran y definen los objetivos globales para
el software, identifican los requisitos conocidos y las
áreas del esquema en donde es necesaria más
definición. Entonces se plantea con rapidez una
iteración de construcción de prototipos y se presenta el
modelado (en la forma de un diseño
rápido). El diseño rápido se centra en una
representación de aquellos aspectos del
software que serán visibles para el cliente o el usuario
final (por ejemplo, la configuración de la interfaz con el
usuario y el formato de los despliegues de salida). El
diseño rápido conduce a la construcción de un prototipo. Después, el prototipo lo
evalúa el cliente/usuario y con la retroalimentación se refinan los requisitos del software
que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para

MC Genaro Alberto Gómez Chi Página 5 de 18

 Modelos de desarrollo de software

satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador
entienda mejor lo que se debe hacer.

De manera ideal, el prototipo debería servir como un mecanismo para identificar los
requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta
emplear los fragmentos del programa ya existentes o aplica herramientas (como
generadores de informes, administradores de ventanas, etcétera) que permiten producir
programas de trabajo con rapidez.

Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósito descrito?
Brooks [BRO75] ofrece una respuesta:

En la mayoría de los proyectos, el primer sistema construido apenas se utiliza. Tal vez sea
demasiado lento, muy grande o torpe en su uso, o reúna las tres características a la vez. No existe otra
opción que comenzar de nuevo, aunque sea doloroso, es lo mejor, y construir una revisión rediseñada en la
que se resuelvan estos problemas... Cuando se aplica un concepto nuevo de sistema o una tecnología
nueva, se tiene que construir un sistema in-servible y que sea necesario desechar, porque incluso la mejor
planeación no es omnisciente como para que el sistema esté perfecto desde la primera vez. Por lo tanto, la
pregunta de la administración no es si debe construirse un sistema piloto y desecharlo. Esto tendrá que
hacerse. La única pregunta es si se planea la construcción de un desechable o se promete entregárselo a
los clientes.

El prototipo puede servir como "primer sistema", el que Brooks recomienda dese-
char. Pero ésta tal vez sea una visión idealizada. Es verdad que a los clientes y los
desarrolladores les gusta el paradigma de construcción de prototipos. A los usuarios les
gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin
embargo, la construcción de prototipos también se torna problemática por las siguientes
razones:

1. El cliente ve lo que parece una versión en funcionamiento del software, sin saber
que el prototipo está unido "con chicle y cable para embalaje", que por la prisa de
hacerlo funcionar no se ha considerado la calidad del software global o la facilidad
de mantenimiento a largo plazo. Cuando se informa que el producto debe
construirse otra vez para mantener los altos niveles de calidad, el cliente no lo
entiende y pide la aplicación de "unos pequeños ajustes” para que se pueda
elaborar un producto final a partir del prototipo. Es muy frecuente que la gestión del
desarrollo de software sea muy lenta.
2. A menudo, el desarrollador establece compromisos de implementación para lograr
que el prototipo funcione con rapidez. Tal vez se utilice un sistema operativo o
lenguaje de programación inadecuado sólo porque está disponible y es conocido;
se puede implementar un algoritmo ineficiente sólo para mostrar capacidad.
Después de un tiempo, el desarrollador quizá se familiarice con estas selecciones y
olvide las razones por las que son inapropiadas. La selección menos ideal ahora se
convierte en una parte integral del sistema.

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser
un paradigma efectivo para la ingeniería del software. La clave es definir las reglas
del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de
acuerdo en que el prototipo se construya y sirva como un mecanismo para la definición de
requisitos, en que se descarte, al menos en parte, y en que después se desarrolle el
software real con un enfoque hacia la calidad.
MC Genaro Alberto Gómez Chi Página 6 de 18
 Modelos de desarrollo de software

El modelo en espiral.

El modelo en espiral, que Boehm [BOE88] propuso originalmente, es un modelo de

proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de
prototipos con los aspectos controlados y sistemáticos del modelo en cascada.
Proporciona el material para el desarrollo rápido de versiones increméntales del software.
Boehm [BOE01] describe este modelo de la siguiente manera:

El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el

riesgo que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con
múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es un enfoque cíclico para
el crecimiento incrementa! del grado de definición e implementación de un sistema, mientras disminuye su
grado de riesgo. La otra es un conjunto de puntos de fijación para asegurar el compromiso del usuario con
soluciones de sistema que sean factibles y mutuamente satisfactorias.

Cuando se aplica el modelo en espiral, el software se desarrolla en una serie dé

entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento
del modelo o un prototipo. Durante las últimas iteraciones se producen versiones cada vez
más completas del sistema desarrollado.

Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo

que define el equipo de ingeniería del
software. Para propósitos ilustrativos se
aprovechan las actividades genéricas del
marco de trabajo expuestas páginas atrás.
Cada una de las actividades del marco de
trabajo representa un segmento de la ruta en
espiral que se presenta en la figura. Cuando
comienza este proceso evolutivo el equipo de
software realiza actividades implicadas en un
circuito alrededor de la espiral que tiene una
dirección en el sentido del movimiento de las
manecillas del reloj, y que se inicia desde el
centro. El riesgo es un factor considerado en cada revolución. Los puntos de fijación —una
combinación de productos de trabajo y condiciones incluidas a lo largo de la ruta de la
espiral— se consideran para cada paso evolutivo.

El primer circuito alrededor de la espiral quizá genere el desarrollo de una espe-

cificación del producto; los pasos subsecuentes alrededor de la espiral se pueden
aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones más
elaboradas del software. Cada paso a través de la región de planeación resulta en ajustes
al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentación
derivada de la relación con el cliente después de la entrega. Además, el administrador del
proyecto ajusta el número de iteraciones planeado que se requiere para completar el
software.

A diferencia de otros modelos de proceso que terminan cuando se entrega el soft-

ware, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software
de computadora. Por lo tanto, el primer circuito alrededor de la espiral podría representar
un "proyecto de desarrollo del concepto", el cual se inicia en el centro de la espiral y

MC Genaro Alberto Gómez Chi Página 7 de 18

 Modelos de desarrollo de software

continúa por múltiples iteraciones hasta que el desarrollo del concepto esté completo. Si el
concepto se desarrollará en un producto real, el proceso continúa en la siguiente fase de
la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El nuevo producto
evolucionará a través de un número de iteraciones alrededor de la espiral. Después, un
circuito alrededor de la espiral se podría emplear para representar un "proyecto de
mejoramiento del producto". En esencia, la espiral, cuando se caracteriza de esta forma,
permanece operativa hasta que el software se retira. En ocasiones el proceso está
inactivo, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada
aprobado (por ejemplo, mejoramiento del producto).

El modelo en espiral es un enfoque realista para el desarrollo de software y de sis-

temas a gran escala. Como el software evoluciona conforme avanza el proceso, el
desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos en
cada etapa evolutiva. El modelo en espiral emplea la construcción de prototipos como un
mecanismo encaminado a reducir riesgos pero, en forma más importante, permite al
desarrollador la aplicación del enfoque de la construcción de prototipos en cualquier etapa
evolutiva del producto. Mantiene el enfoque sistemático de los pasos que sugiere el ciclo
de vida clásico, pero lo incorpora al marco de trabajo iterativo que refleja de forma más
verídica el mundo real. El modelo en espiral exige una consideración directa de los riesgos
técnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir
los riesgos antes de que se vuelvan problemáticos.

Así como otros paradigmas, el modelo en espiral no es una panacea. Es difícil

convencer a los clientes (en particular en situaciones bajo contrato) de que el enfoque
evolutivo es controlable, ya que se requiere una habilidad considerable para evaluar el
riesgo y se confía en dicha habilidad para obtener el éxito. Si un riesgo importante no se
descubre y administra, sin duda surgirán problemas.

El modelo de desarrollo concurrente.

El modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente,

se representa en forma esquemática como una serie de actividades del marco de trabajo,
acciones y tareas de la ingeniería del software y sus
estados asociados. Por ejemplo, la actividad de
modelado, definida para el modelo en espiral, se lleva
a cabo al invocar las acciones siguientes:
construcción de prototipos o modelado y especi-
ficación del análisis y diseño.

En la figura se proporciona un esquema de

una tarea de ingeniería de software relacionada con
la actividad de modelado para el modelo de proceso
concurrente. La actividad —modelado— puede estar
en alguno de los estados destacados mencionados
antes en cualquier momento dado. De forma similar,
otras actividades o tareas (por ejemplo, la
comunicación y la construcción) se representan de
una manera análoga. Todas las actividades existen
de forma concurrente, pero se encuentran en

MC Genaro Alberto Gómez Chi Página 8 de 18

 Modelos de desarrollo de software

diferentes estados. Por ejemplo, al principio del proyecto la actividad de comunicación (no
se muestra en la figura) ha completado su primera iteración y existe en el estado de en
espera de cambios. La actividad de modelado que existió en el estado ninguno mientras
se realizaba la comunicación inicial, ahora realiza una transición al estado en desarrollo.
Sin embargo, si el cliente indica cambios en los requisitos, la actividad de modelado se
mueve del estado en desarrollo al estado de en espera de cambios.

El modelo de proceso concurrente define una serie de eventos que dispararán

transiciones de estado a estado para cada una de las actividades, acciones o tareas de la
ingeniería del software. Por ejemplo, durante los primeros estados del diseño (una acción
de la ingeniería del software que ocurre en el curso de la actividad de modelación) no se
detecta una inconsistencia en el modelo del análisis. Esto genera el evento corrección del
análisis del modelo, el cual disparará la creación del análisis desde el estado realizado
hasta el estado de en espera de cambios.

El modelo de proceso concurrente se aplica a todos los tipos de desarrollo de soft-

ware y proporciona una visión exacta del estado actual de un proyecto. En lugar de
confinar las actividades, acciones y tareas de la ingeniería del software a una secuencia
de eventos, define una red de actividades. Cada actividad, acción o tarea en la red existe
de manera simultánea con otras actividades, acciones o tareas. Los eventos generados en
un punto de la red del proceso disparan transiciones entre los estados.

Un comentario final sobre los procesos evolutivos.

Ya se ha detectado que al software de computadoras moderno lo caracteriza el

cambio continuo, los tiempos de entrega muy reducidos, y una necesidad intensa de
satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es el
requisito de gestión más importante. Si se pierde una ventana del mercado, el mismo
proyecto de software puede perder su significado.

Los modelos evolutivos de procesos se concibieron para abocarse a estos aspectos

y, además, como modelos de proceso de clase general. Estos modelos también tienen
debilidades, las cuales se resumen a continuación:

A pesar de los incuestionables beneficios de los procesos evolutivos de software, se tienen algunas
dificultades con este tipo de procesos. La primera dificultad es que la construcción de prototipos [y otros
procesos evolutivos más elaborados] implican un problema para la planeación del proyecto debido al número
incierto de ciclos requeridos para construir el producto. La mayoría de las técnicas de gestión y estimación
de proyectos se basa en configuraciones lineales de las actividades, por lo que éstas no se ajustan por
completo.

La segunda dificultad es que los procesos evolutivos de software no establecen la velocidad máxima
de la evolución. Si las evoluciones suceden demasiado rápido, sin un periodo de relajación, existe la
certidumbre de que el proceso caerá en el caos. Por otro lado, si la velocidad es demasiado lenta, se podría
afectar la productividad.

Una tercera dificultad es que los procesos de software se deben enfocar en la flexibilidad y
extensibilidad en vez de en la alta calidad. Esta afirmación suena atemorizante. Sin embargo, se debe
priorizar la velocidad del desarrollo sobre los cero defectos. Si el desarrollo se extiende para alcanzar una
alta calidad, se produciría un retraso en la entrega del producto, la cual se haría cuando el nicho de

MC Genaro Alberto Gómez Chi Página 9 de 18

 Modelos de desarrollo de software
oportunidad ya haya desaparecido. Este cambio de paradigma lo impone la competencia en el borde del
caos.

En efecto, un proceso de software que se enfoca en la flexibilidad y la velocidad del

desarrollo por encima de la alta calidad suena atemorizante. Aun así, esta idea la ha
propuesto cierto número de respetados expertos en la ingeniería del software (por
ejemplo, [YOU95], [BAC97]).

El propósito de los modelos evolutivos es desarrollar software de alta calidad de

una manera iterativa o incremental. Sin embargo, es posible aplicar un proceso evolutivo
para destacar la flexibilidad, extensibilidad y velocidad del desarrollo. El reto para los
equipos de software y sus dirigentes es establecer un balance apropiado entre estos
parámetros críticos del proyecto y el producto, y el producto y la satisfacción del cliente (el
arbitro final de la calidad del software).

Modelos especializados de proceso.

Los modelos especializados de proceso adoptan muchas de las características de
uno o más de los modelos convencionales presentados en las secciones anteriores. Sin
embargo, los modelos especializados tienden a aplicarse cuando se ha elegido un
enfoque de ingeniería del software definido de una manera muy estrecha.

Desarrollo basado en componentes.

Los nuevos componentes de software comerciales (NCSC), desarrollados por

vendedores que los ofrecen como productos, se pueden emplear cuando el software está
en proceso de construcción. Estos componentes proporcionan funcionalidad dirigida con
interfaces bien definidas que permiten que el componente se integre en el software.

El modelo de desarrollo basado en componentes (DBC) incorpora muchas de las

características del modelo en espiral. Es evolutivo por naturaleza [NIE92] y exige un
enfoque iterativo para la creación del software. Sin embargo, el modelo configura
aplicaciones a partir de componentes de software empaquetados en forma previa.

Las actividades de modelado y construcción comienzan con la identificación de los

componentes candidatos. Estos componentes se pueden diseñar como módulos de
software convencionales o como clases o paquetes de clases orientados a objetos. Sin
importar la tecnología que se aplique en la creación de los componentes, el modelo de
desarrollo basado en componentes incorpora los siguientes pasos (implementados
mediante un enfoque evolutivo):

 Los productos basados en componentes disponibles se investigan y evalúan para el

dominio de aplicación en cuestión.
 Se consideran los aspectos de integración de componentes.
 Se diseña una arquitectura de software para adaptar los componentes.
 Los componentes se integran en la arquitectura.
 Se realizan pruebas detalladas para asegurar una funcionalidad apropiada.

MC Genaro Alberto Gómez Chi Página 10 de 18

 Modelos de desarrollo de software

El modelo de desarrollo basado en componentes conduce a la reutilización de

software, la cual proporciona beneficios a los ingenieros de software. Con base en
estudios de reutilización, QSM Associates, Inc. informa que el ensamblaje de
componentes conduce a una reducción de 70 por ciento del ciclo de desarrollo; 84 por
ciento del costo del proyecto y un índice de productividad de 26.2, comparado con
una norma de la industria de 16.9 [YOU94]. A pesar de que estos resultados están en
función de la robustez de la biblioteca de componentes, no hay duda de que el
modelo de desarrollo basado en componentes proporciona ventajas significativas
para los ingenieros de software.

El modelo de métodos formales.

El modelo de métodos formales comprende un conjunto de actividades que

conducen a la especificación matemática del software de computadora. Los métodos
formales permiten que un ingeniero de software especifique, desarrolle y verifique un
sistema basado en computadora al aplicar una notación matemática rigurosa. Algunas
organizaciones de desarrollo del software aplican en la actualidad una variación de este
enfoque, llamado ingeniería del software de sala limpia [MIL87, DYE92].

Cuando se utilizan métodos formales durante el desarrollo, éstos proporcionan un

mecanismo para eliminar muchos de los problemas difíciles de superar con otros
paradigmas de la ingeniería del software. La ambigüedad, el estado incompleto y la
inconsistencia se descubren y corrigen con mayor facilidad —no mediante una revisión ad
hoc, sino a través de la aplicación de un análisis matemático—. Cuando los métodos
formales se utilizan durante el diseño sirven como base para la verificación de programas
y, por consiguiente, permiten que el ingeniero de software descubra y corrija errores que
de otra manera podrían no haberse detectado.

A pesar de que aún no existe un enfoque establecido, los modelos de métodos

formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha
mencionado una gran preocupación acerca de su aplicabilidad en su entorno de gestión:

 En la actualidad, el desarrollo de modelos formales es muy caro y consume mucho

tiempo.
 Se requiere una capacitación detallada, debido a que pocos responsables del
desarrollo de software cuentan con los antecedentes necesarios para aplicar
métodos formales.
 Es difícil la utilización de estos modelos como un mecanismo de comunicación con
clientes que no tienen muchos conocimientos técnicos.

No obstante, tal vez el enfoque a través de métodos formales haya ganado adeptos
entre los desarrolladores de software que deben construir sistemas de alta seguridad (por
ejemplo, en los campos de la aeronáutica y de los dispositivos médicos), y entre los
desarrolladores que padecen severas penurias económicas cuando aparecen errores en el
software.

MC Genaro Alberto Gómez Chi Página 11 de 18

 Modelos de desarrollo de software

Desarrollo del software orientado a aspectos.

Sin importar el proceso de software que se elija, los constructores de software

complejo implementan de manera invariable un conjunto específico de características,
funciones y contenido de información. Estas características específicas del software se
modelan como componentes (por ejemplo, clases orientadas a objetos) y después se
construyen dentro del contexto de una arquitectura de sistema. Conforme los sistemas
basados en computadora se vuelven más elaborados (y complejos), ciertos "intereses" —
propiedades requeridas para el cliente o áreas de interés técnico— abarcan toda la
arquitectura. Algunos intereses son propiedades de alto nivel de un sistema (por ejemplo,
seguridad, falta de tolerancia). Otros intereses afectan las funciones (como la aplicación
de reglas de negocios), mientras que otros son sistémicos (como la sincronización de
tareas o la gestión de memoria).

Cuando los intereses se relacionan con múltiples funciones, características e

información del sistema, con frecuencia se denominan intereses generales. Los
requerimientos de aspectos definen estos intereses generales que ejercen un impacto a
través de la arquitectura del software. El desarrollo de software orientado a aspectos
(DSOA), referido con frecuencia como programación orientada a aspectos (POA), es un
paradigma de la ingeniería del software relativamente nuevo que proporciona un proceso y
enfoque metodológico para definir, especificar, diseñar y construir aspectos "mecanismos
más allá de subrutinas y legados para localizar la expresión de un interés general"
[ELR01].

Grundy [GRU02] explica con mayor profundidad los aspectos en el contexto de lo

que él llama ingeniería de componentes orientada a aspectos [ICOA]:

La ICOA utiliza un concepto de capas horizontales a través de componentes de software

descompuestos en forma vertical, llamados "aspectos", para caracterizar propiedades generales de los
componentes, los cuales pueden ser funcionales y no funcionales. Por lo general, los aspectos sistémicos
incluyen interfases con el usuario, trabajo en colaboración, distribución, persistencia, gestión de la memoria,
procesamiento de transiciones, seguridad, integridad y otros. Los componentes pueden proporcionar o
requerir uno o más "detalles de aspecto" relacionados con un aspecto particular, como un mecanismo de
visión, acceso extensible y tipo de interfase (aspectos de la interfase con el usuario); generación,
transportación y recepción de eventos (aspectos de distribución); almacenamiento/recuperación e indización
de datos (aspectos de persistencia); autentificación, codificación y derechos de acceso (aspectos de
seguridad); atomicidad de la transacción, control de concurrencia y control del transporte (aspectos de
transacción), y así sucesivamente. Cada detalle de aspecto tiene una serie de propiedades en relación con
características personales y no funcionales del detalle.

Hasta ahora no se ha concretado un proceso orientado a aspectos diferente. Sin

embargo, es probable que tal proceso adopte características de los modelos de proceso
en espiral y concurrente. La naturaleza evolutiva del modelo en espiral es apropiada
cuando se identifican y construyen los aspectos. La naturaleza paralela del desarrollo
concurrente es esencial porque los aspectos se desarrollan de manera independiente de
los componentes del software localizados y, aun así, los aspectos tienen un impacto
directo sobre estos componentes. Por lo tanto, resulta esencial implementar una
comunicación asincrónica entre las actividades del proceso de software aplicadas al
desarrollo y la construcción de aspectos y componentes.

MC Genaro Alberto Gómez Chi Página 12 de 18

 Modelos de desarrollo de software

El proceso unificado.
En su libro fundamental sobre el proceso unificado, Ivar Jacobson, Grady Booch y
James Rumbaugh [JAC99] exponen la necesidad de un proceso de software "guiado por
los casos de uso, de arquitectura céntrica, iterativo e incremental". Estos autores
establecen:

En la actualidad la tendencia en el software se encamina a sistemas mayores y complejos. Eso se

debe en parte al hecho de que las computadoras se volvían más poderosas cada año, lo que alentaba que
los usuarios esperaran más de ellas. Esta tendencia también la impulsó el uso expandido de Internet para el
intercambio de todo tipo de información. Nuestro apetito por un software cada vez más complejo crece en la
medida en la que aprendemos cómo puede mejorarse un producto desde que sale uno hasta que llega el
otro. Necesitamos un software que se adapte mejor a nuestras necesidades, pero que, a su vez, haga el
software más complejo. En resumen, queremos más.

De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los

mejores rasgos y características de modelos de procesos de software, pero los caracteriza
de manera que implementa muchos de los mejores principios del desarrollo ágil de
software. El proceso unificado reconoce la importancia de la comunicación con el cliente y
los métodos encaminados a describir el punto de vista del cliente con respecto a un
sistema (por ejemplo, el caso de uso). El PU enfatiza el importante papel de la arquitectura
de software, y "ayuda al arquitecto a enfocarse en las metas correctas, como el
entendimiento, el ajuste a los cambios futuros y la reutilización" [JAC99]. Sugiere un flujo
de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el
desarrollo del software moderno.

En esta sección se presenta una visión general de los elementos clave del proceso
unificado.

Una breve historia.

Durante la década de 1980 y al principio de la década siguiente, los métodos y

lenguajes de programación orientados a objetos (OO) obtuvieron una amplia difusión entre
la comunidad de la ingeniería del software. Durante el mismo periodo se propuso una
amplia variedad de análisis y diseño orientados a objetos (AOO y DOO) y se introdujo un
modelo de proceso orientado a objetos de propósito general (similar a los modelos
evolutivos presentados en este capítulo). Al igual que la mayoría de los paradigmas
"nuevos" para la ingeniería del software, los seguidores de cada uno de los métodos de
AOO y DOO argumentaban acerca de cuál de ellos era el mejor, pero ningún método o
lenguaje dominó la escena de la ingeniería del software.

Al principio de la década de 1990, James Rumbaugh [RUM91], Grady Booch

[BOO94] e Ivar Jacobson [JAC92] comenzaron a trabajar en un "método unificado"
que combinaría las mejores características de cada uno de sus métodos individuales
y adoptaría características adicionales que propusieran otros expertos (por ejemplo,
[WIR90]) en el campo OO. El resultado fue el lenguaje de modelado unificado (UML,
por sus siglas en inglés) —que contiene una notación robusta para el modelado y el
desarrollo de sistemas OO—. Para 1997, el UML se convirtió en un estándar de la
industria para el desarrollo de software orientado a objetos. Al mismo tiempo,

MC Genaro Alberto Gómez Chi Página 13 de 18

 Modelos de desarrollo de software

Rational Corporation y otras firmas desarrollaron herramientas automáticas para

apoyar los métodos del UML.

El UML proporciona la tecnología necesaria para apoyar la práctica de la ingeniería

del software orientada a objetos, pero no provee el marco de trabajo del proceso
que guíe a los equipos en la aplicación de la tecnología. En los años siguientes,
Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de trabajo
para la ingeniería del software orientada a objetos, mediante la utilización del
UML. En la actualidad, el proceso unificado y el UML se emplean de forma amplia en
proyectos OO de todos los tipos. El modelo iterativo e incremental que propone el
PU puede y debe adaptarse para satisfacer necesidades de proyecto específicas.

Como consecuencia de la aplicación del UML se puede producir un arreglo de

productos de trabajo (por ejemplo, modelos y documentos). Sin embargo, éstos los
reducen los ingenieros de software para lograr que el desarrollo sea más ágil y reactivo
ante el cambio.

Fases del proceso unificado.

Se han analizado cinco actividades genéricas del marco de trabajo y se ha

explicado que éstas se pueden aplicar para describir cualquier modelo de proceso del
software. El proceso unificado no es la excepción. En la siguiente figura se muestran las
"fases" del proceso unificado (PU).

La fase de inicio del PU abarca la

comunicación con el cliente y las
actividades de planeación. Al colaborar
con los clientes y usuarios finales se
identifican los requisitos de negocios
para el software, se propone una
arquitectura aproximada para el
sistema, y se desarrolla un plan para la
naturaleza iterativa e incremental del
sistema subsiguiente. Los requisitos
fundamentales de negocios se
describen a través de un conjunto
preliminar de casos de uso que
describen cuáles características y fun-
ciones son deseables para cada clase importante de usuarios. En general, un caso de uso
describe una secuencia de acciones que desarrolla un actor (por ejemplo, una persona,
una máquina, otro sistema) cuando éste interactúa con el software. Los casos de uso
ayudan a identificar el ámbito del proyecto y proporcionan una base para la planeación de
éste.

En este punto, la arquitectura no es más que un esquema tentativo de los

subsistemas más importantes y de las funciones y características que los forman.
Después, la arquitectura se refinará y expandirá en un conjunto de modelos que
representarán visiones diferentes del sistema. La planeación identifica recursos, evalúa los

MC Genaro Alberto Gómez Chi Página 14 de 18

 Modelos de desarrollo de software

riesgos importantes, define un itinerario y establece una base para las fases que se
aplicarán conforme se desarrolle el incremento del software.

La fase de elaboración abarca la comunicación con el cliente y las actividades de

modelado del modelo genérico del proceso. La elaboración refina y expande los casos de
uso preliminares que se desarrollaron como una parte de la fase de inicio; además,
expande la representación arquitectónica para incluir cinco visiones diferentes del
software: el modelo de caso de uso, el modelo de análisis, el modelo de diseño, el modelo
de implementación y el modelo de despliegue. En algunos casos, la elaboración crea una
"línea de base arquitectónica ejecutable" [ARL02] que representa un sistema ejecutable en
su "primer corte". La línea de base arquitectónica demuestra la viabilidad de la
arquitectura, pero no proporciona todas las características y funciones necesarias para
utilizar el sistema. Además, el plan se, revisa de manera cuidadosa al término de la fase
de elaboración para asegurar que el ámbito, los riesgos y los datos entregados aún son
razonables. Las modificaciones al plan se deben hacer en este momento.

La fase de construcción del PU es idéntica a la actividad de construcción definida

para el proceso genérico del software. Si se utiliza el modelo arquitectónico como entrada,
la fase de construcción desarrolla o adquiere los componentes del software que harán que
cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los
modelos de análisis y diseño iniciados durante la fase de elaboración se completen para
reflejar la versión final del incremento del software. Todas las características y funciones
necesarias y requeridas del incremento del software (por ejemplo, la entrega) se
implementan en código fuente. Conforme los componentes están en proceso de
implementación, se diseñan y ejecutan pruebas de unidad para cada uno de ellos.
Además, se realizan las actividades de integración (ensamblaje de componentes y
pruebas de integración). Los casos de uso se utilizan para derivar un conjunto de pruebas
de aceptación que se ejecutan antes del inicio de la siguiente fase del PU.

La fase de transición del PU abarca las últimas etapas de la actividad genérica de

construcción y la primera parte de la actividad genérica de despliegue. El software se
entrega a los usuarios finales para realizar pruebas beta, y la retroalimentación del usuario
reporta tanto defectos como cambios necesarios. Además, el equipo de software crea la
información de soporte necesaria (por ejemplo, manuales del usuario, guías de resolución
de problemas, procedimientos de instalación) para el lanzamiento. Al final de la fase de
transición, el incremento de software se convierte en un lanzamiento de software utilizable.

La fase de producción del PU coincide con la actividad de despliegue del proceso

genérico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona
el soporte para el ambiente operativo (infraestructura), y se reciben y evalúan los informes
de defectos y los requerimientos de cambios.

Es probable que mientras se realizan las fases de construcción, transición y

producción ya se hayan iniciado los trabajos para el siguiente incremento del software.
Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una
concurrencia por etapas.

A lo largo de las fases del PU se distribuye un flujo de trabajo de ingeniería del software.
En el contexto del PU, un flujo de trabajo es análogo a un conjunto de tareas. Esto es, un

MC Genaro Alberto Gómez Chi Página 15 de 18

 Modelos de desarrollo de software

flujo de trabajo identifica las tareas necesarias para completar una acción importante de
ingeniería del software y los productos de trabajo que se producen como consecuencia de la
realización exitosa de tareas. Se debe destacar que no todas las tareas identificadas para un
flujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptar
el proceso (acciones, tareas, subtareas y productos de trabajo) para satisfacer sus necesidades.

Productos de trabajo del proceso unificado.

En la siguiente figura se ilustran los productos de trabajo clave que se produjeron como
consecuencia de las cuatro fases técnicas del PU. Durante la fase de inicio, el propósito es
establecer una "visión" general
para el proyecto, identificar un
conjunto de requisitos de
negocios, formar un caso de
negocios para el software y
definir los riesgos del proyecto y
del negocio que pudieran
representar un obstáculo para el
éxito. Desde el punto de vista del
ingeniero de software, el
producto de trabajo más impor-
tante generado durante la etapa
de inicio es el modelo de caso de
uso: una colección de casos de
uso que describen la forma en
que actores externos ("usuarios" humanos y no humanos del software) interactúan con el
sistema y obtienen valor a partir de éste. En esencia, el modelo de casos de uso es una
colección de escenarios de uso con plantillas estandarizadas que implican características
y funciones del software mediante la descripción de una serie de condiciones previas, un
flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la
interacción representada. En un inicio, los casos de uso describen requisitos al nivel del
dominio de negocios (por ejemplo, el grado de abstracción es alto). Sin embargo, el
modelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve
como una entrada importante para la creación de productos de trabajo subsecuentes.
Durante la fase de inicio sólo se completa entre el 10 y 20 por ciento de los casos de uso.
Después de la elaboración, se ha creado entre un 80 y 90 por ciento del modelo.

La fase de elaboración produce un conjunto de productos de trabajo que elabora

requisitos (incluso requisitos no funcionales), así como una descripción arquitectónica y un
diseño preliminar. Cuando el ingeniero de software inicia con el análisis orientado a
objetos, el objetivo primordial es definir un conjunto de clases de análisis que describan en
forma adecuada el comportamiento del sistema. El modelo de análisis del PU es un
producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes
de clases y análisis (colecciones de clases) definidos como una parte del modelo de
análisis se refinan después en un modelo de diseño, el cual identifica clases de diseño,
subsistemas y las interfases entre los subsistemas. Los modelos de análisis y diseño
expanden y refinan una representación evolutiva de la arquitectura del software. Además,

MC Genaro Alberto Gómez Chi Página 16 de 18

 Modelos de desarrollo de software

en la fase de elaboración se revisan los riesgos y el plan de proyecto para asegurar que
cada uno de ellos conserve su validez.

La fase de construcción produce un modelo de implementación que traduce las

clases de diseño en componentes de software que se construirán para ejecutar el sistema,
y un modelo de despliegue convierte los componentes en el ambiente físico de
computación. Por último, un modelo de prueba describe las pruebas empleadas para
asegurar que los casos de uso se reflejen de manera apropiada en el software que se ha
construido.

La fase de transición entrega el incremento del software y evalúa los productos de

trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software.
En esta etapa se produce la retroalimentación proveniente de las pruebas beta y los
requerimientos cualitativos de cambio.

Resumen.

Los modelos prescriptivos del proceso de software se han aplicado durante muchos
años en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada
uno de estos modelos convencionales sugiere un flujo de proceso que de alguna forma es
diferente, pero todos realizan el mismo conjunto de actividades genéricas del marco de
trabajo: comunicación, planeación, modelado, construcción y despliegue.

El modelo en cascada sugiere una progresión lineal de actividades del marco de

trabajo que a menudo resulta inconsistente con la realidad moderna en el mundo del
software (por ejemplo, con el cambio continuo, los sistemas en evolución, las fechas de
entrega restringidas). Sin embargo, este modelo se puede aplicar en situaciones en las
cuales los requisitos están bien definidos y son estables.

Los modelos increméntales del proceso de software producen software como una
serie de entregas de incrementos. El modelo DRA está diseñado para proyectos gran
des que se deben entregar en marcos de tiempo muy reducidos.

Los modelos de proceso evolutivos reconocen la naturaleza evolutiva de la mayoría

de los proyectos de ingeniería del software y están diseñados para ajustarse al cambio.
Los modelos evolutivos, como el de construcción de prototipos y el modelo en espiral,
generan productos de trabajo increméntales (o versiones del software en funcionamiento)
con rapidez. Estos modelos se pueden adaptar para aplicarlos a través de todas las
actividades de la ingeniería del software: desde el desarrollo de conceptos hasta el
mantenimiento del sistema a largo plazo.

El modelo basado en componentes destaca la reutilización y ensambladura de

componentes. Los modelos de métodos formales conducen a la utilización de un
enfoque basado en las matemáticas para el desarrollo y la verificación del software.

El modelo orientado a aspectos incluye los intereses generales que cubren la arqui-
tectura total del sistema.

MC Genaro Alberto Gómez Chi Página 17 de 18

 Modelos de desarrollo de software

El proceso unificado es un proceso de software "guiado por los casos de uso, de

arquitectura céntrica, iterativo e incremental" diseñado como un marco para los métodos y
herramientas del UML. El proceso unificado es un modelo incremental en el que se
definen cinco fases:

1) una fase de inicio que abarca la comunicación con el cliente y las actividades de
planeación, y destaca el desarrollo y el refinamiento de casos de uso como un
modelo primario;
2) una fase de elaboración que abarca la comunicación con el cliente y las actividades
de modelado con un enfoque en la creación de modelos de análisis y diseño, con
énfasis en las definiciones de clase y representaciones arquitectónicas;
3) una fase de construcción que refina y después traduce el modelo de diseño en
componentes de software implementados;
4) una fase de transición que transfiere el software del desarrollador al usuario final
para realizar las pruebas beta y obtener la aceptación; y
5) una fase de producción en la cual se realiza el monitoreo continuo y el soporte.

MC Genaro Alberto Gómez Chi Página 18 de 18