Vaya al Contenido

Modelos - Calidad de Software

Saltar menú
MODELOS
Los modelos aplicados a la calidad del software son marcos conceptuales estructurados que describen atributos, niveles, prácticas o estados deseados de un producto o de un proceso de ingeniería de software. Su objetivo es permitir la comprensión, medición, evaluación y mejora sistemática. A diferencia de las normas formales, algunos modelos son referenciales de la industria o buenas prácticas consolidadas, pero no necesariamente normativas. Pueden orientarse al producto (qué tan bueno es el software) o al proceso (qué tan capaz es la organización para producirlo de forma repetible y controlada).

Propósito
  1. Proporcionar una estructura conceptual para caracterizar la calidad del software o la capacidad de los procesos.
  2. Permitir evaluaciones diagnósticas (assessment) comparando la situación actual con un estado de referencia.
  3. Establecer hojas de ruta de mejora con etapas progresivas.
  4. Alinear prácticas internas con referentes aceptados por el sector.
  5. Facilitar la relación entre requisitos de negocio, requisitos de calidad y procesos de desarrollo y prueba.
Modelos de calidad del producto
Aunque la ISO/IEC 25010 es una norma, su contenido incluye un modelo de calidad ampliamente adoptado para descomponer la calidad del producto en características y subcaracterísticas. Este modelo permite derivar requisitos no funcionales y criterios de aceptación medibles para el software.
Adicionalmente, existen modelos históricos que han influido en la descripción de la calidad del software:
  • Modelo de McCall: agrupa la calidad en factores como operación del producto, revisión del producto y transición del producto; incluye criterios como exactitud, confiabilidad, eficiencia, integridad y usabilidad.
  • Modelo de Boehm: organiza la calidad en utilidad, mantenibilidad y portabilidad, desglosándolas en características más concretas.
  • FURPS/FURPS+ (HP/IBM): clasifica requisitos en Funcionality, Usability, Reliability, Performance, Supportability y, en la extensión “+”, aspectos de diseño, implementación e interfaz.
Uso principal de estos modelos de producto:
  1. Identificación sistemática de atributos de calidad relevantes para el contexto de uso.
  2. Formulación de requisitos de calidad no funcionales.
  3. Trazabilidad entre requisito de calidad, diseño que lo soporta y prueba que lo verifica.
  4. Creación de catálogos organizacionales de requisitos de calidad.
Modelos de madurez y capacidad de procesos
a) CMMI para Desarrollo (CMMI-DEV)
CMMI (Capability Maturity Model Integration) es un modelo de mejora de procesos que define niveles de madurez organizacional y prácticas específicas para áreas de proceso relacionadas con ingeniería, soporte y gestión.
  • Niveles de madurez (1 a 5):
    • Nivel 1: Inicial.
    • Nivel 2: Gestionado.
    • Nivel 3: Definido.
    • Nivel 4: Cuantitativamente gestionado.
    • Nivel 5: Optimización.
  • Áreas de proceso típicas: gestión de requisitos, planificación del proyecto, seguimiento y control, aseguramiento de la calidad del proceso y del producto, gestión de configuración, gestión de riesgos, verificación, validación, integración del producto, desarrollo de requisitos, diseño técnico.
  • Resultados esperados: reducción de la variabilidad del proceso, mayor previsibilidad del desempeño, disminución de defectos, mejor control de proyectos y entregas.
  • Enfoque: evaluación de la capacidad de la organización para aplicar procesos definidos de forma consistente. No es una certificación de producto sino una determinación del nivel de madurez del proceso.
b) ISO/IEC 330xx (evolución de ISO/IEC 15504/SPICE)
La familia ISO/IEC 33000 establece un marco para la evaluación de procesos de software y sistemas mediante niveles de capacidad por proceso. Se compone de varios documentos, entre ellos:
  • ISO/IEC 33001: conceptos y terminología.
  • ISO/IEC 33002: requisitos para la realización de una evaluación.
  • ISO/IEC 33003 y 33004: requisitos para modelos de proceso y modelos de evaluación.
  • ISO/IEC 33020: escala de valoración de la capacidad del proceso.
Características:
  • Escala de capacidad de 0 a 5 por proceso:
    • Nivel 0: Proceso incompleto.
    • Nivel 1: Proceso ejecutado.
    • Nivel 2: Proceso gestionado.
    • Nivel 3: Proceso establecido/definido.
    • Nivel 4: Proceso predecible/medido.
    • Nivel 5: Proceso optimizado.
  • Atributos de proceso: desempeño del proceso, gestión del proceso, definición del proceso, medición y control del proceso, optimización del proceso.
  • Evaluación granular: permite valorar cada proceso de forma independiente sin requerir que toda la organización se encuentre en un mismo nivel.
  • Alineación ISO: adecuado para organizaciones que buscan coherencia con otras normas ISO de sistemas de gestión.
Criterio de selección:
  • CMMI: adecuado cuando se desea un marco integrado y ampliamente difundido para mostrar madurez organizacional completa.
  • ISO/IEC 330xx: adecuado cuando se requiere evaluar y mejorar procesos de forma modular, por áreas específicas, con un enfoque alineado a ISO.
Modelos de madurez de pruebas
a) TMMi (Testing Maturity Model Integration)
TMMi es un modelo que define niveles de madurez específicos para el proceso de pruebas de software.
  • Niveles de madurez:
    • Nivel 1: Inicial.
    • Nivel 2: Gestionado.
    • Nivel 3: Definido.
    • Nivel 4: Medido.
    • Nivel 5: Optimizado.
  • Enfoque: progresión desde pruebas ad hoc hacia pruebas planificadas, definidas, cuantificadas y sujetas a mejora continua.
  • Áreas de proceso típicas: política y estrategia de pruebas, planificación de pruebas, control y monitorización, diseño y ejecución, gestión de entornos de prueba, medición y análisis, prevención de defectos.
  • Beneficio principal: proporciona una ruta de mejora específica para QA, complementaria a modelos de proceso generales (p. ej. CMMI), cuando el objetivo es elevar la capacidad del área de pruebas.
b) Otros modelos de pruebas
En algunos entornos se emplea TPI Next (Test Process Improvement), que organiza la mejora de pruebas en áreas clave (gestión, ciclo de vida, infraestructura, técnicas) y niveles de madurez. Puede utilizarse como complemento para evaluaciones más detalladas de prácticas concretas de prueba.
Modelos de seguridad del desarrollo
a) OWASP SAMM (Software Assurance Maturity Model)
OWASP SAMM es un modelo de madurez para asegurar el software a lo largo de su ciclo de vida. Estructura las prácticas de seguridad en dominios y en niveles de madurez crecientes.
  • Dominios principales (según versión vigente): Gobernanza, Diseño, Implementación, Verificación, Operación.
  • Prácticas: dentro de cada dominio se definen prácticas (por ejemplo, estrategia de seguridad, evaluación de proveedores, requisitos de seguridad, revisión de código, pruebas de seguridad, gestión de vulnerabilidades).
  • Niveles de madurez: cada práctica tiene varios niveles que describen la progresión desde una adopción básica hasta una implantación optimizada y medible.
  • Uso: definición de una línea base de seguridad, establecimiento de objetivos de mejora y seguimiento de implantación de controles de seguridad en el desarrollo.
b) BSIMM (Building Security In Maturity Model)
BSIMM es un modelo de observación que caracteriza las prácticas reales de seguridad en desarrollo en organizaciones maduras. Se utiliza como referencia para compararse con la industria y para identificar brechas en prácticas de seguridad de software.
Otros marcos relacionados
Para organizaciones que prestan servicios de TI además de desarrollar software, pueden considerarse marcos como:
  • ITIL o ISO/IEC 20000 para la gestión del servicio.
  • COBIT para el gobierno de TI.
    Estos marcos no son modelos de calidad de software en sentido estricto, pero proporcionan criterios de control, roles y responsabilidades que pueden integrarse con los modelos anteriores cuando el software forma parte de un servicio gestionado.
Realizado por Yefer Auzaque
Regreso al contenido