1 Tema #1 – Proceso Unificado de Desarrollo INF 322 – Análisis de Sistemas II Deysi Arancibia...
-
Upload
rafael-ceballos -
Category
Documents
-
view
223 -
download
0
Transcript of 1 Tema #1 – Proceso Unificado de Desarrollo INF 322 – Análisis de Sistemas II Deysi Arancibia...
1
Tema #1 – Proceso Unificado de Desarrollo
INF 322 – Análisis de Sistemas II
Deysi Arancibia M.
Gustavo Succi Aguirre
Objetivos
Proporcionar una perspectiva general de RUP y la Ingeniería del Software
Caracterizar las fases y flujos de trabajo principales en el Proceso Unificado de Desarrollo
Contextualizar el uso de los Modelos del Negocio como paso inicial del Desarrollo del Software
Aprender la diferencia entre fase y disciplina
2
Tema #1. Proceso Unificado de Desarrollo
3
Tema #1. Proceso Unificado de Desarrollo
Desarrollo de Software. Las 4 “P”
Proyecto
Procesos
Producto
Personas Herramientas
Automatización
Resultado
Participantes
Plantilla
•Modelos•Codigo fuente•Ejecutables•Documentación
•Modelado Visual UML•Rational Rose, Visual UML, Objecteering
•Integrated Development Environment (IDE)•Visual Studio .NET, NetBeans...
•Gestión de la Configuración•CVS, ClearCase
•Gestión de Requisitos•RequiistPro,..
•Automatización documentación•SoDa•....
•Unified Process (UP)
•Rational Unified (Process) RUP
•OPEN
•OOSP
•...
4
Tema #1. Proceso Unificado de Desarrollo
Proceso de Ingeniería de Software
Conjunto de actividades que permiten trans-formar los requisitos de un cliente/usuario en un sistema software.
Conjunto de procedimientos, técnicas, herra-mientas y soporte documental que ayuda a los desarrolladores a realizar nuevo software.
Proceso de Desarrollo Software
Requisitos Sistema Software
5
LESE-1 Introducción al Modelado Visual
6
Tema #1. Proceso Unificado de Desarrollo
El Proceso Unificado de Desarrollo
Es un proceso de ingeniería del software que agrupa las 6 mejores prácticas de desarrollo software que existen en el mercado
Con
teni
do
Tiempo
7
Tema #1. Proceso Unificado de Desarrollo
Proceso Unificado – 6 Best Practices
Desarrollar Iterativamente
Gestionar Requisitos
Usar Arquitecturas de Componentes
Modelar Visualmente (UML)
Continuamente verificar Calidad del Software
Controlar Cambios en el Software
8
Tema #1. Proceso Unificado de Desarrollo
Proceso Unificado - Características
Dirigido por Casos de Uso Funcionalidad de valor para los usuarios
Centrado en la Arquitectura Descripción de aspectos estáticos y dinámicos del
software que son mas significativos
Iterativo e Incremental Divide el trabajo en mini-proyectos que
incrementalmente crean el producto software
9
Tema #1. Proceso Unificado de Desarrollo
Use Case Model
Analysis Model
Design Model
Implementation Model
Deployment Model
Bussiness Use Case Model Bussines Object Model
Modelos de Sistema Software en RUP
Test Model
especificado por
realizado por
implementado por
distrbuido por
verificado por
automatizado por
realizado por
Modelos en el Proceso Unificado de Desarrollo
de Software
10
Tema #1. Proceso Unificado de Desarrollo
Metodología – Cobertura del Curso
11
Tema #1. Proceso Unificado de Desarrollo
Disciplinas-Modelos-Artefactos
Bussiness Modeling Modelo Conceptual
Casos de Uso del Negocio Modelo de Objetos del Negocio
Requirements/Analysis Modelo de Casos de Uso
Diagramas UML de Casos de Uso Especificación de Casos de Uso
Modelo de Comportamiento Diagramas UML de Secuencia/Colaboración Diagramas UML de Estados/Actividades
12
Tema #1. Proceso Unificado de Desarrollo
Metodología (requerimientos)
Dominio
Glosario
Payment
ammount : Double
Customer
SalePays-for
ProductCatalog
ProductSpecificationdescribed-by
n
Register
1
1
1
1
Captured-on
Store
ncotains
Modelo Conceptual
Accounting System
HR System
Process Sale
Cash In
Payment Authorization Service
Cashier
Process Rental
Manage Users
System Administrator
Mangage Accounts
...
: CashierSystem
: Payment Authorization Service
makeNewSale()
enterItem(id,quantity)
endSale()
makePayment(amount)
validatePayment()
ok
performed
Secuencia Eventos(actores-sistema)Modelo Casos de Uso
Openning
Writing
ReadingClosing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close file
Diagramas Estados(objetos dominio /
Sistema)
RequisitosAutomatización
conceptosreglas dominio
Restricciones OCL
Descripciones c.u.
Modelo Comportamiento
13
Tema #1. Proceso Unificado de Desarrollo
Metodología - (Análisis y Diseño)
Glosario
Payment
ammount : Double
Customer
SalePays-for
ProductCatalog
ProductSpecificationdescribed-by
n
Register
1
1
1
1
Captured-on
Store
ncotains
Modelo Conceptual(atributos-relaciones)
Accounting System
HR System
Process Sale
Cash In
Payment Authorization Service
Cashier
Process Rental
Manage Users
System Administrator
Mangage Accounts
...
: CashierSystem
: Payment Authorization Service
makeNewSale()
enterItem(id,quantity)
endSale()
makePayment(amount)
validatePayment()
ok
performed
Secuencia EventosCasos de Uso
Openning
Writing
ReadingClosing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close file
Diagramas Estados(objetos dominio
Sistema)
RequisitosAutomatización
POSRegister
makePayment()createPayment()
POSSale
makePayment()
POSPayment
amount : Money
getTotal()
reg : POSRegister
p : POSPayment
sale : POSSale
: Cashier
1: makeNewSale() 2: create()
3: create(amount)
Diseño Clases(atributos/operaciones-relaciones)
ArquitecturaDiseño Colaboraciones Clases para evento
(secuencia de llamadas a métodos)
Descripciones c.u.
• Se establece la oportunidad y alcance el proyecto.
• Se identifican todas las entidades externas con las que se trata (actores) y se define la interacción a un alto nivel de abstracción:– Identificar todos los casos de uso
– Describir algunos en detalle
• La oportunidad del negocio incluye:– Criterios de éxito
– Identificación de riesgos
– Estimación de recursos necesarios
– Plan de las fases incluyendo hitos
Fases de RUP: InicioFases de RUP: Inicio
• 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.
Fases de RUP: InicioFases de RUP: Inicio
Productos:
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.
Fases de RUP: InicioFases de RUP: Inicio
Hito:
• Objetivos:– Analizar el dominio del problema
– Establecer una arquitectura base sólida
– Desarrollar un plan de proyecto
– Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto
• Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de arquitectura requieren una visión global del sistema.
Fases de RUP: ElaboraciónFases de RUP: Elaboración
• Es la parte más crítica del proceso:– Al final toda la ingeniería
“dura” está hecha
– Se puede decidir si vale la pena seguir adelante
• A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables.
• Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre.
• Se construye una arquitectura ejecutable que contemple:– Los casos de uso críticos
– Los riesgos identificados
Fases de RUP: ElaboraciónFases de RUP: Elaboración
Productos:
Fases de RUP: ElaboraciónFases de RUP: Elaboración
• 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.
Productos:
• 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?
– ¿Es el plan del proyecto algo realista?
– ¿Están de acuerdo con el plan todas las personas involucradas?
Concepción Elaboración Construcción Transición
Arquitectura de Ciclo de Vida
Fases de RUP: ElaboraciónFases de RUP: Elaboración
Hito:
• 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.
Fases de RUP: ConstrucciónFases de RUP: Construcción
• El producto de software integrado y corriendo en la plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
Fases de RUP: ConstrucciónFases de RUP: Construcción
Productos:
Fases de RUP: ConstrucciónFases de RUP: Construcción
• 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:
• 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
Fases de RUP: TransiciónFases de RUP: Transición
• Obtener autosuficiencia de parte de los usuarios.
• Concordancia en los logros del producto de parte de las personas involucradas.
• Lograr el concenso cuanto antes para liberar el producto al mercado.
Concepción Elaboración Construcción Transición
Producto
Fases de RUP: TransiciónFases de RUP: Transición
Objetivos:
Trabajador• Un trabajador define el comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el proyecto:– Una persona puede tener varios sombreros
– Es el rol que desempeña en un momento dado
• Responsabilidades:– Hacer una serie de actividades
– Ser el responsable de una serie de artefactos
DefinicionesDefiniciones
Actividades
DefinicionesDefiniciones
• Una actividad es una unidad de trabajo que se asigna a un trabajador. Ej.:– Crear o modificar un artefacto
• Una actividad lleva entre un par de horas y un par de días, involucra un solo trabajador y un número pequeño de artefactos.
• Las actividades se consideran en la planificación y evaluación del progreso del proyecto.
• Ejemplos:– Planificar una iteración - Administrador
de proyecto
– Encontrar actores y casos de uso - Analista
– Revisar el diseño - Revisor de diseño
– Ejecutar pruebas de performance - Ing. de pruebas de performance
Recurso Trabajador Actividad
Pablo Diseñador Diseño de Objetos
María Autor de Casos de Uso Detallar un Caso de Uso
José Diseñador de Casos de Uso Diseñar un Caso de Uso
Silvia Revisor de Diseño Revisar el Diseño
Eduardo Arquitecto Análisis de Arquitectura Diseño de Arquitectura
Asignación de actividadesAsignación de actividades
• Elementos de información producidos, modificados o usados por el proceso.
• Son los productos tangibles del proyecto.
• Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.
• Ejemplos:– Un modelo, como el modelo de
casos de uso o el modelo de diseño.
– Un elemento del modelo, como una clase o un caso de uso.
– Un documento tal como el Caso del Negocio o la Arquitectura del Software.
– Código fuente.
– Código ejecutable.
ArtefactosArtefactos
• Una lista de actividades, trabajadores y artefactos constituye un proceso.
• Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso.
• No siempre es posible representar flujos de trabajo.
Análisis deArquitectura
Diseño deArquitectura
DescribirConcurrencia
DescribirDistribución
Análisis deCasos de Uso
Diseño deCasos de Uso
Análisis deObjetos Diseño de
Objetos
Revisar elAnálisis
Revisar elDiseño
Revisar laArquitecturaRevisor de
Diseño
Diseñador
Diseñador deCasos de Uso
Arquitecto
Flujos de trabajoFlujos de trabajo
Flujos de Trabajode Ingeniería
Flujos de Trabajode Apoyo
Flujos de trabajo esencialesFlujos de trabajo esenciales
Flujos de trabajoFlujos de trabajo
• Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de negocios.
• RUP proporciona un lenguaje y proceso común para estos dos ámbitos.
• Para el modelamiento del negocio se usan “business use cases” (casos de uso del negocio):– La forma en que el software dará apoyo al negocio.
Cliente Reciclar
Imprimir Informe
Operador
Administrar Depósito
• 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 casos de uso describen la funcionalidad.
• Los requerimientos no funcionales se incluyen en una especificación complementaria.
RequerimientosRequerimientos
• Descripción de cómo se implementará el sistema: un plano
• Debe:– Ejecutar las tareas y funciones
descritas en los casos de uso
– Satisfacer todos los requerimientos
– Flexible a cambios
• El diseño se centra en la noción de arquitectura.
• Diseñ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ñoAnálisis y diseño
• Propósito:
– 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
ImplementaciónImplementación
• Propósito:– 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 las componentes desde el principio:– Confiabilidad, funcionalidad y
performance
• Las pruebas de regresión son importantes en desarrollos iterativos.
• Rational tiene herramientas para automatizar algunas pruebas.
PruebasPruebas
• Producir un producto y hacerlo llegar a sus usuarios finales.
• Incluye varias actividades:– Producir un “release”
– Empaquetar el software
– Distribuir el software
– Instalar el software
– Apoyar a los usuarios
• A veces también incluye:– Realizar pruebas beta
– Migración de datos
– Aceptación formal
• La mayor parte de la distribución ocurre durante la transición.
• Este es uno de los flujos de trabajo menos documentados en RUP.
DistribuciónDistribución
• 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
Administración de proyectosAdministración de proyectos
• 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
Administración de configuración y cambiosAdministración de configuración y cambios
• 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.
AmbienteAmbiente
Modelado del NegocioModelado del Negocio
Una empresa organiza su actividad por medio de un con-junto de procesos de negocio. Cada uno de ellos con una colección de datos que son producidos y manipula-dos mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo determinado.
Además, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan las políticas y la estructura de la información de la empresa.
La finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus datos, activida-des (o tareas), roles (o agentes) y reglas de negocio.
Modelado del NegocioLa extensión UML para el modelado de Nego-cios se basa en la adición de algunos estereo-tipos.Todos los conceptos de UML pueden ser usados para el modelado de negocios, pero los estereo-tipos que se presentarán proveen una terminolo-gía más afín a este propósito.El modelado del negocio se basa en dos diagra-mas principales, el modelo de casos de uso del negocio y los modelos de objetos del negocio.Adicionalmente se presenta el modelo del domi-nio
Casos de Uso del NegocioSon usados para representar la funcionalidad provista por una organi-zación.Preguntas típicas son:
¿Qué es lo que el negocio hace? ¿Por qué construimos el sistema¿..etc
Estos son representados desde una perspectiva organizacionalNo diferencian entre procesos manuales y automatizados (Los diagra-mas de Casos de Uso, se centran el los procesos automatizados)Muestran las interacciones entre casos de uso del negocio y actores del negocio.
Los casos de uso del negocio representan los procesos que un negocio ejecuta.
Los actores del negocio, representan roles con los cuales el negocio interactúa, tales como cliente o vendedores, etc.
Los actores del negocio representan a cualquiera o cualquier cosa fuera del negocio que interactúe con éste.
No representa roles o trabajadores en el interior de un negocio.Trabajadores en el interior de un negocio, son representado por business workers.
Un worker representa la abstrac-ción de un humano que interactua con el sistema. Un worker interac-tua con otros workers y manipula entidades mientras participa en la realización de un caso de uso.
Un case worker es un worker que interactua directamente con acto-res fuera del sistema.
Un internal worker es un worker que interactua con otros workers y entidades dentro del sistema.
Una entity es una clase pasiva, que no inicia interacciones. En el modelo de negocios representa objetos que los workers acceden, inspeccionan, manipulan y/o producen
NewUseCase<<business use case>> NewUseCase2 NewUseCase3
<Actor Name>
(f rom Actors)
NewClass<<business actor>>
<Actor Name>(f rom Actors)
Estereotipos en Herramienta CASEEstereotipos en Herramienta CASE
NewUseCase<<business use case>> NewUseCase2 NewUseCase3
<Actor Name>
(f rom Actors)
NewClass<<business actor>>
<Actor Name>(f rom Actors)
Estereotipos en Herramienta CASEEstereotipos en Herramienta CASE
La empresa interactúa con distin-tos elementos externos, entre los que se identifican el cliente externo (persona o entidad que solicita la compra de productos a la empre-sa), el proveedor (persona o enti-dad que reabastece de productos a la empresa) y por último la em-presa de transportes, que es una subcontratada encargada de servir los pedidos desde los distintos almacenes regionales a los clien-tes de la empresa.
Modelo de Casos de Uso del NegocioModelo de Casos de Uso del Negocio
Modelo de Obje-tos del Negocio
Vender Producto
Seguimiento y Consulta de Productos
Modelo de Dominio del NegocioModelo de Dominio del Negocio
Los objetos de información que fluyen entre las actividades de un caso de uso del negocio repre-sentan datos del dominio, por lo que constituyen el modelo del dominio, que incluirá los concep-tos y sus relaciones, representa-das en un diagrama de clases UML.
En esta etapa, identificamos conceptos y no tanto relaciones entre ellos, concentrándose en las asociaciones debe conocer.
Por ej. Un pedido debe conocer el cliente que los solicita y los productos que lo componen.
50
Modelación del Negocio de un Conjunto Federado de Bibliotecas:
Un usuario puede ser:•Socio de una biblioteca (S)•Bibliotecario (B)
Las bibliotecas están conectadas entre sí para permitir el préstamo a socios de otras bibliotecas
Dos partes claramente diferenciadas del sistema de una de estas bibliotecas:Operaciones de un usuario en la propia biblioteca
Altas y bajas de socios (B)Altas y bajas de libros (B)Consulta de libros disponibles (B,S)Reservas (S), préstamos y devoluciones de libros (B)Consulta de reservas realizadas y libros prestados (B,S)
Operaciones que implican una conexión a otra bibliotecaConsulta de los libros de otras bibliotecas (S)Reserva de un libro de otra biblioteca (S)Consulta de reservas realizadas y libros prestados en otra biblioteca (S)
Ejercicio PrácticoEjercicio Práctico
51
Referencias
“Understading UML” Shinan Salhir, http://home.earthlink.net/~salhir
“The Object Oriented Paradigm” Shinan Salhir, http://home.earthlink.net/~salhir
“Applying UML and Patterns. An Introduction to Object Oriented Analysis and Design and the Unified Process” Craig Larman. Ed Prentice Hall
“El Proceso Unificado de Desarrollo Software”, I. Jacobson, Grady Booch, J. Rumbaugh, Ed Addison Wesley
es.geocities.com/gustsucc
www.uml.org
www.omg.org