Ingeniería de Requisitos y Diseño de Software: Prototipado, Calidad de la Especificación, Diseño por Contratos y Métricas de Arquitectura

1. Prototipado en la Elicitación de Requisitos

En la ingeniería de requisitos, la elicitación consiste en capturar información de los stakeholders y otras fuentes para comprender el problema. Una técnica clave es el prototipado, que implica construir una versión gráfica "hueca" del sistema para visualizar la información y las interacciones. Este prototipo, sin funcionalidad real, facilita la comunicación con los stakeholders y se desecha tras cumplir su propósito. Un ejemplo es un mapa de pantallas que muestra la distribución de la información y el flujo de interacción. Es importante equilibrar el coste del prototipo con su beneficio en la elicitación.

Ventajas del Prototipado:

• Interacción sencilla y visual con el cliente y usuarios.
• No requiere implementación, se desecha tras su uso.

Desventajas del Prototipado:

• Coste de realización.
• Posible enfoque en la solución (diseño) en lugar del problema.
• Creación de falsas expectativas en el cliente.

El prototipado para la elicitación de requisitos es diferente al desarrollo orientado a prototipos, donde cada prototipo incluye funcionalidades del sistema final.

2. Propiedades de la Calidad de una Especificación

Las tres propiedades más importantes que determinan la calidad de una especificación son: Corrección, Consistencia y Completitud.

Corrección:

Se refiere a la exactitud y redacción adecuada. Un requisito es correcto si es comprensible, preciso, pertinente y no contiene errores. Técnicas para asegurar la corrección:

• Frases cortas, en modo indicativo, con pocos conceptos.
• Evitar dobles negaciones, tiempo condicional en verbos, adjetivos imprecisos (fácil, difícil), pronombres excesivos y acrónimos sin explicar.
• Uso de un vocabulario de dominio.

Consistencia:

Se refiere a la ausencia de contradicciones entre requisitos. Técnicas para asegurar la consistencia:

• Clasificación y ordenación adecuada de los requisitos.
• Matrices de referencias cruzadas para identificar conflictos, acoplamientos y redundancias.

Otras propiedades importantes son: Claridad, Modificabilidad, Trazabilidad, Comprobabilidad, Tamaño adecuado, Condiciones de error, Necesidad y Prioridad.

3. Caso Práctico: Aulaglobal

a) Stakeholders:

• Estudiantes: Usuarios finales del sistema.
• Profesores: Gestionan cursos, contenidos y evaluación.
• Universidad: Lidera el análisis, despliegue y gestión de costes.

b) Requisito de Usuario:

• El profesor podrá gestionar un espacio académico (estudiantes, contenidos, actividades y evaluación) para una asignatura.

c) Requisitos Funcionales:

• El subsistema de evaluación permitirá al profesor subir calificaciones entre 0 y 10.
• El subsistema de gestión de contenidos permitirá al profesor publicar contenidos de hasta 20MB en formatos estándar (PDF y HTML).
• El subsistema de evaluación permitirá establecer pesos positivos en cada criterio de evaluación.

4. Cohesión y Acoplamiento

La cohesión y el acoplamiento son métricas clave para evaluar la calidad de una arquitectura. La cohesión mide la fuerza de asociación de los elementos dentro de un módulo (mayor es mejor). El acoplamiento mide la interdependencia entre módulos (menor es mejor).

La sentencia "Poner juntos todos los elementos (clases) que cambien por la misma razón. Separar los elementos que cambien por diferentes razones" busca minimizar el impacto de los cambios. Agrupar elementos que cambian juntos reduce las dependencias (bajo acoplamiento) y asegura que los elementos colaboren para un mismo objetivo (alta cohesión). Separar elementos que cambian por diferentes razones también mejora el acoplamiento y la cohesión.

5. Diseño por Contratos y Herencia

El diseño por contratos establece acuerdos formales entre módulos. Cada módulo define precondiciones (antes de la ejecución) y postcondiciones (después de la ejecución). En la herencia, la superclase "subcontrata" a las subclases.

Consideraciones en la Herencia:

• Principio de Sustitución (Liskov): Las invariantes de la superclase también aplican a la subclase. La subclase puede tener invariantes más restrictivas, pero no menos.
• Principio de Subcontratación: Al redefinir operaciones, la subclase debe mantener o debilitar la precondición y mantener o reforzar la postcondición.