ALM, PLM, SE, MBSE, Digital Thread — quien se ocupa del desarrollo de productos avanza por una maraña de siglas. Lo molesto es que la mayoría de estos términos tienen pleno sentido en su contexto respectivo. Pero quien no conoce las relaciones, qué va dónde y cómo en ese contexto, simplemente se confunde. Bullshit bingo, vaya.
ALM es un ejemplo perfecto de ello: Application Lifecycle Management. A veces se refiere a un enfoque de gestión, a veces a una herramienta, a veces a algo completamente distinto. Es hora de poner orden.
ALM como enfoque de gestión
Por un lado, ALM representa un enfoque de gestión integral: se trata de acompañar todo el ciclo de vida de una aplicación o de un software, desde la primera idea pasando por el desarrollo y la operación hasta el mantenimiento y el «end of life». En el caso ideal, participan todas las disciplinas e involucrados: desarrollo, pruebas, operación, gestión de la calidad, product owner, etcétera.
ALM es entonces el marco de gestión bajo el cual los procesos están claramente definidos, las transferencias funcionan sin fricciones y la información es transparente.
ALM como categoría de herramientas
En la práctica, sin embargo, ALM se usa igual de a menudo como sinónimo de una clase determinada de herramientas de software. Nombres como Polarion, Codebeamer, Jira, Azure DevOps o IBM Engineering Lifecycle Management llevan tiempo siendo valores fijos en muchas empresas. Estas herramientas suelen ofrecer toda una gama de funciones:
-
Gestión de requisitos
-
Gestión de pruebas
-
Seguimiento de tareas e incidencias
-
Gestión de cambios y de configuración
-
Trazabilidad (traceability)
-
Informes y automatización
El objetivo: reunir el mayor número posible de pasos del proceso de desarrollo en una sola plataforma, para evitar los traspasos manuales entre sistemas y facilitar la colaboración. A menudo con interfaces hacia sistemas de control de versiones como Git u otros similares.
Por cierto, un mercado en movimiento: Polarion pertenece ahora a Siemens, Codebeamer a PTC. Los grandes proveedores de PLM han incorporado herramientas de ALM a su porfolio de forma deliberada. Solo con eso ya se ve que los límites entre las categorías están lejos de ser fijos. Más sobre esto después.
ALM más allá del desarrollo de software
Muchas de estas «herramientas de ALM» ya no se usan desde hace tiempo solo para proyectos de software. Algunas empresas las utilizan como plataforma central para el Systems Engineering, es decir, para la gestión de productos complejos en los que el software es solo un componente entre muchos.
También me he encontrado con que ALM se usa simplemente como sinónimo de herramientas de gestión de requisitos. No del todo equivocado: en la gestión de requisitos reside, de hecho, una de las grandes fortalezas de las herramientas de ALM habituales. Pero representan bastante más que eso. Quien reduce ALM a la gestión de requisitos deja sin aprovechar gran parte de su potencial.
Precisamente en sectores regulados como la automoción, la tecnología médica o la aviación se aprecia otro patrón: allí, las herramientas de ALM se emplean sobre todo por sus posibilidades de documentación y evidencia (la palabra clave es trazabilidad), no solo por las funciones clásicas de desarrollo de software.
ALM, PLM y Systems Engineering: ¿quién está dónde?
Las veces que internamente hemos «discutido» sobre si ALM está al lado de PLM o forma parte de él, he perdido la cuenta. La respuesta es, a la vez, decepcionante y tranquilizadora: ambas son correctas. Depende de hacia dónde se mire.
En productos puramente de software, ALM es el equivalente de PLM (Product Lifecycle Management): abarca todas las tareas de la gestión del ciclo de vida, solo que referidas al software. ALM está entonces al lado de PLM.
En productos mecatrónicos (productos físicos con componentes de software), en cambio, ALM suele ser un subámbito dentro del PLM, más amplio: PLM dirige el producto completo desde la idea pasando por el desarrollo y la fabricación hasta la retirada de servicio, mientras que ALM se ocupa de los componentes de software. Si es que se quiere hacer esta separación, porque, en el caso ideal, ambos mundos están estrechamente entrelazados, técnica y organizativamente. Por ejemplo, mediante interfaces y una trazabilidad continua, para que los requisitos, los cambios y las evidencias se mantengan coherentes en todas las disciplinas.
PLM y ALM describen el «qué», Systems Engineering el «cómo» y las herramientas son el «con qué»
¿Y cómo encaja Systems Engineering en esto? Aquí también ayuda la distinción del principio:
Si se entiende ALM como categoría de herramientas, el asunto está claro: la herramienta de ALM es un instrumento, Systems Engineering es el conjunto de métodos. En la práctica, las herramientas de ALM se usan por eso con gusto como plataforma para el Systems Engineering: apoyan justo lo que SE exige metodológicamente: colaboración entre disciplinas y trazabilidad continua desde el requisito hasta la prueba.
Si en cambio se entiende ALM como enfoque de gestión, la cosa se complica. Entonces ALM (como PLM también) es más bien un término abstracto que engloba el qué: qué ciclo de vida, qué artefactos, qué responsabilidades se gestionan. Systems Engineering describe el cómo: con qué métodos se desarrolla. Aunque solo para una parte de lo que entra dentro de ALM — por ejemplo, el seguimiento de incidencias, DevOps y el soporte no son, clásicamente, terreno de SE.
Si se quiere resumir en una fórmula: PLM y ALM describen el qué, Systems Engineering el cómo, y las herramientas son el con qué. Como toda fórmula, simplifica, pero como brújula para orientarse en la maraña de términos cumple de sobra.
Conclusión: ALM es lo que cada uno hace de él
Por eso, quien hable de ALM debería detenerse siempre un momento y aclarar a qué se refiere exactamente:
-
¿Se trata del enfoque de gestión transversal?
-
¿De métodos de desarrollo para el desarrollo de software?
-
¿De una herramienta concreta o de una categoría de herramientas?
-
¿De un caso de uso muy específico, como requirements engineering, o del apoyo a otras capacidades de Systems Engineering?
-
¿O del papel de ALM en conjunto con PLM para el producto completo?
La respuesta suele ser: «depende». Y eso también está bien, siempre que todos los involucrados compartan el mismo entendimiento. El bullshit bingo del principio no surge porque los términos estén mal, sino porque se usan sin contexto.
Una cosa más: ALM no es un proyecto que se ejecuta una vez y se da por terminado. Es un campo que evoluciona junto con los productos, los métodos de desarrollo y los requisitos normativos. Eso lo hace exigente y relevante de forma duradera.
ALM es ambiguo, y eso está bien. Lo importante es que todos los involucrados entiendan lo mismo. Y que las herramientas, los procesos y los métodos elegidos encajen con los requisitos reales, no con una imagen genérica de ALM sacada de un manual.
¿Está planeando una iniciativa de ALM o está en medio de uno de estos temas? Hable conmigo sin compromiso: acompaño a empresas en BHC y PROSTEP en estrategia, selección de herramientas e implementación. Con neutralidad de proveedor y desde la práctica.
Preguntas frecuentes
¿Qué significa ALM (Application Lifecycle Management)?
ALM significa Application Lifecycle Management y en la práctica se usa con dos sentidos: por un lado, como enfoque de gestión integral que acompaña a un software desde la primera idea, pasando por el desarrollo y la operación, hasta el end of life; por otro, como denominación de una categoría de herramientas como Polarion, Codebeamer o Azure DevOps. Qué sentido se quiere decir solo se deduce del contexto.
¿Es ALM lo mismo que PLM?
No del todo, depende del producto. En productos puramente de software, ALM es el equivalente de PLM y está a su mismo nivel. En productos mecatrónicos con componente de software, en cambio, ALM suele ser un subámbito dentro del PLM, más amplio, que dirige entonces el producto completo abarcando hardware y software.
¿Qué herramientas se consideran herramientas de ALM clásicas?
Entre las herramientas de ALM más conocidas están Polarion (Siemens), Codebeamer (PTC), Jira, Azure DevOps e IBM Engineering Lifecycle Management. Suelen cubrir en una sola plataforma la gestión de requisitos, la gestión de pruebas, el seguimiento de tareas e incidencias, la gestión de cambios y de configuración, así como la trazabilidad y los informes.
¿Cómo se relacionan ALM y Systems Engineering?
Systems Engineering es el conjunto de métodos, y las herramientas de ALM suelen ser la plataforma para aplicarlo. Si se entiende ALM como categoría de herramientas, las herramientas de ALM apoyan justo lo que SE exige metodológicamente: colaboración entre disciplinas y trazabilidad continua desde el requisito hasta la prueba. Si se entiende ALM como enfoque de gestión, SE describe más bien el «cómo» de una parte de lo que ALM abarca como «qué».
