Métrica

La propuesta del Ministerio de Administraciones Públicas fue el desarrollo de la metodología Métrica para que todas las organizaciones siguiesen el mismo modelo y unificasen los criterios para aportar homogeneidad y eficiencia a las aplicaciones informáticas. El ámbito original de aplicación fue la
administración general del estado español, pero puede ser utilizada por otras administraciones o empresas privadas. La primera versión es de 1989, la segunda versión apareció en 1993 y en el año 2001 apareció la tercera versión (Métrica V3).
¿Qué objetivos persigue la última versión de Métrica? Podemos indicar que los objetivos generales de
Métrica son:
• Satisfacer las necesidades de los usuarios dando una mayor importancia al análisis de
requisitos.
• Mejorar la productividad permitiendo una mayor capacidad de adaptación a los cambios y
teniendo en cuenta la reutilización en la medida de lo posible.
• Facilitar la comunicación entre todos los participantes en el desarrollo teniendo en cuenta su
papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
• Facilitar la operación, mantenimiento y uso de los productos software obtenidos.
• Utilizar las distintas tecnologías que actualmente están conviviendo y los aspectos de gestión que
aseguran que un proyecto cumple sus objetivos en términos de calidad, coste y plazos.
Hemos visto los objetivos que persigue, ¿cómo intenta alcanzar esos objetivos? Veamos las
características de Métrica con las que cumple con los objetivos marcados:
• Tiene en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares
de ingeniería del software y calidad, además de referencias específicas en cuanto a seguridad y
gestión de proyectos. Cumple con el estándar propuesto por Eurométodo.
• En una única estructura, Métrica cubre el desarrollo estructurado (con un enfoque mixto
orientado a procesos, datos y eventos) y el desarrollo orientado a objetos (utiliza UML).
• La automatización de las actividades propuestas en la estructura de Métrica es posible ya que
sus técnicas están soportadas por una amplia variedad de herramientas CASE.
• Ha sido concebida para abarcar el desarrollo completo de sistemas sea cual sea su complejidad
y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y
dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto.
• Es una guía formal que descompone cada uno de los procesos en actividades, y éstas a su vez
en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales
acciones, productos, técnicas, prácticas y participantes.
• Aunque propone una secuencia de pasos, que podría identificarse con una estructura de
cascada, hace una propuesta flexible en la que deja libertad para escoger el orden de realización
de las actividades, pudiéndose realizar en paralelo.
• Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad
intelectual, es decir, el Ministerio de Administraciones Públicas de España.

SSADM

En 1980 el gobierno británico plantea la necesidad de crear una metodología para unificar y
estandarizar los proyectos de software de las distintas administraciones. Así se desarrolló, entre el
Central Computing and Telecommunications Agency (CCTA) y Learmonth and Burchett Management
Systems (LBMS), la metodología SSADM (Structures Systems Analysis and Design Method).
Veamos algunas de las características fundamentales de SSADM
que nos permitan acercarnos a esta metodología:
• Centrada en los usuarios, atendiendo a sus requisitos y su
participación.
• Define de forma clara el proceso de producción, dando
especificaciones acerca de qué hacer, cuándo y cómo.
• Utiliza tres puntos de vista, para orientarse a datos, eventos y procesos.
• Flexibilidad en herramientas y técnicas de implementación, proporcionando un conjunto de
procedimientos para llevar a cabo las distintas tareas del análisis y diseño.

Merise

El proyecto Merise nace en 1977 dentro del centro CTI (Centre Technique d’Information) perteneciente al
Ministerio de Industria Francés. Su objetivo era desarrollar una metodología de desarrollo del software
para cubrir las necesidades tanto de la empresa pública como de las empresas en general. En 1978 se
presentó su primera versión para el sector público, y fue en 1982 cuando el modelo se revisó y se
extendió a las empresas del sector privado. Merise puede ser utilizado para el desarrollo de todo tipo de
sistemas de información, desde aquellos que utilizan bases de datos hasta los que procesan eventos
en tiempo real, y pretende que los proyectos se completen con éxito dentro del costo y tiempos
planeados.
La metodología Merise aportó un ciclo de vida más largo que los existentes anteriormente con un
conjunto definido de etapas. Abarca los aspectos relacionados con:
• La recopilación y validación de la información.
• Capacitación de personal.
• Evaluación de equipos informáticos.
• Análisis, diseño y validación de los procesos.
• Implementación, gestión de costos y tiempos y el desarrollo del código.
Además del ciclo de vida mas largo, esta metodología introduce dos ciclos complementarios:
• El ciclo de abstracción, se basa en la percepción de tres niveles de abstracción (de lo más
abstracto a los más concreto): conceptual (finalidades generales de la empresa), organizativo
(descripción de la organización necesaria para alcanzar los objetivos) y físico (concreción de los
medios software y hardware necesarios). Los tres niveles se desarrollan simultáneamente.
• El ciclo de decisión. En cada etapa del ciclo de vida, cada vez se va bajando más en el nivel de
abstracción (según el ciclo de abstracción), y se toman decisiones, al principio de forma global, y
después de forma más detallada, conforme se va progresando en el trabajo.

metodologías mixtas de la administración

Las administraciones públicas, que también desarrollan aplicaciones software, ¿qué metodología
utilizarán? ¿Sería conveniente disponer de una metodología estándar para toda la administración
pública?
Con la intención de estandarizar los diferentes proyectos informáticos que utilizaban y desarrollaban diferentes administraciones del mismo país, los organismos públicos comenzaron a desarrollar a finales de los años 70 y principios de los 80, metodologías de desarrollo software
basadas en el método estructurado. Sin embargo, como las distintas administraciones necesitaban dar respuesta a proyectos de desarrollo muy diferentes, modificaron y ampliaron las metodologías existentes para adaptarlas a sus necesidades.
Vamos a ver varios ejemplos de este tipo de metodologías, la metodología francesa Merise, la británica
SSADM, la española Métrica, y el Eurométodo propuesto por la Unión Europea para dar homogeneidad a
los proyectos ligados a su organización.

Metodologías orientadas a objetos: RUP

Vimos cómo evolucionaron las metodologías para responder al paradigma de la programación orientada a objetos. Ha habido varias metodologías, pero la que se ha consolidado actualmente y tiene más presencia en la ingeniería del software es el Proceso Unificado (RUP) que utiliza las técnicas proporcionadas por el Lenguajede Modelado Unificado (UML). RUP ha unificado
distintas metodologías y técnicas en una sola metodología. Así, RUP constituye la metodología
estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
Sus principales características son:
• Forma disciplinada de asignar y organizar tareas y responsabilidades (quién, cómo, qué, cuándo).
• Desarrollo iterativo e incremental.
• Proporciona mecanismos de gestión del proyecto administrando horarios y recursos.
• Facilita la gestión de requisitos a través de un proceso completo para su recogida y
documentación guiado por casos de uso.
• Centrada en la arquitectura para buscar su robustez con un producto que tenga el
comportamiento deseado.
• Basada en componentes reutilizables.
• Modelado visual del software utilizando el estándar UML (asegura el uso de herramientas CASE).
• Resulta fácil dividir el sistema en varios subsistemas independientes.

Metodologías Mixtas

 que toman en consideración tanto los procesos como los datos, añadiendo el factor tiempo según un modelo de eventos. Aunque fundamentalmente las metodologías estructuradas respondieron inicialmente a un ciclo de vida de cascada, algunas metodologías estructuradas han evolucionado con el tiempo hacia otros modelos de ciclos de vida incluyendo la posibilidad de realizar prototipos.

Metodologías estructuradas orientadas a datos no jerárquicos

En esta metodología se analizan los datos para crear un modelo que integre las entidades y las relaciones entre ellas. Estas entidades representan los elementos de la organización, por ejemplo una entidad podría ser un proveedor de la empresa. En este caso, los datos no tienen por qué responder a una estructura jerárquica sino que pueden relacionarse de cualquier otra forma, como por ejemplo en la figura, donde no hay una
estructura jerárquica.
Un ejemplo de este tipo de metodología es “Information Engineering” (IE) desarrollada por Martin y
Finkelstein en 1981.