Metodología Métrica

Definición oficial: MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistemas de información promovida por el Ministerio de Hacienda y Administraciones Públicas de España, de uso obligatorio en la Administración General del Estado.

¿Qué es Métrica v3?

La versión vigente es Métrica Versión 3 (2001). Cubre el proceso de desarrollo completo, desde la planificación hasta el mantenimiento. Está basada en el estándar ISO/IEC 12207 (ciclo de vida del software) y es compatible con estándares como ISO 9000 y CMMI.

Su objetivo es proporcionar un marco normativo que permita obtener sistemas de información de calidad, que satisfagan las necesidades de los usuarios dentro del tiempo y presupuesto previstos.

Estructura general de Métrica v3

Proceso	Acrónimo	Descripción
Planificación de Sistemas de Información	`PSI`	Define el marco de referencia tecnológico y organizativo
Desarrollo de Sistemas de Información	`DSI`	Contempla las actividades de análisis, diseño, construcción e implantación
Mantenimiento de Sistemas de Información	`MSI`	Gestión de cambios en el sistema tras su puesta en producción

Procesos de Desarrollo de Sistemas de Información (DSI)

El proceso de desarrollo se articula en los siguientes subprocesos o fases:

EVS

Estudio de Viabilidad

ASI

Análisis del Sistema

DSI

Diseño del Sistema

CSI

Construcción

IAS

Implantación y Aceptación

Fase	Sigla	Objetivo principal	Producto clave
Estudio de Viabilidad del Sistema	`EVS`	Analizar si el sistema es viable técnica, económica y operativamente	Informe de Viabilidad
Análisis del Sistema de Información	`ASI`	Obtener una especificación detallada del sistema	Especificación de Requisitos Software (ERS)
Diseño del Sistema de Información	`DSI`	Definir la arquitectura del sistema y sus componentes	Especificación de Diseño
Construcción del Sistema de Información	`CSI`	Desarrollar y probar el sistema	Código fuente, manuales
Implantación y Aceptación del Sistema	`IAS`	Poner en producción el sistema con aceptación del usuario	Sistema en producción

Interfaces con otros procesos (transversales)

Gestión de Proyectos (GP)

Planifica y controla el proyecto en todas sus fases. Es transversal a todo el ciclo de vida.

Seguridad (SEG)

Garantiza la seguridad en todos los procesos del ciclo de vida del sistema.

Gestión de la Configuración (GC)

Control de versiones, cambios y productos generados a lo largo del proyecto.

Aseguramiento de la Calidad (CAL)

Verifica que los productos y procesos cumplan los estándares de calidad establecidos.

Técnicas y prácticas soportadas por Métrica v3

Técnica	Aplicación en Métrica
Orientación a Objetos (OO)	Utiliza UML como lenguaje de modelado en ASI y DSI
Estructurado	Diagramas de flujo de datos (DFD), entidad-relación en ASI y DSI
Casos de Uso	Para captura de requisitos funcionales en ASI
Prototipos	Recogida y validación de requisitos con el usuario
JAD / RAD	Talleres de trabajo estructurado con usuarios

Modelos de Ciclo de Vida

Concepto clave: El ciclo de vida del software define las fases por las que pasa un sistema desde su concepción hasta su retirada. Métrica v3 admite distintos modelos de ciclo de vida según las características del proyecto.

Modelo en Cascada (Waterfall)

El modelo más clásico. Las fases se ejecutan de forma secuencial y lineal. Cada fase produce un entregable que sirve de entrada a la siguiente. No se avanza a la siguiente fase hasta completar la anterior.

Característica	Descripción
Estructura	Secuencial, lineal, sin retorno
Ventajas	Simple, bien documentado, fácil de gestionar, claro para proyectos con requisitos estables
Inconvenientes	Poca flexibilidad ante cambios, el cliente no ve el producto hasta el final, errores tardíos son costosos
Uso recomendado	Proyectos con requisitos bien definidos y poco cambiantes

Modelo en Cascada con Realimentación

Variante del anterior que permite retroceder a fases anteriores cuando se detectan errores o cambios. Es el modelo base de Métrica v3.

En Métrica v3: Se permite la retroalimentación entre fases contiguas (ej.: desde DSI se puede volver a ASI para refinar requisitos).

Modelo en Espiral (Boehm, 1988)

Combina el desarrollo iterativo con el análisis de riesgo. Cada ciclo de la espiral pasa por cuatro cuadrantes:

Cuadrante	Actividad
1. Planificación	Determinación de objetivos, alternativas y restricciones
2. Análisis de riesgo	Evaluación de alternativas, identificación y resolución de riesgos
3. Desarrollo y prueba	Desarrollo del producto del nivel siguiente
4. Evaluación del cliente	Revisión de resultados y planificación del siguiente ciclo

Ventaja principal: Gestión explícita del riesgo en cada iteración. Inconveniente: Complejidad de gestión y aplicable principalmente en proyectos grandes.

Modelo de Desarrollo Evolutivo (Incremental e Iterativo)

Subtipo	Descripción	Diferencia clave
Incremental	Se construye el sistema en incrementos funcionales. Cada incremento añade nueva funcionalidad al anterior	Cada entrega es un subconjunto completo y funcional
Iterativo	Se desarrolla el sistema completo pero de forma refinada en cada iteración, mejorando la versión anterior	Se trabaja sobre el sistema completo desde el inicio, refinándolo

Ambos modelos son apoyados por Métrica v3 mediante el uso de prototipos e iteraciones controladas dentro del proceso de análisis y diseño.

Modelo de Prototipado

Se construye un prototipo inicial (maqueta del sistema) para que el usuario lo evalúe y permita clarificar los requisitos antes del desarrollo definitivo.

Tipo de prototipo	Descripción
Prototipo desechable (Throwaway)	Se construye para clarificar requisitos y luego se descarta. El sistema final se construye desde cero
Prototipo evolutivo	El prototipo evoluciona hasta convertirse en el sistema final. Riesgo de degradación de calidad
Prototipo incremental	Se construyen prototipos de distintas partes del sistema que se van integrando

Modelo RAD (Rapid Application Development)

Orientado a reducir drásticamente el tiempo de desarrollo. Se basa en el uso de herramientas CASE, desarrollo en equipo paralelo y prototipos. Ciclos muy cortos (60-90 días).

Fase RAD	Actividad
Modelado de negocio	¿Qué información maneja el negocio?
Modelado de datos	Identificación de objetos de datos y sus relaciones
Modelado de procesos	Transformaciones para producir la información
Generación de aplicaciones	Construcción con herramientas automáticas (CASE, 4GL)
Pruebas y entrega	Verificación de nuevos componentes

Comparativa de modelos

Modelo	Requisitos	Riesgo	Participación usuario	Documentación
Cascada	Estables, bien definidos	Alto (se detecta tarde)	Inicio y fin	Exhaustiva
Espiral	Pueden evolucionar	Gestionado explícitamente	En cada ciclo	Alta
Incremental	Pueden añadirse	Medio	En cada incremento	Media
Prototipado	Difusos, cambiantes	Bajo (se valida pronto)	Continua	Baja/media
RAD	Bien conocidos, acotados	Bajo-medio	Muy alta (workshops)	Reducida

Gestión del Proceso de Desarrollo

Objetivos del Desarrollo

Satisfacción de requisitos

El sistema debe cumplir todas las necesidades funcionales y no funcionales establecidas por los usuarios.

Calidad del producto

El software debe ser correcto, fiable, eficiente, usable, mantenible y portable (según ISO/IEC 25010).

Cumplimiento de plazos

Entregar el sistema en los tiempos acordados con el cliente/organización.

Control de costes

Ajustarse al presupuesto estimado. Evitar desviaciones mediante seguimiento continuo.

Gestión del riesgo

Identificar, analizar y mitigar los riesgos que pueden afectar al proyecto a lo largo de su ciclo de vida.

Comunicación y coordinación

Garantizar una comunicación fluida entre todos los agentes implicados en el proyecto.

Triángulo de hierro: Los tres vértices clásicos son alcance, tiempo y coste. La calidad es la resultante del equilibrio entre los tres. Si se modifica uno, al menos uno de los otros dos se ve afectado.

Actividades de Gestión

En Métrica v3, la Gestión de Proyectos (GP) es un proceso transversal con las siguientes actividades principales:

Actividad de Gestión	Descripción	Herramientas/técnicas
Inicio y planificación	Definición del alcance, recursos, plazos y estructura del proyecto. Elaboración del Plan de Proyecto	WBS, diagrama de Gantt, PERT/CPM
Estimación	Cálculo del esfuerzo, coste y duración del proyecto	Puntos de función, COCOMO, juicio experto, Planning Poker
Planificación de riesgos	Identificación de riesgos, evaluación de su probabilidad e impacto, y definición de planes de contingencia	Matriz de riesgos, registro de riesgos
Seguimiento y control	Comparación entre lo planificado y lo real. Detección y corrección de desviaciones	Informes de seguimiento, valor ganado (EVM)
Gestión de recursos humanos	Asignación de roles, responsabilidades y perfiles al equipo de proyecto	Matriz RACI, organigrama del proyecto
Gestión de la comunicación	Definición de los flujos de información entre interesados (stakeholders)	Plan de comunicación, actas de reunión
Gestión de cambios	Control formal de las solicitudes de cambio sobre alcance, requisitos o diseño	Formularios de cambio, registro de cambios
Cierre del proyecto	Aceptación formal, lecciones aprendidas y archivo de documentación	Acta de cierre, informe final

Desarrollo en Fases

El desarrollo en fases permite dividir el proyecto en etapas claramente delimitadas, cada una con entradas, salidas (productos o entregables) y criterios de finalización definidos.

Fase de Inicio / Concepción FASE 0

Identificación de la necesidad o problema
Estudio de viabilidad preliminar (EVS)
Definición del alcance inicial del sistema
Identificación de los principales interesados (stakeholders)

EVS Viabilidad técnica, económica y operativa

Fase de Análisis ASI

Obtención y especificación detallada de requisitos (funcionales y no funcionales)
Modelado del negocio y del sistema actual
Definición de casos de uso
Elaboración del modelo de datos conceptual
Resultado: Especificación de Requisitos Software (ERS)

ERS Casos de uso Modelo entidad-relación

Fase de Diseño DSI

Diseño de la arquitectura del sistema (capas, subsistemas, componentes)
Diseño de la base de datos (modelo lógico y físico)
Diseño de interfaces de usuario
Diseño de la seguridad del sistema
Resultado: Especificación de Diseño

Arquitectura BBDD Interfaces

Fase de Construcción CSI

Codificación de los componentes software
Pruebas unitarias y de integración
Elaboración de manuales (técnico, usuario, explotación)
Formación del equipo de operación
Resultado: Sistema construido y probado

Código fuente Pruebas Manuales

Fase de Implantación y Aceptación IAS

Pruebas de aceptación con los usuarios
Paso a producción (migración de datos, instalación)
Formación a los usuarios finales
Cierre del proyecto y traspaso al mantenimiento (MSI)
Resultado: Sistema en producción aceptado por el usuario

Pruebas de aceptación Paso a producción

Tareas y funciones de los distintos agentes

Métrica v3 define claramente los participantes (agentes) del proceso de desarrollo, sus roles y sus responsabilidades:

Agente	Rol en Métrica	Responsabilidades principales
Jefe de Proyecto	Dirección y coordinación	Planificación del proyecto, seguimiento y control, gestión de riesgos, comunicación con los interesados, toma de decisiones ejecutivas
Consultor	Asesoramiento técnico/metodológico	Apoya en la elección de técnicas y herramientas, revisa la aplicación de la metodología, propone mejoras de proceso
Analista	Análisis y especificación	Obtención y especificación de requisitos, modelado funcional y de datos, elaboración de la ERS, validación con usuarios
Analista-Programador	Análisis técnico y desarrollo	Diseño técnico detallado, desarrollo de componentes complejos, pruebas de integración
Programador	Construcción del software	Codificación de componentes, pruebas unitarias, corrección de defectos en construcción
Técnico de Sistemas	Infraestructura y entorno	Definición del entorno tecnológico, instalación y configuración de herramientas, soporte al equipo de desarrollo
Técnico de Comunicaciones	Redes y comunicaciones	Diseño de la arquitectura de red, seguridad de comunicaciones, integración con otros sistemas
Responsable de Seguridad	Seguridad del sistema	Definición de políticas de seguridad, revisión de controles, análisis de riesgos de seguridad
Responsable de Calidad (CAL)	Aseguramiento de calidad	Planificación y seguimiento del plan de calidad, revisiones e inspecciones, auditorías de proceso
Responsable de Implantación	Despliegue del sistema	Coordinación de la puesta en marcha, migración de datos, formación, pruebas de aceptación
Usuario Experto	Representante del cliente/usuario	Aporta conocimiento del negocio, valida requisitos, participa en pruebas de aceptación, aprueba entregables
Directivo Responsable del Sistema	Patrocinio y supervisión	Aprueba el Plan de Proyecto, asigna recursos, resuelve conflictos de alto nivel, acepta el sistema final

Nota importante para oposición: En Métrica v3 los perfiles no son rígidos: una misma persona puede asumir varios roles (ej.: Analista + Jefe de Proyecto en proyectos pequeños). Lo importante es que las funciones estén cubiertas, no que exista una persona distinta para cada perfil.

Estrategias de Determinación de Requerimientos

¿Qué son los requisitos? Un requisito es una condición o capacidad que el sistema debe satisfacer. La correcta determinación de requisitos es la actividad más crítica del desarrollo: los errores en esta fase son los más costosos de corregir.

Tipos de requisitos

Tipo	Descripción	Ejemplos
Funcionales	Definen qué debe hacer el sistema (funciones, comportamientos)	El sistema debe permitir registrar un nuevo usuario
No funcionales	Definen cómo debe ser el sistema (calidad del servicio)	El tiempo de respuesta debe ser <2 segundos
De información	Datos que el sistema debe almacenar y gestionar	El sistema almacenará nombre, NIF y dirección del cliente
De restricción	Limitaciones impuestas al sistema (tecnología, normativa)	Debe cumplir el RGPD; solo se usará Oracle como SGBD

1. Entrevistas

La entrevista es la técnica más utilizada para la obtención de requisitos. Consiste en una conversación estructurada entre el analista y el usuario o experto del dominio.

Tipo de entrevista	Descripción	Cuándo usarla
Estructurada	Preguntas predefinidas, orden fijo, respuestas cerradas	Cuando se necesita información comparable entre entrevistados
No estructurada	Conversación libre, abierta, guiada por el entrevistado	Para explorar el dominio y descubrir problemas latentes
Semiestructurada	Combinación: preguntas base + libertad para explorar	Situación más habitual en proyectos reales

Fases de la entrevista

Preparación: Definir objetivos, seleccionar entrevistados, elaborar el guión de preguntas, estudiar documentación previa
Apertura: Presentación, explicación del objetivo, creación de un clima de confianza
Desarrollo: Formulación de preguntas (abiertas → cerradas), escucha activa, toma de notas
Cierre: Resumen de lo obtenido, agradecimiento, acuerdo sobre próximos pasos
Análisis y documentación: Transcripción, validación con el entrevistado, incorporación a la ERS

Ventajas	Inconvenientes
Permite explorar en profundidad aspectos complejos Facilita la relación analista-usuario Se pueden aclarar ambigüedades en el momento Útil para obtener requisitos ocultos o implícitos	Consume mucho tiempo (preparación + realización) Dependencia de la habilidad del entrevistador El usuario puede dar respuestas sesgadas o incompletas Difícil llegar a consenso cuando hay múltiples entrevistados

Técnicas complementarias a la entrevista: Cuestionarios (cuando hay muchos usuarios dispersos), observación directa del trabajo del usuario, análisis de documentos existentes.

2. Derivación de Sistemas Existentes

Consiste en obtener los requisitos del nuevo sistema analizando el sistema o sistemas que actualmente se utilizan (manuales o automatizados) para realizar las mismas funciones.

Fuentes de información

Código fuente y documentación del sistema actual
Manuales de usuario y procedimientos operativos
Formularios, listados e informes que genera el sistema actual
Registros de incidencias y solicitudes de cambio históricas
Bases de datos y estructuras de datos existentes

Técnica	Descripción
Ingeniería inversa	Análisis del código existente para deducir la funcionalidad y el diseño del sistema actual
Reingeniería	Análisis y transformación del sistema actual para mejorar su calidad sin cambiar su funcionalidad
Análisis de documentos	Revisión sistemática de manuales, formularios, organigramas y procedimientos
Observación (shadowing)	El analista observa directamente cómo el usuario trabaja con el sistema actual

Ventajas	Inconvenientes
Proporciona una base sólida y probada Facilita la migración de datos del sistema antiguo Reduce el riesgo de omitir funcionalidades existentes Los usuarios confían en lo que ya conocen	Puede limitar la innovación ("copiar lo malo") Los sistemas legados pueden estar mal documentados Se pueden heredar defectos del sistema anterior No contempla nuevas necesidades del negocio

3. Análisis Conjunto de Aplicaciones (JAD)

JAD (Joint Application Development) es una técnica de trabajo en grupo estructurado en el que usuarios, directivos y analistas se reúnen en sesiones de trabajo (workshops) para definir conjuntamente los requisitos del sistema.

Participante JAD	Rol
Facilitador (Líder)	Dirige y modera la sesión. Experto en técnicas de grupo y metodología
Patrocinador	Directivo con autoridad para tomar decisiones
Usuarios clave	Expertos en el negocio, los que más conocen las necesidades
Analistas	Recogen y documentan los requisitos identificados
Representante de TI	Aporta perspectiva técnica y de viabilidad

Ventaja clave del JAD: Permite obtener requisitos consensuados de múltiples partes interesadas en muy poco tiempo, reduciendo drásticamente las iteraciones posteriores. Es especialmente útil en proyectos con muchos usuarios o departamentos implicados.

4. Prototipos

Un prototipo es una versión preliminar, simplificada o parcial del sistema que se construye para que el usuario interactúe con él y pueda identificar sus verdaderas necesidades y validar los requisitos.

Tipo	Descripción	Ejemplo
Maqueta de interfaz (Mockup)	Representación visual estática de las pantallas del sistema, sin funcionalidad real	Wireframes en papel o herramientas como Figma/Balsamiq
Prototipo funcional horizontal	Cubre muchas funcionalidades pero de forma superficial (sin lógica de negocio profunda)	Navegación completa pero sin cálculos reales
Prototipo funcional vertical	Cubre una funcionalidad concreta de forma completa (de principio a fin)	Módulo de altas completo pero no los demás módulos
Prototipo desechable	Se construye solo para validar requisitos; después se descarta y se construye el sistema desde cero	Prototipo de interfaz para confirmar flujo de trabajo
Prototipo evolutivo	Se construye el prototipo y evoluciona hasta convertirse en el sistema final	Aplicaciones web desarrolladas iterativamente

Ciclo del prototipado

Identificación inicial de requisitos: Se recogen los requisitos básicos conocidos
Construcción del prototipo: Se desarrolla rápidamente una versión preliminar
Evaluación por el usuario: El usuario interactúa con el prototipo y proporciona feedback
Refinamiento: Se incorporan las modificaciones indicadas por el usuario
Repetición: Se repite el ciclo hasta que el usuario queda satisfecho con el prototipo
Desarrollo del sistema final: Con los requisitos validados, se construye el sistema definitivo

Ventajas del Prototipado	Riesgos e Inconvenientes
Reduce la ambigüedad en los requisitos El usuario ve el sistema antes de que esté terminado Detecta errores de comprensión muy pronto Mejora la comunicación analista-usuario Aumenta la satisfacción del usuario final	El usuario puede confundir el prototipo con el producto final Riesgo de "parálisis por análisis": bucles interminables de cambios Si el prototipo es evolutivo, puede derivar en un diseño de baja calidad Mayor coste inicial (construir dos veces en prototipo desechable)

Comparativa de técnicas de determinación de requisitos

Técnica	Participación usuario	Coste/tiempo	Mejor para	Riesgo principal
Entrevistas	Media-alta (1 a 1)	Medio	Explorar el dominio, requisitos complejos	Información sesgada por el entrevistado
Cuestionarios	Baja (asíncrona)	Bajo	Muchos usuarios dispersos	Respuestas superficiales, baja tasa de respuesta
Derivación (sistema existente)	Baja (indirecta)	Medio-alto	Sustitución o renovación de sistemas	Heredar defectos del sistema actual
JAD / Talleres	Muy alta (grupo)	Alto puntual, bajo total	Proyectos con muchos stakeholders, consenso urgente	Dificultad de coordinar agendas
Prototipos	Muy alta (iterativa)	Medio-alto	Requisitos difusos, interfaces de usuario	Confundir prototipo con sistema final
Observación directa	Pasiva	Bajo-medio	Procesos en los que el usuario no verbaliza bien sus necesidades	El usuario cambia comportamiento al ser observado

Para la oposición: En la práctica, la obtención de requisitos combina varias técnicas. Métrica v3 recomienda usar entrevistas como base, complementadas con análisis de documentos, observación y prototipos según la naturaleza del proyecto. No existe una técnica perfecta; la combinación adecuada depende de las características del proyecto y del contexto organizativo.

Validación y gestión de requisitos

Una vez obtenidos, los requisitos deben ser validados para garantizar su calidad:

Criterio de calidad	Descripción
Correcto	Refleja fielmente la necesidad del usuario
Completo	Cubre todas las necesidades sin omisiones
Consistente	No hay contradicciones entre requisitos
No ambiguo	Tiene una única interpretación posible
Verificable	Puede comprobarse si el sistema lo cumple o no
Trazable	Puede seguirse desde su origen hasta su implementación
Priorizable	Se puede determinar su importancia relativa