Ciclo de vida en la Programación Extrema

Esta metodología define cuatro variables para cualquier proyecto de software: costo, tiempo, calidad y alcance. Además, se especifica que de estas cuatro variables sólo tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto). El valor de la variable restante podrá ser establecido por el equipo de desarrollo, en función de los valores de las otras tres. Este mecanismo indica que por ejemplo, si el cliente establece el alcance y la calidad y el jefe de proyecto el precio, el grupo de desarrollo tendrá libertad para determinar el tiempo que durará el proyecto. Este modelo es analizado por Kent Beck en donde propone las ventajas de un contrato con alcances opcionales.

33

Como se detalló en los apartados anteriores, los ciclos de vida “tradicionales” proponen una clara distinción entre las etapas del proyecto de software, y tienen un plan bien preestablecido acerca del proceso de desarrollo. Así mismo, en todos ellos se parte de especificaciones claras, si no del total del proyecto, por lo menos de una buena parte inicial.

El ciclo de vida de un proyecto en la XP incluye al igual que las otras metodologías, entender lo que el cliente necesita, estimar el esfuerzo, crear la solución y entregar el producto final al cliente. Sin embargo, en la XP se propone un ciclo de vida dinámico, donde se admite expresamente que en muchos casos, los clientes no son capaces de especificar sus requerimientos al comienzo de un proyecto.

Nunca se debe añadir funcionalidad extra al programa aunque se piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.

La metodología XP sugiere además que hay que conseguir diseños simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseño fácilmente entendible e implementable que a la larga costará menos tiempo y esfuerzo desarrollar.

Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con entregables funcionales al finalizar cada ciclo. En cada iteración se realiza un análisis completo, pero utilizando un conjunto de reglas y prácticas que caracterizan a la XP.

El escritor (Pressman, 2006) menciona que “la Programación Extrema abarca un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades del marco de trabajo: planeación, diseño, codificación y pruebas”.

34 Figura 3. Proceso de la programación extrema Fuente: Pressman 2006

Si bien el ciclo de vida de un proyecto en la XP es muy dinámico, se ha logrado separar en fases como se lo muestra en la figura anterior, una síntesis de las mismas se presentan a continuación:

Planeación.- Esta actividad comienza con una serie de historias de usuario que describen las características y funcionalidades requeridas para el software que se construirá. Estas historias sustituyen a los casos de uso de otras metodologías, las escribe el cliente y les asigna una prioridad de acuerdo al valor que aporta al negocio. Son utilizadas para estimaciones de tiempo en la planificación y reemplazan al documento de requerimientos del usuario.

Diseño.- El diseño en la XP sigue de manera rigurosa el principio de mantenerlo simple, se prefiere diseños simples respecto de una presentación más compleja. Ofrece una guía de implementación para una historia tal como está escrita.

La programación extrema apoya la refabricación, una técnica de construcción que también lo es de diseño. Refabricación es el proceso de cambiar un sistema de software de tal manera que no altere el comportamiento del código y que mejore la estructura interna del mismo. Su propósito es controlar esas modificaciones al sugerir pequeños cambios de diseño que

35

pueden mejorar de manera radical el mismo, considerando que el diseño ocurre de manera continua a medida que se construye el sistema.

Codificación.- Luego de diseñar las historias de usuario y el trabajo de diseño preliminar se recomienda que no se debe mover hacia la codificación, sino que se deben desarrollar una serie de pruebas de unidad para ejercitar cada una de las historias que vayan a incluirse en el lanzamiento. Basados en estas pruebas el desarrollador puede centrarse en la implementación necesaria para pasar dichas pruebas sin agregar nada extra manteniendo de esta manera el diseño simple. Al completar el código se puede probar de inmediato para así proporcionar una retroalimentación instantánea al desarrollador.

Pruebas.- Las pruebas de unidad antes de comenzar la codificación son un elemento clave para el enfoque de la programación extrema. Cuando las unidades individuales se organizan en un conjunto de pruebas, las pruebas de integración y validación pueden realizarse a diario lo que proporciona una indicación continua del progreso o una alerta si por el contrario las cosas salen mal. Por último tenemos las pruebas de aceptación las cuales son especificadas por el cliente y están basadas en las características generales y la funcionalidad del sistema. Estas pruebas se derivan de las historias de usuario que se han implementado como parte del lanzamiento del software.

36

CAPÍTULO III

37

Las fases que se seguirán para el presente desarrollo y lo que implica cada una de ellas son explicadas en los siguientes puntos, orientando únicamente algunos de los entregables de cada fase al ámbito de nuestra aplicación, obtenidos como resultado del desarrollo de cada una de dichas fases.