Modelos Prescriptivos

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

3 ¿Por qué se les llama modelo prescriptivos?

Se les llama “prescriptivos”, por que prescriben un conjunto de elementos del proceso: actividades de
marco de trabajo, acciones de ingeniería del software, tareas, productos de trabajo, aseguramiento de
la calidad y mecanismos de control de cambio para cada proyecto.

4 Flujo de trabajo

Cada modelo de proceso prescribe un flujo de trabajo; esto es, la forma en que los elementos del
proceso se interrelacionan entre si.

5 Modelo de cascada

Existen ocasiones en que los requisitos de un problema se entienden de manera razonable: cuando el
trabajo fluye desde la comunicación hasta despliegue de manera lineal. El modelo cascada algunas
veces llamado 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 terminar con el soporte del software
terminado.

6 Modelo cascada

Este modelo se aplica en situaciones de actualización de un software, como un sistema contable

cuando el gobierno ha dictado nuevas regulaciones. También se aplica a un número limitado de nuevos
proyectos, solamente cuando están bien definidos los requerimientos y son estables en forma
razonable.

7 Problemas al aplicar el modelo de cascada

Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. Con frecuencia
es difícil para el cliente establecer todos los requisitos de manera explícita. El cliente debe tener
paciencia. Una versión que funcione del programa estará disponible cuando el proyecto esté muy
avanzado .En la actualidad el trabajo de 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 de
cascada no es apropiado para dicho trabajo. El modelo de cascada puede ser útil en situaciones donde
los requerimientos están fijos y donde el trabajo se realiza hasta su conclusión de una manera lineal.

Modelos Prescriptivos

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

3 ¿Por qué se les llama modelos prescriptivos?

Se les llama “prescriptivos”, porque prescriben un conjunto de elementos del proceso: actividades de
marco de trabajo, acciones de ingeniería del software, tareas, productos de trabajo, aseguramiento de
la calidad y mecanismos de control de cambio para cada proyecto.

4 Flujo de trabajo

Cada modelo de proceso prescribe un flujo de trabajo; esto es, la forma en que los elementos del
proceso se interrelacionan entre si.

8 Modelos de procesos incrementales

El modelo incremental El modelo DRA (Desarrollo Rápido de Aplicaciones)

El modelo incremental combina elementos de la modelo cascada aplicado en forma iterativa. El modelo
incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el
calendario. Cada secuencia lineal produce incrementos de software.

En el modelo incremental el primer incremento es un producto esencial (se incorporan los requisitos
básicos, pero muchas características suplementarias 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 elabora
un plan para el incremento siguiente. El plan afronta la modificación del producto esencial con el fin de
satisfacer de mejor manera la necesidad del cliente y la entrega de características y funcionalidad
adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya
elaborado el producto completo
Modelos Prescriptivos

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

3 ¿Por qué se les llama modelo prescriptivos?

Se les llama “prescriptivos”, por que prescriben un conjunto de elementos del proceso: actividades de
marco de trabajo, acciones de ingeniería del software, tareas, productos de trabajo, aseguramiento de
la calidad y mecanismos de control de cambio para cada proyecto.

4 Flujo de trabajo

Cada modelo de proceso prescribe un flujo de trabajo; esto es, la forma en que los elementos del
proceso se interrelacionan entre si.

Desarrollo rápido de aplicaciones

El modelo DRAEl Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso de software

incremental que resalta un ciclo de desarrollo corto. El DRA es una adaptación de “alta velocidad” del
modelo de cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción
basado en componentes Sí se entienden bien los requisitos y se limita el ámbito del proyecto DRA
permite que un equipo de desarrollo cree un “sistema completamente funcional” en un periodo corto de
tiempo (60 a 90 días)

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 se orienta para que varios equipos de software trabajen en
paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases –modelado de
negocios, modelado de datos y modelado de proceso- y establece representaciones del diseño que
sirve 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 la base para las iteraciones subsecuentes si estas son necesarias.
Inconvenientes del modelo DRA
Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear el
número correcto de equipos DRASi 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 de DRA fallarán.Si un sistema no se puede modular en forma apropiada, la construcción de
los componentes necesarios para el DRA será problemática.

Modelos Prescriptivos

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

3 ¿Por qué se les llama modelos prescriptivos?

Se les llama “prescriptivos”, porque prescriben un conjunto de elementos del proceso: actividades de
marco de trabajo, acciones de ingeniería del software, tareas, productos de trabajo, aseguramiento de
la calidad y mecanismos de control de cambio para cada proyecto.

4 Flujo de trabajo

Cada modelo de proceso prescribe un flujo de trabajo; esto es, la forma en que los elementos del
proceso se interrelacionan entre si.

Modelo de procesos evolutivos

El software como todos los sistemas complejos evolucionan con el tiempo. Los requisitos de los
negocios y productos a menudo cambian como 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 se tiene que presentar una versión limitada para liberar
la presión competitiva y de negocios.

Modelo de procesos evolutivos

En esta y otra situaciones similares, los ingenieros de software necesitan un modelo de proceso que
haya sido diseñado de manera explícita para incluir un producto que evolucione con el tiempo. Los
modelos evolutivos son interactivos; los caracteriza la forma en que permiten que los ingenieros de
software desarrollen versiones

Estos modelos se aplican cuando se reconoce la naturaleza evolutiva del proyecto  de

ingeniería de software.

 Están diseñados para ajustarse al cambio durante el desarrollo del proyecto.

 En este tipo de modelos se tiene el modelo de construcción de prototipos, el modelo en espiral
y el modelo de desarrollo concurrente.

Modelo de construcción de prototipos

 En la práctica, la construcción de prototipos ayuda al ingeniero de sistemas y al cliente

a entender de mejor manera cuál será el resultado de la construcción cuando los
requisitos estén satisfechos.

Desventajas
  El cliente considera la mayoría de las veces al prototipo como el producto final.
 La calidad del software o la factibilidad de mantenimiento puede que no se
tomen en cuenta.

19 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
más necesaria más definición. Entonces se plantea con rapidez una interacción de construcción de
prototipos y se presenta el modelado (en la forma de un diseño rápido.

20 Construcción de prototipos…

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 los
formatos de despliegue de salida El diseño rápido conduce a la construcción de un prototipo. Después
el prototipo es evaluado por el cliente y con la retroalimentación se refinan los requisitos del software
que se desarrollará. La Interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades
del cliente.

21 ¿qué se debe hacer con el prototipo?

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…

22 Problema de la construcción de prototipos

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.
Modelo en espiral

 Conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos

controlados y sistemáticos del modelo en cascada.
 Se basa principalmente en una serie de ciclos repetitivos, donde cada ciclo empieza
identificando:
o Los objetivos de la fase correspondiente.
o Las alternativas.
o Las restricciones. 
 Se centra en algunas prácticas fundamentales del desarrollo de software, tales como la
orientación al manejo de riesgos, la orientación al cliente y el desarrollo iterativo.

Ventajas

 Tiene un enfoque de reutilización de componentes.

 Permite la eliminación de errores con base en información descubierta en
fases iniciales.
 Permite la evaluación en cada fase, así como cambios en los objetivos.
 Integra la actividad del desarrollo con el mantenimiento.
 Como el software evoluciona, a medida que progresa el proceso, el
desarrollador y el cliente comprenden y reaccionan mejor ante situaciones y
decisiones en cada uno de los niveles evolutivos.
 Permite aplicar el enfoque de construcción de prototipos en cualquier etapa de
evolución del producto.
 Demanda una consideración directa de los riesgos técnicos en todas las
etapas del proyeco, reduciéndolos antes de que se conviertan en problemas.

Desventajas

 El cliente puede entrar en una situación de impaciencia debido a que se le van

presentando modelos y funciones diferentes en cada etapa evolutiva del
desarrollo del sistema.
 Este modelo requiere de experiencia en la identificación de riesgos, debido a
los riesgos que pueden aparecer en cada etapa de desarrollo.

 
 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
solo por que es conocido y esta disponible.