Modelo Prescriptivos de proceso

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.

¿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.

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 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.

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.

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 poryecto 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 de procesos incrementales El modelo incremental El modelo DRA (Desarrollo Rápido de Aplicaciones)

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

Modelo incremental 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

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 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 Si 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 iteracciones 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 DRA 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 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.

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

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. El responsable del desarrollo del software esta inseguro de la eficacia de un algoritmo. En estas y otras situaciones un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.

El paradigma de 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.

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 mas necesaria mas 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.

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.

¿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 reuna 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…

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. 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.