El costo oculto de lo no funcional: cómo dimensionar bajo ISO 25010 y escenarios SEI en preventa B2B

Introducción

En el ciclo comercial de servicios tecnológicos y desarrollo de software B2B, existe una tendencia recurrente que drena la rentabilidad: priorizar la funcionalidad visible y descuidar las condiciones bajo las cuales debe operar. Durante las semanas de discovery técnico, equipos comerciales y arquitectos dedican horas a mapear flujos de usuario, detallar campos de entrada y estructurar reglas de negocio. En la propuesta técnica, cada historia de usuario parece impecablemente acotada.

Sin embargo, cuando la solución entra en producción, surge una brecha que desestabiliza los costos operativos. La aplicación procesa transacciones, pero se degrada cuando cientos de usuarios interactúan en simultáneo durante el cierre contable. La sincronización opera según lo previsto, pero satura la red al carecer de paginación eficiente. La base de datos almacena registros, pero incumple los requerimientos de retención o cifrado que la auditoría corporativa del cliente exige al poco tiempo de operar.

En tecnología, los proyectos rara vez colapsan porque un botón falle; fracasan porque nadie dimensionó con rigor los requisitos no funcionales (non-functional requirements o NFRs), conocidos en la ingeniería moderna como atributos de calidad (quality attributes). Presupuestar una solución asumiendo únicamente el "camino feliz" (happy path) funcional equivale a cotizar un puente calculando el peso del concreto, pero omitiendo la fuerza del viento, el tránsito pesado y la resistencia sísmica del terreno.

La anatomía del problema: por qué los adjetivos destruyen márgenes

El desvío financiero en proyectos tecnológicos suele originarse en la ambigüedad con la que se abordan los requisitos no funcionales en los pliegos de condiciones y cotizaciones. Con frecuencia, las especificaciones incluyen enunciados como:

• "El sistema debe ser altamente escalable y tolerante a fallos".
• "La interfaz debe responder de forma rápida e intuitiva".
• "La plataforma debe garantizar la máxima seguridad en los datos".

Para el equipo comercial, estas afirmaciones facilitan el cierre porque generan consenso rápido. Pero para la estimación de costos, representan un cheque en blanco. ¿Qué significa "rápido"? ¿Doscientos milisegundos con diez peticiones concurrentes, o dos segundos bajo un pico de diez mil usuarios? ¿Qué implica "alta disponibilidad"? ¿Un esquema de 99.5 % en horario laboral o un despliegue redundante activo-activo con 99.99 % de tiempo de actividad?

La diferencia entre ambos extremos no es semántica: representa un salto exponencial en horas de ingeniería, infraestructura en la nube (cloud computing), licenciamiento y monitoreo. Cuando esta definición no se fija formalmente en la preventa, el proveedor absorbe la indefinición mediante refactorizaciones no presupuestadas o penalizaciones comerciales por incumplimiento de acuerdos de nivel de servicio (SLAs).

El marco normativo: el modelo de calidad de producto ISO/IEC 25010

Para reemplazar la intuición subjetiva por un estándar verificable, la Organización Internacional de Normalización y la Comisión Electrotécnica Internacional desarrollaron la norma ISO/IEC 25010:2023 (Systems and software Quality Requirements and Evaluation – SQuaRE). Este estándar define un modelo jerárquico que organiza los atributos no funcionales en características fundamentales y subcaracterísticas medibles.

Bajo este estándar, la evaluación técnica de una solución examina de manera estructurada características esenciales de calidad:

1. Eficiencia de desempeño (performance efficiency): Comportamiento temporal (latencias y tiempos de respuesta), utilización de recursos (memoria, CPU) y capacidad máxima de procesamiento.
2. Confiabilidad (reliability): Tolerancia a fallos, recuperabilidad ante caídas (RTO/RPO) y disponibilidad operativa continua.
3. Seguridad (security): Confidencialidad, integridad de datos, no repudio, trazabilidad de accesos (accountability) y autenticidad.
4. Mantenibilidad (maintainability): Modularidad de la arquitectura, reusabilidad de componentes, modificabilidad y comprobabilidad mediante pruebas automatizadas.
5. Flexibilidad y compatibilidad (flexibility and compatibility): Coexistencia con otras aplicaciones, adaptabilidad a nuevos entornos e interoperabilidad mediante interfaces estandarizadas.

Cuando el equipo de preventa utiliza el marco ISO/IEC 25010 como guía de control técnico, transforma deseos dispersos en una matriz rigurosa de análisis. Ya no se indaga si el cliente necesita "seguridad", sino cuáles son sus políticas específicas de cifrado, cuál es la ventana exigida de retención de auditoría y qué esquemas de segregación de roles deben implementarse.

De la teoría al presupuesto: los escenarios de atributos de calidad del SEI

Si bien la norma ISO proporciona la taxonomía, las organizaciones necesitan un método para traducir estos atributos en estimaciones concretas de esfuerzo y costo. Aquí resultan determinantes los aportes del Software Engineering Institute (SEI) de la Universidad Carnegie Mellon.

Las investigaciones del SEI en diseño arquitectónico guiado por atributos (Attribute-Driven Design) demuestran que los requisitos de calidad deben formularse como escenarios de atributos de calidad (quality attribute scenarios). Un escenario convierte un adjetivo abstracto en un caso de prueba observable y presupuestable, estructurado en seis componentes cardinales:

1. Fuente del estímulo (stimulus source): Quién o qué genera la acción (un usuario interno, un sistema externo o una falla de infraestructura).
2. Estímulo (stimulus): La condición concreta que impacta al sistema (la llegada masiva de mil solicitudes por segundo o la caída de un nodo de base de datos).
3. Artefacto afectado (artifact): El componente arquitectónico bajo prueba (la pasarela de APIs, el motor de persistencia o la cola de mensajería).
4. Entorno (environment): El estado operativo del sistema al momento del evento (operación normal o sobrecarga pico de tráfico).
5. Respuesta (response): La acción técnica que el sistema debe ejecutar (procesar peticiones encoladas o activar conmutación por error).
6. Medida de respuesta (response measure): El criterio cuantitativo y verificable que determina el éxito (latencia inferior a trescientos milisegundos en el percentil noventa y cinco, cero pérdida de transacciones o recuperación automática en menos de dos minutos).

Al redactar cada requisito no funcional crítico como un escenario con su respectiva medida de respuesta, el equipo de preventa obtiene un insumo técnico inequívoco. Con esa medida, el arquitecto selecciona patrones de diseño adecuados (caché distribuida, balanceo de carga o persistencia replicada) y calcula con precisión el costo de infraestructura y las horas de desarrollo necesarias.

Prácticas operativas para dimensionar lo no funcional en preventa B2B

Para incorporar esta disciplina en la estructuración de propuestas tecnológicas, los equipos de preventa y liderazgo técnico pueden aplicar tres prácticas operativas:

• Conducir un taller de atributos de calidad en el descubrimiento: Antes de cerrar la estimación económica, convocar una sesión técnica focalizada en interrogar los escenarios límite del cliente. Identificar qué procesos son intolerantes a la latencia, qué datos exigen regulaciones estrictas de custodia y cuáles son las ventanas tolerables de mantenimiento.
• Vincular cada requerimiento no funcional con su componente de costo: En la hoja de dimensionamiento, asociar explícitamente cada escenario de calidad con su impacto arquitectónico directo: dimensionamiento de cómputo en la nube, licencias de middleware y horas de aseguramiento de calidad (quality assurance). Si el cliente solicita reducir el costo, se evidencia de inmediato qué nivel de rendimiento o disponibilidad se vería afectado.
• Documentar los supuestos de carga como límites contractuales: Si la solución fue dimensionada para procesar hasta quinientas solicitudes por minuto con un tiempo de respuesta de medio segundo, ese parámetro debe figurar en el anexo técnico del contrato. Cualquier incremento posterior en el volumen operativo del cliente se gestiona de manera natural como un escalamiento de infraestructura, protegiendo la salud financiera del proveedor.

Reflexión final: la precisión como ventaja competitiva

En el mercado B2B, la sofisticación técnica no se demuestra aceptando pliegos ambiguos con promesas de omnipotencia, sino demostrando la solvencia metodológica necesaria para hacer visible lo invisible. Quien dimensiona con precisión los atributos de calidad no encarece artificialmente sus propuestas; previene el desangre operativo que sufren las empresas que cotizan ilusiones funcionales para luego negociar adendas conflictivas en fase de entrega. Respaldar el dimensionamiento técnico en estándares internacionales y marcos de ingeniería consolidados es la única garantía de construir soluciones viables, contratos sostenibles y relaciones de largo plazo basadas en la confianza mutua.

Fuentes

• ISO/IEC 25010:2023 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model
• Building Quality Software: 4 Engineering-Centric Techniques | CMU Software Engineering Institute

Imagen: Thirdman en Pexels.