is.exp.3.323734
TRANSCRIPT
UNIVERSIDAD AUTONOMA
DE BAJA CALIFORNIAFCAyS
RUPProceso Unificado Racional
AsignaturaIngeniería de Software
Grupo361
ExposiciónEquipo 3
IntegrantesAlejo Dávila Josué325294
González Cosio
Alberto323734
Guzmán Pérez Raudel311555
Labrador Pérez Víctor322801
¿Qué es RUP?• Modelo de Software de
enfoque disciplinario paraasignación de tareas yresponsabilidades
• El desarrollo de software agran escala, mediante unproceso continuo depruebas yretroalimentación,garantizando elcumplimiento de ciertosestándares de calidad.
Su meta es asegurar
la producción del
software de alta
calidad que resuelve
las necesidades de
los usuarios dentro
de un presupuesto y
tiempo establecidos.
Acerca de
RUPLos procesos del RUP
Estiman tareas y horariosRequiere un grupo grande de
programadores.
Describe una clase de los
procesos que son iterativos e
incrementales.
Define actividades y artefactos
Es el Proceso de desarrollo mas
general de los existentes
actualmente.
Desarrollado por Rumbagh en
1999, actualmente propiedad de
IBM
Perspectivas del
RUP
Dinámica (Horizontal)
Muestra las fases del modelo
sobre el tiempo.
Estática (Vertical)
Muestra las actividades del
proceso que representan
Practica
Sugiere buenas practicas
utilizar durante el proceso
Perspectivas del
RUP
• 4-Software modelado visualmente:
• Usar modelos UML gráficos para elaborar representaciones de software estáticas y dinámicas.
• 5-Verificar la calidad del software:
• Garantizar que el software cumpla con los estándares de calidad de la organización.
• 6-Controlar los cambios al software:
• Gestionar los cambios al software con un sistema de administración al cambio. Así como con procedimientos y herramientas de administración de la configuración.
1-Desarrollo de software de manera iterativa:
Incrementar el plan del sistema con base en las prioridades del cliente, y desarrollar oportunamente las características del sistema de mayor prioridad en el proceso de desarrollo.
2-Gestion de requerimientos:
Documentar de manera explicita los requerimientos del cliente y seguir la huella de los cambios a dichos requerimientos. Analizar el efecto de los cambios sobre el sistema, antes de aceptarlos.
3-Usar arquitecturas basadas en componentes:
Estructurar la arquitectura del sistema en componentes.
Características
Esenciales del
RUP
Proceso Dirigido Por
Los Casos de Uso
Describe los pasos que deben
realizarse para llevar a cabo un
proyecto.
Muestra la interacción entre el
sistema y los actores.
No solo comienzan el proceso
si no que lo guían.
Permite establecer
trazabilidad.
Características
Esenciales del RUPProceso Centrado en la Arquitectura
•Afecta al desempeño y potencia , así como el mantenimiento del sistema.
•Los componentes individuales implementan los requerimientos funcionales del sistema
•Las arquitecturas se modelan con frecuencia usando diagramas de bloques, donde cada cuadro representa un componente
• (NO MUY RECOMENDABLE)
Características
Esenciales del RUP
Proceso Iterativo e
Incremental
•Se basa en la idea de diseñar
una implementación
inicial, exponer esta al
comentario del usuario, y luego
desarrollarla en sus diversas
versiones hasta producir un
sistema adecuado.
•Se realizan tantas iteraciones
hasta que se termine la
implementación de la nueva
versión del producto.
Fases 1. Inicio
2. Elaboración
3. Construcción
4. Transición
•El ciclo de vida del software del
RUP se descompone en cuatro
fases secuenciales.
•Al final de cada fase se realiza una
para determinar si los objetivos de
la fase se han cumplido.
•Una evaluación satisfactoria
permite que el proyecto se mueva a
la próxima fase. Planeando las Fases
FasesINICIO ELABORACION
CONSTRUCCION TRANSICION
1. Inicio
El objetivo de esta fase es el
de establecer un caso de
negocios para el sistema. Se
deben identificar todas las
entidades
externas(personas y
sistemas) que interactúan
con el sistema y definir
estas interacciones. Si la
información proporcionada
es de poca importancia, se
puede cancelar el proyecto.
Fases2. Elaboración
Los objetivos de la fase son
desarrollar una comprensión
del dominio del problema,
establecer un marco de
trabajo para el sistema,
desarrollar un plan del
proyecto e identificar los
riesgos clave del proyecto. Al
terminar esta fase se debe
tener un modelo de los
requerimientos del sistema,
un diseño y un plan de
desarrollo del software.
ELABORACIONINICIO CONSTRUCCION TRANSICION
Fases3. Construcción
Comprende el diseño del
sistema, la programación y
las pruebas. Durante esta fase
se desarrollan e integran las
partes del sistema. Al
terminar esta fase, se debe
tener un sistema software
operativo y la documentación
correspondiente lista
para entregarlos a los
usuarios.
CONSTRUCCIONINICIO ELABORACION TRANSICION
Fases4. TransiciónA fase final del RUP se
ocupa de mover el sistema
desde la comunidad de
desarrollo a la comunidad
del usuario y hacerlo
trabajar en un entorno real.
Al terminar esta fase se
debe tener un sistema
software documentado que
funcione correctamente en
su entorno operativo
TRANSICIONINICIO CONSTRUCCIONELABORACION
Fases RUPDependiendo del
proyecto, un ciclo de
desarrollo inicial típico
para un proyecto de
tamaño mediano debe
anticipar la distribución
siguiente el esfuerzo y
horario:
Lo que puede
representarse
gráficamente de la
siguiente manera
Organización y
elementos del RUP
• Flujos de trabajo (Workflow).
• Detalle de flujo de trabajo
• Actores
• Actividades
• Artefactos.
Se puede observar que el
flujo de trabajo de
Requerimientos conlleva
varios pasos, cada uno de
estos pasos tiene asociados
uno o más actores, los
cuales a su vez son los
encargados de la ejecución
de varias actividades, las
cuales a la vez están
definidas en artefactos o
guías para su realización.
Elementos
RUP
Analistas:
o Analista del Proceso de Negocios.
o Diseñador del Negocio.
o Revisor del Modelo de Negocio.
o Revisor de Requerimientos.
o Analista del Sistema.
o Especificador de casos de Uso.
o Diseñador de Interfaz de Usuario.
Desarrolladores:
o Arquitecto.
o Revisor de la Arquitectura.
o Diseñador de Capsulas.
o Revisor del Código y Revisor del Diseño.
o Diseñador de la Base de Datos.
o Diseñador.
o Implementador y un Integrador.
Probadores Profesionales:
o Diseñador de Pruebas.
o Probador.
.
Actores
Son los personajes encargados de la realización de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categorías
•Analistas
•Desarrolladores
•Probadores
•Encargados
• Otros.
Elementos
RUP
Encargados:
o Encargado de Control del Cambio.
o Encargado de la Configuración.
o Encargado del Despliegue.
o Ingeniero de Procesos.
o Encargado de Proyecto.
o Revisor de proyecto.
Otros:
o Cualquier Trabajador.
o Artista Grafico.
o Stakeholder.( parte
interesada, accionistas, inversores etc. )
o Administrador del Sistema.
o Escritor Técnico.
o Especialista de herramientas
Actores
Son los personajes encargados de la realización de las actividades definidas dentro de los flujos de trabajo de cada una de las disciplinas del RUP, estos actores se dividen en varias categorías
•Analistas
•Desarrolladores
•Probadores
•Encargados
• Otros.
Elementos
RUP
1. Artefactos en el
Modelado de Negocios:Son aquellos que capturan y presentan el
contexto de Negocio de Sistema. Los
Artefactos del Modelo de Negocios
sirven como entradas, y referencias
para los requerimientos del sistema.
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
2. Artefactos de
Requerimientos:Estos capturan y presentan información
utilizada en la definición de las
capacidades requeridas del sistema.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
3. Artefactos de Análisis y Diseño:
Capturan y presentan información relacionada con la solución a los problemas planteados durante el flujo de trabajo de requerimientos.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
4. Artefactos de
Implementación:• Los artefactos para la Implementación
capturan y presentan la realización de la
solución presentada en el flujo de
trabado de análisis y diseño.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
5. Artefactos de Prueba:• Los artefactos desarrollados como
productos de las actividades de pruebas
y evaluaciones agrupados por el rol del
responsable.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
6. Artefactos de Despliegue:• Captura y presenta información
relacionada con la transición del sistema
presentado en los artefactos de
implementación dentro del entorno de
producción.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
7. Artefactos de
Administración de
Proyecto:• Captura los artefactos asociados con el
proyecto y el proceso de planificación y
ejecución.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
8. Artefactos de
configuración y
administración de cambios:• Capturan y presentan información
relacionada a la disciplina de
configuración y administración de
cambios.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
9. Artefactos de Entorno: • Estos presentan artefactos que son
usados como guía a través del desarrollo
del sistema para asegurar la consistencia
de todos los artefactos producidos.
Elementos
RUP
ArtefactosSon cualquiera de los productos finales o intermedios de trabajo que se producen y utilizan en un proyecto. Estos pueden ser un Documento, un Modelo o un elemento dentro de un Modelo, Caso de Uso, Código Fuente o un Archivo Ejecutable.
1. Artefactos de configuración y administración de cambio.
2. Artefactos de Despliegue
3. Artefactos de Prueba
4. Artefactos de Administración de Proyecto
5. Artefactos de Análisis y Diseño
6. Artefactos de Implementación
7. Artefactos de Requerimientos
8. Artefactos en el Modelado de Negocios
9. Artefactos de Entorno
Flujo de Trabajo
(WorkFlow)
• Es el estudio de los aspectos operacionales
de una actividad de trabajo: cómo se
estructuran las tareas, cómo se realizan, cuál
es su orden correlativo, cómo se
sincronizan, cómo fluye la información que
soporta las tareas y cómo se le hace
seguimiento al cumplimiento de las tareas
En la figura se muestran ciertos
porcentajes, de forma vertical se
muestra el esfuerzo que se tiene
que realizar por cada una de las
disciplinas o flujos de trabajo, y los
dos porcentajes que se muestran
de forma horizontal son para todo
el proyecto. En la siguiente figura
se puede observar que para la
obtención de requerimientos o
requisitos en la fase de concepción
se empiezan a obtener, en la fase
de elaboración tiene su auge y va
declinando en la fase de
construcción, realizar todo esto
requiere aproximadamente un 15%
de esfuerzo, y así sucesivamente
con las demás disciplinas. En esta
sección y la siguiente, los
porcentajes pueden variar de un
proyecto a otro
DisciplinasProceso1. Modelo de Negocio.
2. Requerimientos.
3. Análisis y Diseño
4. Implementación.
5. Pruebas.
6. Despliegue
Soporte1. Admón.. Del cambio.
2. Admón.. De Proyecto
3. Entorno
Disciplinas de Proceso:
Son las necesarias para la
realización de un proyecto
de software, aunque
proyectos no muy grandes
se pueden omitir algunas.
Disciplinas de Soporte:
Son las que como su
nombre lo indica sirven de
soporte a las de proceso y
especifican otras
características en la
realización de un proyecto
de software.
DisciplinasProceso1. Modelo de Negocio.
2. Requerimientos.
3. Análisis y Diseño
4. Implementación.
5. Pruebas.
6. Despliegue
Soporte1. Admón.. Del cambio.
2. Admón.. De Proyecto
3. Entorno
Disciplinas
de Proceso
• Modelo del NegocioSe modelan los procesos de negocio utilizando
casos de uso de la empresa.
• RequerimientosSe identifican los actores que interactúan con el
sistema y se desarrollan casos de uso para
modelar los requerimientos del sistema.
• Análisis y DiseñoSe crea y documenta un modelo de diseño
utilizando modelos arquitectónicos, de
componentes, de objetos y de secuencias.
Disciplinas de
Proceso: Son las
necesarias para la
realización de un
proyecto de
software, aunque
proyectos no muy
grandes se pueden
omitir algunas.
Disciplinas
de Soporte
• ImplementaciónSe implementan y estructuran los
componentes del sistema en subsistemas de implementación. La generación automática de código a partir de modelos de diseño ayuda a acelerar este proceso.
• PruebasLas pruebas son un proceso iterativo que
se realiza en conjunto con la implementación. Las pruebas del sistema siguen al completar la implementación.
• DespliegueSe crea la liberación de un producto, se
distribuye a los usuarios y se instala en su lugar de trabajo.
Disciplinas de
Soporte: Son las que
como su nombre lo
indica sirven de soporte
a las de proceso y
especifican otras
características en la
realización de un
proyecto de software.
Metodología RUP
para el análisis de
diseño
• Modelo de Casos de Uso del Negocio:
Describe la realización del Caso de Uso, es realizado en la disciplina de
• Modelo de Objetos del Negocio:
Se utiliza para identificar roles dentro de la organización, es realizado en la disciplina de Modelado del Negocio.
• Modelo de Casos de Uso:
Muestra las interrelaciones entre el sistema y su ambiente, además sirve como un contrato entre el cliente y los diseñadores. Es considerado esencial al iniciar las actividades de análisis, diseño y prueba; este modelo es realizado en la disciplina de requerimientos.
• Modelo de Análisis:
Contiene los resultados del análisis del Caso de Uso, y contienen instancias del artefacto de Análisis de Clases; es realizado en la disciplina de Análisis y Diseño.
• Modelo de Diseño:
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 su código fuente, es utilizado como entrada en las actividades de implementación y prueba; este modelo se realizado en la disciplina de Análisis y Diseño.
•
•
La entrada principal para el
Workflow de Análisis y Diseño es el
Modelo de Casos de Uso y el
Glosario creados durante el
Workflow de Requerimientos. Por
las fallas que se descubran en el
Modelo de Casos de Uso, se
generará requerimientos de
cambio.
El RUP propone la utilización de los
modelos para la implementación
completa de todas sus fases
respectivamente con sus disciplinas
Metodología RUP
para el análisis de
diseño
• Modelo de Despliegue:
Muestra la configuración de los nodos del proceso en tiempo de ejecución, muestra los lazos de comunicación entre estos nodos, así como las de los objetos y componentes que en el se encuentran; se realizado en la disciplina de Análisis y Diseño.
• Modelo de Datos:
Es un subconjunto del modelo de implementación que describe la representación lógica y física de datos persistentes en el sistema. También incluye cualquier conducta definida en la base de datos como disparadores, restricciones, etc. Es elaborado en la disciplina de Análisis y Diseño.
• Modelo de Implementación:
Es una colección de componentes, y de subsistemas de aplicación que contienen estos componentes, entre estos están los entregables, ejecutables, archivos de código fuente. Es realizado en la disciplina de Implementación.
• Modelo de Pruebas:
Es utilizado para la elaboración de las pruebas, y se realiza en la disciplina de Pruebas. Estos modelos representan los diagramas que propone el UML para el desarrollo de modelado de un proyecto de software, con los cuales se puede representar los propuesto por UML mediante la metodología RUP utilizando las herramientas que esta provee para la implementación fácil, clara y estructurada de los diagramas utilizados.
La entrada principal para el
Workflow de Análisis y Diseño es el
Modelo de Casos de Uso y el
Glosario creados durante el
Workflow de Requerimientos. Por
las fallas que se descubran en el
Modelo de Casos de Uso, se
generará requerimientos de
cambio.
El RUP propone la utilización de los
modelos para la implementación
completa de todas sus fases
respectivamente con sus disciplinas
Enlace RUP -
UML
• Comparación entre
diagramas de Casos de
Uso.Las clases, al igual que los
demás elementos
notacionales del UML,
pueden estar clasificadas de
acuerdo a varios criterios
El UML proporciona los
diagramas de Caso de Uso,
al mismo tiempo que el
RUP, la única diferencia es la
forma de dibujar los
estereotipos, ya que en el
RUP son una elipse con una
diagonal al lado derecho
Enlace RUP -
UML
• Comparación entre
diagramas de Clases
Las clases, al igual que los
demás elementos
notacionales del
UML, pueden estar
clasificadas de acuerdo a
varios criterios
El UML proporciona los
diagramas de Caso de
Uso, al mismo tiempo que
el RUP, la única diferencia es
la forma de dibujar los
estereotipos, ya que en el
RUP son una elipse con una
diagonal al lado derecho
Conclusión
• La forma en la que se pueden asignar
tareas y responsabilidades dentro de un
proyecto de desarrollo de
software, porque cada uno de los
participantes de un proyecto sabe que
es lo que le toca hacer, cual es su
función, cuando lo tiene que hacer,
• Ayuda a que se pueda desglosar todo el
proyecto en partes más pequeñas y más
fáciles de administrar, así que todas las
actividades están muy bien definidas, y
son auxiliadas por los artefactos de los
flujos de trabajo ya que cada parte del
proceso arroja resultados en forma de
otro artefactos, los cuales van dictando
que es lo que se ha hecho y dan
resultados para qué es lo que se tiene
que hacer.
Puntos a favor:•Es una metodología completa por si sola que hace énfasis en la documentación acertada de los proyectos donde se implementa.
•El tiempo de desarrollo requerido es menor gracias a la reutilización de componentes.
•Capaz de resolver el riesgo de proyecto asociado con los requerimientos cambiantes del cliente.
•Se apoya en un lenguaje popular como lo es el UML.
Puntos en contra: •Los miembros de un equipo que participen en un proyecto bajo esta metodología, deberán ser expertos en su materia.
•RUP no es para todo tipo de proyectos, hablando de escala o tamaño, si no que se recomienda que puede ser benéfico para proyectos de mediana a gran escala.
|