EL PROCESO UNIFICADO (RUP) DE DESARROLLO DE SOFTWARE

INTRODUCCIÓN

La comunidad de desarrollo de software necesita una forma controlada de trabajar, un proceso que:

• proporcione una guía para el orden de las actividades del equipo;

• dirija las tareas de los desarrolladores individuales y del equipo como un todo;

• especifique qué artefactos deben ser desarrollados y cuándo; • ofrezca criterios para supervisar y medir los productos y

actividades del proyecto.

1

El RUP es: • un proceso de desarrollo de software — el conjunto de

actividades necesarias para transformar los requisitos de un cliente/usuario en un sistema de software;

• más que un proceso individual — un armazón genérico para procesos que puede ser especializado para una clase grande de sistemas de software, para diferentes dominios de aplicación, tipos de organizaciones, niveles de competencia, y tamaños de proyectos.

Además, el RUP:

• es un proceso basado en componentes — el sistema de software que se construye está hecho de componentes de software interconectadas via interfaces bien definidas;

• usa UML para preparar todos los planos del sistema de software — UML y el RUP fueron desarrollados conjuntamente.

Sin embargo, las características más distintivas del RUP son:

• es un proceso dirigido por casos de uso; • es un proceso centrado en la arquitectura; • es un proceso iterativo e incremental.

2

LAS MEJORES PRÁCTICAS DE INGENIERÍA DE SOFTWARE

ACTIVIDAD DE EQUIPOS. Debido al tamaño y complejidad de los sistemas de software modernos, su desarrollo es una actividad de equipos:

• gerente de proyecto • analistas de sistemas • desarrolladores

• encargados de pruebas • ingenieros de desempeño • ingenieros de instalación.

Estos equipos presentan desafíos de comunicación.

• las tecnologías más complejas requieren expertos especializados en sólo un área;

• un equipo puede incluir muchos de estos especialistas;

• hay que asegurarse que – estos especialistas se comuniquen efectivamente con el

resto del equipo – las tecnologías construidas por cada especialista se

integren para producir un sistema exitoso;

• la velocidad de los cambios tecnológicos sigue aumentando y muchas tecnologías son usadas antes de haber sido probadas.

3

SÍNTOMAS. ¿Cómo nos va? • muchos proyectos de software son exitosos a pesar de los

problemas — lo demuestran los muchísimos sistemas de los que dependemos a diario

• nuestra tasa de fallas es aún demasiado alta — necesitamos cambiar nuestras prácticas.

Producir software de buena calidad y a tiempo es muy desafiante, debiendo superarse innumerables problemas. Éstos son a menudo reconocidos primero por sus síntomas:

• Entendimiento inexacto de las necesidades del usuario • Incapacidad para manejar requisitos cambiantes • Módulos que no calzan unos con otros • Software que es difícil de mantener o extender • Descubrimiento tardío de fallas serias en el proyecto • La calidad del software es pobre • El desempeño del software es inaceptable • Los miembros del equipo se entorpecen unos a otros, y son

incapaces de reconstruir quién cambió qué, cuándo, dónde, y por qué

• Un proceso de construcción-y-entrega no confiable

4

CAUSAS. Tratar los síntomas no cura la enfermedad: p.ej., el descubrimiento tardío de fallas serias en el proyecto es sólo un síntoma de un problema más grande — realización inadecuada de pruebas.

El tradicional desarrollo en cascada agrava el problema:

las pruebas se hacen muy tarde — las fallas no pueden corregirse sin retrasar significativamente la entrega.

Raíces de los problemas:

• Insuficiente gestión de requisitos • Comunicacione ambiguas • Arquitecturas frágiles • Complejidad abrumadora • Inconsistencias no detectadas entre requisitos, diseños, e

implementaciones • Insuficientes pruebas • Evaluación subjetiva del estado del proyecto • Reducción de riesgos atrasada debido al desarrollo en

cascada • Propagación incontrolada de cambios • Insuficiente automatización

Hay que tratar estas causas para eliminar los síntomas. Eliminando los síntomas uno está en mucho mejor posición para construir software de calidad de manera predecible y repetible.

5

LAS MEJORES PRÁCTICAS: • un conjunto de enfoques para desarrollo de software proba-

dos comercialmente que, cuando se usan combinadamente, atacan las raíces de los problemas del desarrollo de software;

• son “mejores” no tanto porque podamos cuantificar en forma precisa su valor, sino porque se ha observado que son usadas habitualmente por organizaciones exitosas.

Las 6 mejores prácticas de la ingeniería de software:

Desarrollar software iterativamente Gestionar los requisitos Usar arquitecturas basadas en componentes Modelar software visualmente (con UML) Verificar la calidad del software Controlar los cambios al software

Estas prácticas se refuerzan unas a otras:

• el total es mucho más grande que la suma de las partes; • en algunos casos, además, unas prácticas facilitan otras.

6

P.ej., el desarrollo iterativo mejora • la gestión de requisitos — asegura que los usuarios se

involucran a medida que los requisitos evolucionan • el uso de arquitecturas de componentes — valida

tempranamente las decisiones arquitectónicas • el modelamiento visual — aborda incrementalmente la

complejidad del diseño e implementación • la verificación de la calidad — mide la calidad tempranamente

y a menudo • el control de cambios — hace evolucionar incrementalmente

las líneas bases Pero además, el desarrollo iterativo podría fácilmente no converger sin una adecuada gestión de requisitos:

• los requisitos cambian a discresión, • los usuarios no se ponen de acuerdo, y • las iteraciones siguen para siempre.

En cambio, con gestión de requisitos:

• los cambios a los requisitos son visibles, • puede evaluarse el impacto de los cambios sobre el proceso

de desarrollo antes de aceptarse, y • se asegura la convergencia en un conjunto estable de

requisitos.

7

UN PROCESO DIRIGIDO POR CASOS DE USO Un sistema de software es creado para servir a sus usuarios. Para que sea exitoso debemos saber qué es lo que éstos quieren y necesitan — no sólo personas, también otros sistemas que interactúan con el sistema desarrollado. P.ej., una interacción es una persona que usa un cajero automático:

• él (o ella) inserta la tarjeta, contesta las preguntas hechas por el sistema a través de la pantalla, y recibe una suma de dinero en efectivo;

• como respuesta a la tarjeta y a las respuestas del usuario, el sistema realiza una secuencia de acciones que porporcionan al usuario un resultado de valor — el dinero en efectivo.

Una interacción como esta es un caso de uso:

• un caso de uso es una parte de la funcionalidad del sistema que por si sola entrega a un usuario un resultado de valor;

• los casos de uso capturan los requisitos funcionales; • el conjunto de casos de uso constituye el modelo de casos

de uso — descripción de la funcionalidad completa del sistema — reemplazando a la tradicional especificación funcional.

La especificación funcional tradicional contesta la pregunta ¿qué se supone que hace el sistema?

8

En cambio, el modelo de casos de uso • contesta la pregunta ¿qué se supone que el sistema hace

para cada usuario? • nos obliga a pensar en el valor para los usuarios, no sólo en

funciones que sería bueno tener. Los casos de uso, además, dirigen el proceso de desarrollo — el diseño, la implementación, y las pruebas del sistema:

• a partir del modelo de casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que realizan los casos de uso;

• los desarrolladores revisan cada modelo para asegurar que concuerde con el modelo de casos de uso;

• los encargados de las pruebas prueban la implementación para asegurarse que los componentes del modelo de imple-mentación implementan correctamente los casos de uso.

Dirigido por casos de uso significa que el desarrollo sigue un flujo — avanza a través de una serie de flujos de trabajo derivados de los casos de uso:

• los casos de uso se especifican; • los casos de uso se diseñan; y • al final, los casos de uso son la fuente a partir de la cual se

construye los casos de prueba. Finalmente, los casos de uso son elegidos en colaboración recíproca con la arquitectura del sistema — ambos maduran a medida que avanza el ciclo de vida.

9

UN PROCESO CENTRADO EN LA ARQUITECTURA El rol de la arquitectura en la construcción de edificios:

• el edificio es visto desde distintos puntos de vista: estructura, servicios, conductos para calefacción, cañerías de agua, electricidad, etc.

• esto permite al constructor tener un cuadro completo antes de que comience la construcción.

La arquitectura en un sistema de software consiste en las diferentes vistas del sistema en construcción:

• incluye los aspectos estáticos y dinámicos más relevantes del sistema;

• nace de las necesidades de la empresa, detectadas por usuarios y otros interesados, y reflejadas en los casos de uso;

• es influenciada por varios factores: (•) plataforma sobre la cual va a correr el software, (•) componentes reusables disponibles, (•) consideraciones de instalación, (•) sistemas legados, (•) requisitos no funcionales;

• es una vista de todo el diseño en que las características im-portantes se hacen más visibles dejando de lado los detalles.

El valor de la arquitectura depende del arquitecto, pero la existencia de un proceso ayuda al arquitecto a enfocarse en los objetivos correctos:

(•) inteligibilidad, (•) adaptabilidad, (•) reusabilidad.

10

Todo producto (de software) tiene función (casos de uso) y forma (arquitecura):

• una u otra por sí sola no es suficiente; • deben ser balanceadas para crear un producto exitoso; • es necesario que se influyan mutuamente — problema del

huevo y la gallina — y que evolucionen en paralelo; • los casos de uso, una vez realizados, deben calzar en la

arquitectura; • la arquitectura debe permitir las realizaciones de todos los

casos de uso, ahora y en el futuro. La arquitecura de un sistema — la forma que le da el arquitecto — debe permitir su evolución. El arquitecto trabaja a partir de una comprensión general de las funciones claves — los casos de uso claves (p.ej., el 10% más significativo, que forma el núcleo de las funciones del sistema):

• primero crea un esbozo de la arquitectura, comenzando con aquellas partes que no son específicas a los casos de uso;

• luego trabaja con los casos de uso claves, los especifica en detalle y los realiza en términos de subsistemas, clases, y componentes;

• finalmente, a medida que los casos de uso se especifican y maduran, se descubre más de la arquitecura, lo que a su vez ayuda a la maduración de más casos de uso;

• este proceso continúa hasta que la arquitectura es considerada estable.

11

UN PROCESO ITERATIVO E INCREMENTAL El desarrollo de un producto de software puede durar meses o años; conviene dividir el trabajo en miniproyectos:

• cada miniproyecto es una iteración que resulta en un incremento;

• las iteraciones son los pasos en el flujo de trabajo, y deben ser controladas — elegidas y ejecutadas planificadamente;

• los incrementos se refieren al crecimiento del producto. Los desarrolladores eligen qué se va a implementar en una iteración, tomando en cuenta que cada iteración lidia con:

• un grupo de casos de uso que en conjunto extienden la usabilidad vigente del producto; y

• los riesgos más importantes. En cada iteración, los desarrolladores:

• identifican y especifican los casos de uso relevantes; • crean un diseño a partir de la arquitectura elegida; • implementan el diseño en componentes; y • verifican que las componentes satisfacen los casos de uso.

Si una iteración

• satisface sus objetivos — lo que ocurre normalmente — el desarrollo prosigue con la próxima iteración;

• no satisface sus objetivos, hay que revisar decisiones anteriores e intentar un nuevo enfoque.

12

Para economizar durante el desarrollo, el equipo debe: • seleccionar sólo las iteraciones requeridas para alcanzar el

objetivo del proyecto; • secuenciar las iteraciones en un orden lógico; • proceder a lo largo de un curso bien establecido, permitiendo

sólo pequeñas desviaciones. Si aparecen imprevistos que agregan iteraciones o alteran su secuencia, el proceso tomará más esfuerzo y tiempo. Uno de los objetivos de la reducción de riesgos es minimizar los imprevistos.

13

Beneficios de un proceso iterativo controlado: • Reduce el riesgo del costo a los gastos hechos en un

incremento – Si hay que repetir la iteración, perdemos sólo el esfuerzo

de esa iteración, no el valor de todo el producto. • Reduce el riesgo de no terminar el producto en el plazo

planificado: – Cuando los problemas difíciles aparecen durante las

pruebas del sistema, el tiempo necesario para resolverlos excede al tiempo que queda, retrasando la entrega.

– Al identificar los riesgos al comienzo del desarrollo, el tiempo empleado en resolverlos transcurre cuando la gente está menos apurada

• Apura el ritmo del esfuerzo de desarrollo

– Los desarrolladores trabajan más eficientemente hacia resultados precisos y de corto plazo que dentro de planificaciones a largo plazo que no se cumplen.

• Acepta una realidad a menudo ignorada:

– Las necesidades del usuario y los requisitos correspon-dientes no pueden definirse totalmente al principio.

– Los requisitos típicamente son refinados en iteraciones sucesivas — este enfoque facilita la adaptación a requisitos cambiantes.

14

LA VIDA DEL PROCESO UNIFICADO INTRODUCCIÓN. Hemos presentado los tres conceptos claves — dirigido por casos de uso, centrado en la arquitectura, e iterativo e incremental; ahora miremos al proceso en su totalidad:

• ciclos de vida • artefactos • flujos de trabajo

• fases • iteraciones

El RUP se repite en una serie de ciclos que constituyen la vida de un sistema; cada ciclo:

• termina con la entrega de un producto al cliente; • consiste en 4 fases: inicio, elaboración, construcción, y

transición, cada una subdividida en iteraciones. nacimiento muerte

… …

Los ciclos concluyen con un release

Inicio Elaboración Construcción Transición

iter.1 iter.2 iter.n

releases

15

EL PRODUCTO. El resultado de cada ciclo es un nuevo producto listo para entregar:

• código fuente — componentes compilables y ejecutables; • manuales.

El producto terminado, sin embargo, debe

• acomodar las necesidades de todos los interesados — clientes, usuarios, analistas, diseñadores, implementado-res, encargados de pruebas, y gerencia;

• incluir (•) requisitos, (•) casos de uso, (•) especificaciones no funcionales, (•) casos de prueba, (•) arquitectura, y (•) modelos visuales (en UML) — en conjunto, permiten a los interesados usar y modificar el sistema.

Para llevar a cabo el próximo ciclo, los componentes ejecutables no son suficientes:

• cambia el entorno — sistema operativo, base de datos, arquitectura de hardware;

• cambian los requisitos.

16

Los desarrolladores necesitan todas las representaciones: • modelo de casos de uso — todos los casos de uso, sus

relaciones con los usuarios; • modelo de análisis — refina los casos de uso, asigna

inicialmente el comportamiento del sistema a un conjunto de objetos que proporciona tal comportamiento;

• modelo de diseño — estructura estática del sistema en términos de subsistemas, clases, e interfaces, y casos de uso realizados como colaboraciones entre subsistemas, clases, e interfaces;

• modelo de implementación — componentes (código fuente), correspondencia entre clases y componentes;

• modelo de instalación — nodos físicos (computadores), correspondencia entre componentes y nodos;

• modelo de pruebas — casos de prueba que verifican los casos de uso; y

• por supuesto, una representación de la arquitectura. También puede haber un modelo del dominio o del negocio que describe el contexto del sistema. Todos estos modelos están relacionados:

• en conjunto, representan la totalidad del sistema; • los elementos en un modelo tienen dependencias —

rastros — hacia atrás y hacia adelante mediante vínculos a otros modelos.

17

LAS FASES EN UN CICLO. Cada ciclo transcurre en el tiempo y está dividido en 4 fases — inicio, elaboración, construcción, y transición :

• Visualizamos lo que pasa en estas fases a través de una secuencia de modelos.

• En cada fase el trabajo se descompone en iteraciones e incrementos.

• Cada fase termina en un hito – un conjunto de artefactos está disponible – ciertos modelos o documentos han alcanzado un

estado preestablecido. Los hitos sirven para varios propósitos:

• Los gerentes tienen que tomar ciertas decisiones antes que el trabajo pueda proseguir a la siguiente fase.

• Gerentes y desarrolladores pueden supervisar el progreso del trabajo cuando se pasa por estos 4 puntos claves.

• Al medir el esfuerzo y el tiempo gastados en cada fase, desarrollamos un conjunto de datos útiles para:

– estimar las necesidades de tiempo y personal para otros proyectos

– proyectar las necesidades de personal a lo largo de los proyectos

– controlar progresos a partir de estas proyecciones.

18

Fase de inicio:

• Una buena idea es convertida en una visión del producto final, para el cual se elabora el caso de negocio.

• Contesta las preguntas: – ¿Qué va a hacer el sistema para cada usuario? – ¿Cómo sería una arquitectura para ese sistema? – ¿Cuál es el plan y cuánto costará desarrollar el producto?

• Se construye un modelo de casos de uso simplificado, sólo con los casos más críticos.

• La arquitectura es tentativa — un esbozo con los subsistemas cruciales.

• Se identifica y prioriza los riesgos más importantes.

• Se planifica la fase de elaboración en detalle.

• Se hace una estimación aproximada de todo el proyecto.

19

Fase de elaboración:

• Se especifica en detalle la mayoría de los casos de uso del producto

• Se realiza los casos de uso más críticos.

• Se diseña la arquitectura del sistema — vistas de todos los modelos: casos de uso, análisis, diseño, etc.

• La vista del modelo de implementación incluye componentes para demostrar que la arquitectura es ejecutable.

• El resultado de la fase es una fundación arquitectónica.

• Al finalizar la fase, se puede planificar las actividades y estimar los recursos necesarios para completar el proyecto.

• La pregunta es ¿son los casos de uso, la arquitectura y los planes suficien-temente estables y están los riesgos suficientemente bajo control para comprometerse a todo el trabajo de desarrollo en un contrato?

20

Fase de construcción:

• Se construye el producto — queda listo para ser transferido a la comunidad de usuarios.

• La fundación arquitectónica crece y se convierte en un sistema completo.

• Se gasta la mayor parte de los recursos necesarios.

• Al finalizar la fase, el producto contiene todos los casos de uso que la gerencia y el cliente acordaron desarrollar para este release.

• El producto aún puede contener defectos que serán corregidos durante la fase de transición.

• La pregunta es ¿satisface el producto las necesidades de los usuarios suficientemente como para entregarlo a algunos clientes?

21

Fase de transición:

• El producto pasa a una versión β que es puesta a prueba por unos pocos usuarios experimentados

• Los desarrolladores – corrigen los problemas informados – incorporan las mejoras sugeridas

en un release general para la comunidad de usuarios.

• Incluye – manufacturación – capacitación del personal del cliente – habilitación de ayuda en línea – corrección de defectos encontrados después de la

entrega.

• Los defectos pueden ser divididos en dos categorías: – los que, por sus efectos sobre las operaciones, justifican

un release delta inmediato; y – los que pueden ser corregidos en el próximo release

regular.

22

FLUJOS DE TRABAJO INTRODUCCIÓN. En cada fase y en cada iteración se lleva a cabo los siguientes 9 flujos de trabajo:

• Modelamiento del Negocio

• Requisitos

• Análisis & Diseño

• Implementación

• Pruebas

• Instalación

• Gestión de Configuración y Cambios

• Gestión del Proyecto

• Entorno

Flujos Inicio Elaboración Construcción Transición

Model.

Requis.

A&D

Implem.

Test

Instal.

C&CM

Gestión

Entorno

Inicial iter.n

23

MODELAMIENTO DEL NEGOCIO. Un paso opcional; sus objetivos son:

• Entender la estructura y dinámica de la organización. • Asegurar que clientes, usuarios, y desarrolladores tengan un

entendimiento común de la organización. • Derivar requisitos de sistemas para apoyar la organización.

Para lograr estos objetivos, es necesario desarrollar:

• un modelo de casos de uso del negocio, • un modelo de objetos del negocio, • una Especificación Suplementaria del Negocio, • un Glosario.

Participan:

• Analista del Proceso de Negocio: (•) captura vocabulario común; (•) determina actores y casos de uso; (•) estructura el modelo de casos de uso del negocio

• Diseñador del Negocio: (•) detalla caso de uso del negocio; (•) determina y detalla ejecutantes y entidades del negocio

• Revisor del Modelo del Negocio: (•) revisa los modelos

24

REQUISITOS. Sus objetivos son: • Llegar a un acuerdo con los clientes y usuarios acerca de qué

debería hacer el sistema. • Proporcionar a los desarrolladores del sistema un mejor

entendimiento del sistema. • Delimitar el sistema. • Proporcionar una base para planificar el contenido técnico de

las iteraciones. • Definir una interfaz de usuario para el sistema.

Para lograrlos, se desarrolla los siguientes documentos:

• Visión • Necesidades de Interesados

• Modelo de casos de uso • Especificación Suplementaria

• Glosario • Clase de delimitación • Prototipo de la interfaz de usuario

Participan:

• Analista de Sistema: (•) desarrolla visión, (•) extrae necesidades de interesados, (•) maneja dependencias, (•) captura vocabulario común, (•) determina actores y casos de uso, (•) estructura modelo de casos de uso

• Especificador de Casos de Uso: (•) detalla casos de uso • Diseñador de Interfaz de Usuario: (•) modela y construye

prototipo de interfaz de usuario • Arquitecto: (•) prioriza casos de uso • Revisor de Requisitos: (•) revisa requisitos

25

ANÁLISIS Y DISEÑO. Sus objetivos son: • Transformar los requisitos en un diseño del futuro sistema. • Desarrollar una arquitectura robusta para el sistema. • Adaptar el diseño al entorno de implementación.

Los artefactos principales son:

• Modelo de Diseño — realizaciones de casos de uso, clases, paquetes/subsistemas de diseño

• Documento de Arquitectura de Software • Modelo de datos

Participan:

• Arquitecto: (•) análisis y diseño arquitectónicos, (•) describe concurrencia y distribución

• Diseñador: (•) análisis de casos de uso, (•) diseño de subsistemas, clases, y casos de uso

• Diseñador de Base de Datos: (•) diseña base de datos • Revisor de Arquitectura: (•) revisa arquitectura • Revisor de Diseño: (•) revisa diseño

26

IMPLEMENTACIÓN. Sus objetivos son: • Definir la organización del código, en términos de

subsistemas y estratos o niveles. • Implementar clases y objetos en términos de componen-tes

(archivos fuentes, binarios, ejecutables, otros). • Probar individualmente las componentes desarrolladas. • Integrar los resultados, producidos por individuos o equipos

de implementadores, para formar un sistema ejecutable. Sus artefactos principales son:

• Modelo de Implementación — define componentes y subsistemas.

• Plan de Integración. Participan:

• Arquitecto: (•) estructura el modelo de implementación • Integrador de Sistemas: (•) planifica y realiza la integración

del sistema • Implementador: (•) planifica y realiza la integración de

subsistemas, (•) implementa clases, (•) realiza pruebas unitarias, (•) corrige defectos

• Revisor de Código: (•) revisa el código

27

PRUEBAS. Calidad es más que satisfacer los requisitos, o las necesidades y expectativas de los usuarios. El PROCESO UNIFICADO define calidad como la característica de haber demostrado el logro de producir un producto que:

• satisface o supera requisitos acordados, según mediciones hechas de acuerdo con medidas y criterios acordados, y

• es producido siguiendo un proceso acordado. Probar software:

• es muy difícil, y • típicamente se hace sin una metodología clara y sin la

automatización o el apoyo de herramientas necesario. Los problemas son 100 a 1000 veces más caros de encontrar y corregir después de la instalación; es importante:

• comenzar a hacer pruebas tempranamente; • evaluar continuamente la calidad del sistema con res-pecto a

su funcionalidad, confiabilidad, y desempeño; y • estructurar el plan de desarrollo de modo que permita

verificar decisiones arquitectónicas desde las primeras iteraciones.

28

El desarrollo iterativo permite hacer pruebas continuamente: • cada iteración produce un release ejecutable; • el release es integrado y probado exhaustivamente dentro de

la iteración en que es producido, contra los requisitos abordados en esa iteración;

• a medida que el desarrollo avanza a través de varias iteraciones, más partes del sistema se completan, integran, y prueban al final de cada iteración;

• al terminar la última iteración, toda la funcionalidad está en su lugar y el sistema completo se prueba como un todo;

• muchos errores se encuentran temprano en el ciclo de vida, cuando son mucho menos caros de corregir;

• como las primeras iteraciones se enfocan en validar decisiones arquitectónicas — la más caras de cambiar — solucionamos temprano los problemas más caros.

La realización continua de pruebas es ideal pero exige contar con herramientas automáticas; en un caso real:

13,000 pruebas en 2 semanas, 6 personas

versus 13,000 pruebas en 6 horas, una persona.

aspecto ¿por qué? ¿cómo?

Funcionalidad ¿hace lo que se necesita?

Casos de prueba para cada escenario

Confiabilidad ¿tiene problemas de memoria?

Herramientas de análisis, instrumentalizar el código

Desempeño de la aplicación

¿Responde aceptablemente?

Verificar desempeño para cada escenario

Desempeño del sistema

¿puede trabajar bajo carga real?

Probar desempeño para todos los casos de uso

29

Los objetivos del flujo de trabajo Pruebas son: • Verificar la interacción entre objetos. • Verificar la integración de todas las componentes. • Verificar que todos los requisitos han sido implementados

correctamente. • Identificar los defectos y asegurarse que sean abordados con

anterioridad a la instalación del software. Sus principales artefactos son:

• Modelo de pruebas — define casos, procedimientos, y guiones de pruebas

• Plan de pruebas • Defectos • Paquetes, clases, subsistemas, y componentes para pruebas

Participan:

• Diseñador de Pruebas: (•) planifica, diseña, implementa, y evalúa las pruebas

• Verificador de Integración: (•) ejecuta pruebas de integración • Verificador de Sistema: (•) ejecuta pruebas del sistema • Verificador de Desempeño: (•) ejecuta pruebas de

desempeño • Diseñador: (•) diseña clases y paquetes de pruebas • Implementador: (•) implementa componentes y subsistemas

de pruebas

30

GESTIÓN DEL PROYECTO. Sus objetivos son: • Proporcionar un marco de referencia para gestionar

proyectos intensivos en software. • Proporcionar pautas prácticas para planificar, asignar

personal, ejecutar, y supervisar proyectos. • Proporcionar un marco de referencia para manejar riesgos.

El Gerente del Proyecto es responsable por los siguientes artefactos:

• el caso del negocio • el plan de iteraciones • la evaluación de las iteraciones • evaluaciones de situación

Participa:

• Gerente de Proyecto: (•) desarrolla caso de negocio, (•) identifica riesgos, (•) desarrolla plan del proyecto, (•) asigna personal al proyecto, (•) desarrolla y ejecuta plan de iteraciones, (•) revisa riesgos, (•) evalúa iteraciones

31

GESTIÓN DE CAMBIOS Y CONFIGURACIÓN. No podemos impe-dir que se introduzcan cambios en un proyecto, pero debe-mos controlar cómo y cuándo se introducen y por quién.

múltiples desarrolladores organizados en diferentes equi-pos localizados en diferentes sitios, trabajando juntos en múltiples iteraciones, releases, proyectos, y plataformas.

Problemas típicos:

• actualizaciones simultáneas — cuando dos o más ejecu-tantes modifican el mismo artefacto por separado, el último en hacer cambios destruye el trabajo del primero

• notificaciones incompletas — al corregir un problema en artefactos compartidos, algunos de sus usuarios no son informados

• versiones múltiples — y simultáneas de un artefacto en diferentes estados de desarrollo, debido al desarrollo iterativo

Sin un control disciplinado, el proceso de desarrollo se vuelve rápidamente un caos. Un Sistema de CM es el conjunto de métodos, procesos, y herramientas usados para administrar los cambios y las configuraciones:

• mantiene información clave sobre los procesos de desa-rrollo, instalación, y mantenimiento de los productos;

• forma una base de artefactos potencialmente reusables resultantes de la ejecución de estos procesos.

32

Los componentes principales de un Sistema de CM son:

• Gestión de Solicitudes de Cambios — aborda la infraestructura organizacional necesaria para evaluar los impactos en costo y tiempo de un cambio solicitado para un producto existente.

• Gestión de la Configuración — – describe la estructura de los productos de software e

identifica los ítems de configuración que la conforman (considerados entidades individuales sometidas a versiones en el proceso de CM);

– define configuraciones, construye e identifica, y colecciona artefactos (sometidos a versiones) en conjuntos que conforman configuraciones, y mantiene un seguimiento entre sus versiones.

• Mediciones — describe el estado de un producto a base del tipo, número, tasa, y seriedad de los defectos encontrados o corregidos durante el desarrollo.

33

Conceptos de la gestión de cambios y configuración; hay que:

• Descomponer la arquitectura en subsistemas y asignar la responsabilidad de cada subsistema a un equipo.

• Establecer espacios de trabajo seguros para cada desarrollador, que:

– lo aislan de los cambios hechos en otros espacios de trabajo, y

– controlan todos los artefactos de software — requisitos, modelos, códigos, etc.

• Establecer un espacio de trabajo para integración.

• Establecer un mecanismo obligatorio de control de cambios.

• Priorizar las solicitudes de cambios, evaluar sus impactos, y establecer un plan para introducirlos en una iteración y release particular.

• Supervisar las tasas de ocurrencias de los cambios — requisitos inestables, interfaces inestables de componentes, trabajo que hay que rehacer por cada reparación de un defecto.

• Saber qué cambios aparecen en cuáles releases.

• Poder identificar la versión particular de cada artefacto al que aplican informes de problemas o solicitudes de mejoras.

• Liberar una baseline probada al término de cada iteración, con la información necesaria para poder determinar exactamente qué contiene un release.

34

Un Sistema de CM permite: • manejar múltiples variantes de sistemas de software en

evolución, • saber cuáles versiones son usadas en determinados armados

de software, • producir armados de programas individuales o de releases

completos según especificaciones de versión definidas por los usuarios, y

• hacer cumplir políticas de desarrollo específicas. Algunos beneficios directos de un Sistema de CM son:

• permite el empleo de métodos de desarrollo, • mantiene la integridad y asegura la compleción y corrección

del producto, • proporciona un entorno estable en el cual desarrollar el

producto, • restringe los cambios a los artefactos según las políticas del

proyecto, y • proporciona información acerca de por qué, cuándo, y por

quién se hizo modificaciones a un artefacto, y • almacena información acerca del propio proceso.

35

Participan: • Gerente de Proyecto: (•) establece proceso para cambios

de productos, (•) define información de status y requisitos para línea base

• Arquitecto: (•) estructura modelo de implementación • Gerente de CM: (•) escribe plan de CM, (•) • Integrador de Sistema: (•) crea espacios de trabajo para

integración, (•) construye producto • otros: (•) crean espacios de trabajo privados, (•) chequean

artefactos in/out

36

ENTORNO: • Configuración del proceso — adaptar el PROCESO UNIFICADO

a las necesidades de una organización o proyecto • Mejoramiento del proceso — hacer evolucionar el proceso a

base de las lecciones aprendidas a medida que un proyecto se lleva a cabo

• Selección y adquisición de herramientas • Fabricación de herramientas — para (•) apoyar necesi-dades

especiales, (•) proporcionar automatización de tareas tediosas o propensas a errores, y (•) proporcionar mejor integración entre herramientas

• Apoyo al desarrollo — (•) mantenimiento del entorno de desarrollo, (•) administración del sistema, (•) telecomuni-caciones, y (•) creación y reproducción de documentos

• Capacitación

37