.

¿Porqué el ciclo de desarrollo software tradicional falla?

 

ciclo-desarrollo-tradicional

En primer lugar, hablemos de los procesos de desarrollo. ¿sabes a que me refiero con procesos de desarrollo? Son los elementos que componen cualquier proceso de desarrollo de un proyecto TIC. De hecho, el mejor ámbito para los enfoques Ágiles son los proyectos TIC.

Tal vez empleas otro nombre para referirte a ellos, o los divides en elementos mas concretos o incluso los agrupas en diferentes procesos, pero el concepto es el mismo, y estos elementos son lo único que necesitas llevar a cabo para desarrollar un proceso. Ni siquiera dependen de si utilizas un enfoque tradicional, o un enfoque Ágil, sencillamente tienes que cumplir con todos para llevar a acabo un proyecto o solución.

Procesos de desarrollo tradicional

La Especificación; es el primero de los procesos, después están  el diseño, la construcción , la integración, el test, y finalmente la implementación.

Bien, ahora ya sabes que es necesario llevar a cabo todos y cada uno de estos procesos, la cuestión es ¿Cómo debemos hacerlo? La respuesta es con o través de un ciclo de desarrollo.  El ciclo de desarrollo se refiere a la manera, al modo en que se llevan a cabo estos procesos. Veamos a continuación la manera habitual, o tradicional de implementar el ciclo de desarrollo.

Esto que tenemos aquí, en la imagen, es un ciclo de desarrollo  muy simple; en un ciclo de vida como este, los procesos tienen lugar una tras otro, uno después del otro. Es decir, empezamos por la especificación de los requisitos y empleamos tanto tiempo como sea necesario para especificar los requisitos y definir el alcance del proyecto.

Una vez concluidas las especificaciones, empezamos con el diseño de la solución de todo el proyecto. La tercera fase, consiste en construir la solución. Durante esta fase, durante este proceso, es cuando los desarrolladores llevan acabo su trabajo, a continuación integramos el código que los desarrolladores programaron en la fase anterior, los testeamos y eliminamos los fallos y finalmente lo integramos. Tras la integración hacemos las pruebas necesarias para localizar y eliminar los fallos y finalmente lo integramos. Observa como no es hasta el final del ciclo que entregamos el producto.ciclo-desarrollo-tradicional-waterfall

¿Qué sucede con la forma de trabajo tradicional en cascada?

Bien, al final de la primera fase no tenemos otra cosa que documentos. El principal documento que habitualmente creamos al final de esta fase es son “Las Especificaciones de Requisitos”.

Al final de la segunda fase, seguimos teniendo más documentación. En este caso, el documento que generemos al final de esta fase se conoce habitualmente como Arquitectura de la Solución.

Al final de la tercera fase, lo que obtenemos es “código”, no un software en funcionamiento, dado que no podemos garantizar su funcionamiento. En este punto el código que tenemos no ha sido testeado ni integrado. Eso es lo que haremos en las siguientes fase. De momento solo tenemos “código”

Así pues, el software en funcionamiento no lo generamos sino en la última fase, al final del proyecto.

Lo que ocurre es que cuando el cliente recibe el software en funcionamiento, es cuándo entiende lo que necesita y es capaz de solicitar los  cambios que contribuyan a desarrollar una mejor solución.

El problema con este modelo de procesos es que el software en funcionamiento no se produce hasta el final del proceso y es muy caro, es muy costoso cambiar cualquier cosa llegados a este punto.

Una de la debilidades de este modelo es que a lo largo de todo el proyecto, no tenemos un software en funcionamiento que enseñar al cliente, y por lo tanto este no puede darnos su feedback.  Así que todo se retrasa hasta el final del proyecto, lo cual es terrible para el proyecto. Obviamente no para todos los proyectos, pero si para el tipo de proyectos a los que nos referimos.

Por ejemplo para los proyectos de construcción, este proceso es muy adecuado. Por supuesto dado que los proyectos de construcción o edificación son otro tipo de proyectos, serán necesarios otros procesos. Estos procesos, los procesos Ágiles, están especialmente indicados para proyectos del ámbito de los proyectos IT.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  miguel

Dirección proyectos TI y #ecommerce bajo Prince2 o Scrum . Usabilidad, Conversión, Seo, AdWords, Marketing online, Analítica. Consultor y desarrollador.

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR