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)

...