En el competitivo mercado del desarrollo de software, la velocidad de entrega a menudo entra en conflicto con la estabilidad, seguridad y usabilidad de los sistemas. Aquí es donde los estándares internacionales marcan la diferencia. La norma ISO/IEC 25010 (parte de la familia SQuaRE) proporciona un marco objetivo y riguroso para definir, medir y evaluar la calidad del software.

En este artículo, exploraremos en profundidad qué es la norma ISO/IEC 25010, cómo ha evolucionado en su versión de 2023, y cómo las empresas y desarrolladores pueden utilizarla para construir productos excepcionales.

---

1. ¿Qué es la ISO/IEC 25010?

La ISO/IEC 25010 es un estándar internacional que describe el modelo de calidad para el software y los sistemas informáticos. Forma parte de la serie de normas ISO/IEC 25000, también conocida como SQuaRE (Software Product Quality Requirements and Evaluation).

Este estándar divide la calidad del software en características específicas que pueden ser analizadas, probadas y medidas de manera cuantitativa. Al categorizar los atributos de calidad (lo que comúnmente llamamos requisitos no funcionales), la norma asegura que ningún aspecto crucial del ciclo de vida del software sea ignorado.

---

2. Historia de la norma

Para comprender el estado actual de la calidad del software, es esencial conocer su evolución cronológica:

1. ISO/IEC 9126 (1991 - 2001): El primer esfuerzo serio por estandarizar la evaluación de software. Introdujo las 6 características de calidad originales (Funcionalidad, Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad).
2. ISO/IEC 25010:2011: Una revisión completa de la ISO 9126. Se añadieron dos características clave: la Seguridad (que pasó de ser una subcaracterística a característica de primer nivel) y la Compatibilidad. Se reestructuraron las subcaracterísticas para reflejar la madurez de la industria de internet.
3. ISO/IEC 25010:2023: La versión vigente. Adapta el modelo a la era de la inteligencia artificial, la computación en la nube, DevOps y la alta automatización, introduciendo cambios estructurales de gran relevancia que detallaremos más adelante.

---

3. ¿Qué problema resuelve?

Desarrollar software sin un estándar de calidad claro suele provocar los siguientes problemas:

• Ambigüedad en los requisitos: Frases como “el sistema debe ser rápido” o “la app debe ser segura” no son medibles. La norma proporciona la estructura para traducirlas en métricas exactas.
• Deuda técnica acumulada: Los equipos se enfocan solo en “hacer que funcione” (calidad funcional) descuidando la mantenibilidad, lo que incrementa los costos a largo plazo.
• Fallas críticas en producción: Caídas inesperadas por falta de tolerancia a fallos o brechas de seguridad por falta de cifrado.
• Insatisfacción del usuario final: Interfaces confusas que no responden al contexto real de uso.

La ISO/IEC 25010 proporciona un lenguaje común para analistas de negocio, desarrolladores, QAs y clientes, asegurando que todos entiendan qué significa realmente “software de calidad”.

---

4. Familia ISO/IEC 25000 (SQuaRE)

La norma ISO/IEC 25010 no trabaja sola; se sitúa dentro de la familia ISO/IEC 25000, una serie de guías organizadas en cinco divisiones principales:

• ISO/IEC 2500n - División de Gestión de Calidad: Define los modelos, términos y definiciones comunes.
• ISO/IEC 2501n - División de Modelos de Calidad: Contiene la norma ISO/IEC 25010 y modelos complementarios como el de calidad de datos (ISO 25012).
• ISO/IEC 2502n - División de Medición de Calidad: Proporciona fórmulas y métricas específicas para evaluar la calidad (ISO 25022, ISO 25023, ISO 25024).
• ISO/IEC 2503n - División de Requisitos de Calidad: Ayuda a definir los requisitos de calidad que debe cumplir el software (ISO 25030).
• ISO/IEC 2504n - División de Evaluación de Calidad: Establece los requisitos y directrices para el proceso de evaluación del producto de software (ISO 25040, ISO 25041).

---

5. Diferencia entre calidad del producto y calidad en uso

La norma distingue claramente dos modelos de calidad interrelacionados:

Calidad del Producto Software

Se enfoca en las propiedades estáticas y dinámicas del software en sí mismo (código, arquitectura, comportamiento en ejecución). Es el modelo que evalúan los desarrolladores, arquitectos y analistas de QA durante las pruebas de caja blanca y negra.

Calidad en Uso

Se refiere al impacto que tiene el software cuando es utilizado por un usuario en un contexto específico. No mide el software de manera aislada, sino los resultados de su uso (efectividad, satisfacción, mitigación de riesgos).

---

6. Modelo de Calidad del Producto

El núcleo de la ISO/IEC 25010 es la descomposición jerárquica de la calidad en Características y Subcaracterísticas.

A continuación, detallamos la estructura clásica y cómo cada elemento influye en el producto final.

---

7. Las 8 características de la versión 2011

Analicemos de manera pormenorizada cada una de las 8 dimensiones de la calidad definidas en la versión 2011, detallando sus subcaracterísticas, métricas de medición y errores típicos:

7.1. Adecuación Funcional (Functional Suitability)

Representa la capacidad del producto de software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas del usuario bajo condiciones específicas.

• Subcaracterísticas:
  • Completitud Funcional: Grado en el que el conjunto de funciones cubre todas las tareas y objetivos del usuario especificados.
  • Corrección Funcional: Capacidad para proveer resultados correctos o precisos.
  • Pertinencia Funcional: Grado en el que las funciones facilitan la realización de tareas específicas del usuario.
• Cómo medirla: Porcentaje de casos de uso del negocio cubiertos por el software; tasa de defectos lógicos por funcionalidad entregada.
• Errores comunes: Implementar “gold plating” (añadir características innecesarias) o no validar los flujos de negocio alternativos con los stakeholders.

7.2. Eficiencia de Rendimiento (Performance Efficiency)

Evalúa el desempeño del software en relación con la cantidad de recursos utilizados bajo condiciones determinadas.

• Subcaracterísticas:
  • Comportamiento Temporal: Tiempos de respuesta y procesamiento.
  • Utilización de Recursos: Cantidad de CPU, RAM, red y disco consumidos.
  • Capacidad: Límites máximos del sistema (ej. usuarios concurrentes).
• Cómo medirla: Tiempo de respuesta promedio (Latency/RTT), uso porcentual de CPU bajo carga, transacciones por segundo (Throughput).
• Errores comunes: No usar índices en base de datos; consultas SQL ineficientes en bucles; ausencia de capas de caché (como Redis o CDN).

7.3. Compatibilidad (Compatibility)

La capacidad de dos o más sistemas o componentes para intercambiar información y/o realizar sus funciones requeridas compartiendo el mismo entorno de hardware o software.

• Subcaracterísticas:
  • Coexistencia: Compartir un entorno común con otros programas sin afectarlos negativamente.
  • Interoperabilidad: Capacidad de interactuar con otros sistemas (mediante APIs, colas de mensajería, etc.).
• Cómo medirla: Tasa de colisiones de dependencias; porcentaje de conformidad con especificaciones estándar (ej. OpenAPI/REST).
• Errores comunes: Acoplamiento fuerte entre sistemas; no versionar APIs; uso de formatos propietarios en lugar de estándares como JSON o XML.

7.4. Usabilidad (Usability)

El grado en el que el producto puede ser utilizado por usuarios específicos para lograr objetivos determinados con efectividad, eficiencia y satisfacción.

• Subcaracterísticas:
  • Reconocimiento de Idoneidad: Si el usuario entiende rápidamente si el software sirve para lo que necesita.
  • Facilidad de Aprendizaje: Cuánto esfuerzo requiere aprender a usar la herramienta.
  • Operabilidad: Facilidad de control y uso de la interfaz.
  • Protección ante Errores de Usuario: Capacidad del sistema para prevenir fallos cometidos por la interacción del usuario.
  • Estética de la Interfaz: Diseño visual atractivo y agradable.
  • Accesibilidad: Uso por personas con diversidad funcional (normativas WCAG).
• Cómo medirla: Puntuación en la escala System Usability Scale (SUS); tiempo promedio para completar una tarea por primera vez.
• Errores comunes: Falta de mensajes de error descriptivos; navegación confusa; interfaces no adaptables a móviles (Responsive).

7.5. Fiabilidad (Reliability)

Grado en el que un sistema realiza sus funciones bajo condiciones especificadas durante un período de tiempo determinado.

• Subcaracterísticas:
  • Madurez: Frecuencia con la que el sistema falla en condiciones normales.
  • Disponibilidad: Fracción del tiempo en que el sistema está operativo y accesible.
  • Tolerancia a Fallos: Capacidad de operar adecuadamente a pesar de fallos de hardware o software.
  • Capacidad de Recuperación: Habilidad para restaurar datos y estado del sistema tras una interrupción.
• Cómo medirla: Tiempo medio entre fallos (MTBF); porcentaje de Uptime anual (los famosos “nueves”, ej. 99.9%); tiempo de recuperación (MTTR).
• Errores comunes: No configurar respaldos automatizados de base de datos; ausencia de balanceadores de carga; carencia de mecanismos como Circuit Breakers o reintentos (Retries).

7.6. Seguridad (Security)

Protección de la información y los datos de manera que personas o sistemas no autorizados no puedan leerlos ni modificarlos, garantizando el acceso a los autorizados.

• Subcaracterísticas:
  • Confidencialidad: Garantía de que los datos solo son accesibles a quienes tienen autorización.
  • Integridad: Prevención de modificaciones no autorizadas en datos y código.
  • No Repudio: Capacidad de probar que una acción o transacción ocurrió.
  • Responsabilidad: Rastreabilidad de las acciones de un usuario hacia su identidad (auditoría).
  • Autenticidad: Verificación de la identidad de usuarios y sistemas.
• Cómo medirla: Número de vulnerabilidades detectadas en análisis estáticos/dinámicos (SAST/DAST); tiempo de detección y mitigación de brechas.
• Errores comunes: Almacenar contraseñas en texto plano; no implementar cifrado en tránsito (HTTPS/TLS) y en reposo (AES); omitir autenticación multifactor (MFA); no registrar logs de auditoría inmutables.

7.7. Mantenibilidad (Maintainability)

Representa la eficacia y eficiencia con la que el software puede ser modificado por los desarrolladores para corregir errores, mejorar rendimiento o adaptarlo a nuevos requisitos.

• Subcaracterísticas:
  • Modularidad: Nivel de independencia de los componentes del sistema.
  • Reusabilidad: Capacidad de usar activos en otros módulos o proyectos.
  • Analizabilidad: Facilidad de diagnosticar deficiencias o causas de fallos.
  • Modificabilidad: Grado en que puede ser alterado de manera segura y sin introducir regresiones.
  • Probabilidad (Testability): Facilidad con la que se pueden establecer criterios de prueba y ejecutar tests.
• Cómo medirla: Complejidad Ciclomática de McCabe; porcentaje de cobertura de código (Code Coverage); índice de mantenibilidad de SonarQube (de la A a la E).
• Errores comunes: Código espagueti; acoplamiento severo; funciones gigantescas sin pruebas unitarias automatizadas; falta de documentación técnica en la arquitectura.

7.8. Portabilidad (Portability)

Facilidad con la que un sistema o componente puede ser transferido de un entorno de hardware, software u operacional a otro.

• Subcaracterísticas:
  • Adaptabilidad: Capacidad de ajustarse a diferentes entornos de ejecución.
  • Facilidad de Instalación: Esfuerzo necesario para instalar el sistema de forma exitosa.
  • Facilidad de Sustitución: Habilidad para reemplazar un componente por otro similar en el mismo entorno.
• Cómo medirla: Tiempo necesario para portar la aplicación a un nuevo sistema operativo; tasa de éxito de despliegues automatizados en distintos entornos.
• Errores comunes: Uso de rutas absolutas locales; dependencias estrechamente ligadas a un sistema operativo específico; falta de contenedorización (ej. dockerizar la aplicación).

---

8. Cambios importantes en ISO/IEC 25010:2023

La industria del software avanza de forma vertiginosa. Por ello, la actualización del estándar en 2023 introdujo ajustes críticos para alinearse a las necesidades actuales:

Comparativa: ISO/IEC 25010:2011 vs ISO/IEC 25010:2023

Modelo 2011	Modelo 2023	Cambio Principal / Razón
Usabilidad (Usability)	Capacidad de Interacción (Interaction Capability)	Cambio de nombre para enfatizar que el software no solo es “usable”, sino que interactúa bidireccionalmente con el usuario en diversos canales.
Portabilidad (Portability)	Flexibilidad (Flexibility)	Se evoluciona hacia un concepto más amplio. Incluye subcaracterísticas como la Escalabilidad y la Extensibilidad, fundamentales para arquitecturas en la nube.
(No incluido directamente)	Seguridad Física (Safety)	Integrado como característica del producto para evaluar la prevención de riesgos físicos o daños materiales causados por fallos del software (clave en IoT y dispositivos médicos).
Mantenibilidad	Mantenibilidad (Reestructurado)	Mayor foco en la modularidad y la facilidad de mantenimiento continuo dentro de infraestructuras ágiles y DevOps.

Las Nuevas Subcaracterísticas del Modelo 2023:

• Safety: Capacidad del software para mitigar riesgos sobre la vida de los usuarios, propiedad y medio ambiente.
• Flexibilidad Avanzada:
  • Scalability (Escalabilidad): Capacidad de manejar cargas de trabajo crecientes añadiendo recursos de hardware de manera elástica.
  • Inclusiveness (Inclusividad): Garantizar que el software sea accesible para el mayor espectro posible de personas, incluyendo diferencias lingüísticas y cognitivas.
  • Self-descriptiveness (Autodescriptividad): Capacidad del sistema para guiar al usuario en su uso sin necesidad de manuales externos extensos.

---

9. Cómo aplicar la ISO durante un proyecto de software

La calidad no se inyecta al final del desarrollo; se planifica desde la concepción del proyecto. Te mostramos cómo mapearla en cada fase del ciclo de vida del desarrollo de software (SDLC):

A. Fase de Análisis

El analista de negocio traduce las necesidades del cliente en objetivos de la ISO.

• Ejemplo: Si el cliente pide “que aguante muchas visitas”, se define un requisito de Eficiencia de Rendimiento - Capacidad: “El sistema debe soportar hasta 10,000 usuarios concurrentes con un tiempo de respuesta inferior a 2 segundos”.

B. Fase de Diseño

El arquitecto diseña el sistema basado en los atributos de calidad seleccionados.

• Ejemplo: Para asegurar la Fiabilidad, se opta por una arquitectura basada en microservicios balanceados, con bases de datos replicadas y un patrón Circuit Breaker.

C. Fase de Desarrollo

Los desarrolladores implementan buenas prácticas de código que aseguren la Mantenibilidad (SOLID, Clean Code) y la Seguridad (validación de entradas, control de accesos).

D. Fase de QA

El equipo de QA no solo busca bugs visuales, sino que ejecuta pruebas automáticas enfocadas en las características no funcionales: de estrés (Rendimiento), de penetración (Seguridad) y de mutación (Mantenibilidad).

---

10. Cómo medir cada característica

La norma ISO/IEC 25023 proporciona métricas formales. A nivel práctico en ingeniería, podemos agruparlas de la siguiente forma:

1. Rendimiento:
   • Tiempo de respuesta: Latencia media de las peticiones HTTP.
   • Consumo de recursos: Monitoreo de RAM, CPU y almacenamiento en AWS/GCP.
2. Seguridad:
   • Vulnerabilidades: Clasificadas mediante el estándar CVSS (Common Vulnerability Scoring System).
   • Cobertura SAST: Defectos críticos de seguridad detectados por análisis estático de código.
3. Mantenibilidad:
   • Deuda Técnica: Estimada en horas/días de desarrollo necesarios para corregir problemas de calidad de código.
   • Complejidad Ciclomática: Número de caminos independientes a través del código. Se debe mantener idealmente por debajo de 10-15 por función.
4. Usabilidad / Capacidad de Interacción:
   • Tasa de conversión/abandono: Porcentaje de usuarios que inician un proceso y no lo completan.
   • Puntaje SUS: Evaluaciones a través de encuestas estandarizadas post-uso.

---

11. Ejemplo práctico completo: Sistema ERP para Distribución

Supongamos que estamos desarrollando un Sistema ERP en la nube para una empresa distribuidora de mercancías en Ecuador. Apliquemos la norma ISO/IEC 25010:

1. Adecuación Funcional:
   • Requisito: Facturación electrónica autorizada por el SRI.
   • Implementación: Creación de un microservicio específico que consume el WSDL del SRI, valida esquemas XML y firma digitalmente usando algoritmos criptográficos oficiales.
2. Eficiencia de Rendimiento:
   • Requisito: Carga de catálogo de 50,000 productos de forma instantánea.
   • Implementación: Implementación de Redis para almacenamiento en caché de lectura, paginación en base de datos PostgreSQL, e indexación de campos de búsqueda mediante índices B-Tree y GIN.
3. Seguridad:
   • Requisito: Protección de información financiera y de clientes.
   • Implementación: Cifrado de datos sensibles en reposo mediante AES-256; autenticación mediante OAuth 2.0 con tokens JWT firmados; control de acceso basado en roles (RBAC) y logs de auditoría exportados a AWS CloudWatch.
4. Fiabilidad:
   • Requisito: Operar 24/7 sin pérdida de pedidos.
   • Implementación: Despliegue en un clúster de Kubernetes auto-escalable en múltiples zonas de disponibilidad; configuración de copias de seguridad incrementales horarias en Amazon S3.

---

12. Errores comunes al adoptar la norma

• Querer cumplir el 100% al máximo nivel desde el inicio: Es económicamente inviable. Se debe priorizar. Un MVP para validar mercado puede requerir menos mantenibilidad y escalabilidad inmediata que una plataforma bancaria central.
• Confundir calidad funcional con calidad de software: Un software que hace lo que el cliente quiere, pero que tiene un código inmantenible y es propenso a hackeos, no es software de calidad.
• Medir sin actuar: Configurar herramientas como SonarQube para alertar sobre la deuda técnica pero ignorar los reportes en el día a día del equipo de desarrollo.

---

13. Beneficios para empresas

• Retorno de Inversión (ROI): Reducción drástica de costos de mantenimiento correctivo a largo plazo.
• Ventaja Competitiva: Ofrecer un producto certificado bajo estándares internacionales transmite confianza inmediata a clientes corporativos.
• Mitigación de Riesgos: Menor probabilidad de demandas o multas debido a pérdida de datos o interrupciones severas del negocio.

---

14. Beneficios para desarrolladores

• Menos estrés en producción: Sistemas predecibles, tolerantes a fallos y fáciles de monitorear.
• Crecimiento profesional: Trabajar bajo estándares internacionales eleva el nivel técnico del programador y facilita el uso de mejores prácticas globales.
• Código limpio y legible: Arquitecturas mantenibles que permiten añadir nuevas funcionalidades sin miedo a romper el código existente.

---

15. Relación con metodologías ágiles (Scrum)

En entornos ágiles, la calidad no es una fase separada. Los criterios de la ISO/IEC 25010 deben incluirse directamente en:

• Definition of Ready (DoR): Definir los requisitos no funcionales necesarios antes de iniciar el sprint.
• Definition of Done (DoD): Para dar una tarea por terminada, debe pasar validaciones específicas (ej. “Tener cobertura de pruebas unitarias > 80%”, “Sin vulnerabilidades críticas de seguridad”).

---

16. Relación con DevOps

DevOps proporciona la infraestructura tecnológica para hacer operativa la ISO/IEC 25010. A través de flujos automatizados de Integración Continua y Despliegue Continuo (CI/CD), se ejecutan de manera transparente comprobaciones de mantenibilidad, análisis estático de vulnerabilidades y pruebas automatizadas de rendimiento ante cada cambio en el código.

---

17. Relación con QA

El rol de QA se transforma de un “buscador de fallos visuales” a un Ingeniero de Calidad de Software. Este profesional diseña estrategias para probar sistemáticamente cada una de las 8 dimensiones de la norma, asegurando que las pruebas funcionales y no funcionales tengan el mismo peso en el proceso de desarrollo.

---

18. Conclusiones

La norma ISO/IEC 25010 no es un conjunto de reglas teóricas para archivar en una carpeta de procesos. Es una herramienta práctica e indispensable para cualquier empresa de tecnología que aspire a construir software robusto, escalable y seguro.

Al comprender la diferencia entre la calidad del producto y la calidad en uso, y al adoptar los cambios de la actualización de 2023 (como la introducción de Safety y la Flexibilidad), los equipos de desarrollo adquieren un mapa claro hacia la excelencia técnica.

---

¿Necesitas evaluar o mejorar la calidad de los sistemas de tu empresa? En INNODEV SOLUTIONS aplicamos estándares internacionales en cada línea de código. Contáctanos y agenda un diagnóstico de tu software.

---

Referencias Oficiales y Recursos de Consulta:

• Portal oficial de la familia de normas ISO 25000 (SQuaRE)
• Estándar internacional ISO/IEC 25010:2023 (Systems and software engineering)
• Guía de Ciberseguridad y mejores prácticas de desarrollo seguro por OWASP Foundation
• Estándares de calidad y documentación de desarrollo en Google Developers y Microsoft Learn