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