Las actividades del “ciclo de vida” del software son:

    1. Requisitos. Esta actividad tiene como objetivo descubrir los problemas o necesidades que el software debe solventar o suplir.

    2. Análisis. Una vez aterrizadas las necesidades que debe suplir el software, se especificarán sus funcionalidades.

    3. Diseño. Tras concretar las funcionalidades del software se idea el sistema y se define la arquitectura que sustentará el código.

    4. Codificación. A partir del diseño y sobre los cimientos de la arquitectura propuesta se codifica el software.

    5. Pruebas (Verificación y validación). El software debe funcionar correctamente y responder a las expectativas del cliente.

    6. Despliegue. Finalmente, el software se despliega para ser operado por los usuarios.

Existen diferentes métodos para llevar a cabo todas las actividades del ciclo de vida.  Sobre estas metodologías hay dos grandes puntos de vista: la visión predictiva y la visión adaptativa.

Actividad vs Tiempo. Planificación predictiva, sin iteraciones y sin solapamientos

Para construir un producto software que implemente las funcionalidades A, B, C y D, la visión predictiva planifica 5 fases: Requisitos, Análisis y Diseño, Codificación, Pruebas y Despliegue. Cada una de estas actividades son realizadas por especialistas: Analistas, Diseñadores, Codificadores, Probadores y Operadores. Una fase no puede comenzar sin terminar la anterior. La última fase, “despliegue” entrega el producto software completo con todas las funcionalidades. El alcance de cada fase cubre todas las funcionalidades (A, B, C y D). Por ejemplo, en la fase de Requisitos el analista recoge completamente los requerimientos de todas y cada una de las funcionalidades del software. En la fase de “Análisis y Diseño” los analistas y diseñadores elaboran las especificaciones del software para todas y cada una de las funcionalidades. El equipo de desarrollo codifica el producto completo implementando las cuatro funcionalidades. Finalmente, el equipo de testers prueba el software y los técnicos de operaciones lo despliegan.

Actividad vs Tiempo. Planificación adaptativa, con iteraciones, pero sin solapamientos

Para construir un producto software que implemente las funcionalidades A, B, C y D la visión adaptativa planifica cuatro entregas, cada sprint o iteración entregará cada una de las funcionalidades del producto software. Es decir, se planifican cuatro despliegues. Cada iteración es realizada por un equipo de técnicos que reúne todas las competencias necesarias para tener éxito en la iteración. 

La visión adaptativa no sólo prescribe la iteración de actividades para poder entregar periódicamente software con valor para el cliente, también permite el solapamiento de actividades.

Actividad vs Tiempo. Planificación Adaptativa, con iteraciones y con solapamientos

Por ejemplo, en el Sprint A el equipo comienza recogiendo los requisitos de la funcionalidad A, también comienza el análisis y diseño de dicha funcionalidad. Cuando el equipo considera que el análisis y diseño está suficientemente maduro, comienzan la codificación que pronto la solapan con las pruebas automatizadas. Además, es habitual que los miembros del equipo sean capaces de interpretar diferentes roles.

Para ayudar a entender la visión adaptativa, en el ejemplo se han simplificado las entregas de funcionalidad. Es habitual, en el primer sprint, entregar un porcentaje de cada funcionalidad en lugar de entregar totalmente una concreta. Por ejemplo, la primera iteración podría haber entregado el 60% de la A, el 20% de la B, el 10% de la C y el 10% de la D. La segunda iteración podría haber entregado el 10% de la A, el 50% de la B, el 40% de la C y el 5% de la D. Las sucesivas iteraciones irán aumentando el porcentaje de funcionalidad entregada haciendo el producto final cada vez más “completo”. 

En la construcción ágil del producto software no son necesarios los extensos documentos de requerimientos, son sustituidos por sencillas “historias de usuario”. Las necesidades del cliente que debe solventar el producto software se irán detallando según avance el proyecto recibiendo constante “feedback” por parte del negocio. 

Cada miembro del equipo es responsable de diseñar, codificar y probar un segmento funcional (feature), esto reduce la cantidad de documentación a generar. Desaparecen los “planos” del software (diagramas UML rigurosos). Ya no es necesario que el equipo de arquitectos comunique las especificaciones del software al equipo de codificación o que el equipo de testers elabore extensos planes de prueba. Prescindir de toda esta documentación exige nuevas técnicas de diseño. Los desarrolladores no improvisan el código. Los miembros del equipo utilizan técnicas de desarrollo guiadas por pruebas que facilita el diseño de las clases y sus comportamientos. 

Las metodologías adaptativas, también llamadas “ágiles”, subrayan las características propias de la industria del software que la hacen diferente a la industria civil o manufacturera. Juan Palacio en "Flexibilidad con Scrum" (2008) ofrece las siguientes claves: 

• Coste de la materia prima. Un ingeniero de software puede desarrollar con recursos escasos una solución extraordinaria; sin embargo, un arquitecto o un ingeniero naval no pueden hacer lo mismo. Los recursos físicos necesarios para la construcción de sistemas en ninguna ingeniería son despreciables, excepto en la ingeniería de software. Esta característica tiene implicaciones importantes en la gestión porque permite considerar opciones que la gestión clásica de proyectos ni se plantea. Sería absurdo considerar para la construcción de edificios, ir edificando en pequeños incrementos, revisar lo hecho sobre el terreno, y derribar lo que se considere erróneo o mejorable, para rehacerlo de una nueva forma.

• Maleabilidad del producto. Los materiales físicos no son muy maleables. Esta característica refuerza la necesidad de previsión antes de comenzar la construcción de un sistema, porque una vez desarrolladas cada una de las partes o módulos, no es posible su cambio, amoldando lo ya construido. Pero el software no es físico, la maleabilidad puede ser muy elevada si se tiene en cuenta como opción de desarrollo, para acometer ampliaciones y modificaciones del sistema con técnicas de refactorización. El producto software es “moldeable”.

• Valor aportado por las personas. Cuando el grueso del conocimiento reside en los procesos, y las personas aportan capacidad de ejecución en forma de tareas mecánicas o supervisión, la diferencia de productividad o calidad si el trabajador es mejor o peor, no es muy significativa. En la cocina de un Telepizza, que el operario tenga más o menos talento influye muy poco en el resultado. Sin embargo, cuando el grueso del conocimiento reside en las personas, que aportan el talento, y los procedimientos son quienes ayudan a las personas, las diferencias de los resultados entre los mediocres y los mejores son muy relevantes.

• Factor de escala del producto. Algunos productos tienen factores de escala escasos: aumentar el número de unidades realizadas, supone incrementos de proporciones similares en el coste de fabricación. El software tiene un factor de escala prácticamente infinito: cuesta lo mismo producir uno que miles. 

La maleabilidad del producto y el reducido coste de la materia prima permiten plantear ciclos de construcción ágil, pequeños incrementos en iteraciones breves, durante los que se van refinando y descubriendo nuevos requisitos. Un modelo de gestión que parecería absurdo en otras industrias, no lo es tanto si atendemos a las características propias de la industria del software, diferentes a las del resto. La necesidad de desarrollar nuevas formas de ingeniería viene dada por la propia naturaleza intangible del software. Si construir puentes se pareciese a construir software, entonces indicando en la configuración “3 pilares” el puente mágicamente se levantaría sustentado en tres pilares, tras cambiar la configuración a “4 pilares” observaríamos cómo inmediatamente cuatro pilares sostienen el puente.