Proceso Unificado
de Desarrollo (RUP)
RUP
Proceso de
Desarrollo de Software
Dirigido a
Mejores Practicas
Rational Software de IBM
Desarrollo iterativo
Gestión de los cambios
Documentación
Implementación
Análisis
Desarrollo basado en componentes
Modelado visual (UML)
Verificación de La calidad
Para
Metodologías
más utilizadas UML Sistemas orientados
a objetos
Gestión de
requisitos
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:
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 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 se
muestran a continuación:
Inicio, Elaboración, Construcción y Transición.
Hitos
Ciclo de vida de RUP
El ciclo de vida de RUP se caracteriza por:
Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros necesitan y desean, lo cual se capta cuando se modela el negocio y se representa a través de los requerimientos. A partir de aquí los casos de uso guían el proceso de desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo).
Centrado en la arquitectura: La arquitectura muestra la visión común del sistema completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por lo que describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente. RUP se desarrolla mediante iteraciones, comenzando por los CU relevantes desde el punto de vista de la arquitectura. El modelo de arquitectura se representa a través de vistas en las que se incluyen los diagramas de UML.
Iterativo e Incremental: Una iteración involucra actividades de todos los flujos de
trabajo, aunque desarrolla fundamentalmente algunos más que otros.
Ciclo de vida de RUP
Por ejemplo, una iteración de elaboración centra su atención en el análisis y diseño, aunque refina los requerimientos y obtiene un producto con un determinado nivel, pero que irá creciendo incrementalmente en cada iteración.
Es práctico dividir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en los flujos de trabajo, y los incrementos, al crecimiento del producto.
Cada iteración se realiza de forma planificada es por eso que se
dice que son miniproyectos.
Rup fases
Define el alcance del proyecto
Planificar el proyecto, elaborar una arquitectura base
Construir el sistema
Transición a los usuarios
Tiempo
Fases dentro de un ciclo
Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en
secuencia un conjunto de disciplinas o
flujos de trabajos
Modelos Utilizados
• Un Modelo de Casos de Uso consiste de actores, casos de uso y relaciones entre
ellos. Los actores representan todo aquello que intercambia información con el sistema.Cuando un actor usa el sistema, el sistema ejecuta un caso de uso. Un buen caso de uso es una transacción secuencial que produce un resultado para un actor
• La colección de casos de uso es la funcionalidad completa de un sistema. El Modelo del Caso de Uso es usado como entrada esencial para las actividades de análisis, diseño y pruebas.
Modelo de Casos de Uso
• El Modelo de Análisis tiene el propósito de refinar los casos de uso más detalladamente, y realizar una asignación inicial del comportamiento del sistema; a un conjunto de objetos que proporcionen el funcionamiento esperado
• Es un Modelo de Objetos que describe la realización de casos de uso, y sirve como abstracción para el Modelo del Diseño.
El Modelo de Análisis contiene el resultado del análisis de casos de uso, y clases. El Modelo de Análisis es un artefacto opcional.
Modelo de Análisis
• El Modelo de Diseño define la estructura estática del sistema, tales como: subsistemas, clases e interfaces, y la realización de los casos de uso como colaboraciones entre los subsistemas, clases e interfaces.
• Es un Modelo de Objetos que describe la realización del caso de uso, y sirve como una abstracción del Modelo de Implementación y sus códigos fuentes. El Modelo del Diseño es usado como entrada esencial para las actividades de implementación y pruebas
Modelo de
Diseño
Modelos Utilizados
• El Modelo de Implementación es una colección de componentes y subsistemas que los contienen. Los componentes incluyen archivos ejecutables, códigos fuentes y librerías.
• Realizan el mapeo de las clases a los componentes.
Incluyen componentes (representando códigos fuentes).
Modelo de Implementación
• El Modelo de Deployment muestra la configuración de los procesos (nodos) en el tiempo de ejecución, la liga de comunicación entre ellos y los componentes y objetos que residen en ellos.
• Realizan el mapeo de los componentes a los nodos.
• Definen los nodos físicos de las computadoras.
Modelo de Deployment
• El Modelo de Pruebas es una representación de lo que será probado y como será probado. Es una vista de los modelos de diseño e implementación, describiendo las pruebas de ellos mismos. Esto incluye la colección de casos de pruebas, procedimientos de prueba, escritos de prueba y los resultados de prueba esperados junto con una descripción de sus relaciones.
• Describen los casos de pruebas que verificarán los casos de uso
Modelo de
Pruebas
Objetivos
Especificar cuales artefactos deben ser
desarrollados y cuando deben ser desarrollados
Ofrecer criterios para monitorear y medir los productos y actividades del proyecto
Dirigir las tareas de desarrolladores individuales y equipos como una sola
Proporcionar una guía del orden de las actividades de los equipos
RU P
Estructura Estática del proceso. Roles, actividades, artefactos y flujos de trabajo
RU P Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define cuatro elementos los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta
¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la pregunta
¿Cuándo?
Roles: Un rol define el comportamiento y
responsabilidades de un individuo, o de un grupo de individuos
trabajando juntos como un equipo.
Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por
varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un
conjunto de actividades como el ser el
dueño de un conjunto de artefactos
Artefactos: Herramientas
empleadas para el desarrollo del proyecto. Puede ser un
documento, un modelo, un elemento del modelo.
Actividades: Procesos que se han de realizar en cada etapa/iteración.
Trabajadores: Personas involucradas en cada actividad del proyecto.
Elementos
El proceso de desarrollo de software tiene cuatro roles importantes:
1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo exitoso de un producto de software. Explicando qué hacer, cómo, cuando y quién debe hacerlo)
2. Especificar que artefactos deberán desarrollarse y cuando deberán aplicarse.
3. Direccionar las tareas de los desarrolladores individuales y al equipo en general.
4. Ofrecer criterios de monitoreo y medidas de los productos
del proyecto.
RU P
Relación entre roles, actividades, artefactos
Detalle de un workflow mediante roles,
actividades y artefactos
UML es:
UML = Unified Modeling Language Un lenguaje de propósito general para el
modelado orientado a objetos. Impulsado por el Object Management Group (OMG, www.omg.org)
Documento “OMG Unified Modeling Language Specification”
UML combina notaciones provenientes desde:
Modelado Orientado a
Objetos
Modelado de
Datos Modelado de
Componentes
Modelado de Flujos de Trabajo
(Workflows)
Diagramas de uml
Diagrama de Casos de Uso Diagrama de Clases
Diagrama de Objetos
DIAGRAMAS DE COMPORTAMIENTO Diagrama de Estados
Diagrama de Actividad DIAGRAMAS DE ITERACCIÓN
Diagrama de Secuencia Diagrama de Colaboración
DIAGRAMAS DE IMPLEMENTACIÓN
Diagrama de Componentes
Diagrama de Despliegue
Diagramas de uml
https://okhosting.com/blog/herramientas-de-desarrollo-de-software/
Herramientas case
En la ingeniería de Software existen herramientas CASE cuyo propósito es dar soporte automatizado para la
aplicación de todas o algunas técnicas usadas por una o varias metodologías. Ayudan a un ingeniero de
software a desarrollar y mantener el software en un repositorio integrado en donde se alanceará la
información de uno o varios sistemas de información
donde se hace una descripción a detalle del software
desarrollado.
Por ejemplo
Se almacena toda la información de uno o varios sistemas de
información
Contexto Organizacional:
• Organigramas
• Planes estratégicos
• Factores críticos del éxito
• Entre otros El dominio (problema)
de los sistemas desarrollados o en
desarrollo
Modelos de solución e implementación
Información de la metodología que esta
siendo usada
Historia de los proyectos, recursos, presupuestos, etc.
Se utilizan en :
• Metodologías Estructuradas
• Metodologías Orientadas a Objetos
• Identificación
• Definición (significado)
• Tipo, alias
• Ítems, componentes
• Ítems padre
• Reglas de uso
• Quien y cuando lo
creó y lo actualizó por última vez
• Quienes pueden actualizarlo y
consultarlo
• Cual es su estado
• Número de versión
• Donde esta almacenado físicamente
Atributos típicos
Propósito de una herramienta CASE
• Enfrentar el proceso de desarrollo de
software como un
proyecto de Ingeniería de Software ingeniería de Software
1
• Aplicar uno o varios métodos de forma integrada cubriendo todas las actividades del ciclo de vida del software