RUP Metodologia
RUP Metodologia
RUP Metodologia
Ingeniería de Software
Ana Karen
RUP
Proceso Unificado Racional Aplicado
RUP es un proceso de ingeniería de software, que proporciona un enfoque disciplinario para la asignación
de tareas y responsabilidades dentro de un desarrollo organizado, promueve la productividad del trabajo en
equipo proporcionando a cada miembro del equipo un fácil acceso a una base de conocimiento, no importa
que los miembros del equipo trabajen en distintas disciplinas de un proyecto, como requisitos, diseño o
pruebas, los distintos miembros del equipo comparten un lenguaje común, procedimientos y puntos de vista
sobre como desarrollar el software.
Características esenciales
- Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del
sistema.
- Son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el
usuario y no solo en términos de funciones pero además guían el diseño, implementación y prueba,
por lo que los casos de uso constituyen un elemento integrador y una guía del trabajo como se
muestra en la figura.
- Un caso de uso se define como el fragmento de funcionalidad del sistema que proporciona al usuario
un valor añadido.
- 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.
Centrado en la arquitectura
- RUP 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, para
ser utilizada para conceptualizar, construir administrar y evolucionar el sistema en desarrollo.
- Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en
la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los
Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como
Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.
- la evolución de la arquitectura durante las fases de RUP. Se tiene una arquitectura más robusta en
las fases finales del proyecto. En las fases iniciales lo que se hace es ir consolidando la arquitectura
por medio de baselines y se va modificando dependiendo de las necesidades del proyecto.
- Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo
que la - arquitectura se representa mediante varias vistas que se centran en aspectos concretos del
sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo
4+1 de la arquitectura, el cual recibe este nombre porque lo forman las vistas lógica, de
implementación, de proceso y de despliegue, más la de Casos de Uso que es la que da cohesión a
todas
Es 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.
- Cada mini proyecto se puede ver como una iteración del cual se obtiene un incremento que produce
un crecimiento en el producto
- Una iteración puede realizarse por medio de cascada. 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.
Otras características
RUP identifica 6 mejores practicas con las que define una efectiva forma de trabajar para los equipos de
desarrollo de software.
Gestión de requisitos
- RUP brinda una guía para encontrar, organizar, documentar, y seguir los cambios de los requisitos
funcionales y restricciones. Utiliza una notación de Caso de Uso y escenarios para representar los
requisitos.
Ciclo de vida
RUP divide el ciclo de vida en 4 fases, cada una concluye con un hito bien definido.
Inicio
El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los
objetivos del proyecto.
Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar
los riesgos relacionados con el negocio y requerimientos.
Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la
viabilidad de desarrollar el proyecto.
Elaboración
El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para
el esfuerzo de diseño e implementación en la siguiente fase.
La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y
una evaluación del riesgo.
50% casos de usos
Construcción
Transición
Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios.
Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el
entregable del mismo, así como realizar ajustes menores de acuerdo a ajuste menores propuestos por el
usuario.
En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones,
instalación y aspectos sobre utilización.
Roles
- Gestores:
o Jefe de proyecto.
o Jefe de control de cambios.
o Jefe de configuración.
o Jefe de pruebas.
o Jefe de despliegue.
o Ingeniero de procesos.
o Revisor de gestión del proyecto.
o Gestor de pruebas. Apoyo:
o Documentador técnico.
o Administrador de sistema.
o Especialista en herramientas.
o Desarrollador de cursos.
o Artista gráfico.
- Especialistas en pruebas:
o Especialista en Pruebas (tester).
o Analista de pruebas.
o Diseñador de pruebas.
- Otros roles:
o Stakeholders.
o Revisor.
o Coordinación de revisiones.
o Revisor técnico.
o Cualquier rol.
Referencias