EL PROCESO UNIFICADO (RUP) DE DESARROLLO DE SOFTWARE

INTRODUCCIN
La comunidad de desarrollo de software necesita una forma controlada de trabajar, un proceso que: proporcione una gua 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 cundo; ofrezca criterios para supervisar y medir los productos y actividades del proyecto.

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; ms que un proceso individual un armazn genrico para procesos que puede ser especializado para una clase grande de sistemas de software, para diferentes dominios de aplicacin, tipos de organizaciones, niveles de competencia, y tamaos de proyectos. Adems, 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 caractersticas ms 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.

LAS MEJORES PRCTICAS DE INGENIERA DE SOFTWARE

ACTIVIDAD DE EQUIPOS. Debido al tamao 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 desempeo ingenieros de instalacin.

Estos equipos presentan desafos de comunicacin. las tecnologas ms complejas requieren expertos especializados en slo 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 tecnologas construidas por cada especialista se integren para producir un sistema exitoso; la velocidad de los cambios tecnolgicos sigue aumentando y muchas tecnologas son usadas antes de haber sido probadas.

SNTOMAS. Cmo nos va? muchos proyectos de software son exitosos a pesar de los problemas lo demuestran los muchsimos sistemas de los que dependemos a diario nuestra tasa de fallas es an demasiado alta necesitamos cambiar nuestras prcticas. Producir software de buena calidad y a tiempo es muy desafiante, debiendo superarse innumerables problemas. stos son a menudo reconocidos primero por sus sntomas: Entendimiento inexacto de las necesidades del usuario Incapacidad para manejar requisitos cambiantes Mdulos que no calzan unos con otros Software que es difcil de mantener o extender Descubrimiento tardo de fallas serias en el proyecto La calidad del software es pobre El desempeo del software es inaceptable Los miembros del equipo se entorpecen unos a otros, y son incapaces de reconstruir quin cambi qu, cundo, dnde, y por qu Un proceso de construccin-y-entrega no confiable

CAUSAS. Tratar los sntomas no cura la enfermedad: p.ej., el descubrimiento tardo de fallas serias en el proyecto es slo un sntoma de un problema ms grande realizacin 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. Races de los problemas: Insuficiente gestin de requisitos Comunicacione ambiguas Arquitecturas frgiles Complejidad abrumadora Inconsistencias no detectadas entre requisitos, diseos, e implementaciones Insuficientes pruebas Evaluacin subjetiva del estado del proyecto Reduccin de riesgos atrasada debido al desarrollo en cascada Propagacin incontrolada de cambios Insuficiente automatizacin Hay que tratar estas causas para eliminar los sntomas. Eliminando los sntomas uno est en mucho mejor posicin para construir software de calidad de manera predecible y repetible.

LAS MEJORES PRCTICAS: un conjunto de enfoques para desarrollo de software probados comercialmente que, cuando se usan combinadamente, atacan las races 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 prcticas de la ingeniera 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 prcticas se refuerzan unas a otras: el total es mucho ms grande que la suma de las partes; en algunos casos, adems, unas prcticas facilitan otras.

P.ej., el desarrollo iterativo mejora la gestin de requisitos asegura que los usuarios se involucran a medida que los requisitos evolucionan el uso de arquitecturas de componentes valida tempranamente las decisiones arquitectnicas el modelamiento visual aborda incrementalmente la complejidad del diseo e implementacin la verificacin de la calidad mide la calidad tempranamente y a menudo el control de cambios hace evolucionar incrementalmente las lneas bases Pero adems, el desarrollo iterativo podra fcilmente no converger sin una adecuada gestin de requisitos: los requisitos cambian a discresin, los usuarios no se ponen de acuerdo, y las iteraciones siguen para siempre. En cambio, con gestin 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.

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 slo personas, tambin otros sistemas que interactan con el sistema desarrollado. P.ej., una interaccin es una persona que usa un cajero automtico: l (o ella) inserta la tarjeta, contesta las preguntas hechas por el sistema a travs 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 interaccin 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 descripcin de la funcionalidad completa del sistema reemplazando a la tradicional especificacin funcional. La especificacin funcional tradicional contesta la pregunta qu se supone que hace el sistema?

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 slo en funciones que sera bueno tener. Los casos de uso, adems, dirigen el proceso de desarrollo el diseo, la implementacin, y las pruebas del sistema: a partir del modelo de casos de uso, los desarrolladores crean una serie de modelos de diseo e implementacin 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 implementacin para asegurarse que los componentes del modelo de implementacin implementan correctamente los casos de uso. Dirigido por casos de uso significa que el desarrollo sigue un flujo avanza a travs de una serie de flujos de trabajo derivados de los casos de uso: los casos de uso se especifican; los casos de uso se disean; 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 colaboracin recproca con la arquitectura del sistema ambos maduran a medida que avanza el ciclo de vida.

UN PROCESO CENTRADO EN LA ARQUITECTURA

El rol de la arquitectura en la construccin de edificios: el edificio es visto desde distintos puntos de vista: estructura, servicios, conductos para calefaccin, caeras de agua, electricidad, etc. esto permite al constructor tener un cuadro completo antes de que comience la construccin. La arquitectura en un sistema de software consiste en las diferentes vistas del sistema en construccin: incluye los aspectos estticos y dinmicos ms 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 instalacin, () sistemas legados, () requisitos no funcionales; es una vista de todo el diseo en que las caractersticas importantes se hacen ms 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 funcin (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 evolucin. El arquitecto trabaja a partir de una comprensin general de las funciones claves los casos de uso claves (p.ej., el 10% ms significativo, que forma el ncleo de las funciones del sistema): primero crea un esbozo de la arquitectura, comenzando con aquellas partes que no son especficas a los casos de uso; luego trabaja con los casos de uso claves, los especifica en detalle y los realiza en trminos de subsistemas, clases, y componentes; finalmente, a medida que los casos de uso se especifican y maduran, se descubre ms de la arquitecura, lo que a su vez ayuda a la maduracin de ms casos de uso; este proceso contina hasta que la arquitectura es considerada estable.

11

UN PROCESO ITERATIVO E INCREMENTAL

El desarrollo de un producto de software puede durar meses o aos; conviene dividir el trabajo en miniproyectos: cada miniproyecto es una iteracin 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 iteracin, tomando en cuenta que cada iteracin lidia con: un grupo de casos de uso que en conjunto extienden la usabilidad vigente del producto; y los riesgos ms importantes. En cada iteracin, los desarrolladores: identifican y especifican los casos de uso relevantes; crean un diseo a partir de la arquitectura elegida; implementan el diseo en componentes; y verifican que las componentes satisfacen los casos de uso. Si una iteracin satisface sus objetivos lo que ocurre normalmente el desarrollo prosigue con la prxima iteracin; no satisface sus objetivos, hay que revisar decisiones anteriores e intentar un nuevo enfoque.

12

Para economizar durante el desarrollo, el equipo debe: seleccionar slo las iteraciones requeridas para alcanzar el objetivo del proyecto; secuenciar las iteraciones en un orden lgico; proceder a lo largo de un curso bien establecido, permitiendo slo pequeas desviaciones. Si aparecen imprevistos que agregan iteraciones o alteran su secuencia, el proceso tomar ms esfuerzo y tiempo. Uno de los objetivos de la reduccin 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 iteracin, perdemos slo el esfuerzo de esa iteracin, no el valor de todo el producto. Reduce el riesgo de no terminar el producto en el plazo planificado: Cuando los problemas difciles 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 ms 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 correspondientes no pueden definirse totalmente al principio. Los requisitos tpicamente son refinados en iteraciones sucesivas este enfoque facilita la adaptacin a requisitos cambiantes.

14

LA VIDA DEL PROCESO UNIFICADO

INTRODUCCIN. 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 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, elaboracin, construccin, y transicin, cada una subdividida en iteraciones.
nacimiento muerte

fases iteraciones

Los ciclos concluyen con un release

Inicio iter.1 iter.2

Elaboracin

Construccin

Transicin iter.n

releases

15

EL PRODUCTO. El resultado de cada ciclo es un nuevo producto listo para entregar: cdigo fuente componentes compilables y ejecutables; manuales. El producto terminado, sin embargo, debe acomodar las necesidades de todos los interesados clientes, usuarios, analistas, diseadores, implementadores, 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 prximo 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 anlisis refina los casos de uso, asigna inicialmente el comportamiento del sistema a un conjunto de objetos que proporciona tal comportamiento; modelo de diseo estructura esttica del sistema en trminos de subsistemas, clases, e interfaces, y casos de uso realizados como colaboraciones entre subsistemas, clases, e interfaces; modelo de implementacin componentes (cdigo fuente), correspondencia entre clases y componentes; modelo de instalacin nodos fsicos (computadores), correspondencia entre componentes y nodos; modelo de pruebas casos de prueba que verifican los casos de uso; y por supuesto, una representacin de la arquitectura. Tambin puede haber un modelo del dominio o del negocio que describe el contexto del sistema. Todos estos modelos estn relacionados: en conjunto, representan la totalidad del sistema; los elementos en un modelo tienen dependencias rastros hacia atrs y hacia adelante mediante vnculos a otros modelos.

17

LAS FASES EN UN CICLO. Cada ciclo transcurre en el tiempo y est dividido en 4 fases inicio, elaboracin, construccin, y transicin : Visualizamos lo que pasa en estas fases a travs 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 propsitos: 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 visin del producto final, para el cual se elabora el caso de negocio. Contesta las preguntas: Qu va a hacer el sistema para cada usuario? Cmo sera una arquitectura para ese sistema? Cul es el plan y cunto costar desarrollar el producto? Se construye un modelo de casos de uso simplificado, slo con los casos ms crticos. La arquitectura es tentativa un esbozo con los subsistemas cruciales. Se identifica y prioriza los riesgos ms importantes. Se planifica la fase de elaboracin en detalle. Se hace una estimacin aproximada de todo el proyecto.

19

Fase de elaboracin: Se especifica en detalle la mayora de los casos de uso del producto Se realiza los casos de uso ms crticos. Se disea la arquitectura del sistema vistas de todos los modelos: casos de uso, anlisis, diseo, etc. La vista del modelo de implementacin incluye componentes para demostrar que la arquitectura es ejecutable. El resultado de la fase es una fundacin arquitectnica. 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 suficientemente estables y estn los riesgos suficientemente bajo control para comprometerse a todo el trabajo de desarrollo en un contrato?

20

Fase de construccin: Se construye el producto queda listo para ser transferido a la comunidad de usuarios. La fundacin arquitectnica 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 an puede contener defectos que sern corregidos durante la fase de transicin. La pregunta es satisface el producto las necesidades de los usuarios suficientemente como para entregarlo a algunos clientes?

21

Fase de transicin: El producto pasa a una versin 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 manufacturacin capacitacin del personal del cliente habilitacin de ayuda en lnea correccin de defectos encontrados despus de la entrega. Los defectos pueden ser divididos en dos categoras: los que, por sus efectos sobre las operaciones, justifican un release delta inmediato; y los que pueden ser corregidos en el prximo release regular.

22

FLUJOS DE TRABAJO
INTRODUCCIN. En cada fase y en cada iteracin se lleva a cabo los siguientes 9 flujos de trabajo: Modelamiento del Negocio Requisitos Anlisis & Diseo Implementacin Pruebas Instalacin Gestin de Configuracin y Cambios Gestin del Proyecto Entorno

Flujos Model. Requis. A&D Implem. Test Instal. C&CM Gestin Entorno

Inicio

Elaboracin

Construccin

Transicin

Inicial

iter.n

23

MODELAMIENTO DEL NEGOCIO. Un paso opcional; sus objetivos son: Entender la estructura y dinmica de la organizacin. Asegurar que clientes, usuarios, y desarrolladores tengan un entendimiento comn de la organizacin. Derivar requisitos de sistemas para apoyar la organizacin. Para lograr estos objetivos, es necesario desarrollar: un modelo de casos de uso del negocio, un modelo de objetos del negocio, una Especificacin Suplementaria del Negocio, un Glosario. Participan: Analista del Proceso de Negocio: () captura vocabulario comn; () determina actores y casos de uso; () estructura el modelo de casos de uso del negocio Diseador 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 debera hacer el sistema. Proporcionar a los desarrolladores del sistema un mejor entendimiento del sistema. Delimitar el sistema. Proporcionar una base para planificar el contenido tcnico de las iteraciones. Definir una interfaz de usuario para el sistema. Para lograrlos, se desarrolla los siguientes documentos: Visin Necesidades de Interesados Modelo de casos de uso Especificacin Suplementaria Participan: Analista de Sistema: () desarrolla visin, () extrae necesidades de interesados, () maneja dependencias, () captura vocabulario comn, () determina actores y casos de uso, () estructura modelo de casos de uso Especificador de Casos de Uso: () detalla casos de uso Diseador de Interfaz de Usuario: () modela y construye prototipo de interfaz de usuario Arquitecto: () prioriza casos de uso Revisor de Requisitos: () revisa requisitos Glosario Clase de delimitacin Prototipo de la interfaz de usuario

25

ANLISIS Y DISEO. Sus objetivos son: Transformar los requisitos en un diseo del futuro sistema. Desarrollar una arquitectura robusta para el sistema. Adaptar el diseo al entorno de implementacin. Los artefactos principales son: Modelo de Diseo realizaciones de casos de uso, clases, paquetes/subsistemas de diseo Documento de Arquitectura de Software Modelo de datos Participan: Arquitecto: () anlisis y diseo arquitectnicos, () describe concurrencia y distribucin Diseador: () anlisis de casos de uso, () diseo de subsistemas, clases, y casos de uso Diseador de Base de Datos: () disea base de datos Revisor de Arquitectura: () revisa arquitectura Revisor de Diseo: () revisa diseo

26

IMPLEMENTACIN. Sus objetivos son: Definir la organizacin del cdigo, en trminos de subsistemas y estratos o niveles. Implementar clases y objetos en trminos 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 Implementacin define componentes y subsistemas. Plan de Integracin. Participan: Arquitecto: () estructura el modelo de implementacin Integrador de Sistemas: () planifica y realiza la integracin del sistema Implementador: () planifica y realiza la integracin de subsistemas, () implementa clases, () realiza pruebas unitarias, () corrige defectos Revisor de Cdigo: () revisa el cdigo

27

PRUEBAS. Calidad es ms que satisfacer los requisitos, o las necesidades y expectativas de los usuarios. El PROCESO UNIFICADO define calidad como la caracterstica de haber demostrado el logro de producir un producto que: satisface o supera requisitos acordados, segn mediciones hechas de acuerdo con medidas y criterios acordados, y es producido siguiendo un proceso acordado. Probar software: es muy difcil, y tpicamente se hace sin una metodologa clara y sin la automatizacin o el apoyo de herramientas necesario. Los problemas son 100 a 1000 veces ms caros de encontrar y corregir despus de la instalacin; es importante: comenzar a hacer pruebas tempranamente; evaluar continuamente la calidad del sistema con res-pecto a su funcionalidad, confiabilidad, y desempeo; y estructurar el plan de desarrollo de modo que permita verificar decisiones arquitectnicas desde las primeras iteraciones.

28

El desarrollo iterativo permite hacer pruebas continuamente: cada iteracin produce un release ejecutable; el release es integrado y probado exhaustivamente dentro de la iteracin en que es producido, contra los requisitos abordados en esa iteracin; a medida que el desarrollo avanza a travs de varias iteraciones, ms partes del sistema se completan, integran, y prueban al final de cada iteracin; al terminar la ltima iteracin, 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 arquitectnicas la ms caras de cambiar solucionamos temprano los problemas ms caros. La realizacin continua de pruebas es ideal pero exige contar con herramientas automticas; en un caso real:
13,000 pruebas en 2 semanas, 6 personas versus 13,000 pruebas en 6 horas, una persona.

aspecto
Funcionalidad

por qu?

cmo?
Casos de prueba para cada escenario Herramientas de anlisis, instrumentalizar el cdigo Verificar desempeo para cada escenario Probar desempeo para todos los casos de uso

hace lo que se necesita? Confiabilidad tiene problemas de memoria? Desempeo de Responde la aplicacin aceptablemente? Desempeo puede trabajar bajo del sistema carga real?

29

Los objetivos del flujo de trabajo Pruebas son: Verificar la interaccin entre objetos. Verificar la integracin 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 instalacin 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: Diseador de Pruebas: () planifica, disea, implementa, y evala las pruebas Verificador de Integracin: () ejecuta pruebas de integracin Verificador de Sistema: () ejecuta pruebas del sistema Verificador de Desempeo: () ejecuta pruebas de desempeo Diseador: () disea clases y paquetes de pruebas Implementador: () implementa componentes y subsistemas de pruebas

30

GESTIN DEL PROYECTO. Sus objetivos son: Proporcionar un marco de referencia para gestionar proyectos intensivos en software. Proporcionar pautas prcticas 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 evaluacin de las iteraciones evaluaciones de situacin 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, () evala iteraciones

31

GESTIN DE CAMBIOS Y CONFIGURACIN. No podemos impe-dir que se introduzcan cambios en un proyecto, pero debe-mos controlar cmo y cundo se introducen y por quin. mltiples desarrolladores organizados en diferentes equi-pos localizados en diferentes sitios, trabajando juntos en mltiples iteraciones, releases, proyectos, y plataformas. Problemas tpicos: actualizaciones simultneas cuando dos o ms ejecutantes 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 mltiples y simultneas de un artefacto en diferentes estados de desarrollo, debido al desarrollo iterativo Sin un control disciplinado, el proceso de desarrollo se vuelve rpidamente un caos. Un Sistema de CM es el conjunto de mtodos, procesos, y herramientas usados para administrar los cambios y las configuraciones: mantiene informacin clave sobre los procesos de desa-rrollo, instalacin, y mantenimiento de los productos; forma una base de artefactos potencialmente reusables resultantes de la ejecucin de estos procesos.

32

Los componentes principales de un Sistema de CM son: Gestin 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. Gestin de la Configuracin describe la estructura de los productos de software e identifica los tems de configuracin 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, nmero, tasa, y seriedad de los defectos encontrados o corregidos durante el desarrollo.

33

Conceptos de la gestin de cambios y configuracin; 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, cdigos, etc. Establecer un espacio de trabajo para integracin. Establecer un mecanismo obligatorio de control de cambios. Priorizar las solicitudes de cambios, evaluar sus impactos, y establecer un plan para introducirlos en una iteracin y release particular. Supervisar las tasas de ocurrencias de los cambios requisitos inestables, interfaces inestables de componentes, trabajo que hay que rehacer por cada reparacin de un defecto. Saber qu cambios aparecen en cules releases. Poder identificar la versin particular de cada artefacto al que aplican informes de problemas o solicitudes de mejoras. Liberar una baseline probada al trmino de cada iteracin, con la informacin necesaria para poder determinar exactamente qu contiene un release.

34

Un Sistema de CM permite: manejar mltiples variantes de sistemas de software en evolucin, saber cules versiones son usadas en determinados armados de software, producir armados de programas individuales o de releases completos segn especificaciones de versin definidas por los usuarios, y hacer cumplir polticas de desarrollo especficas. Algunos beneficios directos de un Sistema de CM son: permite el empleo de mtodos de desarrollo, mantiene la integridad y asegura la complecin y correccin del producto, proporciona un entorno estable en el cual desarrollar el producto, restringe los cambios a los artefactos segn las polticas del proyecto, y proporciona informacin acerca de por qu, cundo, y por quin se hizo modificaciones a un artefacto, y almacena informacin acerca del propio proceso.

35

Participan: Gerente de Proyecto: () establece proceso para cambios de productos, () define informacin de status y requisitos para lnea base Arquitecto: () estructura modelo de implementacin Gerente de CM: () escribe plan de CM, () Integrador de Sistema: () crea espacios de trabajo para integracin, () construye producto otros: () crean espacios de trabajo privados, () chequean artefactos in/out

36

ENTORNO: Configuracin del proceso adaptar el PROCESO UNIFICADO a las necesidades de una organizacin o proyecto Mejoramiento del proceso hacer evolucionar el proceso a base de las lecciones aprendidas a medida que un proyecto se lleva a cabo Seleccin y adquisicin de herramientas Fabricacin de herramientas para () apoyar necesi-dades especiales, () proporcionar automatizacin de tareas tediosas o propensas a errores, y () proporcionar mejor integracin entre herramientas Apoyo al desarrollo () mantenimiento del entorno de desarrollo, () administracin del sistema, () telecomunicaciones, y () creacin y reproduccin de documentos Capacitacin

37