La calidad del producto software no se limita a que el sistema "funcione". Un sistema puede cumplir una función básica y aun así tener mala calidad si es lento, inseguro, difícil de usar, inaccesible, frágil, costoso de mantener o imposible de adaptar.
Los atributos de calidad describen características importantes del producto, más allá de sus funcionalidades. Ayudan a evaluar si el software es adecuado para su contexto de uso.
En este tema veremos qué significa calidad del producto software, cuáles son los atributos más frecuentes y cómo se relacionan con requisitos, diseño, arquitectura, pruebas y mantenimiento.
La calidad del producto software es el grado en que un sistema satisface necesidades explícitas e implícitas de sus usuarios, clientes y demás actores interesados. Incluye comportamiento funcional y características de calidad.
Un producto de software con calidad debería:
Podemos distinguir entre calidad funcional y calidad no funcional.
| Tipo | Pregunta principal | Ejemplo |
|---|---|---|
| Calidad funcional | ¿El sistema hace correctamente lo que debe hacer? | Calcula bien el total de una compra y aplica descuentos correctos. |
| Calidad no funcional | ¿Cómo lo hace y bajo qué condiciones? | Responde en menos de dos segundos, protege datos y es fácil de usar. |
Ambas son necesarias. Una función correcta puede ser inútil si tarda demasiado, expone datos sensibles o resulta incomprensible para el usuario.
La corrección funcional indica si el sistema realiza las funciones esperadas de acuerdo con los requisitos y reglas de negocio.
Ejemplos:
La corrección funcional suele evaluarse con pruebas funcionales, criterios de aceptación, revisiones de reglas y validación con usuarios.
La confiabilidad indica la capacidad del sistema para funcionar correctamente durante un período y bajo condiciones determinadas.
Un sistema confiable:
La confiabilidad es especialmente importante en sistemas críticos, transaccionales o de uso continuo.
La usabilidad se refiere a qué tan fácil y eficiente es para los usuarios lograr sus objetivos usando el sistema. Un sistema usable reduce errores, frustración, capacitación innecesaria y abandono.
Aspectos de usabilidad:
La usabilidad debe evaluarse con usuarios reales o representativos siempre que sea posible.
El rendimiento describe cómo responde el sistema respecto del tiempo, capacidad y uso de recursos. No se limita a "ser rápido"; debe definirse con condiciones concretas.
Algunos indicadores:
Un requisito de rendimiento debe ser medible. "La búsqueda debe ser rápida" es ambiguo; "debe responder en menos de dos segundos para 10.000 registros" es más verificable.
La seguridad busca proteger datos, operaciones, usuarios y recursos frente a accesos no autorizados, uso indebido, pérdida o manipulación.
Aspectos de seguridad:
La seguridad debe considerarse desde el diseño, no agregarse al final como parche.
La mantenibilidad es la facilidad con la que un sistema puede corregirse, adaptarse y mejorarse. Afecta directamente el costo de evolución.
Un sistema mantenible suele tener:
La mantenibilidad suele no verse directamente por el usuario, pero determina qué tan costoso será cambiar el producto.
La disponibilidad indica cuánto tiempo el sistema está operativo y accesible. La recuperabilidad indica qué tan bien puede volver a funcionar después de una falla.
Ejemplos de requisitos:
Estos atributos influyen en arquitectura, infraestructura, monitoreo, respaldo y operación.
La compatibilidad indica si el sistema puede funcionar correctamente con otros sistemas, navegadores, dispositivos o plataformas. La portabilidad indica qué tan fácil es moverlo o adaptarlo a otros entornos.
Ejemplos:
La accesibilidad busca que el sistema pueda ser usado por personas con distintas capacidades, dispositivos y condiciones de uso. No es solo una mejora opcional; en muchos contextos es una necesidad ética, legal y de calidad.
Aspectos de accesibilidad:
La accesibilidad se relaciona con usabilidad, diseño de interfaz y calidad del producto.
Los atributos de calidad pueden entrar en tensión. Mejorar uno puede afectar otro. Por eso se deben priorizar según el contexto.
| Decisión | Mejora posible | Costo o tensión |
|---|---|---|
| Agregar controles fuertes de seguridad. | Mayor protección. | Puede aumentar fricción para el usuario. |
| Optimizar agresivamente rendimiento. | Mejor tiempo de respuesta. | Puede hacer el código más complejo. |
| Dividir el sistema en muchos servicios. | Escalabilidad independiente. | Mayor complejidad operativa. |
| Agregar mucha configuración. | Mayor flexibilidad. | Más riesgo de errores de configuración. |
No hay calidad absoluta. Hay calidad adecuada para un contexto y objetivos determinados.
Los atributos de calidad deben expresarse como requisitos verificables. De lo contrario quedan como deseos generales.
| Deseo ambiguo | Requisito más verificable |
|---|---|
| El sistema debe ser rápido. | El 95% de las búsquedas debe responder en menos de dos segundos con 10.000 productos. |
| El sistema debe ser seguro. | Después de cinco intentos fallidos, la cuenta debe bloquearse durante quince minutos. |
| El sistema debe ser fácil de usar. | Un usuario nuevo debe completar una reserva sin asistencia durante una prueba guiada. |
| El sistema debe estar siempre disponible. | El sistema debe estar disponible el 99% del tiempo mensual durante horario comercial. |
La calidad puede evaluarse mediante distintas técnicas:
La evaluación debe diseñarse según los atributos más importantes para el producto.
Para un sistema de turnos médicos, los atributos de calidad pueden ser tan importantes como las funcionalidades.
| Atributo | Ejemplo de necesidad |
|---|---|
| Corrección | No debe asignar dos pacientes al mismo turno. |
| Seguridad | Los datos personales deben estar protegidos y accesibles solo para roles autorizados. |
| Usabilidad | Un paciente debe poder reservar un turno con pocos pasos. |
| Disponibilidad | Debe estar disponible durante el horario de atención de la clínica. |
| Mantenibilidad | Debe ser posible agregar nuevas especialidades sin modificar muchas partes del sistema. |
| Auditoría | Los cambios de turnos deben registrar usuario, fecha y acción realizada. |
La calidad no se agrega al final. Debe considerarse durante todo el ciclo de vida:
Al trabajar con calidad del producto suelen aparecer errores como:
Algunas buenas prácticas son:
La calidad del producto software es una característica amplia que combina corrección funcional, atributos de calidad y adecuación al contexto. No se logra únicamente probando al final, sino tomando buenas decisiones desde requisitos, arquitectura, diseño, construcción, despliegue y mantenimiento.
Para quien comienza, la idea principal es esta: un producto de software de calidad no solo hace lo pedido; lo hace de manera útil, confiable, segura, eficiente, usable y sostenible para su contexto.
En el próximo tema veremos usabilidad, accesibilidad y experiencia de usuario, profundizando en la calidad desde la perspectiva de las personas que interactúan con el sistema.