tema 6 proceso unificado - grupo de investigación · dependiendo de la iteración y de la fase en...

Tema 6Proceso Unificado

Ingeniería del Software I

[email protected]

Ingeniería del Software de Gestión www.kybele.es

Índice

Introducción

El proceso unificado Principios básicos

Las 4 “p”

Estructura del proceso unificado

Flujos de trabajo principales

Fases del desarrollo

Otros aspectos Iteración genérica

Planificación y evaluación


Introducción

Realidad actual: sistemas más complejos y más grandes

Objetivo: Desarrollo más rápido menor tiempo de salida al mercado Software de calidad Mejor adaptación del software a las necesidades del cliente

Solución: un proceso de desarrollo que integre todas las facetas de un desarrollo software Dé una guía 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


Índice

Introducción


Las 4 “p”







El Proceso Unificado

Unificación de tres metodologías 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



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 ingeniería (flujos de trabajo) principales

Elementos principales: roles (quién), productos (qué se debe obtener), tareas (qué se debe hacer).



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 metodología. Especifica que las herramientas son necesarias para apoyar el desarrollo del producto. No

indica cuáles utilizar.

Basado en componentes (código reutilizable) Principios:

Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental Usa UML (Unified Modeling Language) como notación 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


Principios del Proceso UnificadoDirigido por casos de uso

Ideas: Cualquier interacción del sistema con el usuario es un

caso de usoActor: alguien o algo

Def.: caso de uso Es una función 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


Principios del Proceso UnificadoDirigido por casos de uso

Conducen el proceso de desarrollo: Los desarrolladores crean modelos de análisis, modelos

de diseño e implementación 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 diseñan y sirven de base para construir los casos de prueba

Se desarrollan junto a la arquitectura del sistemaAmbos evolucionan en paralelo


Principios del Proceso UnificadoCentrado 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 diseño completo que hace visibles las características principales Más 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, reutilización.

Relación entre casos de uso y arquitectura Casos de uso Funcionalidad del sistema Arquitectura Forma

http://www.bredemeyer.com/definiti.htm


Principios del Proceso UnificadoCentrado en la Arquitectura

Tareas relacionadas:Para la definición de la arquitectura se debe poseer

una comprensión 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

Evolución a lo largo del proceso de desarrollo concepto de “vista arquitectónica”


Principios del Proceso UnificadoIterativo e incremental

División del proyecto en miniproyectos. Cada miniproyecto es una iteración (conjunto de pasos). Una iteración produce un incremento. Código ejecutable Cada iteración se centra en disminuir algún riesgo y concluye con un hito bien definido

Todas las iteraciones están planificadas y controladas (gestión de riesgos)

Factores para la selección en una iteración: La iteración trata un grupo de casos de uso que extienden la funcionalidad La iteración trata los riesgos más importantes

Elementos contemplados en cada iteración: Casos de uso relevantes Existe una arquitectura que sirve de guía. Se implementa utilizando componentes (código reutilizable). Elementos contemplados en cada iteración:

Cuando una iteración no cumple sus objetivos, los desarrolladores deben revisar sus decisiones tomadas.



Beneficios de una iteración 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 identificación de riesgos en fases tempranas del desarrollo).

Se obtienen resultados a corto plazo.

El cliente/usuario puede añadir nuevos requisitos en cualquier momento.



Desarrollo iterativo distribuido en grupos de trabajo:

Análisis Diseño e Implantación GeneralizaciónPrueba



Grupo 1

Grupo 2

Grupo n

Tiempo

Tiempo

T



Ciclo de vida del software: El paso a través de las 4 fases principales constituye un ciclo de desarrollo produce una generación del software

Al final de cada ciclo obtenemos una versión nueva del sistema

Entregas: código fuente, ejecutables, manuales y documentos

Hitos por fases (milestones)

...

Entrega

Ciclos

Concepción Elaboración TransiciónConstrucción

Iter.1

Iter.2 ... ...... ... ... ...

Iter.n

Fases

Iteraciones


Principios del Proceso UnificadoOtras características

Soporta las técnicas orientadas a objetos: Los modelos definidos como artefactos del proceso son orientados a objetos Los modelos se basan en la definición de clases, objetos y las relaciones entre

ellos Se utiliza UML como notación común

Enfocado a riesgos: La gestión 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 evaluación 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 organización


Principios del Proceso UnificadoLas 4 “P”

Proyecto: Elemento organizativo a través del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versión de un producto

Proceso: Un proceso de ingeniería de software es una definición 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, código

fuente, ejecutables, y documentación 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 gestión que les da soporte, además de los usuarios, clientes, y otros interesados

La gente trabaja más eficazmente en grupos pequeños. Trabajador = puesto de trabajo al que se le asigna una persona.


Principios del Proceso UnificadoProyecto

Iteracionesen cuatro fases

Planificar

Experiencia pasada

Plan de proyecto

Plan de iteración

Información sobreel sistema propuesto

Informacióndel dominio


Requisitos

Diseño

Implementación

Prueba

Análisis

PlanificaciónAnál. RiesgosPreparación

Elaboración ConstrucciónVerificación

Transición

FASES

Workflow

Iteración(es)Inicial(es)

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)

Iteración en Fase de Elaboración

Principios del Proceso UnificadoProceso


Principios del Proceso UnificadoProducto

Consta de un cuerpo de código fuente incluido en componentes que puede compilarse y ejecutarse, además de manuales y otros productos asociados.

Además, forman parte del producto todos aquellos artefactos que se han ido generando durante el desarrollo de la aplicación.


Modelo de análisis

Modelo de diseño

Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso

Especificado por

Soportado por

Distribuido por

Implementado por

Verificado por

Principios del Proceso UnificadoProducto (Artefactos)


Principios del Proceso UnificadoTrabajadores

Diseño de

Arquitectura

Implementación

de Arquitectura

Estructura Modelo

de Casos de Uso

Descubre Actores

y Casos de UsoAnalista de

Sistemas

Detalla un Caso

de Uso

Especifica

Casos de Uso

Prototipo del Interfaz

de Usuario

Diseñador de

Interface de Usuario

Análisis de

Arquitectura

Prioriza

Casos de UsoArquitecto

Diseña un

Caso de Uso

Analiza un

Caso de UsoIngeniero de

Casos de Uso

Ingeniero de

Componentes

Diseña

una claseAnaliza

un

Paquete

Analiza

una Clase Diseña un

Subsistema

Implementa

una clase

Implementa

Subsistema

Ejecuta Test

Unitario

Implementa

Test

Evalua

Test

Diseña

TestIngeniero de

pruebas

Planifica

Test

Integrador de

Sistemas

Integra

Sistema

Ejecuta Test

de Integración

Ejecuta test

del sistema

Ingeniero de

pruebas de

integración

Ingeniero de

pruebas de

sistema


Índice

Introducción


Las 4 “p”







Estructura del Proceso UnificadoFases 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: Iniciación (inception): Establecer la visión, el alcance y el plan

inicial del proyecto Elaboración (elaboration): Diseñar y probar una arquitectura

correcta, y completar el plan del proyecto Construcción (construction): Desarrollar el sistema (construir

la primera versión operativa) Transición (transition): Proporcionar el sistema a sus

usuarios finales


Estructura del Proceso UnificadoFases e iteraciones

Iteración: representa un ciclo de desarrollo completo, desde la captura de requisitos en el análisis hasta la implementación y pruebas, que produce una versión (interna o externa) de un producto ejecutable, que constituye un subconjunto del producto final en desarrollo

Iteración genérica (similar al modelo en cascada): Planificación Flujos de trabajo fundamentales: requisitos, análisis, diseño,

implementación y pruebas Evaluación

Dependiendo de la iteración y de la fase en la que se encuentre el proyecto, el énfasis se pone más en unos u otros flujos de trabajo

El contenido varía para adaptarse al objetivo de cada fase


Requisitos

Diseño

Implementación

Prueba

Análisis



Transición

FASES

Workflow


Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7


Principios del Proceso UnificadoFases e iteraciones


Estructura del Proceso UnificadoFlujos de trabajo

Flujos de trabajo fundamentales:

Requisitos: extrae los requisitos del sistema a desarrollar utilizando diferentes métodos

Análisis y diseño: describe las diferentes vistas arquitectónicas del sistema

Implementación: tiene en cuenta el desarrollo del software, las pruebas unitarias y la integración

Pruebas: describe los casos de pruebas, los procedimientos y las métricas para la evaluación y rastreo de defectos


Estructura del Proceso UnificadoFlujos de trabajo

Flujos de trabajo auxiliares:

Gestión de configuraciones: controla los cambios y mantiene la integridad de los artefactos de un proyecto y de las actividades de gestión

Gestión del proyecto: describe varias estrategias de trabajo en un proceso iterativo

Entorno: cubre la infraestructura necesaria para desarrollar un sistema


Elementos del Proceso UnificadoModelo y artefacto

Las actividades del proceso unificado se destacan en la creación y mantenimiento de modelos.

Modelo (una perspectiva del sistema): El modelo es una abstracción del sistema, especificando el sistema modelado

desde un cierto punto de vista y en un determinado nivel de abstracción. Representación 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


Elementos del Proceso UnificadoArtefactos

Modelos De casos de uso De análisis De diseño De implementación De pruebas

Otros artefactos Conjunto de requisitos: qué debe hacer el sistema Conjunto de diseño: cómo se va a construir el sistema Conjunto de implementación: ensamblado de los

componentes software Conjunto de despliegue: datos para la configuración del

entregable


Elementos del Proceso UnificadoArtefactos

Artefactos en PU: Fase de Inicio:

Planificación proyecto. Especificación de Requerimientos

Fase de Elaboración: Diagramas de caso de uso Diagramas de clase. Diagramas de colaboración

Fase de Construcción: Diagrama de clases Modelo E-R (si el sistema así lo requiere) Diagrama de Secuencia Diagrama de estados Diagrama de Colaboración Modelo de dominio Mapa de comportamiento a nivel de hardware.


Índice

Introducción


Las 4 “p”







Flujos de trabajo principales (Workflows)

Requisitos

Diseño

Implementación

Pruebas

Análisis



Transición

FASES

Workflow


Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7



Flujos de Trabajo Principales Requisitos

Captura de los requisitos del sistema Difícil: Los requisitos cambian Comprensión: 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 asignación de recursos

Pasos a seguir: Artefactos: Enumerar los requisitos candidatos lista de características Comprender el contexto del sistema modelo de negocio/dominio Capturar requisitos funcionales modelo de casos de uso Capturar requisitos no funcionales requisitos suplementarios o

casos individuales



Modelo de dominio: captura los tipos más 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 análisis.



Artefactos de requisitosModelo de casos de uso

Diagramas de casos de uso: • Flujos de eventos principales • Caminos alternativos

Descripciones textuales de los casos de uso Diagramas de actividad Descripción 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 Diseñador de la interfaz Estructurar el modelo de casos de uso Arquitecto


Flujos de Trabajo Principales Análisis

Se trabaja con conceptos

Especificación más precisa de los requisitos

Se utiliza el lenguaje de desarrolladores

Facilita comprensión, preparación, modificación y mantenimiento de requisitos

Primera aproximación al modelo de diseño



Modelo de Casos de Uso Modelo de Análisis

Lenguaje del cliente Lenguaje del desarrollador

Vista externa del sistema Vista interna del sistema

Estructurado por casos de uso Estructurado por clases y paquetes

Contrato entre cliente-desarrolladores Usado por desarrolladores para entender el sistema

Redundancias, inconsistencias, etc. entre requisitos

No debería contener redundancias ni inconsistencias de requisitos

Captura la funcionalidad del sistema Captura de cómo realizar la funcionalidad del sistema

Define casos de uso Define realizaciones de casos de uso



Una clase de análisis representa una abstracción de una o mas clases del diseño 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 análisis están a un nivel mayor de abstracción.

Pueden clasificarse fácilmente en clases de entidad, interfaz y de control.



Artefactos de análisis Modelo de análisis

Diagramas de colaboración: • Es un diagrama de interacción que define cómo se lleva a cabo y se

ejecuta un caso de uso en términos de objetos de análisis• Tanto para el camino principal como para los caminos alternativos

Diagramas de clases del análisis Descripciones textuales de las clases Descripción de la arquitectura

• Vista de la arquitectura del modelo de análisis• Descomposición del modelo en paquetes

Paquetes de análisis• Proporcionan un medio para organizar los artefactos del modelo de

análisis en piezas manejables.• Son cohesivos y débilmente acoplados• Basados en los requisitos funcionales y en el dominio del problema• Generan subsistemas del diseño



Actividades

Análisis de la arquitectura Arquitecto Identificar paquetes de análisis

Identificar clases de entidad

Requisitos comunes

Analizar (refinar) un caso de uso Ingeniero de CU Identificar clases de análisis

Describir interacciones entre los objetos del análisis

Capturar requisitos especiales sobre la realización del CU

Analizar una clase Ingeniero de Componentes Identificar responsabilidades y atributos

Identificar relaciones: asociación, agregación y generalización

Capturar requisitos especiales sobre la realización del CU

Analizar un paquete Ingeniero de Componentes


Flujos de Trabajo Principales Diseño

Se modela el sistema para que dé soporte a los requisitos funcionales y no funcionales

Su entrada esencial es el modelo de análisis (una comprensión detallada de los requisitos)

Objetivos: Profundizar en los requisitos no funcionales y restricciones dependientes

de la plataforma. Crear una entrada apropiada para la implementación Descomponer los trabajos de implementación en partes mas manejables

y que permitan concurrencia. Utilización de subsistemas Capturar las interfaces entre los subsistemas.

Es el centro de atención final de la fase de elaboración e iteraciones iniciales de la fase de construcción



Modelo de Análisis Modelo de Diseño

Abstracción del sistema Modelo físico. Plano de implementación

Genérico respecto al diseño (aplicable a varios diseños)

No genérico. Específico para una implementación

3 estereotipos conceptuales sobre las clases: interfaz, control y entidad.

Cualquier número de estereotipos físicossobre las clases de diseño (depende del lenguaje de programación)

Menos formal y menos caro de desarrollar Más formal y más caro de desarrollar

Bosquejo del diseño del sistema Manifiesto del diseño del sistema

No necesariamente tiene que estar mantenido durante todo el ciclo de vida del software

Debe ser mantenido durante todo el ciclo de vida del software

Entrada esencial para modelar el sistema Da forma al sistema mientras intenta preservar la estructura heredada del modelo de análisis



Artefactos de diseño Modelo de diseño

Diagramas de secuencia • Es un diagrama de interacción que define cómo se lleva a cabo y se ejecuta un

caso de uso en términos de objetos de diseño• Para flujos de eventos principales y caminos alternativos

Diagramas de clases de diseño Descripciones textuales de las clases Diagramas de transición de estados para el comportamiento interno de

cada clase Descomposición del modelo en subsistemas

Modelo de despliegue Diagramas de despliegue: distribución física del sistema en nodos de

computo Descripciones de los nodos y sus interrelaciones



Actividades Diseño de la arquitectura Arquitecto

Identificar nodos y configuración Identificar subsistemas y clases

Diseñar un caso de uso Ingeniero de CU Identificar clases de diseño y subsistemas Distribuir comportamiento del caso de uso Capturar requisitos de implementación

Diseñar una clase Ingeniero de Componentes Identificar responsabilidades y atributos Capturar requisitos especiales sobre la realización del CU

Diseñar un subsistema Ingeniero de Componentes



Creación modelos

diseño y

despliegue

(arquitecto)

Esbozo nodos del

modelo de despliegue,

subsistemas principales

e interfaces, clases

importantes

Realizar cada caso de uso en

términos de clases, objetos y/o

subsistemas de diseño

(Ingeniero de casos de uso)

Las realizaciones

establecen los requisitos

de comportamiento para

cada clase.

Definen para cada clase de

diseño: atributos y

operaciones.

(Ingeniero de componentes)


Flujos de Trabajo Principales Diseño-Diagrama de clases de diseño


Flujos de Trabajo Principales Diseño-Diagrama de clases de diseño

GestorDeCliente

miTransaccion : Transacción

crear() : GestorDeClientecreaCajeroVirtual()iniciarSesion()

visualizar(resultados : String)

Transacción

miCliente : GestorDeClientedatosTarjeta : DatosTarjetanumIntentosFallidos : 1..3 = 0cuentas : Cuentas

usuarios : UsuariosDelBanco

almacenarDatos(datos : DatosTarjeta)validar(importe : Dinero, cantidad : Dinero)autenticar(datos : DatosTarjeta, PIN : UnPIN) : BooleanretirarDinero(importe : Dinero) : BooleaningresarDinero(importe : Dinero) : Boolean

trasnsferencia(cuentaOrigen : Cuenta, cuentaDestino : Cuenta, importe : Dinero) : Boolean

UsuariosDelBanco

usuarios : Dictionary

validar(datos : DatosTarjeta, PIN : UnPIN) : Boolean

Cuentas

cuentas : Dictionary

reintegro(cuenta : Cuenta, importe : Dinero) : Booleaningreso(cuenta : Cuenta, importe : Dinero) : Boolean

Cuenta

datos : DatosCuentalimiteDiario : Dinero = 50000

reintegro(importe : Dinero) : Booleaningreso(importe : Dinero) : Boolean


Flujos de Trabajo Principales Implementación

Se implementa el sistema en términos de componentes: Ficheros de código fuente, scripts, ficheros de código

binarios, ejecutables y similares

Objetivos: Planificar las integraciones de sistema necesarias en cada

iteración

Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue

Implementar las clases y subsistemas encontrados durante el diseño

Probar los componentes individualmente, integrarlos (compilándolos y enlazándolos en uno o más ejecutables)



Artefactos de implementación Modelo de implementación

Diagramas de componentes

• Muestra cómo los elementos del modelo de diseño se implementan en términos de componentes (ficheros de código fuente, ejecutables...)

• Muestra cómo dependen los componentes unos de otros• Un componente

» Es el empaquetamiento físico 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 diseño que

implementan.» Tienen dependencias de compilación entre ellos (unos deben

haberse compilado antes para poder compilar otros).



Artefactos de implementación• Subsistema de implementación

» Forma de organizar los artefactos del modelo de implementación en trozos más 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 integración de construcciones» 1 construcción = una parte ejecutable del sistema.» Lo normal es que para cada iteración se genere una construcción (1 iteración = 1

construcción)» En algunos casos, si la funcionalidad a implementar en esa iteración es muy

compleja, se puede subdividir en diferentes construcciones (1 iteración = n construcciones).

» El plan de integración de construcciones describe la secuencia de construcciones necesarias en una iteración.

Modelo de despliegue Diagrama de despliegue Nodos



Actividades Implementación 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


Flujos de Trabajo Principales Prueba

Verificamos el resultado de la implementación probando cada construcción

Objetivos:

Planificar las pruebas necesarias para cada iteración

Pruebas de integración

Pruebas de sistema

Diseñar e implementar las pruebas diseñando los casos de prueba

Realizar las diferentes pruebas



Artefactos de prueba

Modelo de pruebas

Casos de prueba

Procedimientos de prueba

Componentes de prueba

Plan de prueba

Defectos

Evaluación de la prueba



Actividades Planificar prueba Diseñador de pruebas

Diseñar prueba Diseñador de pruebas Describir casos de prueba para cada construcción Identificar y estructurar los procedimientos de prueba

Implementar prueba Ingeniero de componentes

Realizar pruebas de integración Ingeniero de pruebas deintegración

Realizar prueba de sistema Diseñador de pruebas

Evaluar prueba Diseñador de pruebas


Flujos de Trabajo Principales Resumen Implementación/Prueba

Creación modelo de implementación

(arquitecto)

Planear las construcciones en la presente iteración

(Integrador del sistema)

Implementación de los componentes para cada

construcción(Ingeniero de componentes)

Los componentes se prueban con pruebas de unidad(Ingeniero de pruebas)

Cada construcción se somete a pruebas de integración

(Ingeniero de integración)

La última integración validada se somete a las

pruebas de sistema(Ingeniero de pruebas)


Índice

Introducción


Las 4 “p”







Fases del Proceso Unificado

Requisitos

Diseño

Implementación

Prueba

Análisis



Transición

FASES

Workflow


Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7



Fases del Proceso UnificadoInicio

Propósito: establecer viabilidad para poner en marcha el proyecto

Objetivo: Análisis del negocio: casos de uso fundamentales para el

negocio

Actividades:1. Delimitar el ámbito (interfaces con otros sistemas)

2. Identificar riesgos críticos (los que afecten a la viabilidad)

3. Demostrar a usuarios y clientes un prototipo (exploratorio)

4. Obtener la arquitectura candidata.


Planificación Fase de Inicio

Definición criterios de evaluación

Flujos de trabajo

Evaluación

Análisis inicial del negocio

Planificación de la fase de elaboración

Requisitos Análisis Diseño Implement. Pruebas

Fases del Proceso UnificadoFase de Inicio


Fases del Proceso UnificadoInicio - Planificación

Entradas de esta fase Información de proyectos anteriores Estudios de mercado Estudios de la competencia

Hay que planificar con poca información ¿Qué hacer?

Reunir la información previa Organizarla para su uso Reunir personas que sepan usarla Descubrir lo que falta, en términos de los objetivos de la fase de

inicio Desarrollar un plan provisional para clarificar requisitos Planificar la creación de una arquitectura Decidir 1 ó 2 iteraciones


Fases del Proceso UnificadoInicio – Definición Criterios de Evaluación

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 ambigüedades 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 tecnología adecuadamente? ¿Puede evolucionar?

Mitigar riesgos críticos ¿Se han identificado? ¿Se han mitigado o existe un plan de contingencia?


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 análisis 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

Elección de plataforma y definición de la arquitectura

Fases del Proceso UnificadoInicio – Requisitos


Objetivo: analizar, refinar y estructurar los requisitos funcionales

1. Análisis de la arquitectura (arquitectura candidata)

Clasificar los casos de uso necesarios para esta fase (sólo los más prioritarios)

Construir modelo de análisis para esta parte del sistema

No exhaustivo

Se podría descartar posteriormente

2. Analizar un caso de uso

Algunos casos de uso comparten recursos. El modelo de análisis revela los recursos compartidos

3. Análisis mínimo de clases y paquetes

Fases del Proceso UnificadoInicio – Análisis


Diseño 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.

Diseño mínimo de clases y subsistemas

Fases del Proceso UnificadoInicio – Diseño


Implementación Hasta que no se implementa no se puede asegurar el

funcionamiento de la arquitectura Escasez de recursos Prototipo de demostración

Pruebas Planes provisionales de pruebas Pruebas del prototipo

Fases del Proceso UnificadoInicio – Implementación y pruebas


Grupo de evaluación: 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 críticos o no haberlos cubierto en el plan de contingencia

¿Qué hacer?

Iteraciones posteriores modificar plan

Abandonar

Modificar criterios

Fases del Proceso UnificadoInicio – Evaluación


Vista la viabilidad establecer:

recursos necesarios

costes de la inversión

estimación de beneficios

aceptación

Recursos y costes: estimación de horas/persona, coste y tiempo: experiencia. ¿y si el proceso o producto son nuevos?

Beneficios y aceptación: Externo: expertos en ventas

Interno: solicitar al departamento estimación del ahorro esperado

Estas estimaciones no son exactas. Demostrar que parece rentable.

Fases del Proceso UnificadoInicio – Análisis inicial del negocio


¿Qué se espera obtener en la fase de elaboración?

Plan económico más exacto

Definir más casos de uso

¿Qué se debe planificar?

Qué se hace en cada iteración

Qué requisitos van a implementar y probar

Qué riesgos se tienen que mitigar

Fases del Proceso UnificadoInicio – Planificación de la fase de elaboración


Lista de características

Versión inicial del modelo de negocio o modelo de dominio

1ª versión del modelo de casos de uso, el modelo de análisis y el de diseño. Requisitos adicionales.

Descripción de la arquitectura candidata

Prototipo exploratorio

Lista de riesgos y clasificación de casos de uso

Esbozo de plan del proyecto

Borrador del análisis del negocio

Fases del Proceso UnificadoInicio – Productos obtenidos


Fases del Proceso UnificadoElaboración

Propósito: factibilidad Objetivo:

Arquitectura estable para guiar el sistema Recopilar la mayor parte de los requisitos definiéndolos como casos de uso Continuar la observación y control de los riesgos críticos Estimación con precisión de costes para fases siguientes. Completar el plan de

proyecto heredado de la fase de Inicio.

Actividades:1. Obtener línea base de la arquitectura. Consiste en: modelos, descripción de la

arquitectura e implementación ejecutable de la arquitectura.2. Identificación de riesgos que pueden perturbar los planes y costes posteriores.3. Especificar niveles para los atributos de calidad: fiabilidad y tiempo de

respuesta.4. Recopilar casos de uso para el 80% de los requisitos funcionales para planificar

la fase de construcción.5. Planificación: personal, recursos materiales.


Planificación Fase Elaboración

Definición criterios de evaluación

Flujos de trabajo

Evaluación

Planificación de la fase de construcción

Requisitos Análisis Diseño Implementación Pruebas

Fases del Proceso UnificadoFase de Elaboración


Fases del Proceso UnificadoElaboración - Planificación

Entradas de esta fase Planificación inicial para la fase de elaboración heredada de la fase de Inicio Modelo parcial de casos de uso Arquitectura candidata Rudimentos de análisis y diseño Un prototipo, si se ha construido

La planificación 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 gestión, comunicaciones, copias de seguridad,...


Establecer criterios de evaluación

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 línea 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 construcción?

Análisis de negocio ¿El plan de proyecto está lo suficientemente definido? ¿Se puede recuperar

la inversión? ¿Se puede redactar un contrato con precio fijo?

Fases del Proceso UnificadoElaboración – Definición Criterios de Evaluación


Representar los requisitos funcionales como casos de uso

Encontrar actores y casos de uso

Identificar casos de uso (80%)

Describir una parte. ¿Cuántos? 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

Fases del Proceso UnificadoElaboración – Requisitos


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

Análisis de la arquitectura

Partición inicial en paquetes de análisis

Descubrir colaboraciones y paquetes genéricos (recuperación de errores, transacciones, persistencia, IU gráficas, distribución de objetos)

Analizar un caso de uso

Buscar clases que realicen el caso de uso considerando las yadefinidas en la arquitectura

Analizar clases

Refinar clases anteriores

Analizar paquetes

Fases del Proceso UnificadoElaboración – Análisis


Fases del Proceso UnificadoElaboración – Diseño

Diseñar sólo lo significativo para la arquitectura

Diseño de la arquitectura

Uso de bloques reutilizables (subsistemas)

Cómo definir los subsistemas (sistemas heredados)

No siempre un paquete de análisis se convierte en un subsistema de diseño.

Distribución. Clases activas. Traducir las clases de análisis en clases de diseño.

Diseñar un caso de uso

Detalles de aspectos de comunicación (diagramas de secuencia)

Diseñar clases

Integrar roles de cada clase. Atributos y métodos.


Fases del Proceso UnificadoElaboración – Implementación

Implementar sólo lo significativo para la arquitectura

Implementación de la arquitectura

A partir del modelo de diseño y despliegue asignar componentes ejecutables a nodos

Implementación de clases y subsistemas

Agruparlos en componentes

Pruebas de unidad


Fases del Proceso UnificadoElaboración – Pruebas

Sólo se pueden probar los componentes ejecutables

Empezar por el uso de mecanismos de distribución, almacenamiento, recuperación, concurrencia,... Rendimiento

Planificar las pruebas

Seleccionar objetivos a probar

Diseñar las pruebas

Integración de subsistemas

Realizar pruebas de integración

Plan de construcciones

Realizar pruebas del sistema

Realizar pruebas y comunicar defectos

Revisar resultados de pruebas

Verificar objetivos iniciales

Nuevos riesgos. Ej: transferencias inconsistentes


Fases del Proceso UnificadoElaboración – Evaluación

Comprobar que la línea 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 iteración obtenemos la línea base de la arquitectura.

Colaboración con el cliente: mejoras


Fases del Proceso UnificadoElaboración – Planificación de la fase de

construcción

Número de iteraciones que se llevarán a cabo en la fase de construcción: tamaño y complejidad (2 ó 3)

Riesgos:

El jefe de proyecto (JP) planifica en qué orden se va a llevar a cabo la construcción para evitar interrupciones

Completar los modelos:

JP planifica en qué orden se desarrollarán los casos de uso y se completarán los modelos

JP organiza trabajos en paralelo basándose en los subsistemas de la arquitectura (Un grupo de desarrollo será responsable de un subsistema de diseño).


Fases del Proceso UnificadoElaboración – Productos obtenidos

Modelo completo del negocio

Nueva versión de los modelos

Línea base de la arquitectura

Lista de riesgos actualizada. Los críticos seguro que se pueden mitigar.

Plan de proyecto para construcción y transición

Manual de usuario preliminar

Análisis del negocio incluida propuesta económica


Fases del Proceso UnificadoConstrucción

Propósito: desarrollar el sistema

Objetivo:Versión beta

Actividades:1. Terminar la identificación, descripción y realización de

todos los casos de uso.2. Finalizar el análisis, el diseño, la implementación y

pruebas.3. Mantener la integridad de la arquitectura.4. Monitorizar los riesgos críticos


Fases del Proceso UnificadoFase de Construcción

Planificación de la Fase de Construcción

Definir criterios de evaluación

Flujos de trabajo

Evaluación

Planificación de la fase de transición

Requisitos Análisis Diseño ImplementaciónPruebas


Entradas de esta fase

Línea base de la arquitectura = la implementación de, aproximadamente, el 10% de los casos de uso

Plan de contingencia de los riesgos críticos. En esta fase ya no deberían existir riesgos críticos sin descubrir ni analizar, sólo riesgos rutinarios.

Responsables financieros deben aprobar el plan del proyecto

Personal

Asignar un responsable para cada subsistema

Puede aumentar considerablemente

Fases del Proceso UnificadoConstrucción - Planificación


Fases del Proceso UnificadoConstrucción – Definición Criterios de Evaluación

Establecer criterios de evaluación

Desarrollar casos de uso Se basan en los requisitos

Material del usuario (guías, texto de ayuda, manuales) ¿Es suficiente para dar soporte a los usuarios en la fase de

transición?

Material de cursos (ejemplos, tutoriales, diapositivas) ¿Es suficiente para dar soporte a los usuarios en la fase de

transición?


Fases del Proceso UnificadoConstrucción – Requisitos, Análisis y Diseño

Requisitos

Representar otros posibles requisitos funcionales como casos de uso

Análisis

Puede que no se mantenga

En la fase de construcción completamos el modelo de análisis heredado de la fase de elaboración.

En cuanto a la arquitectura sólo actualizaciones necesarias

Diseño

No se añaden subsistemas nuevos.


Fases del Proceso UnificadoConstrucción – Implementación

Objetivo principal. Implementar y hacer pruebas de unidad de TODOS los componentes

1. Definir un plan de integración de construcciones

2. Implementación de clases y subsistemas

3. Realizar pruebas de unidad

Corregir diseño e implementación si fuera necesario


Fases del Proceso UnificadoConstrucción – Pruebas

1. Planificar las pruebas

2. Diseñar las pruebas de integración

Objetivo: verificar interfaces entre componentes

3. Diseñar las pruebas de sistema

Objetivo: verificar la integración de diferentes construcciones (el conjunto de construcciones que componen el sistema)

4. Realizar pruebas de integración

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


Fases del Proceso UnificadoConstrucción – Evaluación

Jefe de proyecto y grupo de evaluación:

Revisan los logros de la iteración frente a la planificación

Planifican iteraciones siguientes

Actualizan lista de riesgos

Si es la última iteración, determinan si se han superado las pruebas del sistema

Autorizan el cambio de fase

Actualizan el plan del proyecto


Fases del Proceso UnificadoConstrucción – Planificación de la fase de

transición

Se planifica en detalle

¿Quién probará el sistema?

Instrucciones para llevar a cabo las pruebas

Los resultados son difíciles de prever: riesgos, problemas, fallos


Fases del Proceso UnificadoConstrucción – Productos obtenidos

Plan de proyecto para la fase de transición

Versión ejecutable (versión beta)

Modelos completos del sistema

Descripción de la arquitectura

Manual de usuario para guiar a los usuarios beta

Análisis del negocio


Fases del Proceso UnificadoTransición

Propósito: puesta en funcionamiento del sistema en el entorno del cliente/usuario

Objetivo: Producto final

Actividades:1. Preparar las actividades, por ejemplo, el lugar2. Aconsejar sobre el entorno de funcionamiento3. Manuales y documentos para la entrega4. Ajustar el software al entorno del usuario5. Corregir los defectos detectados en la versión beta6. Determinar cuándo acaba el proyecto

Lecciones aprendidas Asuntos útiles para la versión siguiente


Fases del Proceso UnificadoFase de Transición

Planificación de la Fase de Transición

Flujos de trabajo (sólo correcciones)

Preparación e instalación versión beta

Cierre

Evaluación

Requisitos Análisis Diseño Implementación Pruebas


Fases del Proceso UnificadoTransición - Planificación

Para planificar esta fase disponemos de la información obtenida en la producción de la versión beta durante la fase de construcción.

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 información resultante de las pruebasSi se cumplen requisitos, riesgos inesperados, problemas no

resueltos, fallos, lagunas y ambigüedades en la

documentación…

Los errores deben haber sido detectados y corregidos construcción a construcción (escenario ideal)

Se deben reservar recursos


Fases del Proceso UnificadoTransición – Preparación e instalación de la

versión beta

Seleccionar usuarios

Preparar documentación

Instruir de cómo informar de los problemas

Distribuir la versión beta

Pruebas beta (objetivo: encontrar fallos y errores)

No presente el personal de transición

Instrucciones muy precisas de uso e informes, migraciones de datos,...

En caso de actualización de un sw ya existente. Ejecución en paralelo con sistema anterior

Pruebas de aceptación (objetivo: dar por finalizado el producto)

Presente el personal de transición

Documento de pruebas + comunicación informal

Fallos y problemas se resuelven o se remiten


Fases del Proceso UnificadoTransición – Preparación e instalación de la

versión beta

¿Cómo actuar según los resultados de las pruebas?

Fallos de codificación menores

Resulta de un fallo en un componente. Rastrear hasta requisitos. Pruebas de regresión

¿Nuevos defectos? ¿Afecta a los modelos?

Problemas más importantes

Iteración de pruebas adicional

Tratados por el Comité de Control de Cambios.

Los cambios sustanciales que pudiesen hasta modificar la arquitectura deberían postergarse hasta el siguiente ciclo de desarrollo (una nueva versión del producto).


Fases del Proceso UnificadoTransición – Cierre

¿Cuándo se considera acabado el proyecto?

Cuando el cliente queda satisfecho:

Cuando el sistema va dirigido al mercado sin ningún cliente en específico:

El JP decide según la reacción de usuarios beta

Cuando hay una petición de un cliente:

Al terminar las pruebas de aceptación según requisitos.

Una vez pasa las pruebas de aceptación la fase de transición se considera terminada. Luego el propio cliente decide si el mantenimiento lo llevará él mismo o contratará a un tercero.


Fases del Proceso UnificadoTransición – Evaluación

Control del progreso

El JP compara el progreso real con la planificación

Revisión de tiempo, esfuerzo, coste, % de defectos y otras métricas: Analizar satisfacción de objetivos

Examinar razones de fracaso

Ampliación del conocimiento de la empresa

Revisión del plan de negocio

Este plan prevé si el proyecto tendrá éxito económicamente 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.


Fases del Proceso UnificadoTransición – Evaluación

Jefe de proyecto y grupo de evaluación:

Si las 3 primeras fases se han llevado de forma efectiva se esperaran pocos problemas en la fase de transición.

En cambio si la organización fracasó al identificar los requisitos, en construir una arquitectura correcta, se reflejará en la fase de transición. Modificación en los requisitos y ampliación de la fase de transición

Revisión de las decisiones tomadas

Ver qué áreas han dado más problemas

Necesidad de formación previa.

El grupo de evaluación debe registrar las cosas más importantes (tanto las que se han hecho bien como mal) para en un futuro poder organizar proyectos de forma más efectiva y llevar un proceso de desarrollo con más éxito.


Fases del Proceso UnificadoTransición – Productos obtenidos

Software ejecutable, incluyendo instalación

Contratos, licencias, renuncias de derechos y garantías

Todos los modelos del sistema

Arquitectura del sistema

Manuales y material de formación

Referencias para la ayuda del cliente

Tema 6Proceso Unificado

Ingeniería del Software I

[email protected]

tema 6 proceso unificado - grupo de investigación · dependiendo de la iteración y de la fase en...

Documents