Es un proceso de Ingeniería de Software. Proporciona un enfoque disciplinado para la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es garantizar la producción de alta calidad software que satisfaga las necesidades de sus usuarios finales, dentro de un horario predecible y presupuesto.
HISTORIA
El RUP de desarrollo de software fue desarrollado por la IBM Corporation, de propiedad de Rational Software en 2003.
La Figura 1 ilustra la historia de RUP. El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).
Figura 1: Historia de RUP
Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process.
CARACTERÍSTICAS ESENCIALES
Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental.
1. Proceso dirigido por Casos de Uso
Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que sería bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo como se muestra en la Figura 2.
Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.
2. Proceso centrado en la arquitectura
La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.
La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.
3. Proceso iterativo e incremental
La estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada de etapas como se muestra en la Figura 3. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.
Figura 3: Una iteración
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura.
4. Estructura Dinámica del proceso. Fases e iteraciones
RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un producto. Cada ciclo concluye con una generación del producto para los clientes. Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada fase es variable.
Cada fase se concluye con un hito (entregable) bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a cada iteración. Los hitos para cada una de las fases son: Inicio - Lifecycle Objectives, Elaboración - Lifecycle Architecture, Construcción - Initial Operational Capability, Transición - Product Release.
La duración y esfuerzo dedicado en cada fase es variable dependiendo de las características del proyecto.
PROCESO DE ADMINISTRACIÓN DE REQUERIMIENTOS RUP
Una de las principales causas para el fracaso de un proyecto de software es la mala (o ausencia de) administración de requerimientos.
La administración de requerimientos comprende las actividades relacionadas con la definición, clasificación, asignación, seguimiento y control de los requerimientos durante todo el ciclo de vida de desarrollo de software. Es indispensable para asegurar la calidad de los productos, así como para llevar control y seguimiento de los proyectos.
RUP describe como utilizar de forma efectiva procedimientos comerciales probados en el desarrollo de software para equipos de desarrollo de software, conocidos como “mejores prácticas”.
Una parte importante de estas "mejores prácticas" es: la administración de requerimientos, que consiste en definir, organizar y documentar las especificaciones funcionales y sus limitantes, así como las restricciones; dar seguimiento y documentar decisiones y alternativas tomadas; y capturar y comunicar con facilidad los requerimientos del negocio. Las nociones de "casos de uso" y escenarios utilizados en el proceso de desarrollo son una excelente forma para capturar los requerimientos funcionales.
Este es uno de los flujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema que se construya. Los requerimientos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requerimientos que se especifiquen.
Los requerimientos se dividen en dos grupos. Los requerimientos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los requerimientos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad específica. Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc.
CICLO DE DESARROLLO
El RUP divide un ciclo de desarrollo en cuatro fases consecutivas:
Fase Inicial
Durante la fase inicial, se establece el modelo de negocio para el sistema y delimitar el alcance del proyecto. Para ello se debe identificar todas las entidades externas con las que el sistema va a interactuar (actores) y definir la naturaleza de esta interacción en un alto nivel. Esto implica identificar todos los casos de uso y que describe una los pocos significativos. El caso de negocio incluye criterios de éxito, evaluación de riesgos y estimación de los recursos necesarios y un plan de eliminación con las fechas de los hitos más importantes.
Elaboración de Fase
El propósito de la fase de elaboración es analizar el dominio del problema, establecer una base arquitectónica de sonido, desarrollar el plan del proyecto, y eliminar los elementos de mayor riesgo del proyecto. Para lograr estos objetivos, que debe tener la "milla de ancho y una pulgada de profundidad" vista del sistema. Las decisiones de arquitectura que se hace con una la comprensión de todo el sistema: su alcance, la funcionalidad y los principales requisitos no funcionales, tales como requisitos de desempeño.
Fase de Construcción
Durante la fase de construcción, todos los demás componentes y características de las aplicaciones se desarrollan y se integran en el producto, y todas las características están ampliamente probadas. La fase de construcción es, en cierto sentido, un proceso de fabricación donde se hace hincapié en la gestión de recursos y control de las operaciones para optimizar costos, horarios y de calidad. En este sentido, la mentalidad de gestión experimenta una transición desde el desarrollo de la propiedad intelectual durante el inicio y elaboración, para el desarrollo de productos de despliegue durante la construcción y en transición.
La Transición de Fase
El propósito de la fase de transición es la transición del producto de software para la comunidad de usuarios. Una vez que el producto ha dado al usuario final, suelen surgir problemas que requieren para desarrollar las nuevas versiones, corregir algunos problemas, o acabado de las características que fueron aplazadas.
LENGUAJE DE PROGRAMACIÓN
El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. Se puede aplicar en el desarrollo de software para dar soporte a una metodología de desarrollo de software como el modelo RUP.
Es una norma de la ingeniería de software resultado del esfuerzo internacional de expertos de todo el mundo entre académicos y profesionales. Busca establecer un marco de referencia para la administración de los procesos de la ingeniería de software en el mundo. Define los procesos, actividades y tareas asociadas a los procesos del ciclo de vida del software desde la concepción hasta su retiro. Define los procesos de ingeniería de software como: “un conjunto de actividades que son realizadas por un conjunto de tareas que definen como las acciones transforman las entradas en salidas”.
INTERESANTE
ResponderEliminar