2

DESARROLLO ITERATIVO E INCREMENTAL

El desarrollo iterativo nicamente se debe utilizar en aquellos proyectos que se quiere que tengan xito (UML gota a gota de Martn Fowler) [Larman05].

2.1

LA ITERACIN Y EL INCREMENTO

El desarrollo iterativo e incremental es un enfoque para construir software (o cualquier cosa) en el cual todo el ciclo de vida est compuesto por varias iteraciones. Las iteraciones son pequeos proyectos compuestos de varias actividades cuyo objetivo es entregar una parte de un sistema parcialmente completo, probado, integrado y estable. Todo el software es integrado en cada entrega de cada iteracin hasta obtener el producto software completo en la ltima iteracin [Larman05].

La definicin de dicho enfoque se enmarca en lo qu es una iteracin, en la planificacin de la misma y en el concepto generado de incremento, los cuales se mencionan a continuacin.

2.1.1 La iteracin. Una iteracin es un mini proyecto que tiene como resultado una versin interna de cada uno de los artefactos que pueden ser generados en un proceso de desarrollo de software. Se puede visualizar como un flujo de trabajo [JBR00] compuesto por las actividades fundamentales del proceso (especificacin, anlisis, diseo, implementacin, etc.) adoptado por un equipo de desarrollo para utilizar y producir los artefactos en los que se puede dividir una solucin software.

El conjunto total e integrado de las iteraciones representar la versin externa del software, es decir, el producto final de cara al usuario; para llegar a ello, cada una de las iteraciones dentro del ciclo de vida del software cumplen diferentes objetivos. Las primeras iteraciones se centran en la compresin del problema y de la tecnologa, se preocupan por producir el anlisis del negocio, actividad o proceso que apoyar e integrar el producto. Luego se orientan las iteraciones a establecer las bases del diseo (arquitectura) que se robustecer a medida que fluye el ciclo de vida. Las iteraciones siguientes se concentrarn en la construccin e integracin de los componentes que se van generando producto de las mismas.

12

Aunque se describe un proceso secuencial de iteraciones no se debe entender un proceso iterativo como la divisin por partes de cada una de las fases del proceso cascada; una iteracin incluye su propia planificacin, su especificacin, su anlisis y otras actividades como diseo, implementacin o validacin (pruebas); puede entenderse mejor como un proceso compuesto por pequeas cascadas, donde cada iteracin se concentrar ms en una actividad que en las otras [Larman05].

2.1.2 Planificacin y secuenciacin de las iteraciones. Un ciclo de vida iterativo requiere ms planificacin y comprensin que un modelo en cascada [JBR00] donde toda su planificacin se realiza al principio y contiene mayor incertidumbre y falta de fidelidad para las fases siguientes en el proceso de desarrollo. En contraste, en el modelo iterativo no se planifica el proyecto durante el inicio, slo se dan los primeros pasos; no se intenta llevar a cabo la construccin sin establecer las bases de la planificacin en iteraciones previas. Cada planificacin de una iteracin tiene en cuenta los resultados de las iteraciones precedentes, la seleccin de la especificacin o funcionalidades a realizar y el estado actual del ciclo de vida del proceso, y termina con la preparacin de la versin interna.

La evolucin del software (proceso o producto) no sucede sin un plan que la preceda. Se pretende con la iteracin en el desarrollo de software, ordenar cada flujo de trabajo para obtener un camino directo en el cul las primeras iteraciones proporcionan la base de conocimiento para las siguientes. Estas iteraciones dan como resultado un mayor conocimiento de los requisitos, los problemas, los riesgos y el dominio de la solucin, mientras que las siguientes dan como resultado una serie de incrementos aditivos que conforman finalmente la versin externa, el producto final para el cliente. La secuencia de iteraciones, que siempre avance, representar el xito de la aplicacin del modelo, sin tener que volver nunca a los resultados de una iteracin previa para corregir el modelo debido a algo descubierto en una iteracin posterior.

Las iteraciones pueden solaparse en el tiempo, en el sentido que una est a punto de terminar cuando otra est comenzando. La planificacin para la siguiente iteracin debe comenzar a medida que se va terminando y preparando la entrega de la anterior. La entrega de una iteracin significa que se ha llegado finalmente a una conclusin dentro del equipo de trabajo, que se ha integrado todo el software de la iteracin y puede crearse la versin interna.

El objetivo principal de la planificacin de las iteraciones es realizar una secuenciacin del trabajo de manera que puedan desarrollarse primero las decisiones, especificaciones y funcionalidades ms importantes.

13

2.1.3 Qu es un incremento. Simplemente, el resultado de una iteracin es un incremento [JBR00]. Un incremento est representado en la diferencia entre la versin interna dada por una iteracin y la versin interna obtenida de la siguiente.

En un momento del ciclo iterativo (secuencia de iteraciones) algunos mdulos o subsistemas estarn terminados e integrados, contendrn toda la funcionalidad requerida y plasmada en los requisitos, estarn implementados, probados y validados; otros sistemas estarn parcialmente terminados y otros sin haberse iniciado. Un incremento se puede ver entonces como la diferencia entre dos momentos determinados en el ciclo de vida del proceso. Se van construyendo incrementos de manera iterativa, dando forma a cada unos de los subsistemas que representan el sistema final que ser visualizado cuando se realice la integracin del ltimo incremento.

2.1.4 Qu no es una iteracin. Un ciclo de vida iterativo no es un desarrollo aleatorio; no es algo que slo afecte a los desarrolladores; no es redisear una y otra vez hasta que los desarrolladores prueben que algo funciona; no es impredecible; no puede ser una excusa para fracasar en la planificacin y en la gestin [JBR00].

Una iteracin controlada se planifica y es una herramienta que pueden utilizar los directores de proyecto para controlarlo, y al principio del ciclo de vida, reduce los riesgos que pueden amenazar el progreso en el desarrollo. Las versiones internas proporcionadas por cada iteracin posibilitan la retroalimentacin de los usuarios y esto lleva a una correccin temprana de la trayectoria del proyecto.

2.2

EL PROCESO UNIFICADO DE DESARROLLO RUP

El proceso unificado de desarrollo RUP (Rational Unified Process) es el representante ms conocido del proceso iterativo e incremental. Su aplicacin, como su enseanza, es ampliamente difundida por organizaciones, empresas dedicadas al desarrollo de software, universidades y expertos en prcticas y procesos de ingeniera de software, entre otros, alrededor del mundo.

14

2.2.1 Orgenes. El antecedente ms importante en la historia de RUP se ubica en 1967 con la Metodologa Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximacin del desarrollo basado en componentes, que introdujo el concepto de Casos de uso. Entre los aos de 1987 a 1995 Jacobson fund la compaa Objectory AB y lanza el proceso de desarrollo Objectory (abreviacin de Object Factory). Posteriormente en 1995 la renombrada compaa Rational Software Corporation adquiere a Objectory AB y entre 1995 y 1997 desarrolla el proceso ROP (Rational Objectory Process) a partir del Objectory 3.8 y del enfoque metodolgico de Rational (Rational Approach) adoptando el lenguaje unificado UML [Larman05] como lenguaje de modelado. Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarroll e incorpor diversos elementos para expandir su ROP, destacndose especialmente el conocido modelado del negocio [Letelier02]. En junio del 1998 se lanza el RUP-Rational Unified Process, el conocido Proceso Unificado de Desarrollo propuesto por la Rational Corporation, hoy parte de IBM.

2.2.2 Caractersticas esenciales. Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres caractersticas esenciales: est dirigido por los Casos de uso, est centrado en la arquitectura, y es iterativo e incremental.

Proceso dirigido por Casos de uso. Los Casos de uso son una tcnica de modelado para la captura y representacin de requisitos que obliga a pensar en trminos de importancia para el usuario y no slo en trminos de funciones a contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor agregado. Los Casos de uso representan los requisitos funcionales del sistema.

En RUP los casos de uso no son slo una herramienta para especificar los requisitos del sistema; tambin guan su diseo, implementacin y prueba. Los casos de uso constituyen un elemento integrador y una gua de trabajo, que no slo inicia el proceso de desarrollo sino que tambin proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Basndose en los casos de uso, se crean los modelos de anlisis y diseo, luego la implementacin que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada caso de uso, haciendo que cada modelo est sincronizando con cada uno de ellos. Proceso centrado en la arquitectura. La arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes, lo que permite tener una visin comn entre todos los involucrados en el proceso (desarrolladores y usuarios) y una perspectiva ms clara del sistema completo, necesaria para controlar el desarrollo.

15

La arquitectura involucra los aspectos estticos y dinmicos ms significativos del sistema, est relacionada con la toma de decisiones que indica cmo tiene que ser construido el sistema y ayuda a determinar en qu orden. Adems la definicin de la arquitectura debe tomar en consideracin elementos de calidad del sistema, rendimiento, reutilizacin y capacidad de evolucin, por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, el sistema operativo, los gestores de base de datos y protocolos, entre otros aspectos tcnicos. Muchas de estas restricciones constituyen requisitos no funcionales del sistema.

En el caso de RUP, adems de utilizar los Casos de uso para guiar el proceso se presta especial atencin al temprano establecimiento de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores presentados durante la construccin y el mantenimiento. Existe una interaccin entre los Casos de uso y la arquitectura, los Casos de uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseo, por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayndose de los dems. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura, el cual recibe este nombre porque lo forman las vistas lgica, de implementacin, de proceso y de despliegue, ms la vista de Casos de uso que es la que da la afinidad a todas.

Un proceso iterativo e incremental. El equilibrio correcto entre los casos de uso y la arquitectura en el desarrollo slo se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes ms pequeas o mini proyectos, permitiendo que dicho equilibrio entre casos de uso y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el proceso de desarrollo, cada mini proyecto se puede ver como una iteracin (un recorrido ms o menos completo a lo largo de todos los flujos de trabajo, actividades fundamentales o disciplinas) de la cual se obtiene un incremento que produce un crecimiento en el producto software.

16

Una iteracin puede realizarse por medio de una cascada pasando por los flujos fundamentales de Requisitos, Anlisis, Diseo, Implementacin y Pruebas, como se muestra en la figura 2.1. Tambin existe una planeacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas propias de cada iteracin. Al finalizarla se realiza una integracin de los resultados con lo obtenido de realizar iteraciones anteriores [Letelier02].

Figura 2.1. Una iteracin RUP.

[Letelier02]

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteracin se analiza cuando termina; se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificacin de la siguiente iteracin, el equipo tambin examina cmo afectarn los riesgos que an quedan al trabajo en curso y toda la retroalimentacin de la iteracin pasada se utiliza para reajustar los objetivos de las siguientes iteraciones. Se contina con esta dinmica hasta que se haya finalizado por completo con una versin final del producto software. 2.2.3 Estructura general del proceso RUP. El proceso puede ser descrito en dos dimensiones o ejes como se ve en la figura 2.2:

17

FIG 2.2. Estructura del proceso RUP.

[Letelier02]

El eje horizontal representa la lnea del tiempo y es considerado el eje de los aspectos dinmicos del proceso. Indica las caractersticas del ciclo de vida del proceso, representado en fases (Inicio, Elaboracin, Construccin y Transicin), iteraciones e hitos.

Eje vertical representa los aspectos estticos del proceso. Describe el proceso en trminos de componentes de proceso, disciplinas o flujos de trabajo workflows, artefactos, roles y actividades.

2.2.3.1 Estructura dinmica del proceso. RUP divide el proceso en cuatro fases: Inicio, Elaboracin, Construccin y Transicin, dentro de las cuales se realizan varias iteraciones en un nmero variable, segn el proyecto, y en las que se hace un mayor o menor nfasis en las distintas disciplinas llamadas Workflows - Flujos de Trabajo. En la Figura 2.2 se muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto. Se observa que en cada fase participan todas las disciplinas, pero que dependiendo de la fase, el esfuerzo dedicado a una disciplina vara.

18

Las primeras iteraciones de las fases de Inicio y Elaboracin se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una lnea base para la arquitectura. Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en actividades modelado del negocio y de requisitos.

En la fase de Elaboracin, las iteraciones se orientan a la construccin de la lnea base de arquitectura, abarcan los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin.

La fase de Construccin se lleva a cabo por medio de una serie de iteraciones. Para cada iteracin se seleccionan algunos casos de uso, se refina su anlisis y diseo, y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones como se requieran, hasta que se termine la implementacin de una versin del producto.

En la fase de Transicin se pretende garantizar que se tiene un producto preparado para su entrega a los usuarios.

2.2.3.2 Estructura esttica del proceso. Un proceso de desarrollo de software define quin hace qu, cmo y cundo. RUP define cuatro elementos: los roles, las actividades, los productos (artefactos) y los flujos de trabajo o disciplinas que responden a cada una de estas preguntas.

Roles y Actividades. Una persona puede desempear diversos roles, as como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueo de un conjunto de artefactos. Una actividad en concreto es una unidad de trabajo que una persona desempea.

RUP define grupos de roles, agrupados por participacin en actividades relacionadas. Estos grupos son: Analistas: Analista de procesos de negocio, Diseador del negocio, Analista de sistema y Especificador de requisitos.

19

Desarrolladores: Arquitecto de software, Diseador, Diseador de interfaz de usuario, Diseador de base de datos, Implementador e Integrador. Gestores: Jefe de proyecto, Jefe de control de cambios, Jefe de configuracin, Jefe de pruebas, Jefe de despliegue, Ingeniero de procesos, Revisor de gestin del proyecto y Gestor de pruebas. Apoyo: Documentador tcnico, Administrador de sistema, Especialista en herramientas, Desarrollador de cursos y Artista grfico. Especialista en pruebas: Especialista en Pruebas (Tester), Analista de pruebas, Diseador de pruebas. Otros roles: Stakeholders (participantes), Revisor, Coordinador de revisiones y Revisor tcnico

Artefactos. Los productos o artefactos son los resultados tangibles del proyecto, las cosas que se van creando, modificado y usando hasta obtener el producto final durante el proceso de desarrollo de software. Un artefacto puede ser cualquiera de los siguientes: un documento, un modelo (como el de casos de uso), un elemento propio del modelo (una clase o un caso de uso), un subsistema o componente. Flujos de trabajo (Disciplinas). Con simplemente la enumeracin de roles, actividades y artefactos no se define un proceso, se necesita contar con una secuencia de actividades realizadas por los diferentes roles, as como la relacin entre los mismos. Un flujo de trabajo es una relacin de actividades que producen unos resultados observables, y en RUP son:

Modelado del negocio. Con esta disciplina se pretende llegar a un mejor entendimiento de la organizacin donde se va a implantar el producto (software).

Requisitos. Esta es una de las disciplinas ms importantes, porque en l se establece qu tiene que hacer exactamente el sistema a construir. En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que se especifiquen.

20

Anlisis y Diseo. El objetivo de este flujo es traducir los requisitos a una especificacin que describe cmo implementar el sistema, mediante su representacin a travs de los diferentes modelos UML definidos para las actividades de anlisis y diseo.

Implementacin. En ste flujo se implementan las clases y objetos, en cdigo fuente, binarios y ejecutables. Adems se deben hacer las pruebas de unidad: cada desarrollador es responsable de probar las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.

Pruebas. Este flujo de trabajo es el encargado de evaluar la calidad del producto que est siendo desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino para ir integrndolo en todo el ciclo de vida.

Despliegue. El objetivo de este flujo de trabajo es producir con xito entregables del producto y distribuirlos a los usuarios.

Gestin del proyecto. La gestin del proyecto es el arte de lograr un balance al administrar objetivos, riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios. Configuracin y control de cambios. El objetivo de sta disciplina es mantener la integridad de todos los artefactos que se crean en el proceso, as como de mantener informacin del proceso evolutivo que se ha seguido.

Entorno. La finalidad de ste flujo de trabajo es dar soporte al proyecto con las adecuadas herramientas, procesos y mtodos. Brinda una especificacin de las herramientas que se van a necesitar en cada momento, as como definir el instante concreto del proceso en el que han de ser empleados.

2.2.4 Prcticas. RUP identifica 6 mejores prcticas con las que define una forma efectiva de trabajar en equipos de desarrollo de software. Gestin de requisitos. RUP brinda una gua para encontrar, organizar, documentar, y seguir los cambios de los requisitos funcionales y sus restricciones. Utiliza la notacin de Caso de Uso y escenarios para representar los requisitos.

21

Desarrollo de software iterativo. Desarrollo del producto mediante iteraciones con hitos bien definidos, en las cuales se repiten las actividades pero con distinto nfasis, segn la fase del proyecto. Desarrollo basado en componentes. La creacin intensiva de sistemas en software requiere dividir cada sistema en componentes con interfaces bien definidas, que posteriormente sern ensamblados para generar el sistema. Esta caracterstica en un proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o se desarrollan sus componentes. Modelado visual (usando UML). UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema software. Utilizar herramientas de modelado visual facilita la gestin de dichos modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El modelado visual tambin ayuda a mantener la consistencia entre los artefactos del sistema: requisitos, diseos e implementaciones. El modelado visual ayuda a mejorar la capacidad del equipo para gestionar la complejidad del software. Verificacin contina de la calidad. Es importante que la calidad de todos los artefactos se evale varias veces durante el proceso de desarrollo, especialmente al final de cada iteracin. En esta verificacin las pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso. Para todos los artefactos, no necesariamente ejecutables, las revisiones e inspecciones deben ser continas. Gestin de los cambios. El cambio es un factor de riesgo crtico en los proyectos de software. Los artefactos software cambian no slo por acciones de mantenimiento posteriores a la entrega del producto, sino que durante el proceso de desarrollo aparecen nuevos cambios en los requisitos. Otro gran desafo que debe abordarse en la construccin de software es la participacin de mltiples desarrolladores trabajando a la vez en un mismo incremento y quizs en distintas plataformas. La ausencia de una disciplina, rpidamente conducira al caos. Las prcticas de Gestin de Cambios y de Configuracin es la disciplina que RUP encarga para este aspecto.

22