¿Metodología? El Metadodelo SPEM y de nuevo las 4P

¡La metodología! es uno de los leitmotiv en cursos de Ingeniería del Software (y se extiende a cursos de investigación). Para muchos estudiantes la metodología resulta algo muy complejo, difícil y hasta oculto... Si uno lee el Software Engineering Body of Knowledge (SWEBOK) no ve con claridad la metodología, pese a que este documento es la guía para hacer Ingeniería del Software. Y en  varios textos educativos de Ingeniería del Software (y de investigación) tampoco se ve. La metodología se termina confundiendo en un montón de cosas relacionadas que desvían la atención de lo importante.

Pero en el libro The Process of Software Architecting de Peter Eeles y Peter Cripps esto se resuelve de manera ágil sin perder rigurosidad, se simplifica sin trivializar: En el capítulo 3 se cita el metamodelo SPEM (The Software Systems Process Engineering Metamodel Specification) y de manera sencilla se explica lo que finalmente importa en una metodología: ¿quién hace qué, cómo y cuándo? 

Por supuesto que hay muchas otras cosas que importan, como el ¿con qué? (los recursos, en especial financieros) y el ¿por qué?. Pero simplificando (virtud de los ingenieros) la metodología es simplemente eso y lo demás son detalles. El quién son las personas, el qué son los productos, el cómo es el proceso y el cuándo es el proyecto. De manera que llegamos de nuevo a las 4P.

Al hablar de las personas debemos referirnos a las competencias blandas. Al hablar del producto debemos referirnos al código fuente y ejecutable y a su arquitectura. Y al hablar del proceso debemos centrarnos en las prácticas, los patrones, los estilos, los marcos (framework), los lenguajes de programación y cómo logramos satisfacer los requerimientos y los atributos de calidad. Y al rededor de todo eso están las herramientas, pues el  mundo actual nos exige automatizar todo, ser ágiles y digitales. Esto es lo que finalmente nos interesa en un curso de Arquitectura de Software.

En cuanto a los proyectos, no es que no interesen, sino que son otras cosa muy diferente. Son administración, gestión, gobierno y burocracia. Pero si revisamos marcos de referencia de proyectos como Project Management Body of Knowledge (PMBOK) y PRojects IN Controlled Environments (PRINCE), por muy extensos e interesantes y por muchas etapas, fases, iteraciones, áreas, procesos y todo lo demás que se quiera agregar, los proyectos también se pueden simplificar. Se resumen a la triple restricción: alcance, tiempo y costo. Una triple restricción que demanda garantizar la calidad, algo que depende de la arquitectura del  software.

Entonces, al hablar de arquitectura vamos a olvidarnos un poco de los proyectos y a centrarnos en el proceso, el producto, las personas y las herramientas, centrados siempre en la calidad.

A manera de resumen y como recomendación general, conviene memorizar que al hablar de metodología nos referimos siempre a ¿quién (personas) hace qué (alcance y producto), cómo (proceso) y cuándo (tiempo)? Y si hablamos de metodología en el contexto de un proyecto, debemos agregar el con qué (costo),  pues ya teníamos el alcance y el tiempo. Además, lo clave siempre será satisfacer los requerimientos y los atributos de calidad, para resolver problemas, satisfacer necesidades y expectativas, aprovechar oportunidades y generar  un impacto, evolucionar, transformar, cambiar...