Original article: SDLC Guide – Software Development Life Cycle Phases and Methodologies
Cuando decidí aprender a programar por mí mismo hace casi cuatro años, nunca había oído hablar del ciclo de vida del desarrollo de software, y mucho menos pensado en él.
Como un recién desarrollador, estaba enfocado en aprender las tecnologías que me ayudaran a obtener ese codiciado primer trabajo como desarrollador, no los matices de cómo esos equipos operaban.
Cuando en efecto aprendí sobre ellos, pensé que serían inservibles para mí porque me consideraba a mí mismo como un desarrollador web, no un desarrollador de software.
Desde entonces he aprendido que esto no podría estar más alejado de la realidad, y estos principios/prácticas juegan un rol muy importante en las actividades de mi día a día (ya sea que me dé cuenta o no).
Soy lo bastante afortunado de ver cómo el código que escribo, las características que construyo, y los "bugs" que inadvertidamente creo (más de los que me importa admitir) afectan al usuario final y su experiencia. Esa experiencia me ha ayudado a dar forma a lo que pienso acerca del proceso de construir productos y resolver problemas para mis usuarios.
He tenido algo de tiempo para pensar acerca de las diferencias (y similitudes) que cada uno de estos acercamientos ofrece. En su núcleo, cada uno está concentrado en entregar software de alta calidad, tan eficiente como lo eficientemente costoso como sea posible.
Profesionalmente, solo he usado una o dos de estas metodologías. Pero aún encuentro valor valor, en al menos un entendimiento básico de todas ellas.
Todas estas metodologías siguen una serie de fases similares a este diagrama:
Entonces, aquí están los métodos para el ciclo de vida del software (sin ningún orden en particular):
Ahondemos en las diferencias y similitudes de cada método.
Lean
La metodología Lean se apoya fuertemente y se compone de siete principios.
Sin especificar el orden estos son:
- Eliminar el desperdicio
- Amplificar el aprendizaje
- Decidir tan tarde como sea posible
- Entregar tan rápido como sea posible
- Empoderar al equipo
- Construir integridad
- Ver/Optimizar el panorama general
Cada principio tiene un propósito específico con beneficios que se complementan uno al otro.
Eliminar el desperdicio (características extra, trabajo incompleto, compromiso gerencial, etc) crea más valor para el cliente que, a cambio, aumenta su satisfacción.
Amplificar el aprendizaje permite a los equipos reinvertir en su habilidad productos a los clientes.
Decidir tan tarde como sea posible se refiere a todas las grandes decisiones, dando a los equipos un acercamiento basado en opciones o en conjuntos. Estos permite a los equipos reunir hechos en lugar de opiniones que ayude a influir las decisiones cuando sean tomadas.
Entregar lo más rápido posible se explica por sí mismo: construya el producto lo más rápido posible para entregarlo a los clientes para su evaluación/iteración.
En un escenario típico, los gerentes reparten tareas/trabajos a los desarrolladores. Con la metodología Lean los desarrolladores "enseñan" a los gerentes cómo escuchar a los que "están en las trincheras" por lo tanto, influenciando en las decisiones/elecciones de la gerencia.
Esto ayuda a que los equipos se sientan más empoderados a que se expresen sobre las ideas y soluciones.
Haciendo de la integridad una regla en vez de una excepción significa que el cliente puede confiar en que el sistema está siendo construido. El cliente sabe que el sistema se construye para resistir la cantidad apropiada de crecimiento y "estiramiento" si lo necesita.
Me gusta pensar de la integridad como algo con los mismos lineamientos al sentarse en una silla. Cuando te sientas en la silla crees que está hecha con el mejor material que te aguantará cada vez que te sientes en ella por el resto de su vida útil. El cliente necesita de esa misma confianza en el producto construido.
Por último, ver y optimizar el panorama general se refiere al total del sistema construido. Al optimizar "el todo" miramos al software no como a la suma de varios componentes, sino como a una entidad grande que se optimiza para eficiencia.
Esto significa que durante el desarrollo, el producto es dividido en piezas manejables y que los "bugs" inadvertidos no solo son descubiertos, sino además resueltos rápidamente.
Agile
Este es el acercamiento "falla rápido" para el desarrollo de software.
Hace énfasis en pequeños e incrementales lanzamientos con ciclos de lanzamiento andando. Con cada iteración los equipos apuntan a identificar y localizar pequeños problemas antes de que se hagan grandes.
Estos también significa que los equipos deben involucrar a las partes interesadas (gente/organizaciones que el código puede afectar en última instancia tales como gerentes, líderes técnicos, CTO's, y clientes) para obtener su retroalimentación.
Si eres freelance, las partes interesadas serían tus clientes - ultimadamente necesitas asegurar su satisfacción con el trabajo antes de continuar.
La metodología Agile es técnicamente una ramificación de la metodología Lean, con algunas diferencias notables - principalmente prioriza a la satisfacción del cliente desde el comienzo y permite a los equipos responder rápidamente a la retroalimentación del cliente.
Aunque está más allá de la pertinencia de este artículo, hay un marco de trabajo más complejo dentro de Agile llamado SCRUM. Esta metodología es usada por grandes, extremadamente complejos proyectos y ha sido usado incluso fuera del desarrollo de software.
Waterfall
La metodología Waterfall es, por mucho, la más antigua de todas. Nunca se supuso que fuera un modelo para el desarrollo de software y tuvo sus inicios en los mundos de la construcción y la manufactura.
Este acercamiento es simple en su estructura - concluye todas las partes de una fase antes de continuar con la siguiente fase con más impulso hacia el final del proyecto conforme las etapas son completadas. El inicio y la conclusión de cada etapa (excepto en la primera) depende de la finalización/transferencia de información de la etapa anterior.
Bajo el enfoque Waterfall, cada etapa tiene su propio plan de proyecto rígido que termina con pruebas para el trabajo completado previamente. Cabe señalar que este enfoque no se recomienda para proyectos más grandes o de mayor duración debido a la rigidez antes mencionada.
Piensa en la génesis de esta metodología y la entenderás más. Proviene del mundo de la construcción/fabricación donde es común completar una fase a la vez. Durante la construcción de una casa, no comenzaría a instalar la plomería antes de que se haya colocado el marco.
Esa no es la forma en que funciona el desarrollo de software en general. Como todos sabemos, a veces se hace necesario volver a visitar una fase que antes se creía terminada.
Iterative
Esto se conoce como el "enfoque repetitivo" o el enfoque de "hacerlo mejor la próxima vez" debido a las diferentes oportunidades que brinda para mejorar el producto con cada iteración del ciclo.
No lo sé todo (como todos :D), pero este es mi ciclo de vida favorito para el desarrollo. Creo que funciona mejor para mi situación actual tanto en mi carrera como freelance porque me permite "avanzar constantemente mientras mejoro las cosas".
Con el enfoque iterativo, los equipos implementan una solución, la prueban, evalúan su eficacia/rendimiento y luego identifican otras áreas de mejora. Esto sucede para cada ciclo (iteración) del proceso de desarrollo.
Con cada versión lanzada viene otra iteración hasta que el producto final se completa y está listo para su implementación a los usuarios.
Una de las grandes características del enfoque iterativo es que tú y su equipo obtienen una versión funcional del software desde el principio del proceso de desarrollo. Esto puede ser especialmente útil para mostrar a las partes interesadas para medir su respuesta/retroalimentación.
Uno de los grandes inconvenientes de este enfoque es que puede consumir una gran cantidad de recursos muy rápidamente. Imagine todas las personas, las horas, las correcciones de errores y los salarios que se incluyen en cada iteración del ciclo de desarrollo y obtendrá una buena imagen del uso de los recursos.
Dentro de este enfoque hay un subconjunto de principios desarrollado por Rational Software Corporation (comprado por IBM) llamado Rational Unified Process (RUP) que consta de 4 fases:
- Comienzo
- Elaboración
- Construcción
- Transición (lanzamiento del producto)
Este conjunto de principios pretende ser flexible y adaptarse a las necesidades de cada equipo que lo utilice.
Spiral
La metodología espiral es probablemente la más flexible de las seis. Es una metodología basada en riesgos: identificarlos y negarlos. El riesgo (identificación y aversión) impulsa cada decisión en este modelo. Se divide en cuatro sub-fases:
- Planeación (objetivos)
- Análisis de riesgos (identificar posibles obstáculos)
- Desarrollo y Testeo (la versión actual y la siguiente)
- Evaluación (inspección de la fase actual y planificar la siguiente)
Cada iteración de cada fase comienza con la planificación de la siguiente fase. De esta manera, los riesgos potenciales se identifican antes de que se encuentren. Esto también permite tener un plan de acción cuando surgen dichos riesgos.
Durante las fases, los equipos también trabajan para mitigar estos riesgos y su impacto en futuras iteraciones del desarrollo en espiral.
A medida que continúa el proceso de desarrollo, cada una de estas cuatro sub-fases se repite en forma de espiral. Esto permite múltiples rondas de refinamiento para cada sub-fase hasta su finalización.
Dev Ops
Si realiza una búsqueda rápida, no encontrará escasez de información sobre este método de ciclo de vida de desarrollo. Es el chico nuevo en el vecindario que une a los equipos de desarrollo de software y operaciones de tecnología de la información.
Estos equipos trabajan en conjunto para proporcionar actualizaciones pequeñas, pero impactantes a los productos que se presentan con frecuencia. A su vez, esto crea un ciclo continuo de retroalimentación y mejora que impulsa el desarrollo.
Esta metodología particular también es conocida por automatizar las partes manuales del desarrollo (piense en la implementación).
El objetivo general de esta metodología es, como la mayoría de las otras, acortar el ciclo de vida de desarrollo y proporcionar productos de calidad.
Uno de los inconvenientes de esta metodología es la mentalidad significativa y los cambios culturales dentro de una organización. Los equipos que pueden haber estado acostumbrados a trabajar en muchas cosas encuentran que sus tareas se reducen a solo una o dos.
Por ejemplo, un desarrollador de propósito general puede descubrir que ahora solo se le asigna la parte de testeo o la parte de experiencia del usuario final.
Trayendo todo a casa
Espero que ahora puedas ver la importancia y los beneficios de cada una de estas metodologías. Cada uno de estos posee sus propias fortalezas y debilidades.
Son, en su nivel más básico, un conjunto de pautas y principios que buscan entregar un trabajo eficiente y de alta calidad a las partes interesadas.
Cuando empecé a aprender a programar no tenía un mentor. Al compartir lo que he aprendido, espero ayudar a aquellos que están aprendiendo a programar cuando y donde puedan.
Quiero compartir tanta información y experiencia como me sea posible con otros desarrolladores. Si estás aprendiendo a programar por tu cuenta o si eres un desarrollador experimentado, espero que este artículo te ayude, aunque sea un poco.
Echa un vistazo a mi blog donde con frecuencia publico artículos sobre desarrollo web.
Mientras estás allí, ¿por qué no te suscribes a mi newsletter de noticias? Puede hacerlo en la parte superior derecha de la página principal del blog. Me gusta enviar artículos interesantes (los míos y de otros), recursos y herramientas para desarrolladores de vez en cuando.
Si tienes preguntas sobre este artículo o, en general, mis DM están abiertos -- ven a saludarme en Twitter o en cualquiera de mis otras cuentas de redes sociales que puedes encontrar debajo del newsletter, regístrate en la página principal o en mi perfil aquí :)
!Que tengas un día increíble y feliz coding, amig@!