Metodologias De Desarrollo De Software

Introducción

En la actualidad, el desarrollo de proyectos se hace cada vez más común debido a una gran cantidad de proyectos que se generan día a día. Para el desarrollo de estos existen diversas metodologías tanto para el desarrollo o para la gestión, en este documento nos enfocaremos en las metodologías de desarrollo de software, que son aquellas que nos dicen que pasos seguir y como seguirlos para desarrollar un proyecto.

Las metodologías de desarrollo de software son un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información. Con estas metodologías se puede asegurar el desarrollo ordenado de un proyecto con el fin de entregar soluciones en el tiempo estimado.

Cada metodología trabaja diferente a las otras, unas aseguran más calidad de software que otras pero toman más tiempo en el desarrollo de estas, por lo tanto para elegir una de estas metodologías se debe conocer bien la problemática.

A continuación se explica cómo funciona cada metodología con sus diferentes fases y ciclos de vida y cuál es el propósito de estas.

1. Extreme Programing

Esta metodología está dirigida para proyectos de corto plazo (1 día – 3 meses) con un pequeño equipo de desarrollo (2 a 10 personas). Como principal característica a nombrar es que posee como parte del equipo de trabajo al usuario final para mantener un feedback durante el proceso del desarrollo.

A continuación se explica la metodología xp junto con su ciclo de vida, WBS y un cronograma de un proyecto desarrollado con esta metodología.

Para esta metodología, es el cliente un miembro del equipo que se preocupa de lo que se va a implementar, el puede modificar los requerimientos en cualquier momento del desarrollo del proyecto, esto significa que el cliente está enterado de cómo va evolucionando el proyecto semana a semana. (Beck, 1999)

XP posee 5 valores:

a) Simplicidad:

Este valor es la base de esta metodología, ya que simplifica el diseño y la documentación, por lo tanto, facilita el mantenimiento. Si el diseño es muy complejo, la complejidad del desarrollo aumenta radicalmente.

Con respecto al código, para mantener la simplicidad es necesaria la refactorización, para así se mantenga simple a medida que crece. Con respecto a la documentación, esta se documenta de la justa manera para que el código este autodocumentado.

b) Comunicación:

Al mantener código simple en el desarrollo, permite que la comunicación entre los programadores sea más simple. También se puede ver comunicación en las pruebas unitarias ya que estas describen el diseño de las clases y sus métodos al mostrar ejemplos de sus funcionalidades. Existe una comunicación fluida con el cliente, ya que forma parte del equipo de trabajo. El cliente decide que funciones tienen más prioridad que otras.

c) Retroalimentación (feedback):

Ya que el cliente está integrado en el equipo de desarrollo, éste genera retroalimentación semanalmente.

Debido que cada iteración de XP genera entregables, después de cada una de estas se pueden encontrar errores para poder refinar, y si cumplen o no los requisitos.

d) Coraje o valentía:

Diseñar y programar para el día de hoy y no posponer el desarrollo implica valentía. Permite a los desarrolladores sentirse cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente.

Con valentía, el programador puede permanecer por un día entero sin resolverlo pero luego si es persistente y sigue intentando, lo solucionará.

e) Respeto:

Cada miembro del equipo se respetan entre si ya que el equipo de trabajo es pequeño y tienen mucha comunicación entre ellos para poder realizar las pruebas necesarias. Cada miembro del equipo además de respetar a los otros, respeta su trabajo y trata de generar un producto de calidad. (Joskowicz, 2008)

1.1 Ciclo de Vida

El ciclo de vida ideal de XP consiste de seis fases:

a) Exploración

Aquí los clientes plantean las historias de usuarios, la cual son necesarias para la primera entrega del producto.

También el equipo de trabajo conoce y se familiariza con las herramientas a utilizar. Se analiza la arquitectura de sistemas construyendo un prototipo.

b) Planificación de la Entrega

Aquí el cliente es quien establece la prioridad de cada historia de usuario mientras los programadores calculan el esfuerzo necesario para cada historia.

Se genera un sistema de medida de esfuerzo por puntos, donde cada punto equivale a una semana de desarrollo. Cada historia de usuario normalmente equivale de 1 a 3 puntos.

El equipo de desarrollo posee un registro de velocidad de desarrollo basado en cantidad de puntos por cada iteración.

Esta planificación se puede basar en el tiempo o en el alcance, la velocidad se utiliza para establecer la cantidad de historias de usuario que se podrán entregar antes de cierta fecha establecida.

c) Iteraciones

Se incluyen varias iteraciones sobre el sistema antes de que sea entregado, las entregas están compuestas por iteraciones que no duran más de 3 semanas.

En la primera iteración se establece la arquitectura de sistemas que se utiliza para el desarrollo del proyecto.

Al final de la ultima iteración, el sistema ya estará listo para su producción.

d) Producción

Esta fase requiere de pruebas adicionales y testing del rendimiento antes que sea enviado al entorno del cliente. También se deben tomar las decisiones sobre incluir nuevas funciones a la versión actual ya que pueden haber cambios durante el desarrollo.

e) Mantenimiento

Mientras el producto se encuentra en producción, el proyecto debe mantener el sistema funcionando al mismo tiempo que se desarrollan nuevas iteraciones.

Para lograr esto se requiere de tareas de soporte para el cliente. La fase de mantenimiento puede requerir nuevo personal dentro del equipo de trabajo.

f) Muerte del Proyecto

Cuando el cliente ya no tiene más historias de usuario para incluirlas en el sistema, este muere. Se genera la documentación final del sistema y no se realizan más cambios arquitecturales.

Si el sistema no genera lo que el cliente espera o no hay presupuesto para mantenerlo, este muere también. (Wells, 2000)

...