Metodologías para proyectos de desarrollo de software

Las metodologías para desarrollar software se dividen en dos categorías, las tradicionales y las ágiles.

Las metodologías tradicionales, son aquellas que siguen una línea secuencial de desarrollo: esto quiere decir que para realizar un proceso, es preciso haber concluido con el anterior.  Por ejemplo, para codificar un sistema es necesario haberlo diseñado primero.

La implementación de un cambio durante el desarrollo del proyecto puede dificultarse dentro de esta metodología, pues para aplicarlo es preciso volver a formular el plan y cuando se trata de proyecto grande esto resultaría demasiado costoso.

Algunas  metodologías  tradicionales  son: RUP  (Rational  Unifies  Process)  y  MSF  (Microsoft   Solution

Framework).

Las metodologías ágiles en cambio permiten que el proyecto pueda cambiar durante su desarrollo, siendo éstas la mejor opción para cuando se trata de proyectos pequeños o con requerimientos que no están bien definidos. Algunas de ellas son Scrum, XP y DSDM.

Scrum

Ésta metodología es adecuada para desarrollos de software en donde los requerimientos aún no están bien definidos.  Esto quiere decir que no es necesario  que el cliente decida y exponga  las necesidades  ni los requisitos completos que debe cubrir el software que se va a implementar en la empresa.

De forma general la metodología  se establece  de la siguiente  manera: todo el proyecto es realizado  por medio de iteraciones, es decir, por medio de repeticiones y a cada iteración se le llama sprint.

Antes de comenzar cada sprint, el cliente expone al equipo de trabajo algunos de los requerimientos  que desea que el sistema satisfaga.

Toma el ejemplo  de un empresario  que solicita  un módulo  de ventas  para su negocio,  el cual debe ser desarrollado dentro del sprint cuya duración no debe ser mayor a 30 días. Eso quiere decir que dentro del sprint se desarrollan las funcionalidades del sistema. Mientras éste se está llevando a cabo, no debe haber cambios; estos pueden venir cuando esté terminado y para mejorar la funcionalidad del sistema.

Siguiendo el ejemplo, si el cliente envía más requerimientos,  pero ahora para un módulo de compras, se comenzarán nuevos sprint hasta que el sistema completo se termine. Dentro de cada uno está presente este ciclo de vida: diseño, codificación y pruebas.