El Proceso Unificado de DesarrolloIS... · Estructura del Proceso Unificado Flujos de trabajo (RUP)...

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

Marcos López SanzIngeniería del Software de Gestión

Tema 4c:El Proceso Unificado de Desarrollo


Í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é), tareas (cómo)



Es un proceso de desarrollo software Def.: conjunto de actividades para transformar los requisitos de usuario

en un sistema software

Basado en componentes 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 diseño e

implementación que realizan 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:

Crear una arquitectura inicial no específica de los casos de uso

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 “hitos” obtenidos como consecuencia de la repetición de iteraciones de trabajo Una iteración produce un incremento Cada fase e iteración se centra en disminuir algún riesgo y concluye con

un hito bien definido

Todas las iteraciones son planificadas y controladas Factores para la selección en una iteración:

La iteración trata un grupo de casos que extienden la funcionalidad La iteración trata los riesgos más importantes

Importante: un incremento no siempre es aditivo Elementos contemplados en cada iteración:

Casos de uso relevantes Diseño guiado por arquitectura Actividades de implementación y verificación

Beneficios


Principios del Proceso UnificadoIterativo e incremental

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


Principios del Proceso Unificado

Iterativo e incremental

Ciclo de vida del software: Varios ciclos de desarrollo que concluyen con un producto evolucionado

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

Primera pasada desarrollo inicial

Siguientes ciclos de evolución del sistema

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

Hitos por fases (milestones)

...

Entrega

Ciclos

Concepción Elaboración TransiciónConstrucciónIter.

1Iter.

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

n

Fases

Iterac.



Otras 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



Las 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 loas arquitectos,

desarrolladores, ingenieros de prueba y el personal de gestión que les da soporte, además de los usuarios, clientes, y otros interesados

Las personas son realmente seres humanos, a diferencia del termino abstracto “trabajadores”



Proyecto

Varias 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


Proceso


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


Producto



Personas

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

inicial del proyecto Elaboración (elaboration): Diseñar, implementar 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



Fases 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



Flujos de trabajo (RUP)

Flujos de trabajo fundamentales: Modelado del negocio: describe la estructura y la dinámica de la organización del

cliente

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

Despliegue: cubre la configuración del sistema entregable (materiales, notas de edición, formación, etc.)



Flujos de trabajo (RUP)

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 Unificado

Artefactos y Modelos Las actividades del proceso unificado destacan en la creación y

mantenimiento de modelos más que de documentos en papel

Modelo: representación abstracta y simplificada de la realidad, creada para comprender mejor el sistema que se está desarrollando

Vista: proyección de un modelo RUP: diseño, procesos, implementación, despliegue y casos de uso Kruchten (4+1): lógica, procesos, realización, distribución y casos de uso

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, un modelo o un elemento de modelo



Artefactos y Modelos Modelos

Del negocio Del dominio De casos de uso De análisis De diseño Del proceso De despliegue 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



Artefactos y Modelos Artefactos en RUP:

Fase de Inicio: Documento Visión Especificación de Requerimientos

Elaboración: Diagramas de caso de uso

Construcción: Documento con la descripción de la Arquitectura. Vistas (4+1):

• Vista Lógica:» Diagrama de clases» Modelo E-R (si el sistema así lo requiere)

• Vista de Implementación:» Diagrama de Secuencia» Diagrama de estados» Diagrama de Colaboración

• Vista Conceptual: » Modelo de dominio

• Vista física:» Mapa de comportamiento a nivel de hardware.


Índice

Introducción


Las 4 “p”







Flujos de trabajo principales (Workflows)

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



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 los recursos

Pasos a seguir: 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



Requisitos Artefactos de requisitos

Modelo de casos de uso Diagramas de casos de uso:

• Flujos de eventos principales • Caminos alternativos

Descripciones textuales de los casos de uso Diagramas de estado para explicar los casos de uso complejos

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



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



Análisis

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 cómo realizar la funcionalidad del sistema

Define casos de uso Define realizaciones de casos de uso



Análisis Artefactos de análisis

Modelo de análisis Diagramas de colaboración:


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

Realización de los casos de uso en análisis Diagramas de clases del análisis Diagramas de interacción de objetos del análisis Una descripción textual del flujo de sucesos

Clases y paquetes de análisis



Análisis

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



Diseño

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

Objetivos: Profundizar en la 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. 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



Diseño Artefactos de diseño

Modelo de diseño Diagramas de secuencia


Descripciones textuales de las clases Diagramas de transición de estados para el comportamiento interno de cada

clase

Modelo de despliegue Diagramas de despliegue: distribución física del sistema en nodos de computo Descripciones de los nodos y sus interrelaciones

Descripción de la arquitectura Vista de la arquitectura del modelo de diseño Descomposición del modelo en subsistemas

Realización de los casos de uso en diseño Diagramas de clases de realización en diseño Diagramas de interacción (clases, subsistemas, interfaces) Flujo de sucesos-diseño Requisitos de implementación



Diseño

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



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)



Implementación

Artefactos de implementaciónModelo de implementación

Diagramas de componentes• Subsistemas de implementación y sus dependencias• Componentes (fichero y ejecutables) y sus dependencias• Interfaces

Modelo de despliegue Diagrama de despliegue Nodos

Descripción de la arquitectura Vista de la arquitectura del modelo de implementación Asignación de componentes ejecutables a nodos

Plan de integración de construcciones



Implementación

Actividades Implementación de la arquitectura Arquitecto

Integrar sistemas Integrador de sistemas

Implementar una clase Ingeniero de Componentes

Implementar un subsistema Ingeniero de Componentes

Realizar prueba de unidad Ingeniero de Componentes



Prueba

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

Objetivos:Planificar las pruebas necesarias para cada iteración Pruebas de sistema

Pruebas de integración

Diseñar e implementar las pruebas diseñando 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

Evaluación de la prueba



Implementación

Actividades Planificar prueba Diseñador de pruebas

Diseñar prueba Diseñador de pruebas Describir casos de prueba de 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


Í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 UnificadoInicial

Propósito: establecer viabilidad

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

negocio

Actividades:1. Delimitar el ámbito (interfaces con otros sistemas)2. Proponer una arquitectura especialmente en lo nuevo,

arriesgado o difícil (expresada en función de algunos modelos)

3. Identificar riesgos críticos (los que afecten a la viabilidad)4. Demostrar a usuarios y clientes un prototipo (exploratorio)


Fases del Proceso UnificadoElaboración

Propósito: factibilidad

Objetivo: Arquitectura estable para guiar el sistema Estimación de costes para fases siguientes con precisión

Actividades:1. 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, coste.


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 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 beta

Lecciones aprendidas Asuntos útiles para la versión siguiente


Índice

Introducción


Las 4 “p”







Otros aspectos del Proceso UnificadoIteración genérica

Incluye Planificación Flujos de trabajo fundamentales Requisitos Análisis Diseño Implementación Pruebas

Evaluación

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


Otros aspectos del Proceso UnificadoPlanificación (fases)

Establecer:Asignaciones de tiempo y fecha de entrega por cada

fase (inestable hasta fin de elaboración)

Hitos principales y criterios de aceptación

Iteraciones por fase y qué se realiza en ellas Depende de la complejidad del sistema

Plan de proyecto: Fechas y criterios de objetivos principales

División de fases en iteraciones

Pensar a largo plazo


Otros aspectos del Proceso UnificadoPlanificación (iteraciones)

Se define: Planificación de la Iteración: cuánto tiempo, fecha de terminación,

etc. Contenido de la Iteración: ya está esbozado en el plan del proyecto

pero al comenzar cada iteración se debe detallar: Casos de uso Riesgos técnicos que se deben identificar en forma de casos de uso Cambios que han sufrido los requisitos o defectos encontrados Subsistemas que se deben implementar Personal

El plan de la iteración siguiente se va detallando.

El número de iteraciones de cada fase esta determinado por la complejidad del sistema.


Otros aspectos del Proceso UnificadoPlanificación / Evaluación

Antes de cada iteración se han de planificar los criterios de evaluación para establecer la satisfacción de los objetivos de cada iteración (medidos u observados): Requisitos funcionales en casos de uso Requisitos no funcionales de esos requisitos funcionales Requisitos no funcionales sueltos

Requisitos verificables (pruebas)

Requisitos generales (prototipo)

Productos intermedios para determinar el progreso del trabajo

Al final de cada iteración se realiza la evaluación de la misma de acuerdo a los criterios inicialmente establecidos


Otros aspectos del Proceso Unificado

Evaluación

Jefe de proyecto: ha de crear un documento como resultado de la evaluación

Objetivos: Evaluar iteraciones según criterios: presupuesto, tiempo, requisitos de calidad,

resultados de las pruebas Reconsiderar el plan de la siguiente iteración Modificar el proceso Evaluar y modificar criterios

Es frecuente no alcanzar los criterios prolongar el trabajo a la iteración siguiente: Modificar o extender el modelo de casos de uso Modificar o extender la arquitectura Modificar o extender los subsistemas desarrollados Buscar otros riesgos Incorporar ciertas habilidades al equipo Puede que solo falte tiempo


Otros aspectos del Proceso Unificado

Evaluación

A partir de la evaluación anterior, el jefe de proyecto:

Determina si se puede pasar a la siguiente iteración

Si hay que rehacer, decide cuándo, quién y cómo

Planifica en detalle siguiente iteración

Actualiza el plan de las iteraciones posteriores a la siguiente

Actualiza la lista de riesgos y el plan del proyecto

Evolución del conjunto de modelos


Bibliografía

The unified software development process. Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999

El proceso unificado de desarrollo.Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999

El Proceso Unificado de DesarrolloIS... · Estructura del Proceso Unificado Flujos de trabajo (RUP)...

Documents

Transcript of El Proceso Unificado de DesarrolloIS... · Estructura del Proceso Unificado Flujos de trabajo (RUP)...