MODELOS PRESCRIPTIVOS DE PROCESO Se propusieron originalmente para ordenar el caos del desarrollo de software. Un modelo prescriptivos llena el marco de trabajo con conjuntos de tareas explicitas para las acciones de la ingeniería de software. Los modelos de prescripción del prescriben un conjunto de elementos del proceso; actividades del marco de trabajo, acciones de ingeniería del software, tareas, productos del trabajo, aseguramiento de la calidad, y mecanismos del control del cambio para cada proyecto. Cada modelo de proceso prescribe también un flujo de trabajo; esto es, la forma en la cual los elementos del proceso se interrelacionan entre sí. EL MODELO DE CASCADA Llamado el ciclo de vida clásico, un enfoque sistemático, secuencia hacia el desarrollo del software, que se inicia con la especificación de requerimiento 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. Entre los problemas que aplicar el modelo en cascada están: 1.- Es muy raro que los proyectos reales sigan el flujo secuencia que propone modelo, los cambios confunden mientras el equipo de proyecto actúa. 2.-Es difíciles para el cliente establecer todo los requisitos de manera explícita. 3.- El cliente debe tener paciencia. EL MODELO INCREMENTAL Combina elemento del modelo en casada aplicado en forma iterativa, aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce “incrementos” del software. Al utilizar un modelo incrementa el primero incremento es un producto esencial. Se incorporan los requisitos básicos pero muchas características suplementarias. El producto esencial queda en manos del cliente como resultado de la evaluación se desarrolla un plan para el incremento siguiente. El modelo de proceso incrementado, es iterativo por naturaleza se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones “incompletas” del producto final. EL MODELO DRA El desarrollo rápido de aplicaciones es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. Una adaptación “alta velocidad” del modelo en cascada en el que se logra el desarrollo rápidamente un enfoque de construcción basado en componentes. Cumple con las actividades genéricas del marco de trabajo. La comunicación traba para entender el problema de negocios y las características de información que del incluir el software. La planeación trabaja en paralelo sobre diferentes funciones del sistema. El modelado – modelado de negocios, datos y proceso. La construcción resalta el empleo de componente de software existente y la aplicación de la generación automática de código. Inconvenientes 1.- Para proyectos grandes suficientes recursos humanos 2.-Para los desarrolladores y clientes no se comprometen con las actividades rápidas, los proyectos de DRA fallan 3.-Si un sistema no se puede modular en forma apropiada, la construcción será problemática 4.-Si el alto rendimiento es un aspecto importante y se alcanzara al convertir interfases en componentes del sistema, el enfoque DRA 5.- El DRA sería inapropiado cuando los riesgos técnicos son altos. MODELO DE PROCESO EVOLUTIVO Los modelos de proceso evolutivos producen una versión completa en forma incremental con cada iteración. Son iterativos: los caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más completas del software. COSNTRUCCION DE PROTOTIPOS Cuando el cliente tenga una necesidad legitima, pero no será definir los detalles, como primer paso desarróllese un prototipo. 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 este camino, ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cual será el resultado de la construcción cuando los requisitos estén satisfechos. Se inicia con la comunicación, el ingeniero de software y cliente definen los objetivos globales para el software identifican los requisitos conocidos y las áreas del esquema en donde es necesaria mas definición. Se plantea una iteración y se presenta el modelo. El prototipo sirve como un mecanismo para identificar los requisitos del software, problemática: 1.- Cuando se informa que el producto debe constituirse otra vez para mantener lo altos niveles de calidad, el cliente no lo entiende y pide la aplicación. 2.-Tal utilice un sistema operativo o lenguaje de programación inadecuado solo porque está disponible y es conocido. EL MODELO EN ESPIRAL Boehm propuso un modelo de proceso de software evolución que conjuga iterativa de la construcción de prototipo con los aspectos controlados y sistemáticos del modelo en cascada. Proporciona el material para el desarrollo rápido de versiones incrementales del software. Boehm generador del modelo de proceso guidado por el riesgo que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con múltiples usuarios. Dos características: - enfoque cíclicos para el crecimiento incremental del grado de definición e implementación de un sistema, mientras disminuyes su grado de riesgo. -conjuntos de puntos de fijación para asegura el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias. El software se desarrolla en una serie de entregas evolutivas. Primera iteraciones documentos del modelo o un prototipo, ultimas iteraciones versiones más completas del sistema desarrollado. Divide en un conjunto de actividades del marco de trabajo que define el equipo de ingeniería del software. El primero circuito el desarrollo de una especificación del producto, el modelo del espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora Es un enfoque realista para el desarrollo de software y des temas a gran escala. Como el software evoluciona conforme avanza el proceso, desarrollado y el cliente entiende y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva del producto. El modelo en espiral existe una consideración directa de los riesgos técnicos en todas las etapas del proyecto si se aplica en forma apropiada, debe reducir los riesgos antes de que se vuelva problemáticos. EL MODELO DE DESARROLLO CONCURRENTE Ingeniería concurrente, se representa en forma esquemática con una serie de actividades del marco de trabajo, acciones y tareas de ingeniería del software y sus estados asociados. Todas las actividades existen de forma concurrente, pero se encuentran en diferentes estados El modelo de proceso concurrente define una serie de eventos que dispararan transiciones de estado a estado para cada una de las actividades, acciones o tareas de la ingeniería del software, se aplica a todos los tipos de desarrollo de software y proporciona una visión exacta del estado actual de un proyecto. Los modelos evolutivos de proceso se concibieron para absorberse a estos aspectos y además, como modelos de proceso de clase general, estos modelos también debilidades. Procesos evolutivos de software, se tienen algunas dificultades con ese tipo de procesos, la primera dificultad es que la construcción de prototipos, implica un problema para la planeación del proyecto debido al número incierto de ciclos requeridos para construir el producto, los procesos evolutivos de software se deben enfocar en la flexibilidad y extensibilidad en vez de en la alta calidad. El propósito de los modelos evolutivos se desarrolla software de alta calidad de una manera iterativa o incremental. MODELOS ESPECIALIZADOS DE PROCESO Adoptan muchas de las características de los modelos convenientes presentados tienden a aplicarse cuando se ha elegido un enfoque de ingeniería del software definido de una manera muy estrecha DESARROLLO BASADO EN COMPONENTES (DBC) incorpora muchas de las características del modelo en espiral. Es evolución por naturaleza y existe un enfoque iterativo para la creación del software. Pasos: 1.- los productos basados en componentes disponibles se investigan y evalúan para el dominio de aplicación en cuestión 2.- se consideran los aspectos de integración de componentes 3.- se diseña una arquitectura de software para adaptar los componentes 4.- los componentes se integran en la arquitectura 5.- se realizan pruebas detalladas para asegurar una funcionalidad apropiada Conduce a la reutilización del software EL MODELO DE METODOS FORMALES Comprenden un conjunto de actividades que conduce a la especificación matemáticas del software de computadoras. Los métodos formales permiten especifique, desarrolle y verifique un sistema basado en computadora al aplicar una notación matemática rigurosa. Proporcionan un mecanismo para eliminar muchos de los problemas difíciles de superar con otros paradigmas de la ingeniería del software • El DSV es muy caro y consume mucho tiempo • Se requieren una capacidad detalladas • Es difícil de estos como un mecanismo de comunicación con clientes que no tienen muchos conocimientos técnicos. EL DESARROLLO DEL SOFTWARE ORIENTADO A ASPECTOS Requerido con frecuencia como programación orientada a aspectos, en 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” EL PROCESO UNIFICADO Es un intento encaminado a resumir los mejores rasgos y características de modelos de procesos de software, pero las caracteriza de manera que implementa muchos de los mejores principios del desarrollo ágil de software, reconoce la importancia de comunicación con el cliente y los métodos encaminados a describir el punto de vista del cliente con respecto a un sistema FRASE DEL PROCESO UNIFICADO La fase de inicio abarca la comunicación con el cliente y las actividades de planeación. Elaboración abarca la comunicación con el cliente y las actividades de modelado del modelo genérico del proceso. 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 desarrollo o adquiere los componentes del software que harán que cada de uso sea operativo para los usuarios finales. 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. La producción de PU coincide con la actividad de despliegue del proceso genérico, se monitorea el uso subsiguiente del software se proporciona el soporte para el ambiente operativo y se reciben y evalúan los informes de defectos y los requerimientos de cambios. PRODUCTOS DE TRABAJO DEL PROCESO UNIFICADO El modelo de caos de uso es una colección de escenarios de una 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 un escenario, y un conjunto de condiciones exteriores para la interacción representada, describen requisitos al nivel del dominio de negocios. Uno 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. La fase de elaboración produce un conjunto de productos de trabajo que elabora requisitos, así como una descripción arquitectónica y un diseño preliminar. 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 Es la práctica de la ingeniería del software es una colección de conceptos, principios, métodos y herramientas a las que un ingeniero de software recurre diario. La práctica permite a los gerentes coordinar proyectos de software e ingenieros de la especialidad para consumir programas de computadora.