Procesos de desarrollo

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 /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 as possible (manten las cosas tan sencillas como sea posible). Este diseño evolutivo hace que no se le de apenas importancia al análisis como fase independiente, puesto que se trabaja exclusivamente en función de las necesidades del momento.

FDD

FDD es un proceso diseñado por Peter Coad, Erich Lefebvre y Jeff De Luca y se podría considerar a medio camino entre RUP y XP, aunque al seguir siendo un proceso ligero (en mi opinión, si tenemos que distinguir entre pesado/ligero) es más similar a este último.

FDD esta pensado para proyectos con tiempo de desarrollo relativamente cortos (menos de un año). Se basa en un proceso iterativo con iteraciones cortas (~2 semanas) que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar.

Las iteraciones se deciden en base a features
(de ahí el nombre del proceso)
o funcionalidades, que son pequeñas partes del software con significado
para el cliente. Así, contruir el sistema de ventas
es algo que requiere
mucho tiempo, y contruir el sistema de persistencia
no tiene significado
para el cliente, pero si lo tiene enviar pedido por email.

Un proyecto que sigue FDD se divide en 5 fases:

1. Desarrollo de un modelo general
2. Contrucción de la lista de funcionalidades
3. Plan de releases en base a las funcionalidades a implementar
4. Diseñar en base a las funcionalidades
5. Implementar en base a las funcionalidades

Lista 3: Fases de FDD

Figura 4: Vista general de FDD

Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones, siendo las dos últimas las que absorben la mayor parte del tiempo según va avanzando el proyecto, limitándose las primeras a un proceso de refinamiento.

El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque siempre habrá un responsable último (arquitecto jefe o jefe de programadores en función de la fase en que nos encontremos), con mayor experiencia, que tendrá la última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue que todos formen parte del proyecto y que los menos inexpertos aprendan de las discusiones de los mas experimentados, y al tener un responsable último, se asignan las responsabilidades que todas las empresas exigen.

Las funcionalidades a implementar en una release se dividen entre los distintos subgrupos del equipo, y se procede a implementarlas. Las clases escritas tienen propietario (es decir, solo quién las crea puede cambiarlas), es por ello que en el equipo que implementa una funcionalidad dada deberán estar todos los dueños de las clases implicadas, pudiendo encontrarse un programador en varios grupos, implementando distintas funcionalidades. Habrá también un programador jefe (normalmente el más experimentado) que hará las funciones de lider del grupo que implementa esa funcionalidad.

En el proceso de implementar la funcionalidad también se contemplan como partes del mismo (en otros métodos se describen como actividades independientes) la preparación y ejecución de pruebas, así como revisiones del código (para distribuir el conocimiento y aumentar la calidad) e integración de las partes que componen el software.

FDD también define métricas para seguir el proceso de desarrollo de la aplicación, útiles para el cliente y la dirección de la empresa, y que pueden ayudar, además de para conocer el estado actual del desarrollo, a realizar mejores estimaciones en proyectos futuros.

La comparación

Podríamos pensar que no es posible comparar los distintos métodos de desarrollo, y que todo depende de nuestros gustos personales, pero puesto que todos los procesos se centran en la producción de software (orientado a objetos mayormente) y que el proceso se implantará para aumentar la calidad del software producido y la eficiencia de los desarrolladores, es deseable una comparación, pero no en su conjunto, sino según los medios que emplean y sus resultados.

RUP, XP y FDD tienen pocas similitudes entre si, aunque XP y FDD poseen algunas más al ser ambos ligeros, orientados al cliente y de iteraciones cortas y rápidas. También hay que decir que debido al carácter general de RUP, algunos autores consideran todos los demás procesos de desarrollo como casos particulares de este.

Tamaño de los equipos

RUP esta pensado para proyectos y equipos grandes, en cuanto a tamaño y duración. FDD y XP se implementan mejor para proyectos cortos y equipos más pequeños, siendo quizás FDD más escalable que XP, ya que a mayor tamaño de código y/o equipo mayor es la necesidad de cierta organización.

Obtención de requisitos

RUP y XP crean como base UseCases y UserStories, ambos describen los requerimientos de la aplicación desde el punto de vista del usuario. Ambos definen los requisitos técnicos sin meterse con detalles de implementación. FDD por el contrario no define explícitamente esa parte del proyecto sobre la adquisición de requisitos, y solo define el proceder a partir del momento en que ya se han recogido dichos requisitos, de la forma que queramos, dividiendo los requisitos (de forma similar a las UserStories) en las tres primeras fases del proyecto.

Carga de trabajo

XP es un proceso ligero, esto es, que los creadores del proceso han tenido cuidado de no poner demasiadas tareas organizativas sobre los desarrolladores (como modelado, generación de documentación externa, etc), cuyo efecto se minimiza por medio de la presencia de un representante del cliente. En el desarrollo de un projecto con XP es más importante la entrega al cliente del software que necesita (lo que muy a menudo no es lo mismo que lo descrito en el documento de especificación de requisitos) que las funcionalidades que quedan por implementar. Cuando durante el desarrollo se descubre que se deben cambiar las funcionalidades, se acuerda directamente con el representante del cliente. Con esos cambios se ajustará el plan de iteraciones y el de releases y se tomará la nueva dirección en el desarrollo.

RUP es un proceso pesado, basado mucho en la documentación, en la que no son deseables todos esos cambios volátiles. Existen diferentes elementos de planificación (plan de desarrollo, plan de iteración, plan de calidad, etc.) con los que se controla el desarrollo del software. A través de un predefinido esquema de escalabilidad y gestión de riesgos, se pueden reconocer previamente problemas y fallos de forma temprana y prevenirlos/corregirlos. RUP define en cada momento del ciclo de vida del proyecto, que artefactos, con que nivel de detalle, y por qué rol, se deben crear. Se definirán que artefactos son necesarios para poder realizar una actividad y que artefactos se deberán crear durante dicha actividad.

FDD es por su parte un proceso intermedio, en el sentido de que genera más documentación que XP (donde apenas existe fuera del código fuente) pero menos que RUP (que intenta documentar todo). Se entrega bastante libertad a los desarrolladores, pero siempre bajo cierto orden marcado por una jerarquía (arquitecto, programador jefe, etc), que representa también en nivel de responsabilidad existente en cada caso.

Relación con el cliente

Con RUP se presentarán al cliente los artefactos del final de una fase y se valorarán las precondiciones para la siguiente (definición de riesgos, aceptación del plan de iteracion, prototipos, etc) y solo después de que el cliente acepte los artefactos generados se pasará a la siguiente fase. La calidad de los artefactos generados será probada durante la totalidad del ciclo de vida del proyecto a través de distintas medidas de calidad, como convenciones, revisiones y auditorías periódicas, pruebas, etc.

En contrapartida, la aseguración de la calidad en XP y FDD no se basa en formalismos en la documentación, si no en controles propios y una comunicación fluida con el cliente. Tanto en XP como en FDD, el cliente recibe después de cada iteración un pedazo funcional del programa. A través de un ciclo de iteración corto (pocas semanas) el cliente está informado constantemente sobre la situación del proyecto y puede intervenir rápidamente si el desarrollo se aleja de sus necesidades.

En XP el desarrollo ve en que dirección debe ir gracias al feedback del cliente, sin ningún tipo de restricción previa. En FDD sin embargo existe el modelo general desarrollado en la primera fase, que si bien evoluciona a lo largo del proyecto, provee un marco general dentro del cual evoluciona el proyecto (mientras no sea necesario cambiarlo).

Desarrollo

Todos ellos se basan en un proceso iterativo. Esto permite acercarse poco a poco a la solucion sin entrar demasiado rápido en detalles, aunque las iteraciones de XP y FDD tienen por lo general una duración menor que en RUP, puesto que la carga a llevar por los programadores a parte del desarrollo del propio software es menor.

XP esta diseñado con los programadores en mente, con facilitar su trabajo y es por ello que define casí todo el proceso de desarrollo al completo, incluido el de pruebas y integración. RUP y FDD se centran más en la organización global, y muchas de esas actividades, como ejecución de pruebas, las asumen como obligatorias aunque sin definirlas completamente, dejando libertad a las distintas subunidades del proyecto para implementarlas a su manera (por ejemplo usar la programación por parejas en partes complejas), aunque las directrices de la empresa suelen marcar el camino a seguir.

Debido a que las releases se producen a menudo, XP afirma la necesidad de que se puedan realizar pruebas automáticas. La implementación de las pruebas antes que la propia funcionalidad hace que el desarrollador tenga que pensar pronto sobre lo que tiene que hacer y como probarlo correctamente. A través de pruebas automáticas se conseguirá que la funcionalidad se ajuste a los esperado por cada release, de modo que es importante que solo se envie al cliente código que pase al 100% las pruebas. Este es en todo caso un punto deseable en cualquier proceso de desarrollo.

RUP genera también releases basados en los artefactos después de cada fase, pero en su caso no se limitan solo al código, si no que las releases viene acompañada de todo lo que traería el producto final, es decir, notas de la versión, instrucciones de instalación, ayuda de uso, etc.

Código fuente

XP es el único que presenta la compartición del código, mayormente debido a que esta pensado para equipos pequeños que trabajan conjuntamente y con comunicación constante e inmediata, mientras que los otros dos procesos optan por la propiedad del código, aunque definen grupos y sesiones de trabajo conjuntos de forma que los propietarios de clases relacionadas trabajan juntos, y la comunicación es directa.

Conocimiento sobre la arquitectura

En XP se conseguirá a través de la programación a pares que ya en la creación del código se puedan evitar errores y malos diseños ya que se controlará cada línea de código y decisión de diseño instantaneamente. Se espera que la buena conexión entre ambos desarrolladores genere discusiones que lleven a mejores estructuras y algoritmos y que este proceso aumente la calidad del software de tal manera que compense el coste de la programación por parejas. También se intentará aumentar el conocimiento sobre el conjunto de la aplicación a través de la rotación de los miembros del equipo sobre los componentes y emparejamientos.

En RUP se intentará reducir la complejidad del software a producir a través de una planificación intensiva. Así se intentará evitar que por la desaparación de alguna pieza clave del equipo se pierda el conocimiento sobre la aplicación.

En FDD sin embargo se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una arquitectura sencilla y sin errores y las revisiones de código guiadas por algún programador con más experiencia. Estas sesiones, habituales en cada equipo e iteración, estan más enfocadas al trabajo en conjunto que al intercambio de impresiones y/o estado, como podría ser el caso de las daily meetups de XP.

En todo caso, como no podría ser de otra forma, todos los métodos de desarrollo modernos ponderan la utilización frecuente de reuniones entre los miembros del equipo, que pueden ir desde diarias, como propone XP, a semanales o mensuales, de duración de minutos o de horas, según los objetivos de la reunión.

Evaluación del estado del proyecto

FDD es posiblemente el proceso más adecuado para definir métricas que definan el estado del proyecto, puesto que al dividirlos en unidades pequeñas es bastante sencillo hacer un seguimienmto de las mismas. XP también define esos componentes pequeños, pero la tarea del reporting recae solo en los jefes de proyecto, mientras que en FDD esta más distribuida en la jerarquia. RUP por su parte, es tan grande y complejo en este sentido como en el resto, por lo que manejar el volumen de información que puede generar requiere mucho tiempo.

Puntos flacos.

Por desgracia ninguno de estos procesos puede ser considerado perfecto, ni ser aplicado en su totalidad en en la mayoría de los casos, por lo que también es necesario saber donde estan sus puntos débiles para corregirlos, si es necesario.

XP es un proceso muy orientado a la implementación. Debido al bajo número de documentos a generar, se ofrece al desarrollador un escenario ideal para participar en el proyecto. Este proceso es aceptado con el mejor grado por desarrolladores menos experimentados ya que pueden sacar provecho directo de los compañeros más experimentados.

También el cliente esta contento porque recibe un software que se adapta a sus deseos exactamente, mientras disponga de tiempo y dinero, pero ya que la funcionalidad exacta del software final nunca se definió formal y contractualmente (definirlo sería un contrasentido para XP, puesto que impediría el transcurso normal del proyecto guiado por el feedback del cliente), este método de desarrollo es quizás más aplicable para desarrollos internos, ya que para proyectos externos existe el problema concreto de que se debe realizar muy pronto una oferta concreta que defina que funcionalidad se va a implementar y en que periodo de tiempo, lo que también es importante para el cliente, ya que debe estar en la posición de comprobar tanto el rendimiento como la calidad y el contenido del software y estar seguro de recibirlo cuando lo espera.

Se debe, en todo caso, tener una gran confianza entre el cliente y el equipo de desarrollo (o su empresa) para usar el XP para escribir el software. Se podría considerar que la solución (teórica) a este problema es la presencia del representante del cliente junto al equipo de desarrollo, pero es también poco probable que el cliente pueda prescindir de los empleados que reunen las características requeridas, puesto que suelen ser poco menos que imprescindibles, y la solución habitual de que un miembro del equipo tome el rol de representante del cliente no siempre puede ser acertada, ya que aunque la empresa desarrolladora tenga un experto en el dominio del problema, puede desconocer gran parte de las particularidades de la empresa del cliente, como políticas internas o particularidades remarcables.

La programación por parejas es un interesante punto a favor de XP, hasta el punto de que quizás debería ser utilizado por cualquier otro método en determinadas ocasiones (algoritmos complejos, nuevos miembros del equipo con poca experiencia o malos hábitos, etc.), pero esta por ver hasta que punto el coste que supone es asumible por una empresa, y hasta que punto se puede producir el ambiente que presupone XP (a fín de cuentas a nadie le gusta estar mirando mientras otro esta delante de su ordenador). En todo caso, como ya se ha dicho en repetidas ocasiones, en muchos momentos del proceso de desarrollo, el trabajo en equipo solo puede ser beneficioso. Miembros del equipo con menos experiencia pueden aprender a partir de discusiones sobre una arquitectura más que cuando ya la reciben definida y solo la tienen que implementar y/o completar. Si se debe seguir este modo de trabajo en todas las fases del desarrollo del software depende en gran medida del problema concreto en cuestión y del propio equipo.

Lo que es muy poco deseable en XP es el hecho de evitar cualquier tipo de documentación fuera del código fuente (UML juega un papel prácticamente nulo, por ejemplo). Es asumible y aceptable que solo el propio código contenga la documentación actualizada, pero esto supone carencias que debemos tener en cuenta ya que puede no representar todo lo que debería (dependencias entre componentes, por ejemplo) y hace difícil utilizar la experiencia ganada en otros desarrollos (con otros equipos o por otras parejas), ya que no se ha anotado o archivado nada y se debe generar todo desde cero.

FDD presenta su talón de Aquiles en la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el principio, con la elaboración del modelo global, puesto que no es tan ágil como podría serlo XP. Es en todo caso este requisito una necesidad en cualquier proyecto si queremos llevarlo a buen puerto con éxito. Su punto intermedio entre la libertad de XP y la rigurosidad de RUP lo hacen sin duda un proceso interesante, pero a pesar de cambiar la forma de afrontar el problema, la jerarquía existente puede hacer que las dependencias de esa gente experimentada sean grandes.

El problema de usar RUP esta en otro campo completamente distinto. Para el desarrollo de software por medio de equipos pequeños (hasta unas diez personas) es RUP definitivamente muy grande y practicamente inalcanzable. Se deben repartir 31 roles y generar más de 100 artefactos distintos. Esto supone que antes de implentar RUP se debe adaptar hasta el punto de hacerlo parecer otro proceso, lo que también requiere su tiempo y tiene su coste.

Si el proyecto es suficientemente grande como para compensar la adaptación a RUP, entonces es una buena base para el proceso, para conseguir una mayor y mejor estructura y disciplina del proceso de desarrollo. Una buena posibilidad de reducir el trabajo a realizar es la reutilización de modelos, procesos, etc. ya definidos en utilizaciones previas de RUP en distintos ámbitos.

Resumen de puntos clave

RUP

• Pesado
• Dividido en cuatro fases
• La fase se dividen en iteraciones
• El discurrir del proyecto se define en Workflows
• Los artefactos son el objetivo de cada actividad
• Se basa en roles
• UML
• Muy organizativo
• Mucha documentación

Lista 5: Claves de RUP

XP

• Ligero
• Cercano al desarrollo
• Se basa en UserStories
• Fuerte comunicación con el cliente
• El codigo fuente pertenece a todos
• Programación por parejas
• Tests como base de la funcionalidad
• Solo el mínimo de organización
• Pobre en cuanto a documentación

Lista 6: Claves de XP

FDD

• Ligero
• A medio camino entre el desarrollo y la organización
• Existe un jerarquia dentro del equipo
• El codigo fuente tiene propietario
• Los equipos varían en función de la funcionalidad a implementar
• El conocimiento de la aplicación se reparte a través de trabajo en equipo y revisiones
• Documentación aceptable

Lista 7: Claves de FDD

Conclusión

¿Qué debemos esperar entonces de un proceso de desarrollo?. ¿Qué criterios debe cumplir para que aporte algo a la empresa?. Básicamente el proceso de desarrollo tiene que ayudarnos a escribir software, tiene que poner las reglas necesarias para alcanzar el éxito en nuestro proyecto pero dejando la libertad suficiente para no sentirnos agobiados.

Esto no nos lo va a ofrecer ningún proceso estándar, y como dice el refrán (aunque no se cumple exactamente en el mundo de la informática) todos los caminos conducen a Roma, de forma que es tarea de cada empresa, casi para cada proyecto, decidir cual es el mejor modo de llegar a nuestra meta. Desde este artículo solo hemos intentado mostrar algunos de los caminos más frecuentados, más bien tomados como origen, para que vosotros decidais, y lo adapteis.

Recursos

[1]
Web oficial de RUP
,
http://www.rational.com/products/rup/

[2]
Web oficial de UML
,
http://www.omg.org/uml/

[3]
The Rational Unified Proccess: An introduction,
Philippe Kruchten
,
Addison Wesley, 2000

[4]
Extreme Programming,
Kent Beck
,
Addison Wesley, 2000

[5]
ExtremeProgramming.org
,
http://www.extremeprogramming.org

[6]
www.xprogramming.com
,
http://www.xprogramming.com

[7]
XP Roadmap
,
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

[8]
Descarga del PDF descriptivo
,
http://thecoadletter.com/download/#fddguide

[9]
Últimos avances de FDD
,
http://www.nebulon.com/articles/fdd/latestfdd.html

[10]
FeatureDrivenDevelopment.com
,
http://www.featuredrivendevelopment.com/

[11]
A Practical Guide to Feature-Driven Development,
Steve Palmer, Mac Felsing
,
Prentice Hall 2002

[12]
Angewandte Prozessmodelle,
Andreas Lux

[13]
Enlaces sobre metodologías ágiles
,
http://www.agileprogramming.com

[14]
Grupo de trabajo sobre metodologías ágiles en España,
http://www.agile-spain.com

Acerca del autor

Alberto Molpeceres
Alberto es ahora mismo desarrollador de aplicaciones en ámbito cliente/servidor para la empresa T-Systems ITS GmbH en Dresden (Alemania). Cuando no está trabajando o "metiendo caña" al resto de los integrantes de javaHispano intenta pasear con su novia, buscar la desaparecida lógica del idioma alemán o intenta disfrutar del buen ambiente de la Neustadt.