INGENIERÍA DE

SOFTWARE I
Ing. Angel Ochoa Flores, MSc.
[email protected]
 MODELOS
DEL PROCESO DE SOFTWARE
MODELOS DE PROCESO PRESCRIPTIVO

Los modelos de proceso prescriptivo fueron propuestos originalmente para poner

orden en el caos del desarrollo de software.
La historia indica que estos modelos tradicionales han dado cierta estructura útil al
trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz
para los equipos de software.
Sin embargo, el trabajo de ingeniería de software y el producto que genera siguen
“al borde del caos”.
Todos los modelos del proceso del software pueden incluir las actividades
estructurales generales descritas anteriormente, pero cada una pone distinto
énfasis en ellas y define en forma diferente el flujo de proceso que invoca cada
actividad estructural (así como acciones y tareas de ingeniería de software).
Modelo de la cascada
Hay veces en las que los requerimientos para cierto problema se
comprenden bien: cuando el trabajo desde la comunicación hasta el
despliegue fluye en forma razonablemente lineal.
El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere
un enfoque sistemático y secuencial para el desarrollo del software,
que comienza con la especificación de los requerimientos por parte del
cliente y avanza a través de planeación, modelado, construcción y
despliegue, para concluir con el apoyo del software terminado.
Modelo de la cascada
Una variante de la representación del modelo de la cascada se
denomina modelo en V. En la figura siguiente se ilustra el modelo en V,
donde se aprecia la relación entre las acciones para el aseguramiento
de la calidad y aquellas asociadas con la comunicación, modelado y
construcción temprana.

A medida que el equipo de software avanza hacia abajo desde el lado

izquierdo de la V, los requerimientos básicos del problema mejoran
hacia representaciones técnicas cada vez mas detalladas del problema
y de su solución.
Una vez que se ha generado el código, el equipo sube por el lado
derecho de la V, y en esencia ejecuta una serie de pruebas (acciones
para asegurar la calidad) que validan cada uno de los modelos creados
cuando el equipo fue hacia abajo por el lado izquierdo.

En realidad, no hay diferencias fundamentales entre el ciclo de vida

clásico y el modelo en V. Este ultimo proporciona una forma de
visualizar el modo de aplicación de las acciones de verificación y
validación al trabajo de ingeniería inicial.
El modelo en V
El modelo de la cascada es el paradigma mas antiguo de la ingeniería
de software. Sin embargo, en las ultimas décadas, las criticas hechas al
modelo han ocasionado que incluso sus defensores mas obstinados
cuestionen su eficacia. Entre los problemas que en ocasiones surgen al
aplicar el modelo de la cascada se encuentran los siguientes:
1. Es raro que los proyectos reales sigan el flujo secuencial propuesto
por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace
en forma indirecta. Como resultado, los cambios generan confusión
conforme el equipo del proyecto avanza.
2. A menudo, es difícil para el cliente enunciar en forma explicita
todos los requerimientos. El modelo de la cascada necesita que se
haga y tiene dificultades para aceptar la incertidumbre natural que
existe al principio de muchos proyectos.
3. El cliente debe tener paciencia. No se dispondrá de una versión
funcional del(de los) programa(s) hasta que el proyecto este muy
avanzado. Un error grande seria desastroso si se detectara hasta
revisar el programa en funcionamiento.
Modelos de proceso incremental
Hay muchas situaciones en las que los requerimientos iniciales del software están
razonablemente bien definidos, pero el alcance general del esfuerzo de desarrollo
imposibilita un proceso lineal.
Además, tal vez haya una necesidad imperiosa de dar rápidamente cierta
funcionalidad limitada de software a los usuarios y aumentarla en las entregas
posteriores de software. En tales casos, se elige un modelo de proceso diseñado para
producir el software en incrementos.
El modelo incremental combina elementos de los flujos de proceso lineal y paralelo,
el modelo incremental aplica secuencias lineales en forma escalonada a medida que
avanza el calendario de actividades.
Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse
de manera parecida a los incrementos producidos en un flujo de proceso evolutivo.
Cuando se utiliza un modelo incremental, es frecuente que el primer
incremento sea el producto fundamental. Es decir, se abordan los
requerimientos básicos, pero no se proporcionan muchas
características suplementarias (algunas conocidas y otras no).
El cliente usa el producto fundamental (o lo somete a una evaluación
detallada). Como resultado del uso y/o evaluación, se desarrolla un
plan para el incremento que sigue.
El plan incluye la modificación del producto fundamental para cumplir
mejor las necesidades del cliente, así como la entrega de características
adicionales y mas funcionalidad.
Este proceso se repite después de entregar cada incremento, hasta
terminar el producto final.

El modelo de proceso incremental se centra en que en cada incremento

se entrega un producto que ya opera.

Los primeros incrementos son versiones desnudas del producto final,

pero proporcionan capacidad que sirve al usuario y también le dan una
plataforma de evaluación.
El desarrollo incremental es útil en particular cuando no se dispone de
personal para la implementación completa del proyecto en el plazo
establecido por el negocio. Los primeros incrementos se desarrollan
con pocos trabajadores.

Si el producto básico es bien recibido, entonces se agrega mas personal

(si se requiere) para que labore en el siguiente incremento. Además, los
incrementos se planean para administrar riesgos técnicos.
Por ejemplo, un sistema grande tal vez requiera que se disponga de
hardware nuevo que se encuentre en desarrollo y cuya fecha de
entrega sea incierta.

En este caso, tal vez sea posible planear los primeros incrementos de
forma que eviten el uso de dicho hardware, y así proporcionar una
funcionalidad parcial a los usuarios finales sin un retraso importante.
El modelo incremental
Modelos de proceso evolutivo
El software, como todos los sistemas complejos, evoluciona en el tiempo. Es
frecuente que los requerimientos del negocio y del producto cambien conforme
avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria
rectilínea hacia el producto final; los plazos apretados del mercado hacen que sea
imposible la terminación de un software perfecto, pero debe lanzarse una versión
limitada a fin de aliviar la presión de la competencia o del negocio; se comprende
bien el conjunto de requerimientos o el producto básico, pero los detalles del
producto o extensiones del sistema aun están por definirse.
En estas situaciones y otras parecidas se necesita un modelo de proceso diseñado
explícitamente para adaptarse a un producto que evoluciona con el tiempo.
Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que
permiten desarrollar versiones cada vez mas completas del software.
A continuación se presentan dos modelos comunes de proceso evolutivo.
Hacer prototipos
Es frecuente que un cliente defina un conjunto de objetivos generales para el
software, pero que no identifique los requerimientos detallados para las funciones
y características.
En otros casos, el desarrollador tal vez no este seguro de la eficiencia de un
algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debe
adoptar la interacción entre el humano y la maquina. En estas situaciones, y
muchas otras, el paradigma de hacer prototipos tal vez ofrezca el mejor enfoque.
Aunque es posible hacer prototipos como un modelo de proceso aislado, es mas
común usarlo como una técnica que puede implementarse en el contexto de
cualquiera de los modelos de proceso descritos. Sin importar la manera en la que
se aplique, el paradigma de hacer prototipos le ayudara a usted y a otros
participantes a mejorar la comprensión de lo que hay que elaborar cuando los
requerimientos no están claros.
El paradigma de hacer prototipos comienza con comunicación. Usted se
reúne con otros participantes para definir los objetivos generales del
software, identifica cualesquiera requerimientos que conozca y detecta
las áreas en las que es imprescindible una mayor definición.

Se planea rápidamente una iteración para hacer el prototipo, y se lleva

a cabo el modelado (en forma de un “diseño rápido”).

Este se centra en la representación de aquellos aspectos del software

que serán visibles para los usuarios finales (por ejemplo, disposición de
la interfaz humana o formatos de la pantalla de salida).
El diseño rápido lleva a la construcción de un prototipo. Este se entrega
y es evaluado por los participantes, que dan retroalimentación para
mejorar los requerimientos. La iteración ocurre a medida de que el
prototipo es afinado para satisfacer las necesidades de distintos
participantes, y al mismo tiempo le permite a usted entender mejor lo
que se necesita hacer.

El ideal es que el prototipo sirva como mecanismo para identificar los

requerimientos del software. Si va a construirse un prototipo, pueden
utilizarse fragmentos de programas existentes o aplicar herramientas
(por ejemplo, generadores de reportes y administradores de ventanas)
que permitan generar rápidamente programas que funcionen.
El paradigma de hacer prototipos
Tanto a los participantes como a los ingenieros de software les gusta el
paradigma de hacer prototipos. Los usuarios adquieren la sensación del
sistema real, y los desarrolladores logran construir algo de inmediato.
Hacer prototipos llega a ser problemático por las siguientes razones:

1. Los participantes ven lo que parece ser una versión funcional del software, sin
darse cuenta de que el prototipo se obtuvo de manera rápida; no perciben que
en la prisa por hacer que funcionara, usted no considero la calidad general del
software o la facilidad de darle mantenimiento a largo plazo. Cuando se les
informa que el producto debe rehacerse a fin de obtener altos niveles de
calidad, los participantes gritan que es usted un tonto y piden “unos cuantos
arreglos” para hacer del prototipo un producto funcional. Con demasiada
frecuencia, el gerente de desarrollo del software cede.
2. Como ingeniero de software, es frecuente que llegue a compromisos respecto
de la implementación a fin de hacer que el prototipo funcione rápido. Quizá
utilice un sistema operativo inapropiado, o un lenguaje de programación tan
solo porque cuenta con el y lo conoce; tal vez implemento un algoritmo
ineficiente solo para demostrar capacidad. Después de un tiempo, quizá se
sienta cómodo con esas elecciones y olvide todas las razones por las que eran
inadecuadas. La elección de algo menos que lo ideal ahora ha pasado a formar
parte del sistema.

Aunque puede haber problemas, hacer prototipos es un paradigma eficaz para la

ingeniería de software. La clave es definir desde el principio las reglas del juego; es
decir, todos los participantes deben estar de acuerdo en que el prototipo sirva
como el mecanismo para definir los requerimientos.
El modelo espiral
Es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer
prototipos con los aspectos controlados y sistémicos del modelo de cascada.
Tiene el potencial para hacer un desarrollo rápido de versiones cada vez mas completas.
Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas.
Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las
iteraciones posteriores se producen versiones cada vez mas completas del sistema cuya ingeniería
se esta haciendo.
Un modelo en espiral es dividido por el equipo de software en un conjunto de actividades
estructurales. Para fines ilustrativos, se utilizan las actividades estructurales generales ya analizadas.
Cada una de ellas representa un segmento de la trayectoria espiral ilustrada en la figura siguiente.
Al comenzar el proceso evolutivo, el equipo de software realiza actividades implícitas en un circuito
alrededor de la espiral en el sentido horario, partiendo del centro. El riesgo se considera conforme
se desarrolla cada revolución.
En cada paso evolutivo se marcan puntos de referencia puntuales: combinación de productos del
trabajo y condiciones que se encuentran a lo largo de la trayectoria de la espiral.
Modelo de espiral común
El modelo espiral
El primer circuito alrededor de la espiral da como resultado el
desarrollo de una especificación del producto; las vueltas sucesivas
se usan para desarrollar un prototipo y, luego, versiones cada vez
mas sofisticadas del software.
Cada paso por la región de planeación da como resultado ajustes en
el plan del proyecto.
El costo y la programación de actividades se ajustan con base en la
retroalimentación obtenida del cliente después de la entrega.
Además, el gerente del proyecto ajusta el numero planeado de
iteraciones que se requieren para terminar el software.
A diferencia de otros modelos del proceso que finalizan cuando se
entrega el software, el modelo espiral puede adaptarse para aplicarse a
lo largo de toda la vida del software de computo.

Entonces, el primer circuito alrededor de la espiral quizá represente un

“proyecto de desarrollo del concepto” que comienza en el centro de la
espiral y continua por iteraciones múltiples hasta que queda terminado
el desarrollo del concepto.

Si el concepto va a desarrollarse en un producto real, el proceso sigue

hacia fuera de la espiral y comienza un “proyecto de desarrollo de
producto nuevo”.
El nuevo producto evolucionara a través de cierto numero de
iteraciones alrededor de la espiral. Mas adelante puede usarse un
circuito alrededor de la espiral para que represente un “proyecto de
mejora del producto”.

En esencia, la espiral, cuando se caracteriza de este modo, sigue

operativa hasta que el software se retira. Hay ocasiones en las que el
proceso esta inmóvil, pero siempre que se inicia un cambio comienza
en el punto de entrada apropiado (por ejemplo, mejora del producto).
Modelos concurrentes
El modelo de desarrollo concurrente, en ocasiones llamado ingeniería
concurrente, permite que un equipo de software represente elementos
iterativos y concurrentes de cualquiera de los modelos de proceso
descritos.
Por ejemplo, la actividad de modelado definida para el modelo espiral
se logra por medio de invocar una o mas de las siguientes acciones de
software: hacer prototipos, análisis y diseño.
Un elemento del modelo
de proceso concurrente
La figura muestra la representación esquemática de una actividad de
ingeniería de software dentro de la actividad de modelado con el uso
del enfoque de modelado concurrente.
La actividad —modelado— puede estar en cualquiera de los estados
mencionados en un momento dado. En forma similar, es posible
representar de manera análoga otras actividades, acciones o tareas
(por ejemplo, comunicación o construcción).
Todas las actividades de ingeniería de software existen de manera
concurrente, pero se hallan en diferentes estados.
El modelado concurrente es aplicable a todos los tipos de desarrollo de
software y proporciona un panorama apropiado del estado actual del
proyecto. En lugar de confinar las actividades, acciones y tareas de la
ingeniería de software a una secuencia de eventos, define una red del
proceso.
Cada actividad, acción o tarea de la red existe simultáneamente con
otras actividades, acciones o tareas. Los eventos generados en cierto
punto de la red del proceso desencadenan transiciones entre los
estados.
El objetivo de los modelos evolutivos es desarrollar software de alta
calidad en forma iterativa o incremental. Sin embargo, es posible usar
un proceso evolutivo para hacer énfasis en la flexibilidad,
expansibilidad y velocidad del desarrollo.
El reto para los equipos de software y sus administradores es establecer
un balance apropiado entre estos parámetros críticos del proyecto, el
producto, y la satisfacción del cliente (arbitro definitivo de la calidad del
software).