Modelo RUP
¿Qué es RUP?
Es un proceso de ingeniería de software, que hace una propuesta orientada por
disciplinas para lograr las tareas y responsabilidades de una organización que desarrolla
software.
Su meta principal es asegurar la producción de software de alta calidad que cumpla
con las necesidades de los usuarios, con una planeación y presupuesto predecible.
¿Para quién es RUP?
Diseñado para:
–Profesionales en el desarrollo de software.
–Interesados en productos de software.
–Profesionales en la ingeniería y administración de procesos de software.
¿Por qué usar RUP?
–Provee un entorno de proceso de desarrollo configurable, basado en estándares.
–Permite tener claro y accesible el proceso de desarrollo que se sigue.
–Permite ser configurado a las necesidades de la organización y del proyecto.
–Provee a cada participante con la parte del proceso que le compete directamente,
filtrando el resto.
Características
Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para
establecer el comportamiento deseado del sistema
Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar,
construir, administrar y evolucionar el sistema en desarrollo
Iterativo e Incremental:
–Maneja una serie de entregas ejecutables
–Integra continuamente la arquitectura para producir nuevas versiones
mejoradas
Conceptualmente amplio y diverso
Enfoque orientado a objetos
En evolución continua
Adaptable
Repetible
Permite mediciones:
–Estimación de costos y tiempo, nivel de avance, etc.
Ciclo de Vida y sus Faces
En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales,
cada cual concluye con un producto intermedio.
Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no
con los objetivos de la misma.
Las fases son:
Inicio (Inception)
Elaboración
Construcción
Transición.
RUP (RATIONAL UNIFIED PROCESS)
Esta es una de las metodologías más generales que existe, esta enfocado a cualquier
tipo de proyecto así no sea de software
RUP se basa en casos de uso para describir lo que se tiene y lo que se espera del
software, está muy orientado a la arquitectura del sistema a implementarse,
documentándose de la mejor manera, basándose en UML (Unified Modeling Language
- Lenguaje de Modelado Unificado).
Para poder usar RUP antes hay que adaptarlo a las características de la empresa, y
medir de manera exacta el tiempo, costos y todos los demás recursos involucrados en
el proceso.
Fases de RUP:
Se basa en la documentación generada en cada uno de sus cuatro fases: Inicio (puesta
en marchar), Elaboración (definición, análisis y diseño), Construcción y Transición (fin
del proyecto y puesta en producción)
FASES
FLUJOS Inicio Elaboración Construcción Transición
Modelado del Negocio I
Requisitos I
Análisis y Diseño I R
Implementación I R
I: Inicio, R: Refinamiento
i. FASE DE INICIO:
El propósito general en esta fase es establecer los objetivos para el ciclo de
vida del software a implementar. Durante esta fase se definirá el modelo del
negocio y el alcance proyecto. Se identificarán todos los actores y casos de uso.
Los objetivos específicos de esta fase serán:
Establecer el ámbito del proyecto y sus límites.
Encontrar los casos de uso críticos del sistema, los escenarios básicos que
definen la funcionalidad.
Durante la fase de inicio se definirán el modelo del negocio y el alcance del
proyecto.
1.1. Modelado del Negocio:
El modelado del negocio es el primer flujo de trabajo o disciplina de la
metodología RUP, y consiste en conocer la estructura y la
dinámica de la organización, así como conocer los problemas
actuales e identificar mejoras dentro de la organización.
También conocido como una técnica para conocer los procesos del
negocio de una organización.
Con esta disciplina se pretende llegar a un mejor entendimiento de la
institución. Los principales motivos para ejecutar esta disciplina son
los siguientes: asegurarse de que el producto será algo útil y no un
obstáculo, conseguir que se ajuste de la mejor forma posible en la
organización donde se va a implantar; y tener un marco común para
el desarrollador, los clientes y los usuarios finales.
Ejemplos:
PAGOS: Proceso a cargo del área de Tesorería en el que participan los:
Postulantes, quienes realizan sus pagos por derechos de examen
de admisión, exoneración o traslados.
Estudiantes, quienes realizan sus pagos por derechos de
matrículas, mensualidades, y otros pagos asignados por la
institución en un determinado semestre lectivo.
Tesorería, área que registra y reporta
Los principales objetivos son:
Asegurar que clientes y desarrolladores
tengamos un entendimiento común de la institución.
Entender el problema actual en la institución e
identificar potenciales mejoras.
Entender la estructura y la dinámica de la institución.
Identificar los casos de uso del software y las entidades del
negocio relevantes del software q debe realizar.
RESPONSABLES de MODELO DEL NEGOCIO
Los principales responsables involucrados en el modelo del negocio son:
Analista de procesos del negocio: dirige y coordina el modelado de los
casos de uso del negocio y establece la parte de la organización que se va
a modelar.
Diseñador de negocios: detalla la parte de la organización que se va a
modelar como casos del negocio.
Supervisor de negocios: revisa los resultados del modelado
LOS ARTEFACTOS CLAVES DEL MODELADO DE NEGOCIOS
Los artefactos claves del modelado de negocios son:
El Modelo de Caso de Uso del Negocio.
Especificación de los Caso de Uso del Negocio.
El Modelo de Objetos del Negocio.
El Modelo de Dominio del Problema.
Un glosario con la terminología clave del dominio del problema.
ii. Fase de Elaboración:
En esta fase se especifican en detalle la mayoría de los casos de uso del proyecto y
se diseña la arquitectura del sistema. La arquitectura se expresa en forma de vistas
de todos los modelos del sistema, los cuales juntos representan al sistema entero.
El resultado de esta fase es una línea de base de la arquitectura. Al final de la fase
de elaboración, el director de proyecto está en disposición de planificar las
actividades y estimar los recursos necesarios para terminar el proyecto.
Los artefactos que se presentará en esta fase serán:
Modelo de Casos de Uso de Requerimiento.
Diagramas de Colaboración.
Diagramas de Secuencia.
Diagrama de Clases.
2.1. Requerimientos:
La etapa de Requerimientos es el segundo flujo de trabajo o disciplina de la
metodología RUP, y consiste en establecer los servicios que el sistema debe
proveer y las restricciones bajo las cuales debe operar.
El objetivo principal de esta disciplina es establecer las funciones que se quiere que
satisfaga el sistema a construir.
Los principales objetivos de esta disciplina son:
Definir el ámbito del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y
metas del usuario.
Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo
que el sistema debería hacer.
Tener un mejor entendimiento de los requerimientos del sistema.
Tener una base para estimar recursos y tiempo de desarrollo del sistema.
Los requerimientos serán divididos en dos grupos: Los funcionales, que
describirán las funciones que el software va a ejecutar; y los no funcionales, que
especificarán criterios que pueden usarse para juzgar la operación de un sistema en
lugar de sus funciones específicas.
2.2. Análisis Y Diseño
El objetivo principal de esta disciplina es transformar los requerimientos a una
especificación que describa cómo implementar el sistema en la institución.
Los principales objetivos en esta disciplina son:
Adaptar el diseño para que sea consistente con el entorno de implementación.
Desarrollar una arquitectura para el sistema.
Transformar los requerimientos al diseño del futuro sistema.
El diagrama visto en este flujo de trabajo es:
Diagrama de Colaboración (DC)
Diagrama de Secuencia (DS)
Diagrama de Clases
iii. Fase de construcción:
El objetivo general de esta fase es alcanzar la capacidad operacional del software
de forma incremental a través de las sucesivas iteraciones. En esta fase todas las
características, componentes, y requerimientos serán integrados, implementados, y
probados en su totalidad, obteniendo una versión aceptable del Software
comúnmente llamada versión beta.
Los objetivos específicos de esta fase son:
Minimizar los costos de desarrollo mediante la optimización de recursos y
evitando el tener que rehacer un trabajo o incluso desecharlo.
Conseguir una calidad adecuada tan rápido como sea práctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan
rápido como sea práctico.
El hito en esta fase culmina con el desarrollo del sistema con calidad de producción
y la preparación para la entrega al equipo de transición. Toda la funcionalidad
debe haber sido implementada.
3.1. Análisis Y Diseño
Interfaces del sistema
Para representar el Diseño del sistema se emplearán diferentes diagramas de UML
vistos anteriormente
Nota: En esta fase se van a presentar las interfaces diseñadas para su proyecto
d) Fase Transición. Fin del proyecto y puesta en producción.