Estrategias de Ingeniería de Requerimientos y Modelado de Software

1. Artefactos y Modelos

• Modelos Mentales: Incluyen el contexto, Casos de Uso (CU), diagramas de actividad, clases y el Diagrama Entidad-Relación (DER).
• Reglas de Negocio: Se refieren a las políticas de la empresa que son independientes del software.
• SRS (Software Requirements Specification): Es el documento formal que actúa como contenedor de los Requerimientos Funcionales (RF) y Requerimientos No Funcionales (RNF).
• Criterios de Aceptación: Son de naturaleza binaria. Se estructuran bajo el formato: Dado [escenario], Cuando [evento], Entonces [resultado].

2. DFD (Diagrama de Flujo de Datos - Flujo Lógico)

• Enfoque: Es de carácter lógico. Determina qué transforma los datos y hacia dónde se dirigen.
• Conservación: Establece que las Salidas = Entradas + Información Local.
• Equilibrio: El nivel inferior debe mantener exactamente las mismas Entradas/Salidas (E/S) que el nivel superior.
• Nomenclatura: Los procesos se definen con verbos, mientras que los almacenes y entidades se definen con sustantivos.
• Flujos: Pueden ser de consulta, actualización o diálogo.

4. Historias de Usuario (HU)

• Las 3 C: Se componen de Card (Tarjeta), Conversation (Conversación) y Confirmation (Confirmación).
• INVEST: Las historias deben ser Independientes, Negociables, Valorables, Estimables, Small (Pequeñas) y Testeables.

5. Métricas e Inspección

• De Producto: Incluyen la densidad de defectos, la trazabilidad y la completitud.
• De Proceso: Incluyen la tasa de inspección, la tasa de descubrimiento de defectos y la eficiencia en la eliminación de defectos.

6. Revisiones y Prototipos

• Revisiones:
  • Peer deskcheck: Realizada por un compañero.
  • Passaround: Realizada por varios revisores.
  • Walkthrough: El autor expone el contenido a todos los interesados.
• Prototipado: Se divide en Desechables (sirven para validar y luego se descartan) frente a Evolutivos (aquellos que se convierten gradualmente en el producto final).

7. Verificación vs. Validación

Diferencia: La Verificación evalúa el documento y los procesos internos, mientras que la Validación confirma si el sistema resuelve el problema real del usuario final.

Verificación

• Definición: Asegura que los requerimientos estén documentados correctamente y cumplan con los criterios de calidad internos.
• Pregunta Clave: ¿Estamos construyendo el producto correctamente?
• Técnicas:
  • Inspecciones y Revisiones: Lectura crítica de documentos por parte del equipo para hallar defectos.
  • Análisis Estático: Uso de herramientas automatizadas para verificar la consistencia.
  • Trazabilidad: Asegurar que cada requerimiento tenga un origen y un rastro claro en el desarrollo.

Validación

• Definición: Confirma que los requerimientos satisfacen las necesidades y expectativas reales de los stakeholders.
• Pregunta Clave: ¿Estamos construyendo el producto correcto?
• Técnicas:
  • Prototipado: Crear modelos preliminares para que el usuario interactúe y proporcione feedback.
  • Simulación/Modelado: Usar diagramas como casos de uso o flujos para validar el entendimiento mutuo.
  • Pruebas de Aceptación (UAT): Validación final realizada directamente con el cliente.