diseño de sistemas
DESCRIPTION
esta muy buenaTRANSCRIPT
![Page 1: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/1.jpg)
Rational Unified Process
Oswaldo E. Eusebio RojasUniversidad Garcilaso de la Vega
![Page 2: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/2.jpg)
Temario
Introducción Concepto Vista Dinámica y Estática Características de RUP
Las seis mejores prácticas Disciplinas y Flujos de Trabajo Fases RUP y CMMI Conclusiones
![Page 3: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/3.jpg)
¿Qué es un Proceso de Desarrollo de SW?
Requisitos nuevoso modificados
Sistema nuevoo modificado
Proceso de Desarrollo de Software
Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo
No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable
![Page 4: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/4.jpg)
El Problema
•Si un proceso es utilizado, equipos funcionales diferentes normalmente utilizan procesos y lenguajes de modelación inconsistentes.
Requerimientos
Pruebas
Análisis
Diseño
•La mayoría de los proyectos de softwareutilizan procesos que no están biendefinidos. En su lugar los miembros del equipo (re)inventan sus propios procesos.
????
????
????
??
•Los procesos no están apropiadamente relacionados con herramientas, ó no están propiamente automatizados.
?Proceso Herramienta
![Page 5: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/5.jpg)
Conceptos fundamentales
Proceso: Es un marco de trabajo común compuesto por
actividades de trabajo (conjuntos de tareas, hitos, productos y puntos de garantía de calidad) y actividades de protección (garantía de calidad, gestión de configuración y medición) (Pressman 2001).
Producto: Es el resultado previsto y consistente del proceso.
![Page 6: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/6.jpg)
Conceptos fundamentales
Ciclo de vida del software: Es el conjunto de fases por las que pasa el
software, que abarcan desde su creación u origen, hasta su eliminación o liquidación formal.
Modelo de desarrollo: También denominado Modelo de Proceso. Estrategia de desarrollo basada en el ciclo de
vida, naturaleza del proyecto y metodología, que determina las características específicas del proceso (Pressman 2001).
![Page 7: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/7.jpg)
Rational Unified Process
“RUP es un marco de trabajo genérico que puede especializarse para una variedad de tipos de sistemas, diferentes áreas de aplicación, tipos de organizaciones y diferentes tamaños de proyectos”.
JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James 2000 El proceso unificado de desarrollo de software, Addison Wesley
![Page 8: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/8.jpg)
Noción de Proceso
Rol que puede ser
desempeñado por un
individuo o conjunto de
individuos en la organización de desarrollo
Trabajador/Quién?
Diseñador
Actividad/Cómo?
Describe una unidad de trabajo
que puede ser asignada a un trabajador.
Diseño deCasos de uso
Pieza de información que es producida,
modificada, ó utilizada por un proceso
Artefacto/Qué?
Paquete deCaso de Uso
Caso de Uso
responsable de
![Page 9: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/9.jpg)
Rational Unified Process
Creado por los 3 amigos: Grandy Booch (creador de “The Booch Method”), Ivar Jacobson e James Rumbag (creador de “Object Modeling Technique” = OMT)
Aparece por primera vez en Junio de 1998 con el nombre de Rational Unified Process 5.0 (RUP)
Fue puesto a disposición pública entre finales de 1998 e inicios de 1999.
Centrado en tres Puntos: Personas Procesos Herramientas y métodos
![Page 10: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/10.jpg)
Evolución de RUP
![Page 11: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/11.jpg)
Estructura de RUP
El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el
aspecto dinámico del proceso, expresado en términos de ciclos, fases, iteraciones, y metas.
El eje vertical representa el aspecto estático del proceso; como está descrito en términos de disciplinas: actividades, artefactos, trabajadores y flujos de trabajo.
![Page 12: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/12.jpg)
El Ciclo de Vida del Software en RUP
![Page 13: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/13.jpg)
El Ciclo de Vida del Software en RUP
![Page 14: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/14.jpg)
El Ciclo de Vida del Software en RUP
![Page 15: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/15.jpg)
El Ciclo de Vida del Software en RUP
![Page 16: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/16.jpg)
Disciplina Diagrama
Requerimientos Diagramas de Casos de Uso
Análisis Refinamiento y documentación de los casos de usosDefinición preliminar de clases y Diagramas de Interacción (Secuencia y Colaboraciones)
Diseño EmpaquetamientoDiagramas de Interacción de diseño (Secuencia y Colaboraciones)Diagrama de Clases de diseño Modelo de Datos
Implementación Diagrama de ComponentesDiagrama de Despliegue
Relación entre Diagramas UML y Disciplinas de RUP
![Page 17: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/17.jpg)
RUP Visión Estática En su visión estática, el modelo RUP está
compuesto por:Roles: analista de sistemas, diseñador,
diseñador de pruebas, roles de gestión y roles de administración.
Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación y progreso.
![Page 18: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/18.jpg)
RUP Visión Estática En su visión estática, el modelo RUP está
compuesto por:Artefactos: Son los elementos de entrada y
salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, código, ejecutables…)
Flujos de trabajo: son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.
![Page 19: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/19.jpg)
RUP Visión Estática En su visión estática, el modelo RUP está
compuesto por:Disciplinas: son “contenedores” empleados
para organizar las actividades del proceso. RUP comprende 6 disciplinas de proceso y 3 de soporte.Proceso: modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo.Soporte: gestión de proyecto, gestión de configuración y cambio, y entorno.
![Page 20: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/20.jpg)
RUP Visión Dinámica En su visión dinámica, la visión de la estructura del ciclo de
vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo.
Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP: 1.- Inicio. Es la fase de la idea, de la visión inicial de
producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”.
2.- Elaboración. Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.
![Page 21: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/21.jpg)
RUP Visión Dinámica
3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el “hito del inicio de la capacidad operativa”.
4.- Transición. Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.
![Page 22: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/22.jpg)
AdministraciónAmbiente
Modelación de Negocios
Implementación
Prueba
Análisis y Diseño
Iteración(es)Preliminar
Iter.#1
FasesDisciplinas de Procesos
Iteraciones
Disciplinas de Soporte
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Despliegue
Admin. Configuración
Requerimientos
Elaboración TransiciónInicio Construcción
Estática
RUP Visión Dinámica
Dinámica
![Page 23: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/23.jpg)
Conformación del Equipo
ROLES TAREAS ASIGNADAS
Gestor del proyecto Establecer Condiciones de Trabajo
Analista del sistema Encontrar Actores y Casos de Uso Estructurar el Modelo de Casos de Uso
Arquitecto del sistema Priorizar los Casos de Uso Efectuar el Análisis Arquitectural Efectuar el Diseño Arquitectural Efectuar la Implementación Arquitectural
Especificador de casos de uso Detallar un Caso de Uso
Diseñador de interfaz de usuario Prototipar una Interfaz de Usuario
Ingeniero de casos de uso Analizar un Caso de Uso Diseñar un Caso de Uso
![Page 24: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/24.jpg)
Conformación del Equipo
ROLES TAREAS ASIGNADAS
Ingeniero de componentes Analizar una Clase Analizar un Paquete Diseñar una Clase Diseñar un Subsistema Implementar un Subsistema Implementar una Clase Realizar una Prueba de Unidad Implementar una Prueba
Integrador del sistema Integrar el Sistema
Ingeniero de pruebas Planear las Pruebas Diseñar las Pruebas Evaluar las Pruebas
Verificador de integración Realizar una Prueba de Integración
Verificador del sistema Realizar las Pruebas del Sistema
![Page 25: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/25.jpg)
Características de RUP
Dirigido por los Casos de Uso
Centrado en laArquitectura
Iterativo e Incremental
![Page 26: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/26.jpg)
Dirigido por Casos de Uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema.
Los casos de uso también guían el proceso de desarrollo (diseño, implementación y pruebas).
De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, que avanza a través de una serie de flujos de trabajo.
![Page 27: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/27.jpg)
Identificacion
AdministradorConsulta
<<extend>>
<<communicate>>
XOX
XOX
XOX
Modelo de análisis Modelo de diseño
Modelo de despliegue Modelo de implementación
Modelo de prueba
Especificado por Realizado por Distribuido por Implementado por
Verificado por
Dependencia entre los Casos de Uso y los demás modelos
![Page 28: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/28.jpg)
Iterativo e incremental
Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento.
Las iteraciones deben seleccionarse y ejecutarse de forma planificada. Esta selección se basa en dos cosas:
El conjunto de casos de uso que amplían funcionalidad
En los riesgos mas importantes que deben mitigarse
En cada iteración se identifica y especifica los casos de uso relevantes, se crea un diseño utilizando la arquitectura seleccionada como guía, para implementar dicho caso de uso.
![Page 29: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/29.jpg)
Desarrollo “en cascada” tradicional retarda la reducción del Riesgo
RIESGO
T I E M P O
Test Subs.
Test. Sistema
Cod. & Test U.
Diseño
An. Requer.
![Page 30: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/30.jpg)
Aplicando cascada iterativamente
Las primeras iteraciones reducen los principales riesgos Cada iteración produce una versión ejecutable, un
incremento adicional al sistema Cada iteración incluye integración y test
TC
DR
T I E M P O
Iteración 1 Iteración 2 Iteración 3
TC
DR
TC
DR
![Page 31: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/31.jpg)
Centrado en la Arquitectura La arquitectura se describe mediante diferentes
vistas del sistema en construcción. Incluye aspectos estáticos y dinámicos.
La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando de los detalles de lado.
La arquitectura debe permitir el desarrollo de todos los casos de uso requeridos actualmente y a futuro, y los casos de uso deben encajar en la arquitectura.
![Page 32: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/32.jpg)
Vistas de UML: Arquitectura 4 + 1
5 Vistas 9 Diagramas
Organización de Modelos
![Page 33: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/33.jpg)
casos de uso
Diagramas de Casos de Uso
![Page 34: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/34.jpg)
• Proporciona credibilidad en una etapa inicial del desarrollo del sistema
• Asegura una comprensión mutua de los requisitos
• Que se hayan capturado todos los requerimientos• Que los desarrolladores hayan entendido los
requerimientos
Usados Para VerificarUsados Para Verificar
Usados Para Comunicarse Usados Para Comunicarse con el Usuario Final y el Experto de Dominio con el Usuario Final y el Experto de Dominio
Diagramas de Casos de Uso
![Page 35: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/35.jpg)
Sistema de Pub
Barmen
Vender Bebida
Informar Bodega
Registrar Venta
Sistema de Bodega
«extend»
«include»
incluye
caso de uso
actor
extiende
Límite
Diagramas de Casos de Uso
![Page 36: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/36.jpg)
Diagramas de Clases
![Page 37: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/37.jpg)
Usados para mostrar la Estructura Estática de un sistema computacional o una parte relevante del mundo real
Son los diagramas más frecuentemente usados. Y se les puede considerar con Tres Perspectivas posibles:
Conceptual – muestra las entidades del mundo realcon sus relaciones
Especificación – muestra la estructura del sistemao sus partes, destacando las interfaces
Implementación – el diseño del código fuente
Diagramas de Clases
![Page 38: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/38.jpg)
Cliente
Bebida
Barmen
Pedido
Venta
- valor: Doble
+ ImprimirBoleta()
Bodega
Jugo Natural
Gaseosa
1
1..*
1
realiza
0..*
1tiene
1..*
1almacena
0..*
asociación
multiplicidad
atributooperación
herencia
clase
Diagramas de Clases
![Page 39: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/39.jpg)
Diagramas de Secuencia
![Page 40: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/40.jpg)
Usados para representar el comportamiento del sistema
Muestran colaboración a través de mensajes entre los objetos del sistema
Destacan: Mensajes enviados entre los objetos Orden secuencial entre los mensajes Un escenario concreto, sin condiciones
Útiles tanto en análisis (identificación de clases), como en diseño (especificación de componentes)
Diagramas de Secuencia
![Page 41: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/41.jpg)
mensaje
objeto
línea de vida
{x N}
Pepe :Barmen
Interfaz Barmen
(from Use Case View)
Motor Venta
(from Use Case View)
BD de Ventas
(from Use Case View)
Frambuesa :Jugo Natural
(from Logical Model)
12345 :Venta
(from Logical Model)
Ingresar Datos Venta
Confirmar Venta
Ejecutar Venta
Crear Venta
Crear Bebida
Ingresar Venta
destrucción de objeto
creación de objeto
ciclos
Diagramas de Secuencia
![Page 42: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/42.jpg)
Diagramas de Colaboración
![Page 43: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/43.jpg)
• Usados para representar el comportamiento del sistema
• Muestran colaboración entre los objetos del sistema
• Destacan:– Mensajes enviados entre los objetos– Enlaces entre los objetos– Un escenario concreto, sin condiciones
• Útiles tanto en análisis (identificación de clases),como en diseño (especificación de componentes)
Diagramas de Colaboración
![Page 44: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/44.jpg)
Pepe :Barmen
Bucarest :Sistema de
Bodega
Interfaz Barmen
Comunicador Bodega
Motor Venta
Interfaz Bodega
El cálculo dió la cantidad bajo la mínima permitida - hay que pedir bebida de la bodega
1 Vender Jugo Natural
1.1 Vender Jugo Natural
1.2 Calcular Cantidad Bebida
1.3 Pedir Bebida
1.4 Pedir Bebida
1.5 Pedir Bebida
enlace
objeto
mensaje
Diagramas de Colaboración
![Page 45: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/45.jpg)
Diagramas de Actividades
![Page 46: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/46.jpg)
• Usados para representar el comportamiento del sistema o negocio
• Muestran actividades y procesos
• Destacan:– Condiciones y flujos alternativos– Tareas y procesos concurentes– Responsabilidades sobre ciertas actividades
• Útiles en análisis de negocio para capturar procesos de alto nivel
Diagramas de Actividades
![Page 47: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/47.jpg)
Inicio
Fin
Barmen Ingresa Venta
Sistema Valida Cantidad Bebida
Candidad
<
Mínima
Permitida
Sistema Registra Venta
Pedir Bebida de BodegaVenta de Bebida
[si]
[no]
actividad
decisión
sincronización
Diagramas de Actividades
![Page 48: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/48.jpg)
Diagrama de Estados
![Page 49: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/49.jpg)
• Usados para representar el comportamiento INTERNO de un objetoo de un módulo del sistema
• Muestran estados en los cuales un objeto se puede encontrar
• Destacan:– Estados – Transiciones y condiciones de las transiciones– Actividades realizadas
• Típicamente usados para describirciclo de vida de un objeto
Diagrama de Estados
![Page 50: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/50.jpg)
Inicio
a Pedidos Cobrados
INGRESADO SERVIDO
COBRADO PERDIDO
CANCELADO
a Pedidos Anulados A Pedidos
Perdidos
Si el estado no se cámbia durante 1 día
servir
cancelar1 díacobrar
estado
transición
inicio
fin
Diagrama de Estados
![Page 51: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/51.jpg)
Diagrama de Componentes
![Page 52: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/52.jpg)
• Usados para mostrar los Módulos Físicosde software:– Los ejecutables y librerías dinámicas– Las páginas WEB y los scripts– Los módulos o funciones, etc.
• Sin embargo se usan más bien para capturar la Organización de los Componentes de Software (EXE, DLL, EJB, etc)
• Destacan Dependencias entre los Componentes
Diagrama de Componentes
![Page 53: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/53.jpg)
«executable»
TouchScreen
«DAO»
Venta
«Oracle»
BDPub
«EJB»
Bodeguero
«EJB»
Vendedor
VendedorRemote
BodegueroLocal
Barmen
(from Use Case View)
Sistema de Bodega
(from Use Case View)
dependencia
componente
interfaz
Diagrama de Componentes
![Page 54: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/54.jpg)
Diagrama de Distribución
![Page 55: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/55.jpg)
• Usados Para Modelar las Relaciones entre el Software y el Hardware
• Mapeo de los Componentes de Softwarea los Nodos de Hardware
• Típicamente contienen elementos tales como– Servidores– Procesadores– Impresoras– Redes computacionales– Etc.
Diagrama de Distribución
![Page 56: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/56.jpg)
Serv idor Pub
Serv idor BodegaCliente TouchScreen
«executable»
:TouchScreen
«EJB»
:Vendedor
«DAO»
:Venta
«EJB»
:Bodeguero
Serv idor BD
«Oracle»
:BDPub
Barmen
(from Use Case View) Sistema de Bodega
(from Use Case View)
nodo
enlace
Diagrama de Distribución
![Page 57: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/57.jpg)
Modelado del Nego-
cio Requisitos Análisis Diseño
Implemen-tación
Prueba Despliegue
Modelo del Negocio
X
Modelo del Dominio X X
Modelo de Casos de Uso X
Modelo de Análisis
X
Modelo de Diseño X
Modelo de Despliegue
X X
Modelo de Imple-mentación
X X
Modelo de Prueba
X X
Modelos y Flujos de Trabajo
![Page 58: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/58.jpg)
Seis Mejores Prácticas
![Page 59: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/59.jpg)
Seis “Mejores Prácticas”
Controlar Cambios
Administrar requerimientos
ArquitecturasBasadas en
Componentes
DesarrollarIterativamente
Verificar Calidad
ModelizarVisualmente
![Page 60: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/60.jpg)
• El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada.
• Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema.
• RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero.
• Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable tempranamente.
Desarrollo Iterativo
![Page 61: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/61.jpg)
Desarrollo Iterativo
PlaneamientoPlaneamientoInicialInicial
PlaneamientoPlaneamiento
RequerimientoRequerimientoss
Análisis y DiseñoAnálisis y Diseño
ImplementaciónImplementación
PruebaPrueba
DistribuciónDistribución
EvaluaciónEvaluación
Ambiente deAmbiente deAdministraciónAdministración
Cada iteración resulta en un release ejecutable
![Page 62: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/62.jpg)
• RUP describe cómo:
– Obtener los requerimientos
– Organizarlos
– Documentar requerimientos de funcionalidad y restricciones
– Rastrear y documentar decisiones
– Captar y comunicar requerimientos del negocio
• Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseño, la implementación y las pruebas.
Administración de requerimientos
![Page 63: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/63.jpg)
Req. 10 Aprobado Bajo Alta
Req. 13 Propuesto Medio Baja
Req. 40 Obligatorio Alto Alto
$$$
$$
$
Costo Esfuerzo
RiesgoStatus
Prioridad
Administración de requerimientos
![Page 64: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/64.jpg)
Arquitecturas basadas en componentes
• El proceso se basa en diseñar tempranamente una arquitectura base ejecutable.
• La arquitectura debe ser:– Flexible– Fácil de modificar– Intuitivamente comprensible– Promueve la reutilización de componentes
• RUP apoya el desarrollo basado en componentes, tanto nuevos como preexistentes.
![Page 65: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/65.jpg)
Arquitecturas basadas en componentes
Comprado
Existente
NuevoDatabaseDatabase CRMCRM
Funciones de cliente/productos
Mecanismos de interfaces
Funciones de licenciamiento
Cliente Producto Licencia
![Page 66: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/66.jpg)
Modelamiento Visual
• Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes.
• Bloques de construcción:– Permiten la comunicación en el equipo de
desarrollo– Permiten analizar la consistencia:
• entre las componentes• entre diseño e implementación
• UML es la base del modelamiento visual de RUP.
![Page 67: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/67.jpg)
Diagramas de Casos de Uso Diagramas de Clases Diagramas de Estados Diagramas de Componentes Diagramas de Implementación
Código
Clases
Subsistemas
Modelización Visualeleva el nivel de abstracción
Modelamiento Visual
![Page 68: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/68.jpg)
Verificación de la Calidad
La actividad fundamental de esta práctica es el testing
Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance
• El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.
![Page 69: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/69.jpg)
Plan de actividades de aseguramiento de la calidad
Conjunto de actividades que serán ejecutadas para generar confianza en que el producto cumplirá con los requerimientos y el proceso es efectivo
Cliente
NecesidadesNecesidades
RequisitosRequisitos
Revisiones
Verificaciones
Validaciones
ProductoProducto
Verificación de la Calidad
![Page 70: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/70.jpg)
• Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto.
• RUP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo.
Las solicitudes de cambios formales facilitan la claridad de comunicación
La propagación del cambio es evaluable y controlable
Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo
Control de cambios
![Page 71: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/71.jpg)
Control de cambios
Administración de configuración y cambios
Fallas reportadasFallas reportadas
Órdenes de TrabajoÓrdenes de Trabajo
Petición de nuevasPetición de nuevascaracterísticascaracterísticas
Petición de Petición de cambios y cambios y arreglo de arreglo de defectosdefectos
Petición de Petición de cambios y cambios y arreglo de arreglo de defectosdefectos
Administración Administración de de
configuraciónconfiguración
Administración Administración de de
configuraciónconfiguración
Calidad Calidad del del
productoproducto
Calidad Calidad del del
productoproducto
![Page 72: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/72.jpg)
Disciplinas y Flujos de Trabajo
![Page 73: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/73.jpg)
Disciplinas • Una disciplina es una colección de actividades
relacionadas vinculadas con un área específica del proyecto.
• Este agrupamiento de actividades en disciplinas es principalmente para facilitar la comprensión del proyecto desde la perspectiva tradicional del modelo en cascada.
Flujo de Trabajo• Un flujo de trabajo describe la secuencia en que
se realizan las actividades en una disciplina, quienes la realizan (trabajadores) y que artefactos producen..
![Page 74: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/74.jpg)
1. Modelado del negocio: describe la estructura y la dinámica de la organización.
2. Requisitos: describe el método basado en casos de uso para extraer los requisitos.
3. Análisis y diseño: describe las diferentes vistas arquitectónicas.
4. Implementación: tiene en cuenta el desarrollo de software, la prueba de unidades y la integración.
5. Pruebas: describe los casos de pruebas, los procedimientos y las métricas para evaluación de defectos.
6. Despliegue: cubre la configuración del sistema entregable.
Disciplinas de Proceso
![Page 75: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/75.jpg)
1. Gestión de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto.
2. Gestión del Proyecto: describe varias estrategias de trabajo en un proceso iterativo.
3. Entorno: cubre la infraestructura necesaria para desarrollar un sistema.
Disciplinas de Soporte
![Page 76: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/76.jpg)
Disciplinas y Flujos de Trabajo
Disciplinas de Proceso
Disciplinas de Soporte
![Page 77: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/77.jpg)
Modelamiento de Negocio
Los objetivos son:Entender la estructura y la dinámica del negocio.Asegurar que los clientes, usuarios y desarrolladores
tengan un entendimiento común de la organización.Un Modelo de Casos de Uso del Negocio describe los
proceso de negocio de una empresa en términos de casos de uso del negocio y actores del negocio
que se corresponden con los procesos del negocio y los clientes respectivamente .
![Page 78: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/78.jpg)
Modelamiento de Negocio – Flujo de Trabajo
![Page 79: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/79.jpg)
Requerimientos
• Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer:– Relevar requerimientos– Documentar funcionalidad y restricciones– Documentar decisiones– Identificar actores– Identificar casos de uso
• Los requerimientos no funcionales se incluyen en una especificación complementaria.
![Page 80: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/80.jpg)
Requerimientos – Flujo de Trabajo
![Page 81: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/81.jpg)
Objetivos:• Ejecutar las tareas y funciones descritas en los casos
de uso• Satisfacer todos los requerimientos• Flexible a cambiosEl diseño se centra en la noción de arquitecturaDiseñar y validar la arquitectura es una tarea esencial.El modelo de diseño consta de
• Clases estructuradas en paquetes• Diseños de subsistemas con interfaces
definidas (componentes)• Forma de colaboración entre las clases.
Análisis y Diseño
![Page 82: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/82.jpg)
Análisis y Diseño – Flujo de Trabajo
![Page 83: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/83.jpg)
Implementación
• Objetivo:
– Definir la organización del código– Implementar clases y objetos en forma de
componentes (fuente, ejecutables, etc.)– Probar las componentes desarrolladas– Integrar las componentes en un sistema
ejecutable
![Page 84: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/84.jpg)
Implementación – Flujo de Trabajo
![Page 85: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/85.jpg)
Test
• Objetivo:– Verificar la interacción entre los objetos– Verificar la integración apropiada de componentes– Verificar que se satisfacen los requerimientos– Identificar los defectos y corregirlos antes de la
instalación
• RUP describe como planear y ejecutar estas pruebas.• RUP propone probar los componentes desde el
principio: Confiabilidad, funcionalidad y performance.
![Page 86: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/86.jpg)
Test – Flujo de Trabajo
![Page 87: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/87.jpg)
Despliegue
• Producir un producto y hacerlo llegar a sus usuarios finales.
• Incluye varias actividades:– Producir un “release”– Empaquetar el software– Distribuir el software– Realizar pruebas beta– Instalar el software– Apoyar a los usuarios– Migración de datos
![Page 88: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/88.jpg)
Despliegue – Flujo de Trabajo
![Page 89: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/89.jpg)
Administración y Configuración de Cambios• Forma de controlar los artefactos producidos por las
personas que trabajan en el proyecto.
• Algunos problemas habituales:– Actualizaciones simultáneas– Múltiples versiones
• RUP da guías para:– Desarrollos en paralelo– Automatizar la construcción– Administrar defectos
![Page 90: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/90.jpg)
Administración y Configuración de Cambios – Flujo de Trabajo
![Page 91: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/91.jpg)
Administración del Proyecto
• Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios.
• Existen pocos proyectos realmente exitosos.• RUP incluye:
– Un framework para manejo de proyectos de software
– Guías para planificación, provisión de personal, ejecución y monitoreo de planes
– Un framework para manejar riesgos
![Page 92: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/92.jpg)
Administración del Proyecto – Flujo de Trabajo
![Page 93: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/93.jpg)
Entorno
• Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto.
• RUP guía en la configuración de un ambiente de proceso apropiado a cada proyecto.
• Se debe seleccionar un conjunto de artefactos para el proyecto, esta elección se puede recoger en un documento breve llamado Marco de Desarrollo
![Page 94: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/94.jpg)
Entorno
![Page 95: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/95.jpg)
Requerimientos
El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia el sistema correcto.
Hay diferentes puntos de partida para la captura de requisitos. En algunos casos comenzamos haciendo un modelo
del negocio o partimos de uno ya desarrollado. En otros casos el cliente puede ya haber desarrollado
una especificación completa de requisitos no basada en objetos, de la cual podemos partir.
![Page 96: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/96.jpg)
Analista Arquitecto Especificador de Casos de uso
Diseñador de interface
Requerimientos - Workflow
![Page 97: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/97.jpg)
Requerimientos
Trabajador Responsable de (artefacto)
Analista de sistemas Modelo de casos de uso
Actores
Glosario
Especificador de casos de uso Caso de uso
Diseñador de Interfaz de Usuario Prototipo de interfaz de usuario
Arquitecto Descripción de la arquitectura (vista del modelo de casos de uso)
![Page 98: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/98.jpg)
Análisis
Durante el análisis, revisamos los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos.
El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero, incluyendo su arquitectura.
![Page 99: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/99.jpg)
Análisis - WorkflowArquitecto Ing de Casos
de UsoIng de Componentes
![Page 100: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/100.jpg)
Análisis
Trabajador Responsable de (artefacto)
Arquitecto Modelo de Análisis
Descripción de la arquitectura
Ingeniero de Casos de Uso Realización de casos de usos - Análisis -
Ingeniero de Componentes Clases del Análisis
Paquete del análisis
![Page 101: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/101.jpg)
Diseño
Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis.
El diseño es el centro de atención al final de la fase de elaboración y comienzo de las iteraciones de construcción .
![Page 102: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/102.jpg)
Diseño
Modelo de Análisis Modelo de Diseño
Modelo conceptual. Modelo físico (implementación)
Genérico respecto al diseño (aplicable a varios diseños)
Específico para una implementación
Tres estereotipos: entidad, control, interface.
Cualquier nro. de estereotipos físicos.
Menos formal. Mas formal.
Menos caro de desarrollar Más caro.
![Page 103: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/103.jpg)
Diseño
Modelo de Análisis Modelo de Diseño
Menos capas. Más capas.
Dinámico (no muy centrado en la secuencia)
Dinámico (muy centrado en la secuencia)
Creado principalmente como trabajo manual
Creado fundamentalmente como "programación visual" en ing.de ida y vuelta.
Puede no mantenerse todo el ciclo de vida.
Debe ser mantenido todo el ciclo de vida.
![Page 104: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/104.jpg)
Diseño - WorkflowArquitecto Ing de Casos
de UsoIng de Componentes
![Page 105: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/105.jpg)
DiseñoTrabajador Responsable de (artefacto)
Arquitecto Modelo de diseño
Modelo de despliegue
Descripción de la arquitectura
Ingeniero de Casos de Uso Realización de casos de usos - Diseño -
Ingeniero de Componentes Clases del diseño
Subsistema de Diseño
Interfaz
![Page 106: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/106.jpg)
Implementación Se inicia con el resultado del diseño y se implementa
el sistema en término de componentes, es decir, ficheros de código fuente, scripts, ficheros de código binario, ejecutables, y similares.
Es el centro durante las iteraciones de construcción. Aunque también se realiza durante:
La fase de elaboración, para crear la línea base ejecutable de la arquitectura
La fase de transición para tratar defectos tardíos.
![Page 107: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/107.jpg)
Implementación
Trabajador Responsable de (artefacto)
Arquitecto Modelo de implementación
Modelo de despliegue
Descripción de la arquitectura
Integrador de sistema Integración de sistema
Ingeniero de Componentes Componente
Implementación de subsistema
Interfaz
![Page 108: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/108.jpg)
Implementación - WorkflowArquitecto Integrador del
SistemaIngeniero de
Componentes
![Page 109: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/109.jpg)
Prueba Los objetivos de la prueba son:
Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de integración y las pruebas de sistema.
Diseñar e implementar pruebas creando: Casos de prueba (especifican qué probar),
Procedimientos de prueba (especifican cómo realizar las pruebas),
Componentes de prueba para automatizar las pruebas.
Realizar las pruebas.
![Page 110: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/110.jpg)
Prueba
Trabajador Responsable de (artefacto)
Diseñador de Pruebas Modelo de pruebas
Casos de Prueba
Procedimientos de prueba
Evaluación de pruebas
Plan de pruebas
Ingeniero de Componentes Componente de pruebas
Ingeniero de Pruebas de Integración
Defecto
Ingeniero de Pruebas de Sistema Defecto
![Page 111: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/111.jpg)
Fases
![Page 112: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/112.jpg)
Fase de Inicio Durante la fase de inicio se desarrolla la
descripción del producto final, y se presenta el análisis del negocio.
Esta fase responde las siguientes preguntas:• ¿Cuáles son las principales funciones del sistema para
los usuarios mas importantes?
• ¿Cómo podría ser la mejor arquitectura del sistema?
• ¿Cuál es el plan del proyecto y cuanto costará desarrollar el producto?
En esta fase se identifican y priorizan los riesgos mas importantes.
![Page 113: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/113.jpg)
Fase de Inicio
Los objetivos son:• Poner en marcha el proyecto• Desarrollar el análisis del negocio hasta
justificar la puesta en marcha plan de proyecto
• Para ello• Esbozar una arquitectura• Mitigar los riesgos• Análisis inicial del negocio (coste, agenda,
recuperación de la inversión)
![Page 114: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/114.jpg)
• Un documento de visión general:
– Requerimientos generales del proyecto
– Características principales
– Restricciones
• Modelo inicial de casos de uso (10% a 20 % listos).
• Glosario.
• Caso de negocio:
– Contexto
– Criterios de éxito
– Pronóstico financiero
• Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.
Artefactos
Fase de Inicio
![Page 115: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/115.jpg)
Inicio Elaboración Construcción Transición
Objetivos del Ciclo de Vida
• Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo.
• Comprensión de los requerimientos plasmados en casos de uso.
Hito:
Fase de Inicio
![Page 116: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/116.jpg)
Fase de Elaboración Durante la fase de elaboración se especifican
en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura.
Las iteraciones en la fase de elaboración:Establecen una firme comprensión del problema a
solucionar.Establece un plan detallado para las siguientes
iteraciones.Elimina los mayores riesgos.
El resultado de esta fase es la línea base de la arquitectura.
![Page 117: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/117.jpg)
Fase de Elaboración Los objetivos son:
Recopilar la mayor parte de los requisitos definiéndolos como casos de uso
Establecer una arquitectura sólida para guiar las fases posteriores
Continuar la observación y control de los riesgos críticos
Completar el plan de proyecto• Para ello
• Se toman decisiones considerando la comprensión global del sistema: ámbito, requisitos funcionales y
no funcionales
![Page 118: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/118.jpg)
• Modelo de casos de uso (80% completo) con descripciones detalladas.
• Otros requerimientos no funcio-nales o no asociados a casos de uso.
• Descripción de la Arquitectura del Software.
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.
Fase de Elaboración
Artefactos:
![Page 119: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/119.jpg)
• Condiciones de éxito de la elaboración:
– ¿Es estable la visión del producto?
– ¿Es estable la arquitectura?
– ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos?
– ¿Están de acuerdo con el plan todas las personas involucradas?
Concepción Elaboración Construcción Transición
Arquitectura de Ciclo de Vida
Hito:
Fase de Elaboración
![Page 120: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/120.jpg)
• En esta fase todas las componentes restantes se desarrollan e incorporan al producto.
• Todo es probado en profundidad.• El énfasis está en la producción eficiente y no
ya en la creación intelectual.• Puede hacerse construcción en paralelo,
pero esto exige una planificación detallada y una arquitectura muy estable.
Fase de Construcción
![Page 121: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/121.jpg)
Fase de Construcción
Los objetivos son:Línea base de la arquitectura crece hasta convertirse
en el sistema completoRiesgos reducidos o rutinariosImplementación de los casos de usoPrototipo
• Para ello• A través de sucesivas iteraciones e incrementos
se desarrolla un producto software, listo para operar, éste es frecuentemente llamado versión beta
![Page 122: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/122.jpg)
• El producto de software integrado y corriendo en la plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
Artefactos:
Fase de Construcción
![Page 123: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/123.jpg)
• Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:– ¿El producto está maduro y estable para instalarlo
en el ambiente del cliente?– ¿Están los interesados listos para recibirlo?
Concepción Elaboración Construcción Transición
CapacidadOperacional
Hito:
Fase de Construcción
![Page 124: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/124.jpg)
Fase de Transición Los objetivos son:
Cumplir requisitosGestionar todos los aspectos de implantaciónPruebas de aceptación
• Para ello• Las iteraciones en esta fase continúan
agregando características al sw. • El equipo se encuentra ocupado en
corregir y extender la funcionalidad del sistema desarrollado en la fase anterior.
![Page 125: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/125.jpg)
• El objetivo es traspasar el software desarrollado a la comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos).
• Incluye:– Pruebas Beta para validar el producto con las
expectativas del cliente– Ejecución paralela con sistemas antiguos– Conversión de datos– Entrenamiento de usuarios– Distribuir el producto
Fase de Transición
![Page 126: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/126.jpg)
• Condiciones de éxito:– ¿Se han alcanzado los objetivos fijados en la fase
de Inicio ?– ¿El usuario está satisfecho ?
Concepción Elaboración Construcción Transición
Hito:
Fase de Transición
Producto
![Page 127: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/127.jpg)
RUP y CMMI
![Page 128: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/128.jpg)
Modelo CMMI
Capability Maturity Model Integration. Modelo para la mejora o evaluación de los
procesos de desarrollo y mantenimiento de sistemas y productos de software.
Desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en enero de 2002.
Para los usuarios es difícil especificarlos en forma cuantitativa
![Page 129: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/129.jpg)
CMMI se desarrolló para facilitar y simplificar la adopción de varios modelos de forma simultánea, y su contenido integra y da relevo a la evolución de sus predecesores: CMM-SW (CMM for Sofwtare) SE-CMM(Systems Engineering Capability Maturity
Model) IPD-CMM(Integrated Product Development)
Modelo CMMI
![Page 130: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/130.jpg)
CMMI – Niveles de Madurez
NIVEL Descripción
1-Inicial Punto base. La organización tiene procesos ad-hoc o caóticos. El éxito se debe a personas heroícas.
2-Repetible La organización empieza a guardar información. Ya hay definiciones, pueden repetirse éxitos anteriores.
3-Definido Se conocen procesos estándares para desarrollar o mantener software. Hay prácticas de Ingeniería de Software y de Administración de procesos.
4-Administrado Se usan datos recolectados. Las decisiones están basadas en datos cuantitativos. Los procesos son medidos, hay retroalimentación.
5-Optimizado La organización se dedica a mejorar contínuamente. Se localizan debilidades y fortalezas.
![Page 131: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/131.jpg)
CMMI Areas Clave de Proceso (KPAs)
NIVEL Áreas Clave de Proceso
1-Inicial
2-Repetible Gestión de Requisitos (REQM), Planificación de proyecto, Monitorización y control de Proyectos, Gestión y acuerdo de suministros, Medición y Análisis, Gestión de la calidad de procesos y productos, Gestión de la configuración
3-Definido Desarrollo de requisitos (RD), Solución técnica, Verificación, Validación, Integración de producto, Procesos orientados a la organización, Formación, Gestión Integrada de proyecto, Gestión de riesgos, Análisis y resolución de decisiones
4-Administrado Gestión cuantificada de proyectos, Rendimiento de los procesos de la organización
5-Optimizado Innovación y desarrollo
![Page 132: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/132.jpg)
Análisis RUP – CMMI RUP es un proceso
que define quién debe hacer las cosas, qué debe hacerse, cómo y cuándo.
Dado su enfoque mantiene modelos en lugar de gran cantidad de documentación, utiliza un lenguaje concreto y bien definido (UML).
CMMI es un modelo estático que define áreas claves (PA) en las que se deben
llevar a cabo prácticas específicas o genéricas, por lo tanto el hecho de implementar RUP en el desarrollo de un proyecto implica que ciertas KPA de CMMI sean alcanzadas y otras no.
![Page 133: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/133.jpg)
Áreas Clave de Proceso
Revisión
Gestión de Requisitos
RUP define claramente el proceso de administración de requerimientos y aporta herramientas como los casos de uso, es una de las bases de RUP
Planificación de proyecto
RUP habla de la planeación del proyecto de manera iterativa y del control de riesgos.
Monitorización y control de Proyectos
RUP define cómo debe ser el control del proyecto.
Gestión de la configuración
RUP es muy claro cuando se habla de administración de la configuración incluso es una de las mejores prácticas recomendada.
Análisis RUP – CMMI
![Page 134: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/134.jpg)
Áreas Clave de Proceso
Revisión
Gestión y acuerdo de suministros
RUP no menciona nada sobre administración de acuerdos, es algo no considerado.
Medición y Análisis La medición y análisis no están contemplados detalladamente en RUP.
Gestión de la calidad de procesos y productos
En la etapa de transición se lleva a cabo la verificación de la calidad aunque no tan detallada como lo exige CMMI. La verificación de calidad del producto está bien definida pero la evaluación de calidad del proceso no está considerada.
Análisis RUP – CMMI
![Page 135: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/135.jpg)
Conclusiones
![Page 136: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/136.jpg)
La aplicación formal del Proceso Unificado supone: Desventajas:
Grandes esfuerzos en la construcción de modelos. Necesidad del soporte de herramientas
informáticas. Ventajas:
Disminuye el riesgo del error de análisis / diseño acumulado.
Aligera el esfuerzo en implementación. Proporciona la documentación del ciclo de vida en
el mismo proceso.
Conclusiones
![Page 137: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/137.jpg)
El Proceso Unificado es flexible y se puede adaptar al grado de complejidad del modelo de proceso de desarrollo (descarte de algunos modelos o flujos).
El Proceso Unificado es abierto y permite la incorporación de enfoques y artefactos complementarios:
Patrones de diseño. Patrones de implementación. Combinación de varios modelos de proceso. Arquitecturas Dirigidas por Modelos (Model
Driven Architectures).
Conclusiones
![Page 138: DiseñO De Sistemas](https://reader033.vdocuments.pub/reader033/viewer/2022061200/54721573b4af9f9d0a8b4dd4/html5/thumbnails/138.jpg)
1. Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado, Addison-Wesley, Madrid, 1999.
2. Bruegge B., Dutoit A.H. Ingeniería de Software Orientado a Objetos, Prentice Hall– Pearson educación, México, 2002.
3. Jacobson I., Booch G., Rumbaugh J. El Proceso Unificado de Desarrollo de Software, Addison-Wesley, Madrid, 2000.
4. Pressman R.S. Ingeniería del Software. Un enfoque práctico (5ª ed.) Mc Graw-Hill; New York , 2001.
5. Rumbaugh J., Jacobson I., Booch G. El Lenguaje Unificado de Modelado. Manual de Referencia, Addison-Wesley, Madrid, 2000.
6. Sommerville I. Ingeniería de software, 6ª edición, Prentice Hall – Pearson educación, México, 2002.
7. Stevens P., Pooley R. Utilización de UML en Ingeniería del Software con Objetos y Componentes, Addison-Wesley, Madrid, 2002.
Bibliografía