PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

El PU se puede utilizar para cualquier tipo de sistemas de SW, áreas de aplicación, organizaciones,

niveles de aptitud y tamaño de proyecto, Utiliza UML como Lenguaje de Modelación y es:

-  Orientado a Objetos

-  Dirigido por Casos de Uso

-  Centrado en la Arquitectura

-  Iterativo e Incremental

Dirigido por Caso de Uso

Un Caso de Uso es un requisito funcional des sistema, una característica funcional que requiere

uno o más usuarios; y debe generar un resultado de valor para ese usuario.

El conjunto de todos los casos de uso y sus actores (usuarios) correspondientes se le llama Modelo

de Casos de Uso.

Los casos de uso guían:

-  El análisis: los analistas crean el modelo

del análisis en base a los casos de uso

-  El diseño: los diseñadores crean el modelo

del diseño en base a los casos de uso.

-  La implementación: se realiza la

implementación por casos de uso.

-  La revisión de estos tres puntos se realiza

en base a los casos de uso.

-  Las pruebas: se realizan en base al modelo

de casos de uso.

Centrado En la Arquitectura

• Los Casos de uso se desarrollan a la

vez que la arquitectura del sistema.

Guían la arquitectura del sistema y esta

influye en la selección de los casos de

uso.

• La Arquitectura se describe mediante

diferentes vistas del sistema en

construcción. Da Una idea de la forma

que tendrá el sistema completo.

Se consideran inicialmente los casos de uso más importantes y críticos, también el S.O., BD, código

reutilizable, red, etc. Conforme avanza el proyecto maduran, tanto la arquitectura como los casos

de uso.

Ciclo de Vida Iterativo e Incremental

•  Se divide el proyecto en pequeños miniproyectos, donde cada miniproyecto es una iteración

que resulta en un incremento.

•  Las iteraciones hacen referencia a pasos en el flujo de trabajo.

•  Los incrementos hacen referencia al crecimiento del producto.

•  Las iteraciones deben estar controladas; seleccionarse y ejecutarse de una forma planificada.

•  Los desarrolladores basan la selección de lo que se implementara en una iteración en dos

factores:

1. La iteración trata un grupo de casos de uso que juntos amplían la utilidad del producto

desarrollado hasta ahora.

2. La iteración trata los riesgos más importantes.

•Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo, tal como quedaron en

al final de la última iteración.

Fases y Flujo de Trabajo del PU

Modelado de Negocios

Requerimientos

Analisis y Diseño

Implementación Pruebas

Despliegue/Distribución

Gestión de Configuración

Gestión de proyecto

Entorno/medio ambiente

Inicio Elaboración Construcción Transición

Iteraciones

FLUJOS DE

TRABAJO

PRIMARIOS

FLUJOS DE

TRABAJO

DE APOYO

Fases del Proceso Unificado

1. Inicio: se desarrolla una descripción del producto final a partir de una buena idea; y se presenta el análisis

de negocio para el producto (viabilidad).

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

producto.

3. Construcción: se construye el sistema

4. Transición: prueba final, por parte de un grupo de usuarios, e implantación.

FASE DE INICIO

PROPÓSITO: Establecer una vista general de los objetivos del proyecto. Entender, lo suficiente, el

problema para determinar si el proyecto es viable y si se continua.

Esta fase debe ser muy breve, y normalmente solo tiene una iteración.

Tareas a realizar:

-  Desarrollar una descripción del producto final.

-  Presentar el Análisis del Negocio.

-  Identificación inicial de Riesgos.

-  Establecer las principales funciones del sistema, para los usuarios más importantes,

modelo de casos de uso y la arquitectura base.

-  Establecer un plan de proyecto, principalmente para la fase de Elaboración.

Artefactos tipicos de esta fase:

-  Visión y Análisis del Negocio.

-  Modelado de Casos de Uso.

-  Especificaciones complementarias: describe otros requerimientos.

-  Glosario

-  Lista de Riesgos y Plan de gestión de riesgos

- Prototipos: prueba de conceptos, opcional.

-  Plan de iteración: que se hará en cada una de las iteraciones de la fase de elaboración

-  Plan de Fase: estimación gruesa de la duración y esfuerzo requeridos para la fase de

elaboración.

-  Plan de desarrollo: propuesta o selección de herramientas de desarrollo, actividades de

formación y recursos adicionales.

-  Marco de Desarrollo: descripción de los pasos del PU y artefactos considerados, más

adecuados para este proyecto; es la adaptación del PU al proyecto.

Visión y Análisis del Negocio:

-  Es un documento donde se describe la totalidad del sistema de manera general pero

suficiente para servir como contrato formal o informal entre el cliente y el desarrollador.

-  Muestra los problemas y objetivos a más alto nivel que los Casos de Uso, enfatiza la

globalidad.

Características del Análisis de Negocio

•  contiene una descripción del problema concisa, precisa y entendible por todos los

involucrados.

•  Muestra objetivos funcionales y no funcionales considerados importantes, que pueden

corresponder a varios casos de uso.

•  Se expresa como características del sistema, sentencias concisas, de alto nivel, que

resumen las funciones y restricciones del sistema.

•  Usa no más de 2 niveles descriptivos; no puede tener un nivel de detalle excesivo.

-  El documento no debe repetir los Casos de Uso, sino resumirlos en un documento único, con

énfasis en el panorama global por contraposición a la visión más detallada de los casos de uso.

Objetivos Claves del Análisis del Negocio

•  Delimitar el ámbito/alcance del sistema.

•  Describir o esbozar una propuesta de la arquitectura del sistema (arquitectura candidata)

•  Identificar riesgos críticos, en el desarrollo, y minimizarlos.

•  Demostrar, a usuarios o clientes potenciales, que el sistema es capaz de solventar sus

problemas o mejorar sus objetivos de negocios, con la construcción de un prototipo.

DEFINICION DE REQUISITOS

En la fase de Inicio los analistas identifican la mayoría de los casos de uso para delimitar el sistema

y el alcance del proyecto, y describe los más importantes. Aprox. 10 %

En la fase de Elaboración se identifican un 80%.

El otro 10% es tanto en la fase de Construcción como en la de Transición

Pasos para la definición de requisitos.

1.  Modelo del Negocio.

2.  Enumerar los requisitos candidatos.

3.  Comprender el contexto del sistema

4.  Capturar los requisitos funcionales.

5.  Capturar los requisitos no funcionales.

Lista de características o requisitos candidatos

Nombre Descripción Edo Costo Prioridad Nivel Riesgo

Edo: Propuesto, Aprobado, Incluido, Validado

Prioridad: Crítico, Importante, Secundario

Captura de Requisitos como Casos de Uso

Artefactos fundamentales que se utilizan:

-  Modelo de Casos de Uso (Es un modelo del sistema que contiene actores, casos de uso y

sus relaciones.)

-  Actores

-  Casos de Uso

-  Descripción de la Arquitectura

-  Glosario

-  Prototipo de interfaz con el usuario

Modelo del Negocio

Modelo de objetos del negocio.

Modelo interno a un negocio, Describe como un caso de uso del negocio es realizado por

parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y

unidades de trabajo.

-  Entidad del negocio es algo que los trabajadores toman, inspeccionan, manipulan,

producen o utilizan en un caso de uso del negocio.

-  Unidad de trabajo es un conjunto de entidades que conforman un todo reconocible para

un usuario final

Primero: confeccionar un modelo de casos de uso del negocio.

-  Identificar los actores del negocio.

-  Identificar los casos de uso del negocio que utilicen los actores del negocio.

Segundo: desarrollar un modelo de objetos del negocio compuesto por:

-  Trabajadores

-  Entidades del negocio

-  Unidades de trabajo

ANALISIS

Objetivo: Analizar los requisitos que se describieron en la captura de requisitos, refinándolos y

estructurándolos en un modelo de objetos que sirva como primer impresión del modelo de

diseño.

-  Conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que

nos ayude a estructurar el sistema entero.

Producto resultante: Modelo de Análisis.

- Se utiliza este modelo para definir con precisión los casos de uso, y como ayuda para guiarnos en

el establecimiento de la arquitectura candidata.

Arquitecto -> Análisis de la Arquitectura

Ing. de casos de Uso -> Analizar un caso de uso

Ing. de Componentes -> Analizar una clase | Analizar un Paquete

Análisis de la Arquitectura

Propósito: Esbozar el modelo del Análisis y la Arquitectura mediante la identificación de:

-  Paquetes del análisis.

-  Clases del análisis evidentes.

-  Requisitos especiales comunes.

Paquetes:

-  Permiten organizar el Modelo del Análisis en piezas manejables.

-  Dentro de un Paquete puede haber casos de uso, clases y otros paquetes.

Identificación de Paquetes

-  Pueden identificarse como una forma de dividir el trabajo del análisis.

-  Una identificación se hace, basándose en los requisitos funcionales y en el dominio del problema

- Formas adecuadas de asignar casos de uso a paquetes:

•  Los casos de uso requeridos para dar soporte a un determinado proceso de negocio.

•  Los casos de uso requeridos para dar soporte a un determinado actor.

•  Los casos de uso relacionados entre si, relaciones de extensión e include.

Características de los Paquetes:

-  Deben ser cohesivos, sus contenidos deberían estar fuertemente relacionados.

-  Deben ser débilmente acoplados, las dependencias entre ellos se deben minimizar.

Administración de aspectos comunes entre paquetes del análisis:

-  Al encontrar aspectos comunes entre los paquetes identificados; clase o casos de uso. Se coloca

el elemento común, clase o caso de uso, en un paquete para el solo; y los otros paquetes se hacen

dependientes de este paquete mas general.

Dependencia entre paquetes:

-  Es cuando sus contenidos están relacionados.

-  La dirección de la dependencia debe ser la misma que la de la relación.

-  Lo ideal es que no exista dependencia entre paquetes.

-  Si esta existe debe se lo mas débil que se pueda.

Identificación de clases de entidad obvias:

Clases de Entidad:

•  Son clases que modelan información que posee una vida larga y que a

menudo es persistente. Modelan la información y el comportamiento

asociado a algún fenómeno o concepto; persona, objeto o suceso del mundo

real.

•  Generalmente se derivan de las entidades del negocio. Muestran una

estructura de datos lógicos y contribuyen a comprender de que información

depende el sistema.

Propuesta de las clases de entidad más importantes, basada en las entidades del negocio. Se

definen los atributos de cada clase de entidad identificada.

Entidades del Negocio Clases de entidad

Libro Libro

Atributos: ISBN, Titulo, Autores, Editorial, Edición

Pedido Pedido

Atributos: Número, fecha, cliente, detalle.

Identificación de Requisitos Especiales comunes:

-  Son requisitos que aparecen durante el análisis y que se anotan para ser tratados en las

actividades de diseño e implementación. A veces se encuentran en las realizaciones de casos de

uso y las clases del análisis.

-  Ejemplo: Limitaciones y restricciones sobre:

•  Persistencia

•  Distribución y Concurrencia

•  Características de seguridad.

•  Tolerancia a fallos.

•  Gestión de transacciones.

Análisis de un Caso de Uso

Se analiza un caso de uso para:

-  Identificar las clases del análisis cuyos objetos son necesarios para llevar a cabo el flujo de

sucesos de casos de uso.

-  Distribuir el comportamiento de casos de uso entre los objetos del análisis, que interactúan.

Utiliza como entrada:

-  Modelo de Casos de Uso.

-  Modelo del Negocio.

-  Requisitos Adicionales.

-  Descripción de la Arquitectura.

Producto resultante:

-  Clases del Análisis.

-  Realiz ación de Casos de Uso-Análisis.

Identificación de Clases del Análisis

Se identifican las clases para la realización del caso de uso. Se identifican 3 tipos de clases:

•  Control. •  Entidad. •  Interfaz.

-  Se esbozan sus nombres, atributos y relaciones.

Clases de Interfaz: Solo tienen atributos

Se utilizan para modelar la interacción entre el sistema y sus actores.

-  Esta interacción a menudo implica recibir y enviar información; y

peticiones de y hacia los usuarios y sistemas externos.

-  Modelan las partes del sistema que dependen de los actores, por lo cual

clarifican y reúnen los requisitos en los límites del sistema.

Representan abstracciones de:

•  Ventanas •  Formularios •  Paneles •  Interfaces de comunicación •  Censores y terminales

- Solo debe describir lo que se obtiene con la interacción, información y peticiones que

intercambian el actor y el sistema.

-  Cada clase de interfaz debe estar relacionada con un actor y viceversa

Clases de Control: Solo tiene operaciones, sin atributos

Representan coordinación, secuencia, transacciones y control de objetos.

-  Con frecuencia se usan para encapsular el control de un caso de uso. Para

representar

derivaciones y cálculos complejos, como la lógica del negocio, que no

pueden asociarse a ninguna información concreta almacenada por el

sistema.

Modelan los aspectos dinámicos del sistema, ya que manejan y coordinan las acciones y flujos de

control principales, y delegan el trabajo principal a otros objetos (interfaz y entidad).

Normas para identificar Clases del Análisis:

-  Identificar clases de entidad:

•  Estudiar a detalle la descripción del caso de uso para determinar que información se

utiliza y manipula en la realización del casos de uso; aquello de lo que se quiere guardar

información.

•  Considerar las clases de entidad obvias.

•  Ser consiente de la información que es mejor capturar como atributo y la que es

preferible asociar a clases de interfaz o de control

-  Identificar Clases de Interfaz:

•  Identificar una clase por cada actor humano, esta representa la ventana principal de IU

con la cual interactúa el actor.

•  Identificar una clase primitiva para cada clase de entidad definida, esta representa

objetos lógicos con los cuales interactúa el usuario en el caso de uso.

•  Identificar una clase central por cada actor que sea sistema externo, esta será la interfaz

de comunicación.

-  Identificar Clases de Control:

•  Identificar una clase responsable del control y coordinación de la realización del caso de

uso, y refinarla de acuerdo los requisitos del casos de uso.

Descripción de Interacciones entre Objetos del Análisis:

-  Una vez determinadas las clases para la realización del caso de uso, se describe como

interactúan sus correspondientes objetos, esto mediante un diagrama de Colaboración

que contiene las instancias de actores, los objetos y sus enlaces.

Un diagrama de Colaboración se crea comenzando por el principio del flujo del caso de uso y

continuando el flujo paso a paso, decidiendo que interacciones de objetos y de actores son

necesarias para realizarlo.

NOTA:

- Un caso de uso se invoca mediante un mensaje proveniente de un actor sobre un objeto

de interfaz.

-  Cada clase identificada debe tener al menos un objeto que participe en un diagrama de

colaboración.

-  El mensaje debe reflejar el propósito del objeto invocante en la interacción con el objeto

invocado

- Los mensajes no se asocian a operaciones

-  Los enlaces en el diagrama deben ser instancias de asociaciones entre clases.

-  El diagrama de colaboración deberá tratar todas las realizaciones del casos de uso que se

está tratando.

Análisis de una Clase

Objetivos:

-  Identificar y Mantener las Responsabilidades de la clase del análisis.

-  Identificar y mantener los Atributos y Relaciones de las clases del análisis

Elementos de Entrada:

-  Realizaciones de los casos de uso-análisis

-  Clases del análisis (esbozo)

Se obtiene:

-  Clases del análisis (terminadas)

Identificar Responsabilidades

-  Identificar todos los roles que cumple, la clase, en las diferentes realizaciones de casos

de uso donde participa.

-  Esto se logra estudiando los diagramas de clases y de colaboración.

Identificar Atributos:

-  Atributo: Especifica una propiedad de la clase y generalmente es necesario para las

responsabilidades de la clase.

-  Se deben identificar los atributos tanto de las clases de Entidad, como de las de Interfaz

y Control.

Considerar:

1)  Darles nombres representativos.

2)  Reutilizar tipos ya existentes.

3)  Una instancia de un atributo no puede compartirse por varios objetos del análisis; si

esto es necesario, definir una clase solo para ese atributo.

4) Si una clase se hace demasiado difícil de entender por culpa de los atributos, algunos de

estos podrían separarse en clases independientes.

5)  Los atributos de las clases de entidad suelen ser muy evidentes. Revisar las entidades

del negocio.

6)  Los atributos de las clases de interfaz de humanos, suelen representar elementos de

información manipulados por actores.

7) Los atributos de las clases de interfaz de Sistemas externos, suelen representar

propiedades de una interfaz de comunicación.

8)  Los atributos de las clases de control son poco frecuentes, debido a su corto tiempo de

vida; sin embargo pueden tener atributos que representes valores acumulados o

calculados durante la realización del caso de uso.

Identificar Asociaciones y Agregaciones

-  Se deben modelar las relaciones que deben existir como respuesta a las demandas de las

diferentes realizaciones de casos de uso. Aquí solo se consideran las clases de entidad.

Definir:

-  La multiplicidad de las asociaciones

-  Los nombres de los roles

-  Auto asociaciones

-  Asociaciones n-arias

Las agregaciones se deberán usar cuando los objetos representen:

-  Conceptos que se contienen físicamente uno al otro

como un auto que contiene al conductor y a los

pasajeros.

-  Conceptos que están compuestos uno de otro, como un

auto que consta de un motor, ruedas, accesorios, etc.

-  Conceptos que forman una colección conceptual de

objetos, como una familia que consta de un padre, una

madre e hijos.

Identificar Generalizaciones

Las relaciones de generalización se utilizan para extraer

comportamiento común y compartido entre varias clases del

análisis.

•  Se debe mantener en un nivel alto y conceptual.

•  Su objetivo es hacer el modelo del análisis mas fácil

de entender.

Analizar un Paquete

Objetivo:

Garantizar que los paquetes, del análisis, son tan independientes entre si como sea

posible.

Garantizar que realice algunas clases del dominio o casos de uso.

Describir las dependencias entre paquetes, de forma que pueda estimarse el efecto de los

cambios futuros.

Se incluyen las clases identificadas

Normas Generales:

-  Definir y mantener las dependencias del paquete con otros paquetes, cuyas clases estén

asociadas con el.

-  Asegurarse que el paquete contiene las clases correctas.

-  Hacer cohesivo el paquete, incluyendo solo objetos relacionados funcionalmente.

-  Limitar la dependencia con otros paquetes, considerar reubicar clases que generan demasiadas

dependencias.

FASE DE ELABORACIÓN

Establece un plan para el proyecto y una arquitectura correcta.

- Especificar los Casos de uso mas críticos

- Diseñar la arquitectura(Mediante vistas de todos los modelos del sistema de SW )

- Vista arquitectónica del modelo de casos de uso, de análisis y diseño

Al final de esta fase será posible planificar las actividades y estimar los recursos para terminar el

proyecto.

Administración del Proyecto:

Monitoreo y control: Juntas para ver informes, avances y revisar el estado actual contra lo

planeado. Informes. Revisiones.

Modelado de Negocios:

Se debe construir casi el 100% del modelo de negocios.

Haber identificado los trabajadores y entidades del negocio. Tener casi en su totalidad los

diagramas de objetos del negocio.

Definición de Requisitos :

Identificar al menos el 80% de los casos de uso

Describir del 40 al 80% de los casos de uso

Estar actualizando el estatus de la lista de características

Análisis y Diseño:

Analizar del 20 al 40% de los casos de uso

Definición de la Arquitectura

Análisis arquitectónico (paquetes)

Análisis de Clases

Crecimiento del Diseño

Diseño de la Arquitectura (subsistemas)

Diseño de casos de uso, menos del 10% de casos de uso

Diseño de clases

Diseño de base de datos

Diseño de interfaces de usuario

Revisión de Arquitectura y Diseño

*ANALISIS DE UNA CLASE