Calidad En Desarrollo De Software

Procesos de desarrollo: RUP, XP y FDD

Fecha de creación: 15.12.2002

Revisión 1.0 (15.2.2003)

Alberto Molpeceres

al AT javahispano DOT org

Copyright (c) 2002, Alberto Molpeceres. Este documento puede ser distribuido solo bajo los términos y condiciones de la licencia de Documentación de javaHispano v1.0 o posterior (la última versión se encuentra en http://www.javahispano.org/licencias/).

Introducción

El mundo de la informática no para de hablar de procesos de desarrollo, el modo de trabajar eficientemente para evitar catastrofes que llevan a que un gran porcentaje de proyectos se terminen sin éxito.

El objetivo de un proceso de desarrollo es subir la calidad del software (en todas las fases por las que pasa) a través de una mayor transparencia y control sobre el proceso. Da igual si es algo casero o para un cliente, hay que producir lo esperado en el tiempo esperado y con el coste esperado. Es labor del proceso de desarrollo hacer que esas medidas para aumentar la calidad sean reproducibles en cada desarrollo.

La implantación de un proceso de desarrollo es una labor más a medio-largo plazo que una labor de resultados inmediatos. Cuesta tiempo que los trabajadores se adapten al proceso, pero una vez superado la inversión se recupera con creces. Es por ello que no tiene sentido ajustarse a un proceso al pie de la letra, sino que hay que adaptarlo a las necesidades y caracteristicas de cada empresa, equipo de trabajo o casi a cada proyecto.

Es labor del jefe de desarrollo decidir cual es el que mejor se adapta a la situación concreta a la que se enfrenta para minimizar la inversión requerida y obtener los resultados esperados. Por ejemplo, ¿tenemos el conocimiento necesario?, ¿es el equipo abierto a posibles cambios?. Esta labor es difícil de llevar a cabo si no conocemos las exigencias de los procesos existentes. Para facilitar esa decisión, en este artículo describiremos y compareramos tres de los más famosos y conocidos procesos de desarrollo: Proceso Unificado de Rational, Rational Unified Process (RUP desde ahora), Programación Extrema, eXtreme Programming (XP desde ahora) y Desarrollo Guiado por la Funcionalidad Feature Driven Development (FDD desde ahora).

Lo que en ningún caso será este artículo es una guía exhaustiva de aplicación de ninguno de ellos, dejando para el lector interesado la profundización en cualquiera de ellos y su aplicacicación donde lo estime oportuno.

Procesos de desarrollo

En los últimos tiempos la cantidad y variedad de los procesos de desarrollo ha aumentado de forma impresionante, sobre todo teniendo en cuenta el tiempo que estuvo en vigor como ley única el famoso desarrollo en cascada. Se podría decir que en estos últimos años se han desarrollado dos corrientes en lo referente a los procesos de desarrollo, los llamados métodos pesados y los métodos ligeros. La diferencia fundamental entre ambos es que mientras lo métodos pesados intentan conseguir el objetivo común por medio de orden y documentación, los métodos ligeros (también llamados métodos ágiles) tratan de mejorar la calidad del software por medio de una comunicación directa e inmediata entre las personas que intervienen el el proceso.

En este artículo, como ya hemos dicho, hablaremos de RUP, un proceso pesado, de XP, un proceso ligero, y de FDD, un proceso cuya catalogación depende de los gustos, siendo ligero para la gente que considera más acertados los pesados, y pesado para los seguidores de los ligeros.

RUP

RUP es uno de los procesos más generales del los existentes actualmente, ya que en realidad esta pensado para adaptarse a cualquier proyecto, y no tan solo de software.

Un proyecto realizado siguiendo RUP se divide en cuatro fases:

1. Intercepción (puesta en marcha)

2. Elaboración (definición, análisis, diseño)

3. Construcción (implementación)

4. Transición (fin del proyecto y puesta en producción)

Lista 1: Fases de RUP

En cada fase se ejecutarán una o varias iteraciones (de tamaño variable según el proyecto), y dentro de cada una de ellas seguirá un modelo de cascada o waterfal para los flujos de trabajo que requieren las nueva actividades anteriormente citadas.

Figura 1: Vista general de RUP

RUP define nueve actividades a realizar en cada fase del proyecto

1. Modelado del negocio

2. Análisis de requisitos

3. Análisis y diseño

4. Implementación

5. Test

6. Distribución

7. Gestión de configuración y cambios

8. Gestión del proyecto

9. Gestión del entorno

Lista 2: Actividades de RUP

y el flujo de trabajo (workflow) entre ellas en base a los llamados diagramas de actividad. El proceso define una serie de roles que se distribuyen entre los miembros del proyecto y que definen las tareas de cada uno y el resultado (artefactos en la jerga de RUP) que se espera de ellos.

Figura 2: Flujos de trabajo de RUP

RUP se basa en casos de uso para describir lo que se espera del software y esta muy orientado a la arquitectura del sistema, documentándose lo mejor posible, basándose en UML (Unified Modeling Language) como herramienta principal.

RUP es un proceso muy general y muy grande, por lo que antes de usarlo habrá que adaptarlo a las características de la empresa. Por suerte ya hay muchos procesos descritos en internet que son versiones reducidas del RUP.

XP

Mientras que el RUP intenta reducir la complejidad del software por medio de estructura y la preparación de las tareas pendientes en función de los objetivos de la fase y actividad actual, XP, como toda metodología ágil, lo intenta por medio de un trabajo orientado directamente al objetivo, basado en las relaciones interpersonales y la velocidad de reacción.

XP intenta minimizar el riesgo de fallo del proceso por medio de la disposición permanente de un representante competente del cliente a disposición del equipo de desarrollo. Este representante debería estar en condiciones de contestar rápida y correctamente a cualquier pregunta del equipo de desarrollo de forma que no se retrase la tomar de decisiones, de ahí lo de competente.

XP define UserStories como base del software a desarrollar. Estas historias las escribe el cliente y describen escenarios sobre el funcionamiento del software, que no solo se limitan a la GUI si no también pueden describir el modelo, dominio, etc. A partir de las UserStories y de la arquitectura perseguida se crea un plan de releases (dejaré el término en inglés, pues las habituales traducciones al castellano, liberación o entrega del software, no son de mi agrado, supongo que son cosas de vivir en el extranjero) entre el equipo de desarrollo y el cliente.

Para cada release se discutirán los objetivos de la misma con el representante del cliente y se definirán las iteraciones (de pocas semanas de duración) necesarias para cumplir con los objetivos de la release. El resultado de cada iteración es un programa que se transmite al cliente para que lo juzgue. En base a su opinión se definen las siguientes iteraciones del proyecto y si el cliente no esta contento se adaptará el plan de releases e iteraciones hasta que el cliente de su aprobación y el software este a su gusto.

Junto a los UserStories estan los escenarios de pruebas que describen el escenario contra el que se comprueba la realización de las UserStories. UserStories y casos de pruebas son la base sobre la que se asienta el trabajo del desarrollador.

Como primer paso de cada iteracion se escribirán las pruebas, de tal forma que puedan ser ejecutadas automáticamente, de manera que pueda comprobarse la correción del software antes de cada release. Esto es de vital importancia en XP debido a su apuesta por las iteraciones cortas que generan software que el cliente puede ver y por la refactorización para mejorar el código constantemente, que hacen más que deseable una cantidad considerables de test lo más automatizables posible. Asi pués, la funcionalidad concreta del software solo se escribe cuando las pruebas para su corrección esten preparadas.

Figura 3: Vista general de XP

La codificación del software en XP se produce siempre en parejas (dos programadores, un ordenador), por lo que se espera que la calidad del mismo suba en el mismo momento de escribirlo. Al contrario que muchos otros métodos, el código pertenece al equipo en completo, no a un programador o pareja, de forma que cada programador puede cambiar cualquier parte del codigo en cualquier momento si así lo necesita, dejándose en todo caso las mejoras orientadas al rendimiento para el final. Las parejas no se mantienen para todo el proyecto si no que rotan ciclicamente a lo largo del mismo, tanto en cuanto a los componentes de la misma como en las partes del software que desarrollan, asi cada componente del equipo aprende como trabaja el resto. El objetivo ideal sería que cada compontente del equipo trabaje al menos una vez con cada uno de los demás integrantes y con cada componente software, de forma que el conocimiento de la aplicación completa lo posea el equipo entero y no unos pocos miembros.

En XP se programará solo la funcionalidad que es requerida para la release actual. Es decir, una gran flexibilidad y capacidad de configuración solo será implementada cuando sea necesaria para cumplir los requerimientos de la release. Se sigue un diseño evolutivo con la siguiente premisa: conseguir la funcionalidad deseada de la forma más sencilla posible. De ahí una variación educada del famoso KISS (Keep It Simple Stupid), Keep things as simple

...