ISO/IEC 25010 Aplicada al Desarrollo de Software: Guía Práctica Paso a Paso

Paso 1: Levantamiento y Especificación de Criterios No Funcionales (Fase de Análisis)

El 80% de los problemas de rendimiento y estabilidad en producción nacen en la toma de requisitos. Cuando un cliente o Product Owner formula requerimientos ambiguos, el equipo programa a ciegas.

En esta fase, la ISO/IEC 25010 sirve como diccionario de traducción para transformar deseos vagos en criterios de aceptación verificables:

Paso 2: Diseño de la Arquitectura de Software

La arquitectura de una aplicación representa el conjunto de decisiones estructurales más difíciles y costosas de cambiar una vez iniciado el desarrollo. Cada decisión debe responder directamente a uno o más atributos de calidad de la norma.

Decisiones técnicas prioritarias en la arquitectura:

1. Modularidad y Modificabilidad (Mantenibilidad): Implementa una Arquitectura Hexagonal (Puertos y Adaptadores) o Arquitectura Limpia. Separa el núcleo de dominio (reglas puras del negocio) de los adaptadores de infraestructura (controladores HTTP, repositorios de base de datos, clientes de correo). Esto permite migrar de base de datos o sustituir librerías externas sin alterar una sola línea del modelo de negocio.
2. Interoperabilidad (Compatibilidad): Establece contratos de interfaz formales utilizando especificaciones estandarizadas como OpenAPI 3.1 para servicios REST o esquemas tipados con Protocol Buffers para comunicaciones gRPC. Los sistemas externos deben integrarse a través de especificaciones claras y contratos versionados.
3. Resiliencia y Tolerancia a Fallos (Fiabilidad): Aplica el patrón Circuit Breaker en cada llamada a dependencias de red externas. Si un servicio externo comienza a arrojar errores o retrasos anormales, el interruptor se abre para evitar saturar los hilos de ejecución del backend, respondiendo con un comportamiento de contingencia (fallback).

Paso 3: Desarrollo Backend con Código Limpio y Seguridad Defensiva

Durante la fase de construcción, el equipo de desarrollo debe convertir los principios de calidad en hábitos cotidianos de codificación.

Comparativa: Código Monolítico vs. Código Orientado a Calidad

Observa la diferencia entre un código escrito sin estándares frente a una implementación desacoplada y preparada para pruebas unitarias:

// IMPLEMENTACIÓN DEFICIENTE
// Viola el Principio de Responsabilidad Única. Difícil de probar, acoplado y frágil.
async function procesarOrden(ordenData: any) {
  // 1. Validación manual débil (Riesgo de Adecuación Funcional y Seguridad)
  if (!ordenData.clienteId || ordenData.total <= 0) {
    throw new Error("Datos inválidos");
  }
  
  // 2. Consulta SQL directa con riesgo de inyección si no se parametriza
  const query = `INSERT INTO ordenes (cliente_id, total) VALUES ('${ordenData.clienteId}', ${ordenData.total})`;
  await database.raw(query);
  
  // 3. Llamada directa acoplada a servicio de terceros (Riesgo de Fiabilidad)
  const respuestaPago = await http.post("https://api.pagos.com/cobrar", { monto: ordenData.total });
  
  // 4. Envío directo de email dependiente de red
  await smtp.sendMail({ to: "[email protected]", subject: "Orden lista" });
}

// IMPLEMENTACIÓN ORIENTADA A ISO 25010 (Mantenibilidad, Fiabilidad, Seguridad)
// Separación de responsabilidades, inyección de dependencias y código comprobable.
export class ProcesadorOrdenUseCase {
  constructor(
    private readonly validador: ValidadorOrden,
    private readonly ordenRepository: OrdenRepositoryPort,
    private readonly pasarelaPagos: PasarelaPagosPort,
    private readonly notificador: NotificadorPort
  ) {}

  async ejecutar(command: CrearOrdenCommand): Promise<ResultadoOrden> {
    // Seguridad y Adecuación: validación estricta de esquema
    const ordenValida = this.validador.validar(command);

    // Mantenibilidad: persistencia desacoplada mediante interfaz
    const ordenGuardada = await this.ordenRepository.guardar(ordenValida);

    // Fiabilidad: llamada protegida por adaptador con Circuit Breaker y timeout
    await this.pasarelaPagos.cobrar(ordenGuardada.id, ordenGuardada.total);

    // Resiliencia asincrónica: evento emitido a cola de mensajería
    await this.notificador.notificarCreacion(ordenGuardada);

    return new ResultadoOrden(ordenGuardada.id, "PROCESADA");
  }
}

Paso 4: Optimización de Frontend (Interaction Capability & Rendimiento)

El frontend es el punto de contacto directo con el usuario. Las directrices de la versión 2023 de la norma priorizan la Capacidad de Interacción y el Comportamiento Temporal:

Paso 5: Estrategia de Pruebas Automatizadas (La Pirámide de Testing)

El equipo de aseguramiento de calidad (QA) debe articular una estrategia de pruebas que cubra las distintas dimensiones de la norma según la Pirámide de Automatización:

Paso 6: Automatización en CI/CD y Quality Gates Infranqueables

El control de calidad no debe depender de la memoria de las personas ni de listas de verificación manuales. Debe ejecutarse automáticamente en cada git push o Pull Request mediante un flujo de Quality Gate:

# Ejemplo representativo de GitHub Actions con Quality Gate
name: Pipeline de Calidad ISO 25010

on: [push, pull_request]

jobs:
  calidad-y-seguridad:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configurar Entorno
        uses: actions/setup-node@v4
        with:
          node-version: 20

      # 1. Mantenibilidad: Verificación de estilo y complejidad
      - name: Ejecutar Linter y Reglas de Código
        run: npm run lint

      # 2. Adecuación y Mantenibilidad: Pruebas unitarias con umbral de cobertura
      - name: Pruebas Unitarias con Cobertura
        run: npm run test:coverage -- --coverageThreshold='{"global":{"lines":80}}'

      # 3. Seguridad: Análisis Estático de Vulnerabilidades (SAST)
      - name: Escaneo de Seguridad y Deuda Técnica
        uses: sonarsource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

      # 4. Compatibilidad y Portabilidad: Verificación de construcción en contenedor
      - name: Build de Imagen Docker
        run: docker build -t app:${{ github.sha }} .

Paso 7: Observabilidad y Operaciones en Producción

La evaluación de la calidad bajo ISO 25010 no concluye con el despliegue; se valida continuamente mediante la telemetría en tiempo real:

Checklist Práctico de Implementación para el Tech Lead

Utiliza esta lista de verificación paso a paso para auditar el cumplimiento del estándar en tu equipo:

Conclusión

Adoptar la norma ISO/IEC 25010 no requiere cambiar radicalmente la metodología de trabajo ni detener las operaciones del negocio. Se trata de incorporar disciplina técnica en cada paso: definir requisitos medibles, diseñar arquitecturas tolerantes a fallos, escribir código limpio y automatizar las comprobaciones de calidad en el pipeline.

Al ejecutar este proceso paso a paso, los equipos de desarrollo dejan de apagar incendios en producción y construyen sistemas escalables, robustos y rentables para la organización.

Referencias Oficiales y Recursos de Consulta:

• [1] ISO — ISO/IEC 25010:2023: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE). iso.org
• [2] Google Site Reliability Engineering (SRE): Monitoring Distributed Systems and The Four Golden Signals. sre.google
• [3] OWASP Foundation: DevSecOps Guideline and Secure Coding Practices. owasp.org
• [4] W3C Web Accessibility Initiative (WAI): Web Content Accessibility Guidelines (WCAG) 2.2. w3.org/WAI