Conceptos PUDS

Ingeniería del Software I (4º I.I.)

1

Ingeniería del Software I (4º I.I.) Módulo 1. Tema 4: Desarrollo de Sistemas OO: Proceso Unificado de Desarrollo 1

MODULO I:

Tema 4: Desarrollo de Sistemas Orientado a Objetos. Proceso Unificado de Desarrollo


Proceso Unificado de Desarrollo. RUP

Hacia un Método Orientado a Objetos

Un proceso de desarrollo de programas tiene como objetivo la formalización de las actividades relacionadas con la elaboración de sistemas informáticos.

Debe ser:• Reproducible• Definido• Medible en cuanto a rendimiento• Optimizable• ...


2


Proceso Unificado de Desarrollo. RUP


Proceso Unificado de DesarrolloLa estructura estática del Proceso Unificado de Rational (RUP) se define en base a cuatro elementos,

que son: - los roles que responde a la pregunta ¿quién?, - las actividades (activities), que responden a la pregunta ¿cómo?, - los productos (artifacts), que responden a la pregunta ¿qué?, y- los flujos de trabajo (workflows), que responden a la pregunta ¿cuándo?

Roles: Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el ‘dueño’ de un conjunto de artefactos.

Actividades: Una actividad de un trabajador en concreto es una unidad de trabajo que una persona que desempeñe ese rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.

Productos: Un producto o artefacto es un trozo de información que es producido, modificado o usado por un proceso. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final.


3


Proceso Unificado de DesarrolloRUP ofrece una plantilla para el proceso de desarrollo, identificando tanto los roles,

como las actividades.

En la descripción del proceso, tal y como aparece en el gráfico anterior, se muestran las dos dimensiones en las que se estructura el proceso:

• El eje horizontal representa el tiempo y muestra como es el despliegue del ciclo de vida, es decir, el aspectos dinámicos del proceso y cómo se llevará a efecto mediante fases, iteraciones e hitos. A lo largo del tiempo, el proyecto se desarrolla en 4 fases: Inicio, Elaboración, Construcción y Transición. A su vez, cada una esas fases se pueden dividir en una serie de iteraciones (de 1 a n) según las necesidades del proyecto.

• El eje vertical representa las disciplinas que agrupan las actividades del proceso de desarrollo. Por ejemplo, las actividades relacionadas con la adquisición de requisitos (Requirements), la gestión de proyectos (Project Management), etc.

La combinación de ambas dimensiones nos permite identificar en que momento comenzarán cada una de las disciplinas y la carga de trabajo que representa por la amplitud de la curva. Por ejemplo, durante la fase de inicio, se comenzarían el modelado de negocio, requisitos, análisis y diseño, implementación, pruebas, etc, teniendo las dos primeras la mayor carga de trabajo del proyecto durante esta fase.


Se apoya en tres principios básicos:Dirigido por casos de uso

Los casos de uso dirigen y controlan el proceso de desarrollo ensu totalidad

Centrado en la arquitectura Es la pieza clave que permite comprender el sistema, organizar el desarrollo y hacer evolucionar el software.

Proceso iterativo e incrementalEl desarrollo se plantea de manera progresiva, de tal modo que se atenúen los riesgos y se planteen las cuestiones en el instante en el que estamos capacitados para resolverlas.

El Proceso Unificado de Desarrollo. RUP


4


Requisitos Capturar, definir y validar los casos de uso

Realizar los casos de uso

Verificar que se satisfacen los casos

de uso

Análisis & Diseño

Implementación

Pruebas

Casos de Usointegran el

trabajo

Dirigido por casos de uso


Use Case Use-Case Realization - Analysis

Use-Case Realization - Design

Test Case

X

«trace» «trace»

«trace» «trace»

Black-box test

White-box test

[The Unified Software Development Process. I. Jacobson, G. Booch and J. Rumbaugh. Addison-Wesley, 1999]

Dirigido por casos de usoUn caso de uso es una facilidad que el software debe proporcionar a sus usuarios. Los casos de uso reemplazan la antigua especificación funcional tradicional y constituyen la guía

fundamental establecida para las actividades a realizar durante todo el proceso de desarrollo incluyendo el diseño, la implementación y las pruebas del sistema.

Una de las características de RUP es estar dirigido por casos de uso, de manera que cualquier decisión de diseño o análisis, queda determinada por la necesidad de cumplir algún caso de uso. Además, los casos de pruebas de caja negra (aquellas que se dedican a observar si el comportamiento del sistema satisface los requisitos, sin conocer cómo está implementado) también se diseñan a partir de los casos de uso. Recordemos que los casos de uso, no sólo se describen mediante un diagrama, sino también mediante la secuencia de pasos que describen cómo llevar a cabo esa funcionalidad.


5






6


Centrado en la arquitecturaLa arquitectura involucra los elementos más significativos del sistema y está influenciada entre

otros por plataformas software, sistemas operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y requisitos no funcionales. Es como una radiografía del sistema que estamos desarrollando, lo suficientemente completa como para que todos los implicados en el desarrollo tengan una idea clara de qué es lo que están construyendo, pero lo suficientemente simple como para que si quitamos algo, ninguna parte importante del sistema quede sin especificar.

Se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de lo demás. Todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura, recibe este nombre porque lo forman cuatro vistas:

• la vista lógica, que es el modelo de objetos del diseño,

• la vista de realización, que describe la organización estática del software en su entorno de desarrollo.

• la vista de proceso, que captura los aspectos de sincronización y concurrencia del diseño,

• la vista de distribución, que describe la correspondencia del software sobre el hardware y refleja sus aspectos distribuidos,

A ellas se une la vista de casos de uso que es la que da cohesión a todas


Centrado en la arquitectura

Vista LógicaVista Lógica

Vista de ProcesosVista de Procesos

Vista de DistribuciónVista de

Distribución

Vista deRealizaciónVista de

RealizaciónVista de los Casos de Uso

Modelo 4 + 1 de la arquitectura


7


Vista Lógica

La vista lógica describe los aspectos estáticos y dinámicos de un sistema en términos de clases y objetos.

Se usan:• Objetos• Clases• Colaboraciones• Interacciones• Categorías (paquetes estereotipados)


Vista de Realización

Se preocupa de la organización de los componentes en el entorno de desarrollo

Muestra el reparto de clases en componentes y estos en subsistemas

Se usan:• Módulos• Subprogramas• Tareas• Subsistemas (paquetes estereotipados)


8


Vista de Procesos

Representa la descomposición en flujos de ejecución (threads), la sincronización entre flujos y la asignación de objetos y clases en dichos flujos.

Fiabilidad, rendimiento, etc.

Importante en entornos multitarea.

Se usan:• Tareas, threads, procesos.• Interacciones.


Vista de Distribución

Describe los diferentes recursos de hardware y la implementación del programa en dichos recursos

Se consideran:• Tiempos de respuesta y rendimiento• restricciones geográficas• potencia de cálculo distribuido• sobrecargas• tolerancia a fallos y a averías

Se usan:• nodos, módulos y programas principales


9


Vista de los Casos de Uso

Los casos de uso unifican las cuatro vistas precedentes

Se usan:• Actores,• Casos de uso• Clases• Colaboraciones


Centrado en la arquitectura

Arquitectura de un sistema es la organización o estructura de sus partes más relevantesUna arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedadesRUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo

Arquitectura

Inicio Elaboración Construcción Transición


10


Workflows (Disciplinas)Workflows Primarios

•Business Modeling (Modado del Negocio)

•Requirements (Requisitos)

•Analysis & Design (Análisis y Diseño)

•Implementation (Implementación)

•Test (Pruebas)

•Deployment (Despliegue)

Workflows de Apoyo•Environment (Entorno)

•Project Management (Gestión del Proyecto)

•Configuration & Change Management (Gestión de Configuración y Cambios)

Proceso iterativo e incremental


Requisitos

Diseño

Implementación

Prueba

Análisis

P re lim ina ryIte ra tion(s)

ite r.# 1

ite r.# 2

ite r.# n

ite r.#n+ 1

ite r.# n+2

ite r.# m

ite r.#m +1

Inicio Elaboration Construction Transition

FasesActividades

Una iteración en lafase de elaboración

Proceso Unificado de Desarrollo


11


WorkersAnalyst workers

– Business-Process Analyst– Business Designer– Business-Model Reviewer– Requirements Reviewer– System Analyst– Use-Case Specifier– User-Interface Designer

Developer workers– Architect– Architecture Reviewer– Capsule Designer– Code Reviewer– Database Designer– Design Reviewer– Designer– Implementer– Integrator

Testing professional workersTest DesignerTester

Manager workersChange Control ManagerConfiguration ManagerDeployment ManagerProcess EngineerProject ManagerProject Reviewer

Other workersAny WorkerCourse DeveloperGraphic ArtistStakeholderSystem AdministratorTechnical WriterTool Specialist



ArtefactosResultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividades

Un artefacto puede ser un documento, un modelo o un elemento de modelo

Conjuntos de Artefactos

Deployment Set

Project Management Set

Configuration & Change Management Set

Environment Set

Business Modeling Set

Requirements Set

Analysis & Design Set

Implementation Set

Test Set



12


RUP es un proceso aplicable a cualquier tipo de proyecto, tanto referido al tamaño del mismo como al dominio del problema. Ello hace que en su definición aparezcan una gran diversidad de actividades, roles y artefactos para dotarle de esa flexibilidad. Es por ello labor del gestor de proyecto, en colaboración con el resto del equipo, decidir cual es la personalización más adecuada del mismo.

Existe un conjunto de artefactos mínimo que han de desarrollarse a lo largo del proceso y que aparecen identificados en la figura.



Workers, Actividades, Artefactos

Ejemplo: System Analyst Worker



13




Proceso iterativo e incremental. ModelosBusiness Model

Analysis Model

Requirement Model

Design Model

Dep loym ent Mode lImpementation Model

Test Model

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

<<trace>>

Un modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Por ello, éste describe completamente aquellos aspectos del sistema que son relevantes a su propósito y con un apropiado nivel de detalle.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés

Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos.


14




Cada etapa itera sobre cinco flujos de trabajo:Requisitos

Averiguar lo que el sistema debe hacer.Análisis

Conseguir una compresión más precisa de los requisitos.Diseño

Compresión de requisitos no funcionales y adaptación de los requisitos funcionales para su implementación.

ImplementaciónImplementación de clases y pruebas de componentes individuales. Distribución del sistema asignándolo a nodos.

PruebaPlanificar, diseñar y realizar las pruebas de integración y de sistema.



15


Se definen cuatro etapas:Inicio

Se desarrolla una descripción del producto final y se presenta el análisis del negocio asociado al sistema a desarrollar

Elaboración Se especifican en detalle la mayoría de los casos de uso y se diseña la arquitectura.

ConstrucciónSe crea el producto. La base arquitectónica crece hasta convertirse en el producto final.

TransiciónBásicamente, agrupa actividades encaminadas a hacer llegar el producto al usuario: distribución, training, soporte, mantenimiento.




EnfoqueCascada

EnfoqueIterativo


16


Cada etapa incluye:

Planificación de la etapa

Realización de los flujos de trabajo fundamentales

Evaluación de la etapa



Establece la viabilidad

Delimitar el ámbito del sistema.

Esbozar una propuesta de arquitectura del sistema.

Identificar riesgos críticos.

Demostrar a usuarios o clientes que el sistema propuesto es capaz de solventar sus problemas, para lo cual puede ser útil construir un pequeño prototipo.

Inicio•Objetivos•Planificación•Actividades•Evaluación

ElaboraciónConstrucciónTransacción

Etapa de inicio


17




Etapa de inicio


Llevar a cabo los siguientes pasos:Reunir la información recogida antes de que el proyecto comenzase.Organizarla de forma que pueda ser utilizada.Reunir a un pequeño grupo de gente que sepa cómo utilizarla.Descubrir lo que falta, no en términos de las cuatro fases, sino en términos de los objetivos altamente limitados de la fase de inicio.



Planificación


18


Explorar fuentes de información previa.Software para venta en general.

Existen trabajos de responsables de marketing que permiten obtener información del nuevo sistema.

Software para otra área de la empresa.Un área encarga el sistema directamente pero no

parte de ningún estudio inicial.Se parte de un estudio global de tipo planificación

estratégica que aporta modelos del negocio.

Software para otra organización cliente.Podemos partir de un documento de petición inicial

detallado.



Fuentes de información


Ejecución de flujos de trabajo fundamentales.

Ajustar el proyecto al entorno de desarrollo.

Identificación de riesgos críticos.



Grandes tareas


19


Recopilar requisitosEnumerar los requisitos candidatosComprender el contexto del sistema. Representar los requisitos funcionales como casos de uso.

Encontrar actores y casos de usoDeterminar la prioridad de los casos

de uso.Detallar cada caso de usoConstruir un prototipo de la interfazEstructurar el modelo de casos de uso.

Recoger los requisitos no funcionales.



Ejecución de flujos de trabajo fundamentales


Analizar:

Refinar los requisitos y estructurarlos en un modelo de análisis.

Analizar la arquitectura candidata.

Definir un modelo de análisis que permita apreciar los recursos compartidos por varios casos de uso.

Analizar una clase y analizar un paquete.





20


Diseñar:

Esbozar el diseño de la arquitectura.Esbozar los modelos de diseño.Esbozar los modelos de despliegue.

Diseñar un caso de uso.

Diseñar una clase y un subsistema.





ImplementarEn algunos proyectos que se tiene poca experiencia en su desarrollo puede ser necesario la realización de un pequeño prototipo.En general no es necesario realizar este flujo.

ProbarNo se realiza ningún trabajo significativo de pruebas durante esta etapa.





21


El entorno de desarrollo consiste en:Un proceso de desarrollo.Las herramientas para llevarlo a cabo.

Herramientas para soportar los flujos de trabajo.

Herramientas para la administración y gestión de proyecto, gestión de configuraciones, etc.



Ajustar el proyecto al entorno de desarrollo


Riesgo: probabilidad de que un proyecto experimente sucesos no deseados y que ponen en peligro el éxito del mismo.

Crear una lista de riesgos.Breve descripción.Prioridad.Impacto: qué partes del proyecto se pueden ver

afectadas.Responsable de su eliminación o controlContingencia: qué hay que hacer si se produce el

riesgo.Si no se planifican los riesgos estos se suelen

presentar al finalizar el proyecto.Cuanto antes se detecten y se estudien los

efectos y las acciones de contingencia será mejor.



Identificación de riesgos críticos


22


Clasificación de riesgos críticos.Relacionados con tecnología utilizada.

Novedad de las tecnologías utilizadas.Utilización de entornos de desarrollo nuevos.

Relativos a la arquitectura.Selección de los casos de uso críticos para

definirla.Relativos a construir el sistema adecuado

Obtención de los requisitos correctos.Relativos a requisitos no funcionales

Seguridad de los datos.Rendimiento o tiempo de respuesta.Fiabilidad de los cálculos.Usabilidad.



Identificación de riesgos críticos


Evaluar la etapa finalizada.Ver si se han cumplido los objetivos y metas definidas al principio

Planificar y estimar costes de la siguiente etapa.

Presentar una estimación del coste y esfuerzo Detalle de la fase de elaboración.Aproximación de la totalidad del proyecto.

Realizar un primer análisis de coste/beneficio.

Planificar temporalmente la siguiente etapa.



Evaluación


23


Objetivo: elaborar una arquitectura estable para guiar el sistema a lo largo de su vida futura.

Se centra en la factibilidadSe centra en el estudio de la funcionalidad significativa desde el punto de vista arquitectónico.Identifica los riesgos significativos.Especifica los valores de los atributos de calidad, como: tiempo de respuesta, seguridad, fiabilidad, etc.Recopila los casos de uso para el 80% de los requisitos funcionales.Presenta una propuesta detallada del sistema a construir.

InicioElaboración

•Objetivos•Planificación•Actividades•Evaluación

ConstrucciónTransacción

Etapa de elaboración


InicioElaboración



Etapa de elaboración


24


Antes de empezar.Revisar la planificación realizada al final de la fase de inicio.Creación del equipo de trabajo.Establecer las metas a alcanzar tras la finalización de la etapa.

Extensión de requisitos.Definición de la línea base de la arquitectura.Mitigar riesgos significativos.Reevaluar el análisis de coste/beneficio realizado en la fase de inicio.

InicioElaboración



Planificación


Recopilar de requisitosEncontrar casos de uso y actores.Desarrollar prototipos de las interfaces de usuario. Determinar la prioridad de los casos de uso.Detallar cada caso de uso.Estructurar el modelo de casos de uso.

InicioElaboración



Actividades


25


AnalizarAnalizar la arquitectura candidata.

Analizar cada caso de uso, ver las clases y roles con que participa cada una.

Definir un modelo de análisis que permita apreciar los recursos compartidos por varios casos de uso.

Analizar una clase.

Analizar un paquete.

InicioElaboración



Actividades


DiseñarEsbozar el diseño de la arquitectura.

Identificar la arquitectura en capas.Identifica los subsistemas y sus interfacesIdentifica las clases de diseño significativas para la arquitectura.Si se trata de un sistema distribuido, identificar los nodos y las configuraciones de red.

Diseñar un caso de uso.

Diseñar una clase y un subsistema.

InicioElaboración



Actividades


26


ImplementarImplementación de la arquitectura.Implementación de las clases que forman parte de la arquitectura.Integrar el sistema desarrollado.

InicioElaboración



Actividades


ProbarPlanificar las pruebas.Diseñar las pruebas.Realizar pruebas de integración.Realizar pruebas del sistema.

InicioElaboración



Actividades


27


Evaluar la etapa finalizada.Ver si se han cumplido los objetivos y metas definidas al principio.

Planificar y estimar costes de la siguiente etapa.

Presentar una estimación del coste y esfuerzo del resto del proyecto o de cada uno de los subsistemas a construir

Revisar el análisis de coste/beneficio.

Planificar temporalmente la siguiente etapa.

InicioElaboración



Evaluación


Objetivo: Desarrollar el sistema de una forma rápida, económica y respetando los estándares de calidad.

Minimizar los costes de desarrollo, optimizando recursos y evitando rehacer y descartar trabajo.

Alcanzar los niveles de calidad rápidamente.

Alcanzar versiones útiles (alpha, beta, otras versiones de test) rápidamente.

InicioElaboraciónConstrucción

•Objetivos•Actividades•Evaluación

Transacción

Etapa de Construcción


28




Transacción

Gestión y control de recursos, optimización del proceso

Desarrollo completo de componentes y test contra los criterios de evaluación definidos.

Evaluación de las versiones del producto frente a los criterios de aceptación

Actividades


ProductosSistema integrado en su plataformaLos manuales de usuarioUna descripción de la versión actual

Evaluar la etapa finalizada.Estimar si el producto (beta), site, y usuarios se encuentran en disposición de ser operativos sin incurrir en riesgos. Evaluar si los recursos consumidos respecto a los estimados son aceptables o no.



Transacción

Evaluación


29


Objetivo: transferir el producto software objeto del proyecto a los usuarios.

Alcanzar los usuarios un nivel de autosuficiencia.

Alcanzar un acuerdo por parte de los stakeholders que se han conseguido los objetivos propuestos.

Hacer el producto final tan rápida, económica y prácticamente como sea posible

InicioElaboraciónConstrucciónTransacción


Etapa de Transacción


Ingeniería específica de distribución

Actividades de ajuste: errores, rendimiento y usabilidad

Evaluación del producto frente a los criterios de aceptación y los requisitos del sistema (visión)



Actividades


30


Evaluar la etapa finalizada.Estimar si el producto cumple con los requisitos, sino nueva iteración. Evaluar si los recursos consumidos respecto a los estimados son aceptables o no.



Evaluación

Conceptos PUDS

Documents

Transcript of Conceptos PUDS