Fruto de las visiones predictiva y adaptativa han surgido multitud de metodologías para llevar a cabo las actividades del ciclo de vida del software. Cada metodología implementa el proceso de construcción de software prescribiendo un conjunto de roles, actividades y artefactos:

• Roles. Responden al “quién”. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser interpretado por varias personas. Un rol lleva a cabo un conjunto de actividades y es “dueño” de un conjunto de artefactos. Por ejemplo, “arquitecto”, “programador” o “tester” son roles.

• Tareas. Responden al “cómo”. Las tareas tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún artefacto. Por ejemplo, la “gestión de los requisitos” o la “integración del producto” son tareas.

• Artefactos. Responden al “qué”. Es un trozo de información que es producido, modificado o usado por un proceso. Los artefactos o entregables son los resultados tangibles del proyecto. Por ejemplo, la “matriz de requerimientos” o la “hoja de riesgos” son artefactos.

Podemos agrupar las diferentes metodologías en:

• En cascada. El proyecto discurre en fases secuenciales (unas tareas detrás de otras). Los requisitos son fijados al inicio. 

• Iterativa. Los requisitos son dinámicos y las tareas se repiten hasta la corrección de los prototipos. El producto es mejorado gracias a las demostraciones de funcionamiento de los prototipos interactivos o pruebas de concepto. 

• Incremental. El proyecto se basa en varios desarrollos incrementales. Solo se planificaría la primera fase, pues las siguientes se van definiendo conforme avanzan los trabajos de la fase actual. El cliente recibe frecuentes entregas de pequeñas versiones del producto. 

• Ágil. Son proyectos donde no se conoce el alcance y se desarrollan pequeñas porciones del proyecto marcadas por los sprints, al final de las cuales el cliente puede ver lo que se ha desarrollado. Su objetivo es entregar valor de forma frecuente a los clientes.

Ejemplo de metodologías predictivas (en cascada) es la ISO 12207 y su versión española Métrica v3. Por el contrario, Scrum o Kanban son ejemplos de metodologías adaptativas (ágiles). Cabe señalar que Métrica v3 permite diferentes estrategias de implantación:  en cascada, por versiones, con prototipos o de ciclo iterativo.

Existen también metodologías a medio camino entre ambos extremos como RUP (implementación de IBM del Proceso Unificado).

Las metodologías predictivas son más prescriptivas y rígidas que las metodologías ágiles. Una muestra de ello es la cantidad de artefactos contemplados por RUP: Documento de visión, Diagramas de casos de uso, especificaciones de requisitos, Diagramas de requisitos, diagramas de clases, modelo entidad-relación, etc.

Exigir menos artefactos y entregables, no implica necesariamente menor rigurosidad o calidad. Por el contrario, la exigencia de las metodologías ágiles de entregar “software funcionando”, implica un fuerte compromiso del equipo de desarrollo del producto con la calidad. En las metodologías ágiles la calidad del producto software no descansa necesariamente en la cantidad de artefactos o en el “grosor” de los documentos generados sino en el software corriendo en producción.

Frameworks ágiles como Scrum únicamente prescriben tres roles (Scrum Master, Product Owner y Equipo de Desarrollo), cuatro actividades (Dailys, Planning meetings, Demos y Retros) y apenas tres entregables: diagrama de burndown, el backlog y, por supuesto, software desplegado y funcionando.

A pesar de que la visión adaptativa está ampliamente implantada en la industria del software, existen excepciones a tener en cuenta. Dependiendo del tipo de software que se desea construir puede resultar adecuado utilizar metodologías con un punto de vista más predictivo.  Por ejemplo, en el caso de construir un software fuertemente acoplado a otros productos industriales o a dispositivos hardware, como software embebido para equipamiento médico o software de trazabilidad de una línea de producción industrial o software controlador de un avión, pueden resultar adecuados los procesos de gestión predictiva. En estos casos, las características que hacen única a la industria del software se ven atenuadas:

• Maleabilidad del producto. La capacidad del software para ofrecer nuevas funcionalidades (extensibilidad) queda estrechamente ligada a la capacidad evolutiva de los dispositivos físicos al que el software va unido. El software de control de un avión no puede monitorizar un tercer o cuarto motor sin que estos se añadan físicamente. No es posible que el software de trazabilidad de una línea de producción capture el grosor de una tuerca sin que previamente se haya instalado el correspondiente sensor. La capacidad del software para implementar nuevas funcionalidades no resulta tan efectiva en estos casos al verse fuertemente restringida al producto físico en el que el software se embebe.

• Factor de escala del producto. Instalar un nuevo software controlador de un equipamiento médico o de un avión o de una línea de producción requiere construir un nuevo equipo médico o un nuevo avión o una nueva línea de producción. El factor de escala del producto software no ofrece valor al “acoplarse” el software al producto físico.

En estas circunstancias el principal valor que se espera de la metodología de construcción es la correcta planificación, el software es solo uno más de los elementos del producto final. Es imprescindible cumplir los hitos de entrega para coordinar el “ensamblaje” del software con el hardware o dispositivos físicos con los que debe comunicarse. Asimismo, en estos escenarios los procesos del negocio a los que el software debe dar solución han sido muy detallados debido a la necesidad de la industria “manufacturera” de definir el producto físico al que se acoplará el software. No es necesario “descubrir” el producto software, los requisitos vendrán impuestos por el producto físico, las especificaciones del software pueden “recogerse al dictado”.