Ciclos de vida en Ingeniería de Software

Hoy no será para nada un post técnico. Hoy vamos a hablar de un tema en especial como amigos de toda la vida aunque, estoy completamente seguro que ningún amigo de toda la vida te hablaría del ciclo de vida del software, sin embargo es el tema en turno en la clase de Ken uno de los temas más apasionantes de la Ingeniería de Software así que, vamos allá.

via GIPHY

Un ciclo de vida no es otra cosa más que una serie de pasos bien definidos que sirven como guía para desarrollar software de una manera más efectiva y no pasarnos toda la vida añadiendo características que al final no se van a usar o solucionando bugs eternamente cosa que suele pasar muy a menudo en los últimos días de nuestros proyectos finales. En el Mundo Real™ no solamente está en juego nuestra calificación sino entran recursos más valiosos como tiempo y dinero, así que en el papel estas metodologías parecen ser maná venido del cielo.

¿Por qué digo que parecen ser? Bueno, porque como en la mayoría de temas críticos parece ser que nadie ha encontrado la solución definitiva y todo esto es porque el software es muy MUY complejo. Existen un número considerable de metodologías que buscan ser el ciclo de vida perfecto en la cuál el software pueda ser desarrollado y a continuación evaluaremos algunas de ellas.

code-and-fix

via GIPHY

Yo la he usado, tu también y qué va, todo el mundo la ha usado. Este ciclo de vida consiste en comenzar a escribir código como a nosotros nos parezca, solucionar los problemas que vayan surgiendo sobre la marcha y repetirlo toda la vida. ¿El problema? Bueno, que quizá nunca lleguemos a un producto terminado porque no sabemos ni siquiera qué es lo que queríamos hacer desde un principio. 

Este ciclo de vida es por demás ineficaz pero también es el favorito de los estudiantes de ISC, su desventaja más grande es que si por algún milagro divino logramos tener un producto final este no será la mejor versión que pudimos haber desarrollado y terminaremos aceptando que perdimos muchísimo tiempo y energía en algo que sinceramente no nos termina por convencer.

waterfall

De The original uploader was PaulHoadley de Wikipedia en inglés. - Transferido desde en.wikipedia a Commons., CC BY-SA 2.5, Enlace

El más querido por todos los maestros de las universidades. Cuando escuches la palabra análisis de requerimientos en alguna clase ten por seguro que este modelo estará en el slide siguiente, pues es uno de los más populares a pesar de que no es siempre la mejor opción de todas. Entonces... ¿Cuándo se usa? Cuando estás seguro de qué tareas estás buscando ejecutar pero también sabes que será complejo pero, repite conmigo, cuando estás seguro de qué tareas estás buscando ejecutar, ¿por qué? Bueno, ¿has visto una cascada regresar por el lugar de dónde vino? Yo tampoco. Una vez que avanzas en las etapas es muy difícil volver hacia atrás. Este modelo no es precisamente el mejor si necesitas hacer cambios a la mitad del desarrollo o si no eres una persona precisamente bueno definiendo las cosas claramente desde el principio.

¿Por qué lo aman los maestros? Porque este método es sumamente sencillo de seguir sobre todo para los equipos sin experiencia. No me malentiendas, este modelo no es malo ni mucho menos, al contrario es sumamente eficaz en las circunstancias propicias pero ten en cuenta que debes de tener ciertas consideraciones antes de elegir x o y modelo.

spiral

By Conny, CC BY-SA 3.0, Link

¿Te gusta hacer prototipos? Bueno, no me importa, si eliges este modelo tendrás que acostumbrarte a ellos porque los harás, y muchos. Con este modelo por cada fase que avances irás reduciendo poco a poco la incertidumbre que rodea el desarollo de un nuevo producto pues al principio todo fluirá correctamente aún y cuando los requerimientos cambien, como podrás notar, este modelo dista mucho del diseño waterfall ya que permite tener bastantes prototipos a lo largo del desarollo que harán que el feedback sera recurrente.¿El problema? Cuesta dinero y cuesta mucho. El problema es que cuando finalices cada prototipo será como iniciar de nuevo pero con un poco de menos riesgo, es decir, tendrás que comenzar a planear de nuevo, cambiar cosas aquí y allá lo que supone que debes de ser muy abierto al cambio si eliges este modelo cuando desarrolles tu proyecto.

evolutionary prototyping

via GIPHY

También conocido como el método Windows Vista. Bueno, la verdad es que ese nombre se lo puse yo pero tiene mucho más sentido si le llamamos así, sobre todo porque ilustra muy bien lo que puede pasar si todo sale mal con este modelo. 

Digamos que este modelo es el modelo waterfall con un loop infinito después de la mitad pues una vez que pasas la etapa del diseño de arquitectura comienzas a hacer un diseño detallado, codificas, debuggeas, pruebas y liberas una versión de tu programa. Cuando haces ya has terminado una etapa lo que sigue es comenzar a trabajar en la siguiente que se traduciría como una nueva versión de tu programa ¿ya comenzaste a ver la ventaja? Si no, aquí te la relato: tu jefe estará más que contento. Este modelo acepta un feedback sin precedentes pues los mismos usuarios serán tus conejillos de indias para hacerte notar en qué puedes mejorar o qué puedes solucionar. 

Pero... Por qué me refiero a él como el modelo Windows Vista? Bueno, porque si la coordinación no se hace bien o el marketing es pésimo tendrás un desastre asegurado además, si no sabes donde parar las nuevas versiones tendrás un sobrecosto que harán que tu programa no sea la mejor opción. 

¿Cuál es el mejor?

Depende enteramente de tu proyecto, te relaté algunos de los modelos de ciclo de vida que conozco pero hay unos cuantos más. Ninguno es mejor que otro pero, para aprovechar lo mejor de cada uno tú tendrás que hacer una buena elección que se ajuste a tu proyecto ,a los requerimientos del mismo, el costo de la mano de obra, la tolerancia al riesgo, la visibilidad del progreso y claro, disponibilidad a la retroalimentación. ¿Te sientes abrumado? Bueno, todos nos hemos sentido así alguna vez, sobretodo cuando iniciamos en el mundo administrativo del software y dejamos de codificar todo a la primera de cambio. Abajo te dejaré una comparativa que encontré por ahí en una presentación de la Universidad de Washington que no está para nada mal. Sin más que decir, ¡nos vemos a la vuelta!

Model category matrix

Recuerda que la información de este post fue recabada de: washington.edu y tutorialspoint.com