Eurométodo, oportunidad para METRICA

Análisis del proyecto europeo de metodología de desarrollo

Euromethod -Eurométodo, EM- proyecto encargado por la Comisión Europea a Eurogroup, consorcio amplísimo encabezado por Sema Group como principal contratante, acaba de pasar la primera prueba de aceptación por Grupo de Compras Públicas (PPG) de la Dirección General III. Desde el actual mes de junio puede empezarse a 'hablar' de EM, primero en sentido propio (se ha desarrollado en los últimos tres años de forma muy reservada) y además de un contenido que ha logrado una madurez lo suficientemente estable como para empezar a levantar los interrogantes que subyacen a una iniciativa tan poderosa.

La opacidad de desarrollo de EM puede crear muchas confusiones que la CE está ahora dispuesta a despejar cuanto antes. Una vez desvelado el contenido, la primera paradoja a desvelar ya es polémica: ¿Eurométodo es un 'método'?

No es un 'método' No lo es, en el estricto sentido informático tradicional adscrito al 'desarrollo' o construcción de Sistemas de Información (SI), empezando por su software (EM prefiere hablar de 'adaptación' del S.I.), pues siempre se parte implícitamente de un estado inicial del proyecto, que es el S.I. 'actual' (existente o virtual).

Puede por tanto estarse básicamente de acuerdo con la definición de Gumersindo García (Documentación de la Jornada Inaugural del Foro español Eurométodo, FOREM, 3.3.94), que explicita como Eurométodo es un 'marco metodológico' de ámbito europeo y del dominio público para la contratación y gestión de servicios de desarrollo y mantenimiento de Sistemas de Información. El marco definirá una interfaz europea común cliente/proveedor de alto nivel para esta clase de proyectos.

Esta definición corresponde a la situación ACTUAL, muy bien descrita por Pere Botella y Gumersindo García (Novática 108, marzo-abril 1994): El mecanismo que actualmente usa el sector público para la adquisición de sistemas de información crea una situación que enfrenta al comprador (o a quien ha de tomar la decisión de compra) ante un amplio rango de métodos de desarrollo que condicionan el contenido de las ofertas, y cuya teoría o cultura subyacente es distinta, lo cual complica extraordinariamente la decisión, al no disponer de elementos de comparación objetivos ... Estas restricciones, que afectan tanto al sector cliente como al proveedor, entran en claro conflicto con las expectativas y necesidades del mercado único europeo. El programa Euromethod trata de resolver esos problemas mediante el desarrollo de un marco común para usuarios y proveedores ... pretende: crear un marco complementario a los métodos existentes para construcción de S.I. ... ayudar a los compradores a evaluar ofertas; asistir a los suministradores en la valoración e interpretación de los requisitos; abrir internacionalmente el mercado de S.I..

¿Qué no es Euromethod? ... No es 'otro método de desarrollo de Sistemas de Información; no compite con los métodos existentes; no aporta elementos para comparar unos métodos con otros ...

Si es un 'método' Pero EM podría considerarse un método de 'desarrollo', si se toma la acepción de éste con un alcance más amplio y no sólo tecnológico.

Esta ambigüedad relativa a la identificabilidad de Eurométodo con un método, no es sólo terminológica: tiene su origen en un deslizamiento del propio proyecto, enfrentado como otros muchos proyectos europeos a equilibrar los nuevos intereses continentales con respetables trayectorias nacionales. Puede afirmarse sin rodeos que en sus primeros pasos (1989), EM se concebía por buena parte de sus primeros impulsores como un 'método' europeo capaz de ir reemplazando progresivamente a la 'torre de babel' actual. Este objetivo, ni utópico ni inalcanzable, pero no alcanzable con realismo a medio plazo, se ha fragmentado en muchas más fases, como el propio proyecto de la 'Europa sin fronteras' (en este caso, tecnológicas).

Así, en el ámbito de los 'lenguajes' metodológicos, el proyecto EM ha conseguido despejar fundamentalmente el intrincado terreno de sus aparentes incompatibilidades (no forzosamente contradictorias), sin reducir por ello las variedades 'dialectales' de los distintos métodos de desarrollo, pero preparándolas para un tratamiento 'sintáctico' a fondo, en cuanto a conceptos y reglas correspondientes (y que no forzosamente conducen a una clasificación cualitativa y no cuantitativa, que en cierta forma equivaldría en el terreno de los lenguajes a juzgar si el inglés es 'mejor' que el italiano, por ejemplo).

Dicho en otros términos, EM permite organizar el 'discurso de los métodos' en torno a un objetivo preciso, la 'comunicación' entre los grupos protagonistas finales de cualquier proyecto, el cliente-impulsor y el proveedor; y con una 'herramienta gramatical' bien definida, basada en 'modelos' que articulan 'guías'. Por otra parte, no hay que recordar como, detrás de los modelos, están primero las técnicas y después las futuras herramientas de coherencia funcional; mientras que, detrás de las 'guías', están primero las secuencias de procedimientos y productos entregables, así como dependiendo de ellas las futuras herramientas de coherencia documental.

Metamétodos EM se alinea con las tendencias metodológicas que tienden a analizar los conceptos y relaciones subyacentes a la gran mayoría de los métodos tradicionales o nuevos. El modelo V ('Vorgehensmodell' o 'modelo avanzado') es un ejemplo ilustrativo de dicha tendencia, adoptado como norma por la Administración Pública alemana por lo que forma parte del núcleo metodológico europeo preanalizado para acotar la estructura del propio EM, en cuya modelización parece que ha sido muy influyente. Así, este modelo V, orientado al proceso de 'adaptación' de S.I., define en su interno todas las posibles actividades de un tipo abstracto de proyectos, junto a los cambios de estado que determinan en los resultados; y además articula en su entorno sendos submodelos de desarrollo de productos/resultados, de aseguramiento de calidad, de gestión del proyecto y de gestión de configuraciones.

El 'interno' del modelo V comprende no sólo las actividades de desarrollo y producción de software, sino que articula con ellas las demás actividades de los otros submodelos del 'entorno', asignándoles unos estados y unos responsables abstractos con roles definidos. Esta consideración centrada en actividades, tareas, estados, roles y resultados/productos, tiene una infraestructura conceptual similar a la que subyace a la gestión de flujos de trabajo (Work Flow Management), ligados por otra parte a la reingeniería de procesos de organizaciones (Business Process Reengineering) y al paradigma 'groupware' (¿el desarrollo y adaptación de S.I. no es un típico trabajo de equipos?).

Areas de trabajo y submodelos Como V y muchos otros métodos (entre ellos el español METRICA v.2 del sector público), EM define como áreas de trabajo los submodelos en la 'adaptación' de un S.I. que constituyen el entorno de su 'desarrollo' en sentido estricto, mencionando específicamente los tres sistemas de gestión de proyecto, calidad y configuración.

Otros submodelos se están incorporando al flujo central de 'adaptación' de S.I., en toda su extensión (seguridad, arquitecturas, métricas) o en ciertos tramos bien definidos.

El grado de articulación en los proyectos de estos submodelos con él, promete ser uno de los aspectos más importantes de las perspectivas metodológicas; junto a un tratamiento contractual de los proyectos como el que tipifica a EM; así como el necesario desglose de los componentes de todo método con ambición 'universal' entre un núcleo siempre presente que 'engancha' un 'utillaje' específico adaptado al tipo de aplicación o 'trabajo' a realizar (como en una máquina portaherramienta).

La insuficiente integración de los submodelos con el flujo central plantea problemas de contenidos e interfases no bien res

TE PUEDE INTERESAR...

Contenido Patrocinado

Forma parte de nuestra comunidad

 

¿Te interesan nuestras conferencias?

 

 
Cobertura de nuestros encuentros
 
 
 
 
Lee aquí nuestra revista de canal

DealerWorld Digital