MODELOS PRESCRIPTIVOS

Transcripción

1 MODULO II Ingeniería de Software INF MODELOS PRESCRIPTIVOS Resumen preparado por Miguel Cotaña 1

2 Los modelos prescriptivos de proceso proporcionan estabilidad, control y organización a una actividad que si no se controla puede volverse caótica. El proceso conduce a un equipo de software a través de un conjunto de actividades del marco de trabajo que se organizan en un flujo de proceso, el cual puede ser lineal, incremental o evolutivo. 2

3 Se les llama prescriptivos porque prescriben un conjunto de elementos del proceso: Actividades del marco de trabajo, Acciones de la IS, Tareas, Productos del trabajo, Aseguramiento de la calidad, Mecanismos de control del cambio para cada proyecto. 3

4 Modelo en cascada Algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático secuencial hacia el desarrollo de software. Se considera 5 etapas: Comunicación Inicio proyecto Recopilación req Planeación estimación itinerario seguimiento Modelado análisis diseño Construcción código prueba Despliegue Entrega Soporte retroalimentacion 4

5 Entre los problemas al aplicar el modelo: 1.- Son raros los proyectos que siguen un flujo secuencial, a pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. 2.- Con frecuencia es difícil para el cliente especificar todos los requisitos de manera exacta. 3.- El cliente debe tener paciencia. Una versión estará disponible sólo cuando el proyecto esté muy avanzado. 5

6 El modelo en cascada conduce a estados de bloqueo (Bradac) en los cuales algunos miembros del equipo deben esperar a otros para terminar tareas dependientes. Sin embargo, sirve como modelo de proceso útil en situaciones donde los requerimientos son claros y completos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal. 6

7 Modelos de procesos incrementales El modelo incremental: El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce incrementos del software. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos. 7

8 Al utilizar el modelo incremental, el primer incremento es un producto esencial, se incorporan requisitos básicos. Este producto queda en manos del cliente (o se somete a una evaluación). Como resultado de la evaluación se desarrolla un plan para el siguiente incremento. El plan afronta la modificación del producto esencial afin de satisfacer necesidades del cliente. Este procesos se repite hasta la entrega final. 8

9 Funcionalidad y caractérísticas del Sw Combina elementos del modelo en cascada aplicado en forma iterativa. Incremento #n Incremento #2 Entrega del n-ésimo incremento Incremento #1 Entrega del 2do. incremento Entrega del 1er. incremento Tiempo del calendario de proyecto 9

10 El modelo DRA El Desarrollo Rápido de Aplicaciones 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 mediante un enfoque de construcción basado en componentes. Si se entiende los requisitos y el dominio del proyecto. El proceso DRA permite crear un sistema completamente funcional dentro de un periodo muy corto. 10

11 Equipo #n Modelado Modelado del negocio Modelado de los datos Modelado del proceso comunicación Equipo #2 Modelado Modelado del negocio Modelado de los datos Modelado del proceso construcción Reutilización componentes Generación de código pruebas planeación Equipo #1 Modelado Modelado del negocio Modelado de los datos construcción Reutilización componentes Generación de código pruebas despliegue integración entrega retroalimentación Modelado del proceso construcción Reutilización componentes Generación de código pruebas días 11

12 Las restricciones de tiempo impuestas sobre un proyecto DRA exigen ámbito de escalas. Si una aplicación de negocios se puede modular de forma que cada gran función pueda completarse en menos de tres meses, é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. 12

13 Modelos de procesos evolutivos El software, al igual que todos los sistemas complejos, evolucionan 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 fechas tope del mercado imposibilitan la conclusión de un producto completo. 13

14 Construcción de prototipos Con frecuencia 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 de software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un SO. En estas y en otras situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque 14

15 Un prototipo se puede usar de manera independiente, se emplea más comúnmente como una técnica que puede implementarse dentro del contexto de cualquiera de los modelos de proceso. La construcción de prototipos ayuda al IS y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. 15

16 La construcción de prototipos se inicia con la comunicación. El IS 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 modelo (en la forma de un diseño rápido). 16

17 El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente (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 y con la retroalimentación se refinan los requisitos del software que se desarrollará. 17

18 La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. 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 que permita producir programas de trabajo con rapidez. 18

19 Plan rápido comunicación Modelado Diseño rápido Desarrollo Entrega y retroalimentación Construcción del prototipo Modelo de construcción de prototipos 19

20 Identificar los requerimientos Desarrollar un prototipo Utililizar el prototipo Prototipo funcional SI Usuario satisfecho? NO Revisar y mejorar el prototipo 20

21 Desventajas a) El cliente ve lo que parece una versión en funcionamiento del software, sin saber que el prototipo (por la prisa de hacerlo funcionar) no considera calidad y facilidad de mantenimiento a largo plazo. b) Frecuentemente, el desarrollador establece compromisos de implementación para lograr que el prototipo funcione con rapidez 21

22 El modelo en espiral El modelo en espiral que Boehm 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 incrementales del software. 22

23 Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de 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 mas completas del sistema desarrollado. 23

24 Un proceso en espiral se divide en un conjunto de actividades del marco de trabajo que define el equipo de IS. Cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral. Cuando comienza este proceso evolutivo el equipo de software realiza actividades implicadas en un circuito alrededor de la espiral y que se inicia desde el centro. 24

25 comunicación Estimación Itinerario Analisis de riesgos Planeación modelado Reingeniería Desarrollo de Mejora de la Nueva Aplicación la Aplicación Mantenimiento de la Aplicación Desarrollo del concepto Analisis diseño despliegue Entrega retroalimentación Codigo construcción construcción 25

26 El factor riesgo es 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 especificación del producto; los pasos siguientes se pueden aprovechar para desarrollar un prototipo y después, en forma progresiva, versiones más elaboradas del software. 26