IS4 11 12 TEMA VI ProcesoUnificado

Tema 6 Proceso Unificado
Ingeniera del Software I feliu.trias@urjc.es
ndice
Introduccin El proceso unificado
Principios bsicos Las 4 p
Estructura del proceso unificado Flujos de trabajo principales Fases del desarrollo Otros aspectos
Iteracin genrica Planificacin y evaluacin

Ingeniera del Software de Gestin www.kybele.es
Introduccin

Realidad actual: sistemas ms complejos y ms grandes Objetivo:

Desarrollo ms rpido menor tiempo de salida al mercado Software de calidad Mejor adaptacin del software a las necesidades del cliente
Solucin: un proceso de desarrollo que integre todas las facetas de un desarrollo software

D una gua para ordenar las actividades del equipo Dirija las tareas individuales y del equipo Especifique los productos (artefactos) que hay que desarrollar Ofrezca criterios para monitorizar y medir los productos y actividades
www.kybele.es
Ingeniera del Software de Gestin
ndice



El Proceso Unificado
Unificacin de tres metodologas de desarrollo basadas en el paradigma orientado a objetos

OOSE (Object-Oriented Software Engineering)
Ivar Jacobson
Booch
Grady Booch
OMT (Object Modeling Technique)
James Rumbaugh
www.kybele.es
Unified Process (1999) vs. Rational Unified Process (2003)

UP: define el proceso y un marco extensible para el desarrollo de
software RUP (propietario: IBM / Rational):

6 disciplinas de ingeniera (flujos de trabajo) principales Elementos principales: roles (quin), productos (qu se debe obtener), tareas (qu se debe hacer).
www.kybele.es
Es un proceso de desarrollo software

Def.: conjunto de actividades para transformar los requisitos de usuario en un sistema
software Entre modelo de proceso y metodologa. Especifica que las herramientas son necesarias para apoyar el desarrollo del producto. No indica cules utilizar.

Basado en componentes (cdigo reutilizable) Principios:

Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental Usa UML (Unified Modeling Language) como notacin para los modelos del proceso de desarrollo Otros: enfocado a riesgos, impulsa la calidad, es configurable, etc.
Las 4 P del proceso unificado:

Proyecto Proceso Producto Personas
www.kybele.es
Principios del Proceso Unificado

Dirigido por casos de uso
Ideas:
Cualquier interaccin del sistema con el usuario es un
caso de uso Actor: alguien o algo
Def.: caso de uso

Es una funcin del sistema que da al usuario un
resultado til Captura los requisitos funcionales
Qu debe hacer el sistema para cada actor?

Modelo de casos de uso
www.kybele.es

Dirigido por casos de uso
Conducen el proceso de desarrollo:

Los desarrolladores crean modelos de anlisis, modelos
de diseo e implementacin a partir de los casos de uso Los encargados de pruebas aseguran que los componentes implementan los casos de uso
Los casos de uso se especifican, se disean y sirven de base para construir los casos de prueba
Se desarrollan junto a la arquitectura del sistema
Ambos evolucionan en paralelo
www.kybele.es

Centrado en la Arquitectura
Def.: D. Garlan and D. Perry (guest editorial to the IEEE Transactions on Software Engineering, April 1995):
Software architecture is "the structure of the components of a program/system,
their interrelationships, and principles and guidelines governing their design and evolution over time Es una vista del diseo completo que hace visibles las caractersticas principales Ms definiciones: http://www.bredemeyer.com/definiti.htm
Influencias:
Plataforma, aspectos legales, componentes reusables disponibles...
El proceso ayuda a centrarse en los objetivos correctos: legibilidad, adaptabilidad, reutilizacin. Relacin entre casos de uso y arquitectura
Casos de uso Funcionalidad del sistema Arquitectura Forma
www.kybele.es

Centrado en la Arquitectura
Tareas relacionadas:
Para la definicin de la arquitectura se debe poseer
una comprensin general de los C.U. tener en cuenta otros aspectos como la plataforma.
Trabajar con un conjunto seleccionado de casos de
uso que representan las tareas clave del sistema.

Caso de uso subsistemas, clases y componentes
Evolucin a lo largo del proceso de desarrollo
concepto de vista arquitectnica
www.kybele.es

Iterativo e incremental
Divisin del proyecto en miniproyectos. Cada miniproyecto es una iteracin (conjunto de pasos).
Una iteracin produce un incremento. Cdigo ejecutable Cada iteracin se centra en disminuir algn riesgo y concluye con un hito bien definido
Todas las iteraciones estn planificadas y controladas (gestin de riesgos) Factores para la seleccin en una iteracin:
La iteracin trata un grupo de casos de uso que extienden la funcionalidad La iteracin trata los riesgos ms importantes
Elementos contemplados en cada iteracin:

Casos de uso relevantes Existe una arquitectura que sirve de gua. Se implementa utilizando componentes (cdigo reutilizable). Elementos contemplados en cada iteracin:
Cuando una iteracin no cumple sus objetivos, los desarrolladores deben revisar sus decisiones tomadas.
www.kybele.es

Beneficios de una iteracin controlada y planificada:

Reduce el coste del riesgo a los costes de un solo incremento. Reduce el riesgo de no sacar al mercado el producto en el
calendario previsto (mediante la identificacin de riesgos en fases tempranas del desarrollo). Se obtienen resultados a corto plazo. El cliente/usuario puede aadir nuevos requisitos en cualquier momento.
www.kybele.es

Desarrollo iterativo distribuido en grupos de trabajo:

Tiempo
Anlisis
Diseo e Implantacin
Prueba
Generalizacin
Grupo n
Anlisis
Diseo e Implantacin
Prueba
Generalizacin
Grupo 2
Anlisis Diseo e Implantacin Prueba Generalizacin
T Grupo 1 Tiempo
www.kybele.es

Ciclo de vida del software:

El paso a travs de las 4 fases principales constituye un ciclo de desarrollo
produce una generacin del software

Al final de cada ciclo obtenemos una versin nueva del sistema Entregas: cdigo fuente, ejecutables, manuales y documentos Hitos por fases (milestones)
Entrega
Ciclos
...
Fases Iteraciones
Concepcin
Iter. 1 Iter. 2
Elaboracin
Construccin
Transicin
...
...
...
...
...
...
Iter. n
www.kybele.es

Otras caractersticas
Soporta las tcnicas orientadas a objetos:

Los modelos definidos como artefactos del proceso son orientados a objetos Los modelos se basan en la definicin de clases, objetos y las relaciones entre
ellos Se utiliza UML como notacin comn
Enfocado a riesgos:
La gestin del riesgo est incluida en el proceso Los riesgos se identifican y se acometen al principio del proceso de desarrollo
(a tiempo)
Impulsa un control de la calidad:

La evaluacin de la calidad est contenida en el proceso (trazabilidad) Implica a todos los participantes mediante medidas y criterios objetivos No se trata como algo a posteriori o una actividad separada
Es un proceso configurable:
Puede adaptarse a proyectos de diferente envergadura (medianos-grandes) Se adapta a las necesidades de desarrollo de la organizacin
www.kybele.es

Las 4 P
Proyecto:
Elemento organizativo a travs del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versin de un producto
Proceso:
Un proceso de ingeniera de software es una definicin del conjunto de
actividades necesarias para transformar los requisitos de usuario en un producto Un proceso es una plantilla para crear proyectos
Producto:
Artefactos que se crean durante la vida del proyecto, como los modelos, cdigo
fuente, ejecutables, y documentacin El resultado de llevar a cabo un proceso software dentro de un proyecto concreto
Personas:
Los principales autores de un proyecto de software son los arquitectos,
desarrolladores, ingenieros de prueba y el personal de gestin que les da soporte, adems de los usuarios, clientes, y otros interesados La gente trabaja ms eficazmente en grupos pequeos. Trabajador = puesto de trabajo al que se le asigna una persona.
www.kybele.es

Proyecto
Iteraciones en cuatro fases Informacin sobre el sistema propuesto Plan de proyecto
Planificar
Informacin del dominio
Plan de iteracin
Experiencia pasada
www.kybele.es

Proceso
FASES
Workflow
Requisitos Anlisis
Planificacin Anl. Riesgos Preparacin
Elaboracin
Construccin Verificacin
Transicin
Iteracin en Fase de Elaboracin
Diseo
Implementacin
Prueba
Iteracin(es) Inicial(es) Iter. #1 Iter. #2 Iter. #3 Iter. #4 Iter. #5 Iter. #6 Iter. #7
(Adaptado de Jacobson, 1999)


Producto
Consta de un cuerpo de cdigo fuente incluido en componentes que puede compilarse y ejecutarse, adems de manuales y otros productos asociados. Adems, forman parte del producto todos aquellos artefactos que se han ido generando durante el desarrollo de la aplicacin.
www.kybele.es

Producto (Artefactos)
Especificado por Soportado por
Modelo de anlisis
Modelo de diseo
Distribuido por Modelo de despliegue Implementado por Modelo de implementacin
Verificado por
Modelo de pruebas
www.kybele.es

Trabajadores
Analista de Sistemas
Descubre Actores y Casos de Uso
Estructura Modelo de Casos de Uso
Planifica Test
Disea Test
Evalua Test
Ingeniero de pruebas
Especifica Casos de Uso
Detalla un Caso de Uso
Integra Sistema
Integrador de Sistemas
Diseador de Interface de Usuario
Prototipo del Interfaz de Usuario
Ejecuta Test de Integracin
Ingeniero de pruebas de integracin
Anlisis de Arquitecto Prioriza Casos de Uso Arquitectura
Diseo de Arquitectura
Implementacin de Arquitectura
Ingeniero de Ejecuta test pruebas de del sistema sistema
Ingeniero de Casos de Uso
Analiza un Caso de Uso
Disea un Caso de Uso
Analiza una Clase

Ingeniero de Componentes
Analiza un Paquete
Disea una clase
Disea un Subsistema Implementa Subsistema
Implementa una clase
Implementa Ejecuta Test Test Unitario
www.kybele.es
ndice

Estructura del Proceso Unificado

Fases e iteraciones
Fase: intervalo de tiempo entre dos hitos importantes del proceso durante el cual se cumple un conjunto bien definido de objetivos, se completan artefactos y se toman decisiones sobre si pasar a la siguiente fase 4 fases:
Iniciacin (inception): Establecer la visin, el alcance y el plan
inicial del proyecto Elaboracin (elaboration): Disear y probar una arquitectura correcta, y completar el plan del proyecto Construccin (construction): Desarrollar el sistema (construir la primera versin operativa) Transicin (transition): Proporcionar el sistema a sus usuarios finales
www.kybele.es

Fases e iteraciones
Iteracin: representa un ciclo de desarrollo completo, desde la captura de requisitos en el anlisis hasta la implementacin y pruebas, que produce una versin (interna o externa) de un producto ejecutable, que constituye un subconjunto del producto final en desarrollo Iteracin genrica (similar al modelo en cascada):
Planificacin Flujos de trabajo fundamentales: requisitos, anlisis, diseo,
implementacin y pruebas Evaluacin
Dependiendo de la iteracin y de la fase en la que se encuentre el proyecto, el nfasis se pone ms en unos u otros flujos de trabajo El contenido vara para adaptarse al objetivo de cada fase
www.kybele.es

Fases e iteraciones
FASES
Workflow
Requisitos Anlisis
Elaboracin
Transicin
Diseo
Implementacin
Prueba


Flujos de trabajo
Flujos de trabajo fundamentales: Requisitos: extrae los requisitos del sistema a desarrollar utilizando diferentes mtodos Anlisis y diseo: describe las diferentes vistas arquitectnicas del sistema Implementacin: tiene en cuenta el desarrollo del software, las pruebas unitarias y la integracin Pruebas: describe los casos de pruebas, los procedimientos y las mtricas para la evaluacin y rastreo de defectos
www.kybele.es

Flujos de trabajo
Flujos de trabajo auxiliares: Gestin de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto y de las actividades de gestin Gestin del proyecto: describe varias estrategias de trabajo en un proceso iterativo Entorno: cubre la infraestructura necesaria para desarrollar un sistema
www.kybele.es
Elementos del Proceso Unificado

Modelo y artefacto
Las actividades del proceso unificado se destacan en la creacin y mantenimiento de modelos. Modelo (una perspectiva del sistema):
El modelo es una abstraccin del sistema, especificando el sistema modelado
desde un cierto punto de vista y en un determinado nivel de abstraccin. Representacin abstracta y simplificada de la realidad, creada para comprender mejor el sistema que se est desarrollando. Se puede ver como un contenedor de elementos como clases, casos de uso, actores, subsistemas, colaboraciones que se encuentran representados en diferentes diagramas, bocetos, prototipos
Artefacto: Resultado 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, los diagramas UML y su texto asociado,
bocetos de la interfaz de usuario, prototipos A su vez, un modelo es considerado un artefacto
www.kybele.es

Artefactos
Modelos
De casos de uso De anlisis De diseo De implementacin De pruebas
Otros artefactos
Conjunto de requisitos: qu debe hacer el sistema Conjunto de diseo: cmo se va a construir el sistema Conjunto de implementacin: ensamblado de los
componentes software Conjunto de despliegue: datos para la configuracin del entregable


Artefactos
Artefactos en PU:
Fase de Inicio: Planificacin proyecto. Especificacin de Requerimientos Fase de Elaboracin: Diagramas de caso de uso Diagramas de clase. Diagramas de colaboracin Fase de Construccin: Diagrama de clases Modelo E-R (si el sistema as lo requiere) Diagrama de Secuencia Diagrama de estados Diagrama de Colaboracin Modelo de dominio Mapa de comportamiento a nivel de hardware.
www.kybele.es
ndice

Flujos de trabajo principales

(Workflows)
FASES
Workflow
Requisitos
Anlisis
Elaboracin
Transicin
Diseo Implementacin Pruebas

www.kybele.es
Flujos de Trabajo Principales

Requisitos
Captura de los requisitos del sistema Difcil:

Los requisitos cambian Comprensin: lenguaje utilizado cliente El cliente debe ser capaz de leer y comprender el resultado de la captura
Objetivo: guiar el desarrollo hacia el sistema correcto El resultado ayuda al jefe de proyecto a planificar las iteraciones y a la asignacin de recursos Pasos a seguir:

Enumerar los requisitos candidatos Comprender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales
lista de caractersticas modelo de negocio/dominio modelo de casos de uso requisitos suplementarios o

casos individuales
www.kybele.es
Artefactos:

Requisitos
Modelo de dominio: captura los tipos ms importantes de objetos en el contexto donde trabaja el sistema.
Representado mediante un diagrama de clases. Las clases
del dominio se utilizan en el desarrollo de los modelos de casos de uso y de anlisis.
www.kybele.es

Requisitos
Artefactos de requisitos
Diagramas de casos de uso:
Flujos de eventos principales Caminos alternativos
Descripciones textuales de los casos de uso Diagramas de actividad Descripcin de la arquitectura Glosario Prototipo de la interfaz de usuario Actividades Encontrar actores y casos de uso Analista de sistemas Priorizar los casos de uso Arquitecto Detallar un caso de uso Especificador de C.U. Prototipar la interfaz de usuario Diseador de la interfaz Estructurar el modelo de casos de uso Arquitecto
www.kybele.es

Anlisis
Se trabaja con conceptos
Especificacin ms precisa de los requisitos

Se utiliza el lenguaje de desarrolladores Facilita comprensin, preparacin, modificacin y mantenimiento de requisitos Primera aproximacin al modelo de diseo
www.kybele.es

Anlisis
Modelo de Casos de Uso Lenguaje del cliente Vista externa del sistema Estructurado por casos de uso Contrato entre cliente-desarrolladores Redundancias, inconsistencias, etc. entre requisitos Captura la funcionalidad del sistema Define casos de uso
Modelo de Anlisis Lenguaje del desarrollador Vista interna del sistema Estructurado por clases y paquetes Usado por desarrolladores para entender el sistema No debera contener redundancias ni inconsistencias de requisitos Captura de cmo realizar la funcionalidad del sistema Define realizaciones de casos de uso
www.kybele.es

Anlisis
Una clase de anlisis representa una abstraccin de una o mas clases del diseo del sistema Se centra en el tratamiento de los requisitos funcionales Son evidentes en el dominio del problema Los atributos, operaciones y relaciones de las clases de anlisis estn a un nivel mayor de abstraccin. Pueden clasificarse fcilmente en clases de entidad, interfaz y de control.
www.kybele.es

Anlisis
Artefactos de anlisis
Modelo de anlisis Diagramas de colaboracin: Es un diagrama de interaccin que define cmo se lleva a cabo y se ejecuta un caso de uso en trminos de objetos de anlisis Tanto para el camino principal como para los caminos alternativos Diagramas de clases del anlisis Descripciones textuales de las clases Descripcin de la arquitectura Vista de la arquitectura del modelo de anlisis Descomposicin del modelo en paquetes Paquetes de anlisis Proporcionan un medio para organizar los artefactos del modelo de anlisis en piezas manejables. Son cohesivos y dbilmente acoplados Basados en los requisitos funcionales y en el dominio del problema Generan subsistemas del diseo
www.kybele.es

Anlisis
Actividades
Anlisis de la arquitectura
Identificar paquetes de anlisis Identificar clases de entidad Requisitos comunes
Arquitecto
Analizar (refinar) un caso de uso
Ingeniero de CU
Identificar clases de anlisis Describir interacciones entre los objetos del anlisis Capturar requisitos especiales sobre la realizacin del CU
Analizar una clase
Identificar responsabilidades y atributos Identificar relaciones: asociacin, agregacin y generalizacin Capturar requisitos especiales sobre la realizacin del CU
Analizar un paquete
www.kybele.es

Diseo
Se modela el sistema para que d soporte a los requisitos funcionales y no funcionales Su entrada esencial es el modelo de anlisis (una comprensin detallada de los requisitos) Objetivos:
Profundizar en los requisitos no funcionales y restricciones dependientes
de la plataforma. Crear una entrada apropiada para la implementacin Descomponer los trabajos de implementacin en partes mas manejables y que permitan concurrencia. Utilizacin de subsistemas Capturar las interfaces entre los subsistemas.
Es el centro de atencin final de la fase de elaboracin e iteraciones iniciales de la fase de construccin

www.kybele.es

Diseo
Modelo de Anlisis Modelo de Diseo
Abstraccin del sistema

Genrico respecto al diseo (aplicable a varios diseos) 3 estereotipos conceptuales sobre las clases: interfaz, control y entidad.
Modelo fsico. Plano de implementacin

No genrico. Especfico para una implementacin Cualquier nmero de estereotipos fsicos sobre las clases de diseo (depende del lenguaje de programacin)
Menos formal y menos caro de desarrollar Ms formal y ms caro de desarrollar Bosquejo del diseo del sistema Manifiesto del diseo del sistema
No necesariamente tiene que estar mantenido durante todo el ciclo de vida del software
Entrada esencial para modelar el sistema
Debe ser mantenido durante todo el ciclo de vida del software

Da forma al sistema mientras intenta preservar la estructura heredada del modelo de anlisis
www.kybele.es

Diseo
Artefactos de diseo
Modelo de diseo Diagramas de secuencia
Es un diagrama de interaccin que define cmo se lleva a cabo y se ejecuta un caso de uso en trminos de objetos de diseo Para flujos de eventos principales y caminos alternativos
Diagramas de clases de diseo Descripciones textuales de las clases Diagramas de transicin de estados para el comportamiento interno de cada clase Descomposicin del modelo en subsistemas
Modelo de despliegue Diagramas de despliegue: distribucin fsica del sistema en nodos de computo Descripciones de los nodos y sus interrelaciones

Diseo
Actividades
Diseo de la arquitectura Arquitecto Identificar nodos y configuracin Identificar subsistemas y clases Disear un caso de uso Ingeniero de CU Identificar clases de diseo y subsistemas Distribuir comportamiento del caso de uso Capturar requisitos de implementacin
Disear una clase Ingeniero de Componentes Identificar responsabilidades y atributos Capturar requisitos especiales sobre la realizacin del CU Disear un subsistema
www.kybele.es

Diseo
Creacin modelos diseo y despliegue (arquitecto) Esbozo nodos del modelo de despliegue, subsistemas principales e interfaces, clases importantes
Realizar cada caso de uso en trminos de clases, objetos y/o subsistemas de diseo (Ingeniero de casos de uso)
Las realizaciones establecen los requisitos de comportamiento para cada clase.
Definen para cada clase de diseo: atributos y operaciones. (Ingeniero de componentes)
www.kybele.es

Diseo-Diagrama de clases de diseo
www.kybele.es

Diseo-Diagrama de clases de diseo
Transaccin miCliente : GestorDeCliente datosTarjeta : DatosTarjeta numIntentosFallidos : 1..3 = 0 cuentas : Cuentas usuarios : UsuariosDelBanco almacenarDatos(datos : DatosTarjeta) validar(importe : Dinero, cantidad : Dinero) autenticar(datos : DatosTarjeta, PIN : UnPIN) : Boolean retirarDinero(importe : Dinero) : Boolean ingresarDinero(importe : Dinero) : Boolean trasnsferencia(cuentaOrigen : Cuenta, cuentaDestino : Cuenta, importe : Dinero) : Boolean GestorDeCliente miTransaccion : Transaccin crear() : GestorDeCliente creaCajeroVirtual() iniciarSesion() visualizar(resultados : String)
Cuentas cuentas : Dictionary reintegro(cuenta : Cuenta, importe : Dinero) : Boolean ingreso(cuenta : Cuenta, importe : Dinero) : Boolean
UsuariosDelBanco usuarios : Dictionary validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean
Cuenta datos : DatosCuenta limiteDiario : Dinero = 50000

reintegro(importe : Dinero) : Boolean ingreso(importe : Dinero) : Boolean
www.kybele.es

Implementacin
Se implementa el sistema en trminos de componentes:

Ficheros de cdigo fuente, scripts, ficheros de cdigo
binarios, ejecutables y similares
Objetivos:
Planificar las integraciones de sistema necesarias en cada
iteracin Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue Implementar las clases y subsistemas encontrados durante el diseo Probar los componentes individualmente, integrarlos (compilndolos y enlazndolos en uno o ms ejecutables)

Implementacin
Artefactos de implementacin
Modelo de implementacin
Diagramas de componentes
Muestra cmo los elementos del modelo de diseo se implementan en trminos de componentes (ficheros de cdigo fuente, ejecutables...) Muestra cmo dependen los componentes unos de otros Un componente Es el empaquetamiento fsico de los elementos de un modelo Cada uno puede implementar varios elementos dependiendo del lenguaje que se utilice. Proporcionan las mismas interfaces que los elementos que implementan. Tienen relaciones de traza con los elementos del diseo que implementan. Tienen dependencias de compilacin entre ellos (unos deben haberse compilado antes para poder compilar otros).

Implementacin
Artefactos de implementacin
Subsistema de implementacin
Forma de organizar los artefactos del modelo de implementacin en trozos ms manejables. Un subsistema puede estar formado por: componentes, interfaces y otros subsistemas
Interfaz
Un componente que implementa una interfaz debe implementar correctamente todas las operaciones de la interfaz Un subsistema que implementa una interfaz debe contener componentes que proporcionen la interfaz u otros subsistemas que la proporcionen.
Plan de integracin de construcciones

1 construccin = una parte ejecutable del sistema. Lo normal es que para cada iteracin se genere una construccin (1 iteracin = 1 construccin) En algunos casos, si la funcionalidad a implementar en esa iteracin es muy compleja, se puede subdividir en diferentes construcciones (1 iteracin = n construcciones). El plan de integracin de construcciones describe la secuencia de construcciones necesarias en una iteracin.
Modelo de despliegue Diagrama de despliegue Nodos
www.kybele.es

Implementacin
Actividades
Implementacin de la arquitectura Arquitecto Implementar una clase Ingeniero de Componentes Implementar un subsistema Ingeniero de Integrar sistemas Integrador de sistemas
Componentes
Realizar prueba de unidad Ingeniero de Componentes

Prueba
Verificamos el resultado de la implementacin probando cada construccin Objetivos:
Planificar las pruebas necesarias para cada iteracin Pruebas de integracin Pruebas de sistema Disear e implementar las pruebas diseando los
casos de prueba Realizar las diferentes pruebas


Prueba
Artefactos de prueba
Modelo de pruebas Casos de prueba Procedimientos de prueba Componentes de prueba Plan de prueba Defectos Evaluacin de la prueba
www.kybele.es

Prueba
Actividades
Planificar prueba
Diseador de pruebas
Disear prueba Diseador de pruebas Describir casos de prueba para cada construccin Identificar y estructurar los procedimientos de prueba
Implementar prueba Realizar pruebas de integracin
Ingeniero de componentes Ingeniero de pruebas de

integracin
Realizar prueba de sistema Evaluar prueba

Diseador de pruebas Diseador de pruebas

www.kybele.es

Resumen Implementacin/Prueba
Creacin modelo de implementacin (arquitecto)
Planear las construcciones en la presente iteracin (Integrador del sistema)
Implementacin de los componentes para cada construccin (Ingeniero de componentes)
Cada construccin se somete a pruebas de integracin (Ingeniero de integracin)
Los componentes se prueban con pruebas de unidad (Ingeniero de pruebas)
La ltima integracin validada se somete a las pruebas de sistema (Ingeniero de pruebas)

ndice

Fases del Proceso Unificado

FASES
Workflow
Requisitos
Anlisis
Elaboracin
Transicin
Diseo Implementacin Prueba

www.kybele.es

Inicio
Propsito: establecer viabilidad para poner en marcha el proyecto Objetivo:

Anlisis del negocio: casos de uso fundamentales para el
negocio
Actividades:
1. 2. 3. 4.
Delimitar el mbito (interfaces con otros sistemas) Identificar riesgos crticos (los que afecten a la viabilidad) Demostrar a usuarios y clientes un prototipo (exploratorio) Obtener la arquitectura candidata.
www.kybele.es

Fase de Inicio

Planificacin Fase de Inicio Definicin criterios de evaluacin Flujos de trabajo
Requisitos
Anlisis
Diseo
Implement.
Pruebas
Evaluacin Anlisis inicial del negocio Planificacin de la fase de elaboracin
www.kybele.es

Inicio - Planificacin
Entradas de esta fase

Informacin de proyectos anteriores Estudios de mercado Estudios de la competencia
Hay que planificar con poca informacin Qu hacer?

Reunir la informacin previa Organizarla para su uso Reunir personas que sepan usarla Descubrir lo que falta, en trminos de los objetivos de la fase de inicio Desarrollar un plan provisional para clarificar requisitos Planificar la creacin de una arquitectura Decidir 1 2 iteraciones

Inicio Definicin Criterios de Evaluacin
Referentes al mbito del sistema

Est claro lo que va a formar parte del sistema? Se han identificado todos los actores? Se han definido las interfaces con estos actores? Lo que se ha incluido en el mbito puede constituir un sistema que funcione?
Resolver ambigedades de los requisitos de esta fase

Se han identificado y detallado los requisitos de los casos de uso necesarios? Se han identificado y detallado los requisitos adicionales?
Determinar arquitectura candidata

Satisface las necesidades de los usuarios? Puede usar la tecnologa adecuadamente? Puede evolucionar?
Mitigar riesgos crticos

Se han identificado? Se han mitigado o existe un plan de contingencia?
www.kybele.es

Inicio Requisitos
1. Enumerar requisitos candidatos 2. Comprender el contexto del sistema Desarrollar si no existe un modelo de negocio o modelo de dominio 3. Representar los requisitos funcionales como casos de uso
3.1. Encontrar actores y casos de uso Ignorar alternativas de los c.u. que no sean significativas Ignorar los c.u. que tengan poco efecto en el anlisis inicial del negocio 3.2. Determinar la prioridad de los casos de uso Refinar el plan del proyecto y de las iteraciones 3.3. Detallar los casos de uso Puede parecer que se han comprendido los requisitos Detallar el 10% de los casos de uso.
4. Recoger requisitos no funcionales relacionados

Eleccin de plataforma y definicin de la arquitectura
www.kybele.es

Inicio Anlisis
Objetivo: analizar, refinar y estructurar los requisitos funcionales
1. Anlisis de la arquitectura (arquitectura candidata) Clasificar los casos de uso necesarios para esta fase (slo los ms prioritarios) Construir modelo de anlisis para esta parte del sistema No exhaustivo Se podra descartar posteriormente 2. Analizar un caso de uso Algunos casos de uso comparten recursos. El modelo de anlisis revela los recursos compartidos 3. Anlisis mnimo de clases y paquetes
www.kybele.es

Inicio Diseo
Diseo de la arquitectura (arquitectura candidata)

Colaboraciones entre subsistemas o clases Identificar interfaces Elegir sw del sistema Considerar rendimiento y requisitos no funcionales Modelo de despliegue limitado a los nodos cuyo rendimiento es dudoso.
Diseo mnimo de clases y subsistemas
www.kybele.es

Inicio Implementacin y pruebas
Implementacin
Hasta que no se implementa no se puede asegurar el
funcionamiento de la arquitectura Escasez de recursos Prototipo de demostracin
Pruebas
Planes provisionales de pruebas Pruebas del prototipo
www.kybele.es

Inicio Evaluacin

Grupo de evaluacin: representantes del cliente o usuario. Criterios no alcanzables en el plan original:
El diagrama de casos de uso no abarca lo necesario Desarrollo de prototipo exploratorio no ha cumplido las
expectativas Sospecha de no haber encontrado todos los riesgos crticos o no haberlos cubierto en el plan de contingencia
Qu hacer?
Iteraciones posteriores modificar plan Abandonar Modificar criterios
www.kybele.es

Inicio Anlisis inicial del negocio
Vista la viabilidad establecer:

recursos necesarios costes de la inversin
estimacin de beneficios
aceptacin
Recursos y costes: estimacin de horas/persona, coste y tiempo: experiencia. y si el proceso o producto son nuevos?
Beneficios y aceptacin:
Externo: expertos en ventas
Interno: solicitar al departamento estimacin del ahorro esperado
Estas estimaciones no son exactas. Demostrar que parece rentable.

www.kybele.es

Inicio Planificacin de la fase de elaboracin
Qu se espera obtener en la fase de elaboracin?

Plan econmico ms exacto Definir ms casos de uso
Qu se debe planificar?
Qu se hace en cada iteracin
Qu requisitos van a implementar y probar

Qu riesgos se tienen que mitigar
www.kybele.es

Inicio Productos obtenidos

Lista de caractersticas Versin inicial del modelo de negocio o modelo de dominio 1 versin del modelo de casos de uso, el modelo de anlisis y el de diseo. Requisitos adicionales. Descripcin de la arquitectura candidata Prototipo exploratorio Lista de riesgos y clasificacin de casos de uso Esbozo de plan del proyecto Borrador del anlisis del negocio
www.kybele.es

Elaboracin
Propsito: factibilidad Objetivo:

Arquitectura estable para guiar el sistema Recopilar la mayor parte de los requisitos definindolos como casos de uso Continuar la observacin y control de los riesgos crticos Estimacin con precisin de costes para fases siguientes. Completar el plan de proyecto heredado de la fase de Inicio. Obtener lnea base de la arquitectura. Consiste en: modelos, descripcin de la arquitectura e implementacin ejecutable de la arquitectura. Identificacin de riesgos que pueden perturbar los planes y costes posteriores. Especificar niveles para los atributos de calidad: fiabilidad y tiempo de respuesta. Recopilar casos de uso para el 80% de los requisitos funcionales para planificar la fase de construccin. Planificacin: personal, recursos materiales.
Actividades:
1. 2. 3. 4.
5.
www.kybele.es

Fase de Elaboracin

Planificacin Fase Elaboracin Definicin criterios de evaluacin Flujos de trabajo
Requisitos
Anlisis
Diseo
Implementacin
Pruebas
Evaluacin Planificacin de la fase de construccin
www.kybele.es

Elaboracin - Planificacin
Entradas de esta fase

Planificacin inicial para la fase de elaboracin heredada de la fase de Inicio Modelo parcial de casos de uso Arquitectura candidata Rudimentos de anlisis y diseo Un prototipo, si se ha construido
La planificacin hecha en la fase de inicio puede no ser completa No se conocen de forma exacta los recursos necesarios Jefe de Proyecto (JP) replanifica:
Formar el equipo Mantener memoria del equipo Necesidades adicionales: expertos en componentes Modificar el entorno de desarrollo Herramientas de desarrollo, de gestin, comunicaciones, copias de seguridad,...
www.kybele.es

Elaboracin Definicin Criterios de Evaluacin
Establecer criterios de evaluacin

Extender los requisitos
Se han identificado requisitos, actores y casos de uso para la arquitectura? Se han identificado los riesgos? Se han detallado los casos de uso necesarios?
Definir lnea base de la arquitectura

La arquitectura satisface los requisitos recopilados formalmente hasta ahora y las necesidades del usuario? Es robusta y flexible?
Mitigar riesgos significativos

Se han eliminado o existe plan de contingencia? Se han identificado los riesgos significativos? Los riesgos que perduran se pueden eliminar de forma rutinaria en construccin?
Anlisis de negocio
El plan de proyecto est lo suficientemente definido? Se puede recuperar la inversin? Se puede redactar un contrato con precio fijo?

Elaboracin Requisitos
Representar los requisitos funcionales como casos de uso Encontrar actores y casos de uso
Identificar casos de uso (80%) Describir una parte. Cuntos? Depende del riesgo asumible, exactitud del precio Analizar parte de los descritos
Determinar la prioridad de los casos de uso

Riesgos y casos de uso
Detallar los casos de uso

Detallar el 40-80% de los casos de uso
Estructurar el modelo de casos de uso

Reducir redundancia
Recoger requisitos no funcionales relacionados


Elaboracin Anlisis
La entrada principal: el borrador obtenido en la fase de inicio Se analiza el 50% de los descritos en detalle en el flujo de trabajo de Requisitos
Anlisis de la arquitectura Particin inicial en paquetes de anlisis Descubrir colaboraciones y paquetes genricos (recuperacin de errores, transacciones, persistencia, IU grficas, distribucin de objetos) Analizar un caso de uso Buscar clases que realicen el caso de uso considerando las ya definidas en la arquitectura Analizar clases Refinar clases anteriores Analizar paquetes

Elaboracin Diseo
Disear slo lo significativo para la arquitectura Diseo de la arquitectura Uso de bloques reutilizables (subsistemas) Cmo definir los subsistemas (sistemas heredados) No siempre un paquete de anlisis se convierte en un subsistema de diseo. Distribucin. Clases activas. Traducir las clases de anlisis en clases de diseo. Disear un caso de uso Detalles de aspectos de comunicacin (diagramas de secuencia) Disear clases Integrar roles de cada clase. Atributos y mtodos.
www.kybele.es

Elaboracin Implementacin
Implementar slo lo significativo para la arquitectura Implementacin de la arquitectura A partir del modelo de diseo y despliegue asignar componentes ejecutables a nodos Implementacin de clases y subsistemas Agruparlos en componentes Pruebas de unidad
www.kybele.es

Elaboracin Pruebas
Slo se pueden probar los componentes ejecutables Empezar por el uso de mecanismos de distribucin, almacenamiento, recuperacin, concurrencia,... Rendimiento Planificar las pruebas Seleccionar objetivos a probar Disear las pruebas Integracin de subsistemas Realizar pruebas de integracin Plan de construcciones Realizar pruebas del sistema Realizar pruebas y comunicar defectos Revisar resultados de pruebas Verificar objetivos iniciales Nuevos riesgos. Ej: transferencias inconsistentes

Elaboracin Evaluacin
Comprobar que la lnea base de la arquitectura lleva a cabo los objetivos iniciales y mitiga los riesgos Varias iteraciones. Evaluar de acuerdo a los objetivos fijados en cada una Comprobar que en la ltima iteracin obtenemos la lnea base de la arquitectura. Colaboracin con el cliente: mejoras
www.kybele.es

Elaboracin Planificacin de la fase de construccin
Nmero de iteraciones que se llevarn a cabo en la fase de construccin: tamao y complejidad (2 3) Riesgos: El jefe de proyecto (JP) planifica en qu orden se va a llevar a cabo la construccin para evitar interrupciones Completar los modelos: JP planifica en qu orden se desarrollarn los casos de uso y se completarn los modelos JP organiza trabajos en paralelo basndose en los subsistemas de la arquitectura (Un grupo de desarrollo ser responsable de un subsistema de diseo).
www.kybele.es

Elaboracin Productos obtenidos
Modelo completo del negocio Nueva versin de los modelos Lnea base de la arquitectura Lista de riesgos actualizada. Los crticos seguro que se pueden mitigar. Plan de proyecto para construccin y transicin Manual de usuario preliminar Anlisis del negocio incluida propuesta econmica
www.kybele.es

Construccin

Propsito: desarrollar el sistema Objetivo:

Versin beta
Actividades:
1. Terminar la identificacin, descripcin y realizacin de
todos los casos de uso. 2. Finalizar el anlisis, el diseo, la implementacin y pruebas. 3. Mantener la integridad de la arquitectura. 4. Monitorizar los riesgos crticos
www.kybele.es

Fase de Construccin
Planificacin de la Fase de Construccin Definir criterios de evaluacin Flujos de trabajo
Requisitos
Anlisis
Diseo
Implementacin Pruebas
Evaluacin Planificacin de la fase de transicin
www.kybele.es

Construccin - Planificacin
Entradas de esta fase Lnea base de la arquitectura = la implementacin de, aproximadamente, el 10% de los casos de uso Plan de contingencia de los riesgos crticos. En esta fase ya no deberan existir riesgos crticos sin descubrir ni analizar, slo riesgos rutinarios. Responsables financieros deben aprobar el plan del proyecto Personal Asignar un responsable para cada subsistema Puede aumentar considerablemente
www.kybele.es

Construccin Definicin Criterios de Evaluacin
Establecer criterios de evaluacin

Desarrollar casos de uso
Se basan en los requisitos
Material del usuario (guas, texto de ayuda,
manuales)
Es suficiente para dar soporte a los usuarios en la fase de transicin?
Material de cursos (ejemplos, tutoriales,
diapositivas)
Es suficiente para dar soporte a los usuarios en la fase de transicin?

Construccin Requisitos, Anlisis y Diseo
Requisitos
Representar otros posibles requisitos funcionales como casos
de uso
Anlisis
Puede que no se mantenga En la fase de construccin completamos el modelo de anlisis
heredado de la fase de elaboracin. En cuanto a la arquitectura slo actualizaciones necesarias
Diseo
No se aaden subsistemas nuevos.
www.kybele.es

Construccin Implementacin Objetivo principal. Implementar y hacer pruebas de unidad de TODOS los componentes 1. Definir un plan de integracin de construcciones 2. Implementacin de clases y subsistemas 3. Realizar pruebas de unidad Corregir diseo e implementacin si fuera necesario
www.kybele.es

Construccin Pruebas
1. Planificar las pruebas 2. Disear las pruebas de integracin Objetivo: verificar interfaces entre componentes 3. Disear las pruebas de sistema Objetivo: verificar la integracin de diferentes construcciones (el conjunto de construcciones que componen el sistema) 4. Realizar pruebas de integracin Si se detectan fallos, se registran y notifican al JP 5. Realizar pruebas del sistema Si se detectan fallos, se registran y notifican al JP 6. Evaluar las pruebas

Construccin Evaluacin
Jefe de proyecto y grupo de evaluacin:

Revisan los logros de la iteracin frente a la planificacin Planifican iteraciones siguientes Actualizan lista de riesgos Si es la ltima iteracin, determinan si se han superado las
pruebas del sistema Autorizan el cambio de fase Actualizan el plan del proyecto
www.kybele.es

Construccin Planificacin de la fase de transicin
Se planifica en detalle
Quin probar el sistema? Instrucciones para llevar a cabo las pruebas
Los resultados son difciles de prever: riesgos, problemas, fallos
www.kybele.es

Construccin Productos obtenidos
Plan de proyecto para la fase de transicin Versin ejecutable (versin beta) Modelos completos del sistema Descripcin de la arquitectura Manual de usuario para guiar a los usuarios beta Anlisis del negocio
www.kybele.es

Transicin
Propsito: puesta en funcionamiento del sistema en el entorno del cliente/usuario Objetivo:

Producto final
Actividades:
1. 2. 3. 4. 5. 6.
Preparar las actividades, por ejemplo, el lugar Aconsejar sobre el entorno de funcionamiento Manuales y documentos para la entrega Ajustar el software al entorno del usuario Corregir los defectos detectados en la versin beta Determinar cundo acaba el proyecto Lecciones aprendidas Asuntos tiles para la versin siguiente
www.kybele.es

Fase de Transicin
Planificacin de la Fase de Transicin Flujos de trabajo (slo correcciones)
Requisitos
Anlisis
Diseo
Implementacin
Pruebas
Preparacin e instalacin versin beta Cierre Evaluacin
www.kybele.es

Transicin - Planificacin
Para planificar esta fase disponemos de la informacin obtenida en la produccin de la versin beta durante la fase de construccin. No podemos pretender planificar de forma detallada esta fase. Se desconoce la cantidad de trabajo . Depende de los resultados de las pruebas beta. Planificar la manera de recopilar la informacin resultante de las pruebas
Si se cumplen requisitos, riesgos inesperados, problemas no resueltos, fallos, lagunas y ambigedades en la documentacin
Los errores deben haber sido detectados y corregidos construccin a construccin (escenario ideal) Se deben reservar recursos
www.kybele.es

Transicin Preparacin e instalacin de la versin beta

Seleccionar usuarios Preparar documentacin Instruir de cmo informar de los problemas Distribuir la versin beta Pruebas beta (objetivo: encontrar fallos y errores)
No presente el personal de transicin
Instrucciones muy precisas de uso e informes, migraciones de
datos,... En caso de actualizacin de un sw ya existente. Ejecucin en paralelo con sistema anterior
Pruebas de aceptacin (objetivo: dar por finalizado el producto)

Presente el personal de transicin Documento de pruebas + comunicacin informal
Fallos y problemas se resuelven o se remiten


Transicin Preparacin e instalacin de la versin beta
Cmo actuar segn los resultados de las pruebas?
Fallos de codificacin menores

Resulta de un fallo en un componente. Rastrear hasta
requisitos. Pruebas de regresin Nuevos defectos? Afecta a los modelos?
Problemas ms importantes
Iteracin de pruebas adicional Tratados por el Comit de Control de Cambios. Los cambios sustanciales que pudiesen hasta modificar
la arquitectura deberan postergarse hasta el siguiente ciclo de desarrollo (una nueva versin del producto).

Transicin Cierre
Cundo se considera acabado el proyecto? Cuando el cliente queda satisfecho: Cuando el sistema va dirigido al mercado sin ningn cliente en especfico:
El JP decide segn la reaccin de usuarios beta
Cuando hay una peticin de un cliente:

Al terminar las pruebas de aceptacin segn requisitos. Una vez pasa las pruebas de aceptacin la fase de
transicin se considera terminada. Luego el propio cliente decide si el mantenimiento lo llevar l mismo o contratar a un tercero.

Transicin Evaluacin
Control del progreso

El JP compara el progreso real con la planificacin
Revisin de tiempo, esfuerzo, coste, % de defectos y otras mtricas:

Analizar satisfaccin de objetivos Examinar razones de fracaso Ampliacin del conocimiento de la empresa
Revisin del plan de negocio

Este plan prev si el proyecto tendr xito econmicamente
hablando. Cliente: Ha cubierto el precio contratado los costes del proyecto? Mercado: El xito se mide de acuerdo a si el producto alcanzar objetivos tales como el margen de beneficios obtenido sobre el capital invertido en el desarrollo.

Transicin Evaluacin
Jefe de proyecto y grupo de evaluacin:

Si las 3 primeras fases se han llevado de forma efectiva se
esperaran pocos problemas en la fase de transicin. En cambio si la organizacin fracas al identificar los requisitos, en construir una arquitectura correcta, se reflejar en la fase de transicin.
Modificacin en los requisitos y ampliacin de la fase de transicin
Revisin de las decisiones tomadas
Ver qu reas han dado ms problemas

Necesidad de formacin previa. El grupo de evaluacin debe registrar las cosas ms
importantes (tanto las que se han hecho bien como mal) para en un futuro poder organizar proyectos de forma ms efectiva y llevar un proceso de desarrollo con ms xito.

Transicin Productos obtenidos
Software ejecutable, incluyendo instalacin Contratos, licencias, renuncias de derechos y garantas Todos los modelos del sistema Arquitectura del sistema Manuales y material de formacin Referencias para la ayuda del cliente
www.kybele.es
Tema 6 Proceso Unificado
Ingeniera del Software I feliu.trias@urjc.es

IS4 11 12 TEMA VI ProcesoUnificado

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IS4 11 12 TEMA VI ProcesoUnificado

Cargado por

Copyright:

Formatos disponibles

Tema 6 Proceso Unificado

Ingeniera del Software I feliu.trias@urjc.es

Introduccin El proceso unificado

Principios bsicos Las 4 p

Iteracin genrica Planificacin y evaluacin

Realidad actual: sistemas ms complejos y ms grandes Objetivo:

Ingeniera del Software de Gestin

Introduccin El proceso unificado

Iteracin genrica Planificacin y evaluacin

Unificacin de tres metodologas de desarrollo basadas en el paradigma orientado a objetos

Ingeniera del Software de Gestin

Unified Process (1999) vs. Rational Unified Process (2003)

software RUP (propietario: IBM / Rational):

Ingeniera del Software de Gestin

Es un proceso de desarrollo software

Basado en componentes (cdigo reutilizable) Principios:

Las 4 P del proceso unificado:

Proyecto Proceso Producto Personas

Ingeniera del Software de Gestin

Principios del Proceso Unificado

caso de uso Actor: alguien o algo

Def.: caso de uso

resultado til Captura los requisitos funcionales

Qu debe hacer el sistema para cada actor?

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Conducen el proceso de desarrollo:

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Ingeniera del Software de Gestin

Principios del Proceso Unificado

uso que representan las tareas clave del sistema.

Evolucin a lo largo del proceso de desarrollo

concepto de vista arquitectnica

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Elementos contemplados en cada iteracin:

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Beneficios de una iteracin controlada y planificada:

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Desarrollo iterativo distribuido en grupos de trabajo:

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Ciclo de vida del software:

produce una generacin del software

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Soporta las tcnicas orientadas a objetos:

ellos Se utiliza UML como notacin comn

Impulsa un control de la calidad:

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Iteraciones en cuatro fases Informacin sobre el sistema propuesto Plan de proyecto

Informacin del dominio

Ingeniera del Software de Gestin

Principios del Proceso Unificado

Planificacin Anl. Riesgos Preparacin

Iteracin en Fase de Elaboracin

(Adaptado de Jacobson, 1999)