El significado y los campos de aplicación de RUP
6. Flujos de trabajo principales de RUP del proceso de desarrollo de software unificado (Core Workflows)
Hay 9 flujos de trabajo principales en RUP, que se dividen en 6 flujos de trabajo de procesos principales (Core Process Workflows) y 3 flujos de trabajo de soporte principales. Aunque los flujos de trabajo de los 6 procesos principales pueden recordar varias etapas del modelo en cascada tradicional, cabe señalar que las etapas del proceso iterativo son completamente diferentes y estos flujos de trabajo se visitan una y otra vez a lo largo del ciclo de vida. Los nueve flujos de trabajo principales se utilizan en rotación a lo largo del proyecto y se repiten con distinto énfasis e intensidad en cada iteración.
1． Modelado de negocios
El flujo de trabajo de modelado de negocios describe cómo desarrollar un concepto para una nueva organización objetivo y definir los procesos y roles de la organización en el modelo de casos de uso de negocios y el modelo de objetos de negocios basados en este concepto y responsabilidad.
2. Requisitos
El objetivo del flujo de trabajo de requisitos es describir lo que debe hacer el sistema y permitir que los desarrolladores y usuarios lleguen a un consenso sobre esta descripción. Para lograr este objetivo se deben extraer, organizar y documentar las funciones y restricciones requeridas, lo más importante es comprender la definición y el alcance del problema resuelto por el sistema;
3. Análisis y diseño (Análisis y diseño)
El flujo de trabajo de análisis y diseño convierte los requisitos en el diseño de sistemas futuros, desarrolla una estructura sólida para el sistema y ajusta el diseño para que coincida con el entorno de implementación y optimiza su rendimiento. El resultado del diseño de análisis es un modelo de diseño y un modelo de análisis opcional. El modelo de diseño es una abstracción del código fuente y consta de clases de diseño y algunas descripciones. Las clases de diseño están organizadas en paquetes de diseño y subsistemas de diseño (Subsistema) con buenas interfaces, y la descripción refleja cómo los objetos de la clase trabajan juntos para realizar la función del caso de uso. Las actividades de diseño se centran en el diseño arquitectónico. La arquitectura se expresa mediante varias vistas estructurales. La vista estructural es una abstracción y simplificación de todo el diseño. Algunos detalles se omiten en esta vista para aclarar las características importantes. La arquitectura no es sólo un medio para buenos modelos de diseño, sino que también mejora la calidad de los modelos creados durante el desarrollo del sistema.
4. Implementación
El propósito de implementar el flujo de trabajo incluye definir la estructura organizativa del código en forma de subsistemas jerárquicos; implementar clases y objetos en forma de componentes (archivos fuente, archivos binarios, archivos ejecutables); componentes desarrollados como unidades e integrar los resultados producidos por un único desarrollador (o grupo) en un sistema ejecutable.
5. Prueba (Test)
El flujo de trabajo de prueba debe verificar la interacción entre objetos, verificar la correcta integración de todos los componentes en el software, verificar que todos los requisitos se hayan implementado correctamente, identificar y confirmar que los defectos se hayan corregido antes. implementación de software planteada y procesada. RUP propone un enfoque iterativo, lo que significa realizar pruebas a lo largo del proyecto para detectar defectos lo antes posible, reduciendo fundamentalmente el costo de modificar defectos. Las pruebas son similares a un modelo tridimensional y se realizan desde la confiabilidad, la funcionalidad y el rendimiento del sistema.
6. Implementación
El propósito del flujo de trabajo de implementación es generar exitosamente una versión y distribuir el software a los usuarios finales. Los flujos de trabajo de implementación describen aquellas actividades relacionadas con garantizar la usabilidad de un producto de software para los usuarios finales, incluido el empaquetado del software, la creación de productos distintos del software en sí, la instalación del software y la prestación de asistencia a los usuarios. En algunos casos, esto también puede incluir la planificación y realización de pruebas beta, la portabilidad de software y datos existentes y la aceptación formal.
7. Gestión de configuración y cambios (Configuración y gestión de cambios)
El flujo de trabajo de Gestión de configuración y cambios describe cómo controlar una gran cantidad de artefactos en un proyecto de varios miembros. Los flujos de trabajo de configuración y gestión de cambios proporcionan pautas para gestionar múltiples variantes en un sistema en evolución, rastreando las versiones durante la creación del software. El flujo de trabajo describe cómo gestionar el desarrollo paralelo, el desarrollo distribuido y cómo crear proyectos automáticamente. También explica cómo mantener registros de auditoría sobre los motivos, el tiempo y el personal para las modificaciones del producto.
8． Gestión de proyectos (Project Management)
La gestión de proyectos de software equilibra varios objetivos potencialmente conflictivos, gestiona riesgos, supera diversas limitaciones y ofrece con éxito productos que satisfacen a los usuarios. Sus objetivos incluyen: proporcionar un marco para la gestión de proyectos, proporcionar directrices prácticas para la planificación, dotación de personal, ejecución y seguimiento de proyectos, y proporcionar un marco para la gestión de riesgos.
9. Entorno (Environment)
El propósito del flujo de trabajo del entorno es proporcionar el entorno de desarrollo de software, incluidos los procesos y herramientas, a la organización de desarrollo de software. Los flujos de trabajo ambientales se centran en las actividades necesarias para configurar el proceso del proyecto y también respaldan las actividades de desarrollo de especificaciones del proyecto, proporcionando orientación paso a paso y describiendo cómo implementar el proceso en su organización.
7. Modelo de desarrollo iterativo de RUP
Cada etapa de RUP se puede descomponer en iteraciones. Una iteración es un ciclo de desarrollo completo que produce una versión ejecutable del producto, un subconjunto del producto final, que evoluciona incrementalmente de una iteración a otra para convertirse en el sistema final. La organización tradicional del proyecto consiste en pasar cada flujo de trabajo secuencialmente y cada flujo de trabajo solo una vez, que es el conocido ciclo de vida en cascada (consulte la Figura 2). El resultado de esto es que al final de la implementación, cuando el producto esté completo y comiencen las pruebas, aparecerá una gran cantidad de problemas ocultos que quedaron de las fases de análisis, diseño e implementación, y es posible que sea necesario detener el proyecto. y comienza un largo ciclo de corrección de errores.
Un enfoque más flexible y menos riesgoso es pasar por diferentes flujos de trabajo de desarrollo varias veces, para poder comprender mejor los requisitos, construir una arquitectura sólida y, en última instancia, entregar una serie de versiones paso a paso. . A esto se le llama ciclo de vida iterativo. Cada paso secuencial en el flujo de trabajo se denomina iteración. El ciclo de vida del software es una sucesión iterativa a través de la cual el software se desarrolla de forma incremental. Una iteración incluye las actividades de desarrollo para generar una versión ejecutable, así como otros componentes auxiliares necesarios para usar esta versión, como la descripción de la versión, la documentación del usuario, etc. Por lo tanto, una iteración de desarrollo es, en cierto sentido, un proceso completo en todos los flujos de trabajo, que al menos incluyen: flujo de trabajo de requisitos, flujo de trabajo de análisis y diseño, flujo de trabajo de implementación y flujo de trabajo de prueba. Parece un pequeño proyecto de cascada en sí mismo (ver Figura 3).
Figura 3 Modelo iterativo de RUP
Comparado con el modelo en cascada tradicional, el proceso iterativo tiene las siguientes ventajas:
Reduce el gasto en un riesgo incremental. Si un desarrollador repite una iteración, la pérdida es sólo el costo de la iteración que se desarrolló incorrectamente.
Reduce el riesgo de que los productos no puedan entrar al mercado según el cronograma establecido. Al identificar los riesgos en las primeras etapas del desarrollo, es posible abordarlos tempranamente en lugar de acelerarlos más adelante.
Acelera el progreso de todo el trabajo de desarrollo. Como los desarrolladores saben cuál es el foco del problema, trabajan de manera más eficiente.
Dado que las necesidades del usuario no pueden definirse completamente desde el principio, normalmente se perfeccionan en etapas posteriores. Por tanto, el modelo de proceso iterativo facilita la adaptación a los cambios en los requisitos.