Tema 14: Calidad del Software y Gestión del Examen

Resumen Ejecutivo

Esta sesión establece la calidad como el cimiento de la Ingeniería del Software: no es un extra, es el objetivo final de todos los procesos y herramientas. Se analizan los factores que determinan si un software es "bueno" (externos vs internos), las dimensiones de calidad de Garvin y el coste exponencial de los errores según la fase de detección. Finalmente, se detalla la estructura y estrategia para el examen final.

Conceptos Clave

Enfoque Multicapa: La calidad es la base que soporta el Proceso, los Métodos y las Herramientas.
Factores Externos: Lo que el usuario percibe (velocidad, estética, usabilidad).
Factores Internos: Lo que el ingeniero percibe (código limpio, modularidad, trazas).
MVP (Producto Mínimo Viable): Producto "suficientemente bueno" para salir al mercado y validar hipótesis, no un producto a medio hacer.
Coste del Cambio: Corregir un error en mantenimiento es hasta 100 veces más caro que en requisitos.

Desarrollo del Temario

1. La Ingeniería del Software como Enfoque de Calidad

La Ingeniería del Software se define como una tecnología multicapa.

Herramientas y Métodos: Son el "cómo" hacemos las cosas.
Procesos: Organizan el trabajo (unificado, ágil, etc.).
Enfoque de Calidad (Base): Es el "por qué" nos complicamos la vida con todo lo anterior. El objetivo final es un software de mayor calidad.

2. Factores de Calidad: Externos vs. Internos

Para determinar si un software es bueno o malo, analizamos dos tipos de factores.

A. Factores Externos (Lo que se ve)

Son detectables por el usuario final (no tecnólogo). Si estos fallan, el software se percibe como malo, aunque el código sea una obra de arte.

Facilidad de mantenimiento: Capacidad de adaptar el software a nuevos requisitos del cliente rápidamente (ej. cambiar formato de facturas en 3 días vs. 2 semanas).
Confiabilidad: No es solo que no falle, sino que si falla, el daño sea mínimo.

Ejemplo del Profesor: Si Zoom se cierra en clase, el daño es bajo (molestia). Si el software de un avión se reinicia al aterrizar, el daño es catastrófico. La confiabilidad mide el impacto del fallo.
Eficacia: Que haga lo que se supone que debe hacer.
Usabilidad: Que sea agradable y fácil de usar.
Reusabilidad: Capacidad de usarse en contextos diferentes (ej. Google Sheets vs Excel local).
Portabilidad: Funcionar en diferentes plataformas.

B. Factores Internos (Lo que no se ve)

Solo los perciben los ingenieros. Son el medio para conseguir los factores externos.

Facilidad de traza (Logging): Si implementas un buen sistema de logs, cuando el software falle (factor externo), podrás arreglarlo rápido (mantenibilidad).
Modularidad y Legibilidad: Permiten que el equipo entienda y mejore el código.

La Metáfora del Coche (Fiat Multipla): Un coche puede tener una suspensión mecánica revolucionaria (Factor Interno excelente), pero si es estéticamente horrible y los acabados son de plástico malo (Factores Externos deficientes), el usuario lo percibirá como un mal coche. Los factores internos deben trabajar para potenciar los externos.

3. Dimensiones de la Calidad de Garvin

Garvin propone 8 dimensiones para evaluar la calidad de un producto (aplicable a software):

Desempeño: ¿Proporciona valor? ¿Hace lo que dicen los requisitos?
Características: Funcionalidades que agradan al usuario.
Confiabilidad: Frecuencia de fallos y disponibilidad.

¡OJO AL DATO!: Disponibilidad no siempre es 24/7. Si una web de la administración pública solo tramita expedientes de 08:00 a 15:00, y tú entras a las 16:00 y no va, no es un fallo de confiabilidad, es una definición del servicio.
Conformidad: Cumplir estándares (legales, de interfaz).

Ejemplo de la Interfaz (Android): El profesor mencionó el trauma del cambio de Android 4.0 a 4.4, donde Google invirtió el botón de "Atrás". Romper la conformidad de la interfaz frustra al usuario.
Durabilidad: Vida útil del software.
Servicio: Facilidad de recibir soporte y mantenimiento.
Estética: UX/UI agradable.
Percepción: La reputación de la marca influye en la calidad percibida.

Ejemplo Personal (Mega vs. Iberbox): El profesor fundó Iberbox (startup) y venía de Mega. Aunque Iberbox fuera técnicamente mejor, era difícil venderlo porque Mega tenía la reputación (percepción) de calidad establecida.

4. El MVP (Producto Mínimo Viable)

Relación entre calidad y emprendimiento.

Definición: El producto "suficientemente bueno". Debes sentir un poco de vergüenza al lanzarlo (si no, has tardado demasiado), pero no demasiada vergüenza (debe funcionar).
Estrategia de Construcción: No construyas por piezas (Rueda -> Eje -> Chasis -> Coche), construye por soluciones de movilidad (Monopatín -> Patinete -> Bici -> Coche).
La Pirámide del MVP: No hagas solo la capa funcional. Un MVP debe ser una "rebanada" vertical que incluya un poco de: Funcionalidad + Fiabilidad + Usabilidad + Diseño.

5. El Coste de la Calidad (Gráfica de Pressman)

El coste de arreglar un error crece exponencialmente según la fase en la que se detecta.

Fase de Detección	Coste Relativo (Aprox)
Requisitos	$1 (Base)
Diseño	~$3-4
Codificación	~$10
Pruebas	~$70
Mantenimiento (Producción)	~$100

Conclusión: Las metodologías ágiles intentan mover la detección de errores a la izquierda (fases tempranas) mediante iteraciones rápidas para evitar el coste brutal de la fase de mantenimiento.

6. Estructura del Examen Final (¡MUY IMPORTANTE!)

El profesor dedicó gran parte de la clase a explicar el formato del examen.

Formato General:

Duración: Estándar de la universidad.
Modalidad: Online (cuidado con las normas de la habitación/cámara) o Presencial.
Material: No se permite material extra, solo una hoja de borrador (que no se entrega/sube).

Partes del Examen:

Parte 1: Test Teórico (5 Puntos)

Cantidad: 12 preguntas (4 opciones, solo 1 correcta).
Contenido: Teoría pura de toda la asignatura.
Origen: El profesor tiene una batería grande de preguntas y un programa selecciona 12 aleatorias y distribuidas por temas. No son las mismas preguntas que los test de la plataforma online.
Puntuación:
Acierto: Suma.
Fallo: Resta (aprox -0.25 puntos reales, fórmula base 5).
Blanco: No suma ni resta.
Nota: Puede ocurrir por azar que 4 respuestas seguidas sean la "D". No te asustes.

Parte 2: Práctica (5 Puntos) - Dividida en dos bloques

Bloque A: Diagrama de Clases (2 Puntos)

Enunciado: Te darán un diagrama de clases (UML) ya pintado.
Tu tarea: "Traducir" ese diagrama a texto (lenguaje natural).
Estrategia: Explica minuciosamente todo lo que veas:
"La clase X hereda de la clase Y..."
"Existe una relación de agregación entre A y B con cardinalidad 1 a N..."
"La clase Z tiene un atributo derivado..."
Tip: Todos los diagramas tienen alguna "trampa" o característica especial (una clase asociativa, una herencia, etc.). Asegúrate de mencionarla.

Bloque B: Supuestos Teórico-Prácticos (3 Puntos)

Cantidad: 3 preguntas cortas (1 punto cada una).
Estilo: No son de desarrollar un tema entero ("Háblame del Proceso Unificado"). Son preguntas de comprensión, diferencias, listas o razonamiento.
Corrección: El profesor busca palabras clave y comprensión. Escribir "paja" o rollos largos que no van al grano puede penalizar (lectura en diagonal). Se puede responder en un párrafo bien hecho.
¡OJO AL DATO! (Pista de Examen): El profesor "regaló" una posible pregunta que suele poner:

"Diferencias entre Procesos Ágiles y Procesos Tradicionales". (Preparad bien esta respuesta).

Preguntas de Autoevaluación

Sobre Costes: Si corregir un error en la fase de requisitos cuesta 1 unidad de esfuerzo, ¿aproximadamente cuánto cuesta corregirlo si el error se descubre una vez el software ya está entregado al cliente (mantenimiento)?
Sobre MVP: ¿Es correcto definir un MVP como una primera versión que solo tiene funcionalidad pura sin diseño ni usabilidad? ¿Por qué?
Sobre Factores: Clasifica los siguientes atributos en Internos o Externos: Modularidad, Usabilidad, Portabilidad, Legibilidad del código.
Sobre Examen (Práctica): En el examen, si te encuentras un rombo negro en el diagrama de clases que une "Coche" y "Motor", ¿qué debes escribir en tu explicación textual?
Sobre Garvin: Si un software funciona perfectamente técnicamente pero el usuario final no percibe que le aporte valor a su trabajo diario, ¿qué dimensión de calidad de Garvin está fallando?