Calidad: aseguramiento, control, verificación y validación
Qué significa que un software "tenga calidad", por qué es difícil de definir y de comprobar, qué hace la gestión de la calidad en un proyecto, y cómo se relacionan la calidad del proceso, la del producto y la seguridad.
- Definir la calidad del software y explicar las tensiones que la hacen difícil.
- Distinguir aseguramiento, planificación y control de la calidad, y saber por qué la calidad debe ser independiente de la gestión del proyecto.
- Distinguir verificación de validación y clasificar actividades de calidad.
- Usar el modelo ISO/IEC 25010, explicar TQM y la relación entre calidad de proceso y de producto.
Tema 2, diap. 55-66. Objetivo del tema: "conocer el proceso de la gestión de la calidad y las principales actividades de gestión de calidad". Ampliación: verificación vs. validación (las diapositivas no lo nombran, pero es fundamento universal), coste de la calidad, técnicas (revisiones, pruebas, análisis estático), y la versión 2023 de ISO 25010. Hay una discrepancia entre la diap. 64 y la norma sobre dónde está la seguridad; se explica en la sección 5.
1. Qué es la calidad del software
Simplificando, la calidad del software significa que un producto debe cumplir con sus especificaciones. Pero esto no es fácil de conseguir ni de comprobar en software, por tres motivos:Tema 2, diap. 58. Sommerville, Software Engineering, 10ª ed., cap. 24.
- Tensión entre los requisitos de calidad de los clientes (eficiencia, fiabilidad, privacidad…) y los de los desarrolladores (mantenibilidad, reutilización…). El concejal quiere que TusBus sea rápida y fiable; al equipo y a quien lo mantenga dentro de 3 años le importa que el código sea fácil de cambiar. Ambas son calidad.
- Algunos requisitos de calidad son difíciles de especificar de manera inequívoca: "fácil de usar", "mantenible". (Por eso en la lección 4 se insistía en RNF medibles.)
- Las especificaciones suelen ser incompletas y, a menudo, incoherentes: un producto puede cumplir la especificación y aun así no servir.
Por eso la definición moderna va más allá de "cumplir la especificación": el ISO/IEC 25010 la define como el grado en que un sistema satisface las necesidades declaradas e implícitas de sus stakeholders.Diap. 64: "grado en el que un sistema cumple con los requisitos funcionales y no funcionales (ISO/IEC 25010)". "Implícitas" incluye lo que nadie escribió pero todos esperan: que la app no se cuelgue, que no filtre datos.
¿Qué es un código de calidad?
Determinar si un código tiene calidad puede ser subjetivo, pero se supone que un código de calidad:Tema 2, diap. 60.
- Hace lo que debe (en funciones de negocio y de seguridad).
- Sigue un estilo consistente.
- Es fácil de entender.
- Está bien documentado.
- Se puede probar.
- No tiene vulnerabilidades.
- No puede usarse de formas no previstas.
Y por qué importa: la calidad del código influye en la legibilidad, en reducir la probabilidad de errores, en facilitar encontrarlos, en el mantenimiento y evolución, en el trabajo colaborativo, en la reusabilidad y en la seguridad.Tema 2, diap. 57. Conecta con el TCO (lección 14): el mantenimiento es la mayor parte del coste de vida, y su coste depende de la calidad del código.
Las diapositivas citan a tres autores del libro Clean Code (Robert C. Martin, 2008):Tema 2, diap. 61-62.
- Bjarne Stroustrup (creador de C++): el código debe ser elegante y eficiente; lógica directa para que los errores no se escondan, dependencias mínimas, manejo de errores completo. "El código limpio hace una cosa bien".
- Dave Thomas: el código limpio puede leerlo y mejorarlo un desarrollador distinto de su autor; tiene pruebas unitarias y de aceptación, nombres significativos, dependencias explícitas y una API mínima.
- Michael Feathers: el código limpio parece escrito por alguien a quien le importa.
Fíjate en que ninguno habla de "que funcione": eso se da por supuesto. Hablan de que otra persona pueda entenderlo y cambiarlo. Es calidad desde el punto de vista del desarrollador.
2. La gestión de la calidad
La gestión de la calidad se centra en asegurar que se alcanza el nivel de calidad requerido en un producto software. Implica definir normas (estándares internos) de calidad adecuadas y procedimientos para garantizar que se siguen, y debe crear una "cultura de calidad", donde la calidad sea vista como responsabilidad de todos (no sólo del tester).Tema 2, diap. 56.
Las tres actividades
Siguiendo a Sommerville, las diapositivas distinguen tres actividades:Tema 2, diap. 59.
| Actividad | Qué hace | Nivel | Ejemplo |
|---|---|---|---|
| Aseguramiento / garantía de la calidad (QA) | Establecer procedimientos de organización y estándares de calidad | Organización | La consultora define su guía de estilo, su proceso de revisión de código y sus plantillas de documentos |
| Planificación de la calidad | Seleccionar los procedimientos y estándares para un proyecto concreto y adaptarlos | Proyecto | Plan de calidad de TusBus: guía de estilo de Dart, cobertura mínima del 70 %, accesibilidad WCAG 2.1 AA, revisión obligatoria de cada PR |
| Control de la calidad (QC) | Garantizar que el equipo sigue esos procedimientos y estándares | Proyecto, durante la ejecución | Revisar que cada PR tiene revisión, que la cobertura no baja del 70 %, auditar una muestra de entregables |
Un matiz de vocabulario (ampliación): en el PMBOK y en la industria, "control de calidad" suele significar también inspeccionar los productos para detectar defectos (probar, revisar entregables), mientras que "aseguramiento" se centra en el proceso (prevenir defectos haciendo bien las cosas). Ambas lecturas encajan: QA = prevenir con un buen proceso; QC = comprobar que el proceso se sigue y que el producto cumple.Ampliación. PMBOK 6, "Gestionar la calidad" (Ejecución) y "Controlar la calidad" (Monitoreo y Control). En un examen antiguo: "Realizar el control de la calidad" → Procesos de Control y Monitorización.
Independencia
La gestión de la calidad debe estar separada de la gestión del proyecto para garantizar su independencia. ¿Por qué? Porque el JP está sometido a la presión del plazo y el coste, y la tentación de "dar por buena" una entrega para cumplir la fecha es enorme (recuerda la lección 8: recortar pruebas en silencio). Un responsable de calidad que no depende del JP puede decir "esto no cumple" sin que su carrera dependa del plazo. En empresas grandes es un equipo de QA independiente; en equipos ágiles pequeños, la independencia se consigue con reglas que nadie se salta (Definition of Done, pipelines que bloquean) y con revisiones cruzadas.
3. Verificación y validación
La distinción clásica de Barry Boehm, que todo ingeniero del software debe saber:Ampliación. Boehm, B. (1979/1984); SWEBOK v4, KA Software Quality; Sommerville, cap. 8.
| Verificación | Validación | |
|---|---|---|
| Pregunta | "¿Estamos construyendo el producto correctamente?" | "¿Estamos construyendo el producto correcto?" |
| Compara con | La especificación (requisitos, diseño, estándares) | Las necesidades reales del cliente y los usuarios |
| Técnicas | Revisiones, inspecciones, análisis estático, pruebas unitarias e integración | Prototipos, demos, pruebas de aceptación con usuarios, pruebas beta |
| TusBus | "La API responde en p95 < 300 ms, como dice el requisito" | "Los usuarios en la parada encuentran su autobús en menos de 10 segundos" |
Se puede verificar perfectamente un producto que no sirve (cumple una especificación equivocada). Por eso la validación temprana (prototipos, entregas iterativas, lección 7) es tan valiosa: detecta antes que la especificación está mal, cuando cambiarla es barato (lección 1, coste del error).
Técnicas de calidad
- Estáticas (sin ejecutar): revisiones entre pares, inspecciones formales (Fagan: roles, checklist, registro de defectos), walkthroughs, análisis estático automático (linters, SAST, complejidad). Una revisión entre pares del documento de arquitectura para encontrar inconsistencias es una actividad de gestión de la calidad (salió así en un examen antiguo).
- Dinámicas (ejecutando): pruebas por niveles (unitarias, integración, sistema, aceptación), pruebas de rendimiento, de seguridad (DAST, pentesting, lección 18), de usabilidad.
- Automatización en CI: cada cambio pasa por los controles; la calidad deja de ser una fase al final y se vuelve continua (lección 18).
El coste de la calidad
Un modelo clásico (Juran, Feigenbaum, Crosby) que conecta calidad y coste (lección 14):Ampliación. Ver Cost of poor quality.
| Coste de conformidad (invertir en calidad) | Coste de no conformidad (pagar la falta de calidad) |
|---|---|
| Prevención: formación, estándares, guías, diseño cuidadoso Evaluación: revisiones, pruebas, auditorías | Fallos internos: defectos encontrados antes de entregar (retrabajo, depuración) Fallos externos: defectos encontrados por el cliente (soporte, parches, penalizaciones, reputación) |
La idea: cada euro en prevención y evaluación ahorra varios en fallos, sobre todo externos. Es la versión económica del coste del error creciente.
4. De la ausencia de defectos a la calidad total
Históricamente, la calidad comenzó siendo sinónimo de falta de defectos. Hoy se persigue la Gestión de la Calidad Total (TQM, Total Quality Management):Tema 2, diap. 63.
- Relacionada con la percepción de la calidad: la calidad la define el cliente, no sólo el número de bugs.
- Surgió en los años 50 (Deming y Juran en la industria japonesa), pero no se popularizó hasta mediados de los 80.
- Los procesos de SQA (Software Quality Assurance) se inspiran en el concepto holístico de calidad de TQM.
Principios de TQM (ampliación): orientación al cliente; implicación de todos (la "cultura de calidad" de la diap. 56); enfoque a procesos; mejora continua (el ciclo PDCA de Deming, lección 11); decisiones basadas en datos. La norma ISO 9001 (sistemas de gestión de la calidad) se construye sobre estos principios y sobre PDCA.
5. Calidad y seguridad: ISO/IEC 25010
Las diapositivas presentan calidad y seguridad como dos caras de la misma moneda:Tema 2, diap. 64. ISO/IEC 25010:2011.
- Calidad del software: grado en que un sistema cumple los requisitos funcionales y no funcionales (ISO/IEC 25010).
- Seguridad del software: capacidad del producto para proteger información y datos de acceso o modificación no autorizada.
- Un software no puede considerarse de alta calidad si no es seguro, aunque cumpla su funcionalidad.
El modelo de calidad del producto
| ISO/IEC 25010:2011 (8 características) | ISO/IEC 25010:2023 (9 características) |
|---|---|
| Adecuación funcional | Adecuación funcional |
| Eficiencia de desempeño | Eficiencia de desempeño |
| Compatibilidad | Compatibilidad |
| Usabilidad | Capacidad de interacción (sustituye a usabilidad; añade inclusividad, entre otras) |
| Fiabilidad | Fiabilidad |
| Seguridad (confidencialidad, integridad, no repudio, responsabilidad, autenticidad) | Seguridad (añade resistencia) |
| Mantenibilidad | Mantenibilidad |
| Portabilidad | Flexibilidad (sustituye a portabilidad; añade escalabilidad) |
| — | Safety · seguridad física / protección frente a daños (nueva) |
Ampliación. arc42 quality model · ISO 25010 update 2023; iso25000.com.
La discrepancia: la diap. 64 dice que la seguridad "pertenece al atributo fiabilidad y protección de la información". En ISO/IEC 25010 (tanto 2011 como 2023), la seguridad (security) es una característica propia, al mismo nivel que la fiabilidad, no una subcaracterística de ella. (En la norma anterior, ISO 9126, la seguridad era una subcaracterística de la funcionalidad.) Para el examen: si preguntan literalmente por lo que dice la diapositiva, responde según ella; si preguntan por el modelo ISO 25010, la seguridad es una característica independiente. La idea de fondo de la diapositiva sí es correcta y universal: la seguridad forma parte de la calidad.
Y otro matiz útil: en español "seguridad" traduce dos cosas distintas. Security = protección frente a ataques y accesos no autorizados. Safety = que el sistema no cause daños a personas o al entorno (un sistema de frenado, un dispositivo médico). La versión de 2023 las separa.
6. Calidad del proceso y del producto
La hipótesis: la calidad de un producto está influida por la calidad del proceso de su producción. Es especialmente importante en software porque algunos atributos de calidad del producto son difíciles de evaluar directamente (¿cómo mides la mantenibilidad antes de mantenerlo?), así que se confía en que un buen proceso produzca buen producto.Tema 2, diap. 65-66.
Sin embargo, la relación entre proceso y calidad del producto es muy compleja y difícil de entender, y aún más en seguridad. En manufactura, un buen proceso produce piezas casi idénticas; en software, cada producto es único (lección 1) y depende mucho de las personas, la tecnología y el problema.
El diagrama de la diap. 66 lo convierte en un ciclo de mejora:
- Si sí → estandarizar el proceso (se convierte en norma de la organización).
- Si no → preguntar ¿el proceso influye?
- Si sí → mejorar el proceso y volver a desarrollar.
- Si no → resolver los problemas del producto directamente (no era culpa del proceso).
Es un PDCA aplicado al proceso. Y es la base de los modelos de madurez como CMMI (lección 2), que evalúan la madurez del proceso de una organización (niveles 1 inicial, 2 gestionado, 3 definido, 4 gestionado cuantitativamente, 5 en optimización) con la hipótesis de que procesos más maduros producen resultados más predecibles.
Objetivos frente a acciones de calidad
Una distinción que salió en un examen antiguo: en un plan de acción para mejorar la calidad, hay objetivos (resultados medibles que se quieren alcanzar) y acciones (lo que se hace para alcanzarlos).
- Objetivo: "Que sólo el 10 % de los casos de uso tengan errores en las pruebas", "Resolver los errores en menos de 2 horas el 80 % de las veces".
- Acción: "Convocar una reunión para analizar las causas de la baja calidad", "Formar a los analistas", "Identificar en qué tecnologías tenemos más errores".
Un objetivo bien formulado es SMART (lección 3); una acción es algo que alguien hace y se puede marcar como hecho.
- "Calidad = ausencia de defectos": esa es la visión histórica; hoy es calidad total, ligada a la percepción del cliente.
- "La calidad es responsabilidad del equipo de pruebas": es responsabilidad de todos (cultura de calidad).
- "El JP es quien mejor puede controlar la calidad": la calidad debe ser independiente de la gestión del proyecto.
- "Verificar es comprobar que el cliente está satisfecho": eso es validar; verificar es comprobar contra la especificación.
- "Un buen proceso garantiza un buen producto": lo influye, pero la relación es compleja, sobre todo en seguridad.
- "En ISO 25010 la seguridad es parte de la fiabilidad": es una característica propia (la diapositiva lo simplifica).
Práctica
¿Aseguramiento, planificación o control de la calidad (según la definición de las diapositivas)?
- La empresa redacta su guía corporativa de revisión de código para todos los proyectos
- Para TusBus se decide aplicar la guía y añadir el requisito de accesibilidad WCAG
- Se audita una muestra de PRs para comprobar que todos tienen revisión
- Se definen las plantillas de documentos que usarán todos los equipos
- El pipeline bloquea los cambios que bajan la cobertura del 70 % acordado
¿Verificación o validación?
- Comprobar que la API cumple el tiempo de respuesta especificado
- Probar el prototipo con usuarios reales en una parada de autobús
- Inspección del código contra la guía de estilo del proyecto
- Demo de la iteración al concejal para ver si es lo que necesita
- Revisar que el diseño cubre todos los requisitos de la matriz
¿Por qué el temario dice que la gestión de la calidad debe estar separada de la gestión del proyecto?
- Porque el jefe de proyecto no tiene conocimientos técnicos de calidad
- Porque las normas ISO prohíben que el jefe de proyecto revise el código
- Porque la calidad sólo se evalúa cuando el proyecto ya ha terminado
- Para que la presión de plazo y coste no comprometa las decisiones de calidad
Según ISO/IEC 25010:2011, ¿cómo se clasifica la seguridad (security)?
- Como una subcaracterística de la fiabilidad del producto
- Como un requisito funcional, fuera del modelo de calidad
- Como una característica de calidad propia del producto
- Como una subcaracterística de la adecuación funcional
En un plan para mejorar la calidad del software de la empresa, ¿cuáles son objetivos y no acciones?
- Convocar una reunión para analizar los problemas de calidad
- Conseguir que solo el 10 % de los casos de uso fallen en pruebas
- Poner en marcha un curso de formación para los analistas
- Resolver los errores en menos de 2 horas el 80 % de las veces
- Identificar en qué tecnologías se producen más errores
El equipo sigue el proceso definido, pero el producto sale con una vulnerabilidad grave. Según el diagrama de la diap. 66, ¿qué se pregunta a continuación?
- Si el producto se puede estandarizar tal y como está
- Si hay que despedir al responsable del módulo afectado
- Si el cliente aceptará el producto con la vulnerabilidad
- Si el proceso influye en ese problema de calidad
Clasifica cada coste según el modelo de coste de la calidad.
- Formar al equipo en programación segura
- Ejecutar las pruebas de integración
- Rehacer un módulo que no pasó la revisión
- Atender las quejas de usuarios por un fallo en producción
Verdadero o falso: "La gestión de la calidad total (TQM) surgió a mediados de los 80".
- Verdadero
- Falso
TusBus cumple todos sus requisitos especificados y pasa todas las pruebas, pero los usuarios dicen que no les sirve porque en la parada no hay cobertura y la app no funciona sin conexión. ¿Qué ha fallado, en términos de verificación y validación, y qué se podría haber hecho?
Repaso espaciado · lecciones 4, 11, 14
EV = 55.000 €, AC = 50.000 €. ¿CPI?
"El revisor detecta que el módulo de pagos no cumple el estándar de cifrado de la empresa." ¿A qué registro va?
- Registro de riesgos
- Registro de decisiones
- Registro de no conformidades
- Registro de peticiones de cambio
Para profundizar
Sommerville, I. (2016). Software Engineering, 10ª ed., cap. 24 "Quality management" (la base de las diapositivas: tensiones, QA/planificación/control, proceso vs. producto) y cap. 8 (verificación y validación). software-engineering-book.com. Para ISO 25010: iso25000.com (en español).
Haz una lista de 10 actividades de calidad de tu proyecto de prácticas y clasifícalas en aseguramiento/planificación/control y en verificación/validación; pide a un asistente que te corrija. La discrepancia de la seguridad en ISO 25010 es buena pregunta para tutoría: así sabrás qué respuesta espera el profesor.