Modelo de cascada extendido

Este artículo explica el modelo de cascada extendido, incluyendo preguntas típicas de examen, componentes clave y etiquetas asociadas. Lee un “artículo aleatorio” cada día en esta página y amplía tu conocimiento, aunque muchos temas puedan parecerte nuevos al principio.

En pocas palabras

El modelo de cascada extendido mantiene las fases claras del modelo clásico, pero las complementa con bucles de retroalimentación controlados entre fases adyacentes y prototipos tempranos. Esto permite detectar errores más pronto y reducir riesgos de manera sistemática.

Descripción técnica compacta

En el modelo de cascada extendido, las fases aún se ejecutan secuencialmente (requisitos → diseño → implementación → pruebas → despliegue/mantenimiento), pero:

• Existen saltos definidos a la fase anterior cuando no se cumplen los criterios de aceptación.
• La planificación de pruebas y aseguramiento de calidad se preparan en paralelo (por ejemplo, el concepto de pruebas se define en análisis y diseño).
• Los prototipos (de interfaz o arquitectura) se utilizan tempranamente para validar requisitos poco claros o riesgos técnicos.

Conceptos clave:

• Verificación: “¿Estamos construyendo el producto correctamente?” (contra la especificación)
• Validación: “¿Estamos construyendo el producto correcto?” (contra el propósito empresarial)

Muy popular, especialmente en exámenes de la IHK para especialistas en informática en desarrollo de aplicaciones

¿Por qué? El modelo de cascada es ideal para proyectos pequeños, que generalmente se realizan en el contexto de una formación o prácticas. El modelo de cascada extendido no es tan rígido y ofrece la posibilidad de correcciones mediante saltos hacia atrás. Yo también lo elegí para mi proyecto de examen, y resultó fácil de explicar e implementar.

Conceptos importantes en detalle

Líneas base

Definición: Una línea base es un estado fijo de artefactos del proyecto en un momento específico. Sirve como punto de referencia para cambios futuros.

Tipos de líneas base:

• Línea base de requisitos: Requisitos aprobados (especificación técnica/documento de requisitos)
• Línea base de diseño: Documentos de diseño liberados (arquitectura, diseño modular)
• Línea base de código: Versión de código estable y probada (candidato a versión)
• Línea base de pruebas: Resultados de pruebas aceptados y protocolos de prueba

Ejemplo: Después de completar la fase de requisitos, se establece la línea base de requisitos. Todos los cambios posteriores deben solicitarse formalmente como Change Request.

Solicitudes de cambio

Definición: Una solicitud de cambio es una solicitud formal para modificar artefactos ya incluidos en una línea base.

Proceso de solicitud de cambio:

1. Presentación: ¿Quién solicita qué y por qué?
2. Análisis de impacto: ¿Cuáles son las implicaciones del cambio?
3. Evaluación: Sopesar costos, beneficios y riesgos
4. Decisión: Aprobación o rechazo por el Change Advisory Board (CAB)
5. Implementación: Ejecutar el cambio y documentarlo

Ejemplo: Durante la implementación, el cliente solicita añadir una nueva función. Esto requiere una solicitud de cambio con análisis de impacto.

Análisis de impacto

Definición: El análisis de impacto examina las consecuencias de un cambio planificado en todo el proyecto.

Áreas de análisis:

• Impacto técnico: ¿Qué componentes necesitan ajustarse?
• Impacto temporal: ¿Se prolonga la duración del proyecto?
• Impacto económico: ¿Hay costos adicionales en desarrollo y pruebas?
• Impacto cualitativo: ¿Afecta el cambio a la calidad del sistema?
• Impacto en riesgos: ¿Surgen nuevos riesgos técnicos o relacionados con el proyecto?

Ejemplo: Cuando cambian los requisitos, se analiza qué elementos de diseño, módulos de código y casos de prueba se ven afectados.

Trazabilidad de requisitos a pruebas

Definición: La trazabilidad asegura el seguimiento de requisitos a través de todas las fases del proyecto hasta las pruebas.

Cadena de trazabilidad:

Requisito (REQ-001) → Diseño (ARCH-015) → Código (CODE-042) → Prueba (TEST-087)

Propósitos de la trazabilidad:

• Comprobación de completitud: Cada requisito se implementa y prueba
• Análisis de impacto: Identificar rápidamente áreas afectadas por cambios
• Aseguramiento de calidad: Detectar lagunas en la cobertura
• Evidencia de auditoría: Para cumplimiento normativo y certificaciones

Ejemplo de matriz de trazabilidad:

ID de requisito	Requisito	ID de diseño	Componente de código	ID de caso de prueba	Estado
REQ-001	Registro de usuario	ARCH-015	UserService.java	TEST-087	✅
REQ-002	Restablecimiento de contraseña	ARCH-016	PasswordService.java	TEST-088	✅
REQ-003	Catálogo de productos	ARCH-017	ProductService.java	TEST-089	❌

Muy popular en exámenes de la IHK para especialistas en informática en desarrollo de aplicaciones

Por qué el modelo de cascada extendido es tan importante en exámenes de la IHK:

1. Enfoque estructurado

La IHK evalúa si los candidatos pueden trabajar de manera sistemática y estructurada. El modelo de cascada extendido proporciona precisamente esta estructura con fases y responsabilidades claras.

2. Conciencia de calidad

El aseguramiento de calidad es un tema central en la IHK. El modelo de cascada extendido integra medidas de QA en cada fase (revisiones, pruebas, prototipos).

3. Obligación de documentación

La IHK exige documentación completa. El modelo genera artefactos demostrables en cada fase (especificación técnica, documento de requisitos, protocolos de prueba).

4. Gestión de riesgos

Los especialistas en informática deben ser capaces de identificar y evaluar riesgos. El modelo de cascada extendido ofrece minimización de riesgos formalizada mediante prototipos y revisiones.

5. Gestión de cambios

En la práctica, los cambios deben gestionarse profesionalmente. Las solicitudes de cambio y análisis de impacto son competencias relevantes para la IHK.

6. Rastreabilidad

Los examinadores deben entender por qué se tomaron determinadas decisiones. Las líneas base y la trazabilidad proporcionan exactamente esta visibilidad.

7. Relevancia práctica

Muchas empresas medianas aún trabajan con modelos tipo cascada. La IHK prepara para condiciones laborales reales.

Escenarios típicos en exámenes de la IHK:

• Crear y justificar un plan de fases del proyecto
• Realizar y evaluar un análisis de cambios
• Crear una matriz de trazabilidad
• Definir medidas de aseguramiento de calidad para una fase
• Describir y gestionar un escenario de retroalimentación

El modelo de cascada extendido en detalle

Flujo de fases con bucles de retroalimentación

    ┌─────────────────────┐
    │  1. Fase de         │
    │      requisitos      │
    └─────────┬───────────┘
              │ Aceptación
              ▼
    ┌─────────────────────┐
    │  2. Diseño de       │◄────────────────┐
    │      sistema        │                 │
    └─────────┬───────────┘                 │
              │ Aceptación                   │
              ▼                              │
    ┌─────────────────────┐                 │
    │  3. Diseño de       │◄────────────────┤
    │      arquitectura    │                 │
    └─────────┬───────────┘                 │
              │ Aceptación                   │
              ▼                              │
    ┌─────────────────────┐                 │
    │  4. Diseño modular  │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Aceptación                   │
              ▼                              │
    ┌─────────────────────┐                 │
    │  5. Implementación  │◄────────────────┤
    └─────────┬───────────┘                 │
              │ Aceptación                   │
              ▼                              │
    ┌─────────────────────┐                 │
    │  6. Preparación de  │◄────────────────┤
    │      pruebas        │                 │
    └─────────┬───────────┘                 │
              │ Aceptación                   │
              ▼                              │
    ┌─────────────────────┐                 │
    │  7. Ejecución de    │◄────────────────┤
    │      pruebas        │                 │
    └─────────┬───────────┘                 │
              │ Aceptación                   │
              ▼                              │
    ┌─────────────────────┐                 │
    │  8. Despliegue      │                 │
    └─────────────────────┘                 │
                                           │
                                           │ Saltos
                                           │ controlados
                                           │ ante errores
                                           │
                                           └─────────────────

Descripción detallada de las fases

Fase 1: Análisis de requisitos

Objetivos: Capturar, especificar y aprobar los requisitos de forma completa

Artefactos:

• Documento de requisitos del cliente (perspectiva del cliente)
• Especificación de requisitos (perspectiva del proveedor)
• Catálogo de requisitos con IDs
• Criterios de aceptación
• Glosario

Actividades:

• Entrevistas con stakeholders
• Talleres con el departamento especializado
• Análisis de requisitos
• Priorización (MoSCoW)
• Aprobación técnica

Aseguramiento de calidad:

• Revisiones de requisitos
• Verificaciones de consistencia
• Controles de completitud
• Inicio de matriz de trazabilidad

Retroalimentaciones típicas: Ninguna, ya que es el punto de partida

---

Fase 2: Diseño del sistema

Objetivos: Definir los límites del sistema, especificar las interfaces

Artefactos:

• Diagrama de contexto
• Catálogo de interfaces
• Diagramas de flujo de datos
• Arquitectura del sistema (de alto nivel)
• Conceptos técnicos

Actividades:

• Delimitar los límites del sistema
• Definir interfaces externas
• Modelar flujos de datos
• Especificar requisitos no funcionales
• Justificar la elección de tecnologías

Aseguramiento de calidad:

• Revisiones de arquitectura
• Validación de interfaces
• Estimaciones de rendimiento
• Revisión de conceptos de seguridad

Retroalimentaciones típicas: Requisitos poco claros → Fase de análisis de requisitos

---

Fase 3: Diseño de la arquitectura

Objetivos: Establecer la arquitectura detallada, minimizar riesgos técnicos

Artefactos:

• Diagrama de componentes
• Diagrama de despliegue
• Modelo de datos (Diagrama E-R)
• Catálogo de objetivos de calidad
• Documento de decisiones arquitectónicas (ADR)

Actividades:

• Diseñar componentes
• Modelado de datos
• Definir atributos de calidad
• Desarrollar prototipos (pruebas de UI, pruebas de concepto tecnológicas)
• Detallar conceptos de seguridad

Aseguramiento de calidad:

• Revisiones de arquitectura
• Pruebas de prototipo
• Benchmarks de rendimiento
• Revisiones de seguridad

Retroalimentaciones típicas: Ambigüedades técnicas → Diseño del sistema

---

Fase 4: Diseño modular

Objetivos: Diseño detallado de todos los módulos, finalizar contratos de interfaces

Artefactos:

• Diagramas de clases
• Diagramas de secuencia
• Especificaciones de interfaces
• Descripciones de algoritmos
• Esquema de base de datos

Actividades:

• Diseñar clases y objetos
• Especificar algoritmos
• Diseño de base de datos
• Diseño de interfaz de usuario (pantallas, wireframes)
• Conceptos de integración

Aseguramiento de calidad:

• Revisiones de diseño
• Pruebas de generación de código
• Normalización de base de datos
• Pruebas de usabilidad de interfaz

Retroalimentaciones típicas: Problemas de diseño → Diseño de la arquitectura

---

Fase 5: Implementación

Objetivos: Crear el código conforme a la especificación, implementar medidas de aseguramiento de calidad

Artefactos:

• Código fuente (versionado)
• Pruebas unitarias
• Documentación del código
• Scripts de construcción
• Paquetes de despliegue

Actividades:

• Programación conforme a estándares
• Revisiones de código
• Análisis de código estático
• Desarrollo de pruebas unitarias
• Integración continua

Aseguramiento de calidad:

• Revisiones de código
• Análisis estático (SonarQube)
• Cobertura de pruebas unitarias
• Conformidad con estándares de codificación

Retroalimentaciones típicas: Problemas de implementación → Diseño modular

---

Fase 6: Preparación de pruebas

Objetivos: Crear una estrategia de pruebas completa, construir el entorno de pruebas

Artefactos:

• Concepto de pruebas
• Casos de prueba (detallados)
• Datos de prueba
• Scripts de automatización de pruebas
• Entornos de prueba

Actividades:

• Definir estrategia de pruebas
• Derivar casos de prueba (a partir de requisitos)
• Preparar datos de prueba
• Desarrollar automatización de pruebas
• Configurar entornos de prueba

Aseguramiento de calidad:

• Revisión del concepto de pruebas
• Análisis de cobertura de casos de prueba
• Validación de datos de prueba
• Verificaciones del entorno de pruebas

Retroalimentaciones típicas: Brechas en pruebas → Implementación/Diseño modular

---

Fase 7: Ejecución de pruebas

Objetivos: Demostrar la calidad del sistema, encontrar y corregir defectos

Artefactos:

• Protocolos de prueba
• Reportes de errores
• Reportes de aceptación de pruebas
• Mediciones de rendimiento
• Resultados de pruebas de seguridad

Actividades:

• Pruebas de módulo
• Pruebas de integración
• Pruebas del sistema
• Pruebas de aceptación
• Pruebas de rendimiento

Aseguramiento de calidad:

• Revisiones de pruebas
• Análisis de errores
• Pruebas de regresión
• Controles de aceptación

Retroalimentaciones típicas: Errores del sistema → Implementación/Arquitectura

---

Fase 8: Introducción

Objetivos: Iniciar la operación en producción, capacitar a los usuarios, proporcionar documentación

Artefactos:

• Guía de instalación
• Manual de usuario
• Manual de administración
• Materiales de capacitación
• Contrato de mantenimiento

Actividades:

• Instalación/Despliegue
• Migración de datos
• Capacitación de usuarios
• Crear manual de operación
• Construir estructura de soporte

Aseguramiento de calidad:

• Pruebas de instalación
• Validación de migración
• Retroalimentación de capacitación
• Verificaciones de disponibilidad de soporte

Retroalimentaciones típicas: Problemas operativos → Ejecución de pruebas

Puntos clave para el examen

• Fases secuenciales con retroalimentaciones controladas
• Integrar la planificación de pruebas temprano (criterios de aceptación ya en análisis)
• Verificación/Validación en cada fase (revisiones, walkthroughs)
• Decisiones de puerta con criterios de aceptación (IHK)
• Prototipos para reducir riesgos
• Trazabilidad (Requisito → Diseño → Código → Prueba)
• Gestión de cambios + Líneas base

Componentes principales

1. Análisis de requisitos (Documentos de requisitos, criterios de aceptación)
2. Diseño del sistema (Contexto, interfaces, modelo de datos)
3. Diseño de la arquitectura (Objetivos de calidad, decisiones, prototipos)
4. Diseño modular (Diseño detallado, contratos de interfaces)
5. Implementación (Revisiones, análisis estático)
6. Preparación de pruebas (Concepto, casos, datos de prueba)
7. Ejecución de pruebas (Módulo/Integración/Sistema/Aceptación)
8. Introducción (Migración, operación, manual)
9. Bucles de retroalimentación (Saltos hacia atrás autorizados)
10. Gestión de configuración/cambios (Versionamiento)

Verificación y validación en detalle

Verificación: “¿Estamos construyendo el producto correctamente?”

La verificación comprueba si el producto desarrollado se ajusta a las especificaciones.

Métodos de verificación:

• Revisiones de código: ¿Se ajusta el código a los estándares de codificación?
• Pruebas unitarias: ¿Cumplen las funciones los requisitos especificados?
• Análisis estático: ¿Contiene el código errores conocidos o patrones problemáticos?
• Pruebas de integración: ¿Funcionan las interfaces como se especificó?
• Revisiones de documentación: ¿Es la documentación completa y correcta?

Ejemplo de verificación:

Especificación: "La función de contraseña debe aceptar 8-20 caracteres"
Verificación: Prueba unitaria verifica valores límite 7, 8, 20, 21 caracteres
Resultado: ✅ Especificación implementada correctamente

Validación: “¿Estamos construyendo el producto correcto?”

La validación comprueba si el producto desarrollado satisface las necesidades reales del usuario.

Métodos de validación:

• Pruebas de aceptación: ¿Cumple el sistema los requisitos de negocio?
• Pruebas de usabilidad: ¿Pueden los usuarios operar el sistema de forma intuitiva?
• Pruebas beta: ¿Responden los usuarios reales como se esperaba?
• Pruebas de rendimiento: ¿Alcanza el sistema el rendimiento requerido?
• Pruebas de seguridad: ¿Es el sistema lo suficientemente seguro para el despliegue?

Ejemplo de validación:

Requisito: "Los usuarios deben poder iniciar sesión rápida y fácilmente"
Validación: 50 usuarios de prueba realizan tarea de inicio de sesión (Medida: <3 segundos)
Resultado: ✅ Aceptación alcanzada, necesidad satisfecha

Modelo V: Conexión entre verificación y validación

Análisis de requisitos ←───────────────── Prueba de aceptación (Validación)
        ↓                                    ↑
Diseño del sistema ←───────────────────── Prueba del sistema (Validación)
        ↓                                    ↑
Diseño de la arquitectura ←─────── Prueba de integración (Verificación)
        ↓                                    ↑
Diseño modular ←───────────────────── Prueba de módulo (Verificación)
        ↓                                    ↑
Implementación ────────────────────────

Caso práctico integral: plataforma de comercio electrónico

Descripción del proyecto

Objetivo: Desarrollar una plataforma de comercio electrónico con sistemas de pago externos Equipo: 8 personas (2 PM, 2 arquitectos, 4 desarrolladores) Duración: 6 meses Presupuesto: 450.000€

Fase 1: Fase de requisitos (4 semanas)

Artefactos creados:

Pliego de condiciones (Cliente):
- 150 historias de usuario con criterios de aceptación
- 23 requisitos no funcionales
- 12 interfaces de integración

Especificación técnica (Proveedor):
- Especificaciones detalladas
- Condiciones técnicas marco
- Planificación de tiempo y costos

Matriz de trazabilidad:
REQ-001 → ARCH-015 → TEST-087
REQ-045 → INTF-003 → TEST-156
...

Criterios de cierre:

• ✅ Todos los requisitos priorizados (MoSCoW)
• ✅ Aprobación de expertos por 3 interesados
• ✅ Matriz de trazabilidad completa
• ✅ Análisis de riesgos realizado

Resultado: Fase aprobada, 2 solicitudes de cambio documentadas

---

Fase 2: Diseño del sistema (3 semanas)

Artefactos creados:

Diagrama de contexto:
- 8 sistemas externos (Payment, CRM, ERP, etc.)
- 3 roles de usuario (Customer, Admin, Partner)

Catálogo de interfaces:
- REST API: 47 endpoints
- SOAP: 3 interfaces legacy
- Message Queue: 12 tipos de eventos

Diagramas de flujo de datos:
- Proceso de pedido (7 pasos)
- Procesamiento de pagos (4 pasos)
- Sincronización de inventario (diaria)

Decisión de prototipo: Prototipo UI para el proceso de pedido desarrollado → Feedback de usuarios positivo

Criterios de cierre:

• ✅ Todas las interfaces externas especificadas
• ✅ Requisitos de rendimiento definidos (<2s tiempo de carga)
• ✅ Concepto de seguridad creado
• ✅ Stack tecnológico definido (React, Node.js, PostgreSQL)

Retroalimentación: 1 requisito poco claro → regresa a Fase 1

---

Fase 3: Diseño arquitectónico (3 semanas)

Artefactos creados:

Diagrama de componentes:
- Frontend: React SPA
- Backend: 6 microservicios
- Database: PostgreSQL + Redis Cache
- Message Queue: RabbitMQ

Objetivos de calidad:
- Rendimiento: <2s tiempo de respuesta
- Disponibilidad: 99.9%
- Escalabilidad: 10.000 usuarios simultáneos
- Seguridad: OWASP Top 10 cubierto

ADR (Architecture Decision Records):
ADR-001: Arquitectura de microservicios elegida
ADR-003: Event-Driven para asincronía
ADR-007: CQRS para consultas complejas

Prototipos técnicos:

• Integración de pagos (Spike: 3 días)
• Test de rendimiento (Load: 5.000 usuarios)
• Test de seguridad (Penetration test)

Criterios de cierre:

• ✅ Revisión arquitectónica aprobada
• ✅ Benchmarks de rendimiento alcanzados
• ✅ Revisión de seguridad aprobada
• ✅ Prototipos exitosos

---

Fase 4: Diseño de módulos (2 semanas)

Artefactos creados:

Diagramas de clases:
- User Service: 12 clases
- Order Service: 18 clases
- Payment Service: 8 clases

Especificaciones de interfaces:
- Internal API: 67 métodos
- External API: 47 endpoints
- Database Schema: 23 tablas

UI Design:
- 47 wireframes
- 23 mockups de alta fidelidad
- Diseño responsivo (Mobile/Desktop)

Aseguramiento de calidad:

• Design reviews con desarrolladores senior
• Normalización de base de datos (3NF)
• Usability tests UI con 5 usuarios

---

Fase 5: Implementación (8 semanas)

Artefactos creados:

Código fuente:
- 45.000 líneas de código
- 237 unit tests (92% cobertura)
- 47 integration tests

CI/CD Pipeline:
- Automated Builds
- Code Quality Checks (SonarQube)
- Automated Testing
- Deployment to Staging

Métricas de calidad:

• Code Coverage: 92%
• SonarQube Quality Gate: ✅ Passed
• Build Time: 4 minutos
• Test Execution: 8 minutos

Retroalimentación: 2 problemas de rendimiento → regresa a Fase 4

---

Fase 6: Preparación de tests (2 semanas)

Artefactos creados:

Concepto de tests:
- 4 niveles de prueba (Unit/Integration/System/Acceptance)
- 3 entornos de test (Dev/Staging/Prod)
- Automatización de tests: Selenium + Cypress

Casos de prueba:
- 345 tests funcionales
- 67 tests de rendimiento
- 23 tests de seguridad
- 12 tests de usabilidad

Datos de prueba:
- 1.200 clientes sintéticos
- 5.000 productos de prueba
- 800 pedidos de prueba

---

Fase 7: Ejecución de tests (4 semanas)

Resultados de tests:

Tests de módulos: 237/237 ✅ (100%)
Tests de integración: 45/47 ✅ (96%)
Tests del sistema: 89/95 ✅ (94%)
Tests de rendimiento: 22/23 ✅ (96%)
Tests de seguridad: 20/23 ❌ (87%)

Errores encontrados:
- Critical: 2 (Security issues)
- Major: 8 (Functional defects)
- Minor: 15 (UI issues)

Retroalimentaciones:

• Security issues → regresa a Fase 3 (Arquitectura)
• Problema de rendimiento → regresa a Fase 4 (Diseño)

---

Fase 8: Lanzamiento (2 semanas)

Artefactos creados:

Deployment:
- Docker Container
- Kubernetes Konfiguration
- Monitoring (Prometheus + Grafana)
- Logging (ELK Stack)

Documentación:
- Guía de instalación (45 páginas)
- Manual de usuario (120 páginas)
- Manual de administrador (80 páginas)
- API Documentation (OpenAPI 3.0)

Capacitación:
- 12 entrenamientos de administrador
- 45 trainings de usuario
- 8 guías de soporte

Resultado de go-live:

• ✅ Deployment exitoso
• ✅ Migración de datos completada
• ✅ Usuarios capacitados
• ✅ Monitoring activo

---

Resumen del proyecto

Éxitos:

• ✅ Cronograma cumplido (+2 semanas de buffer)
• ✅ Presupuesto respetado (+5%)
• ✅ Objetivos de calidad alcanzados
• ✅ Aceptación de usuarios: 87%

Desafíos:

• 3 retroalimentaciones mayores (Fases 3, 4, 7)
• 2 solicitudes de cambio durante desarrollo
• 1 problema de seguridad en el último momento

Lecciones aprendidas:

• Los prototipos tempranos reducen riesgos
• Las revisiones regulares son decisivas
• La trazabilidad ahorra mucho tiempo en depuración

Ventajas e inconvenientes

Ventajas

• Planificación clara y responsabilidades definidas
• Detección más temprana de errores (reviews/prototipos)
• Cambios menos costosos al final del proyecto
• Buena documentación (Audit/IHK)

Inconvenientes

• Los saltos hacia atrás generan esfuerzo de coordinación
• Tiempo de preparación mayor (especificación/planificación de tests)
• Menos flexible que modelos fuertemente iterativos

Trazabilidad y gestión de requisitos

Crear matriz de trazabilidad

Propósito: Asegurar que cada requisito se implemente y se pruebe.

Ejemplo de matriz de trazabilidad:

ID de requisito	Texto del requisito	Elemento de diseño	Componente de código	Caso de prueba	Estado
REQ-001	Registro de usuario con validación de email	UserRegistrationController	UserRegistrationService	TEST-001, TEST-002	✅
REQ-015	Función de reset de contraseña	PasswordResetController	PasswordResetService	TEST-045, TEST-046	✅
REQ-023	Catálogo de productos con filtrado	ProductCatalogController	ProductService	TEST-089, TEST-090	❌
REQ-034	Función de carrito de compras	ShoppingCartController	CartService	TEST-123, TEST-124	✅

Herramientas de trazabilidad:

• Requirements Management Tools: JIRA, Polarion, DOORS
• Test Management Tools: TestRail, Zephyr, Xray
• Excel/Google Sheets: Para proyectos pequeños
• Custom Solutions: Scripts de trazabilidad

Proceso de trazabilidad

1. Capturar requisito → REQ-XXX
2. Asignar diseño → ARCH-XXX
3. Vincular implementación → CODE-XXX
4. Derivar casos de prueba → TEST-XXX
5. Documentar aceptación → STATUS: ✅/❌
6. Analizar desviaciones → Change Request

Gestión de cambios y baselines

Definir baselines

Baseline: Estado documentado de artefactos en un momento específico.

Tipos de baselines:

• Requirements Baseline: Requisitos aprobados
• Design Baseline: Documentos de diseño liberados
• Code Baseline: Versión de código estable
• Test Baseline: Resultados de prueba aceptados

Proceso de Solicitud de Cambio

Ingresar Solicitud de Cambio
        ↓
Realizar Análisis de Impacto
        ↓
Junta Asesor de Cambios (CAB) evalúa
        ↓
Decisión: Aprobado/Rechazado
        ↓
Si se aprueba:
  - Actualizar baseline
  - Ajustar trazabilidad
  - Informar fases afectadas
  - Ejecutar pruebas

Plantilla de Solicitud de Cambio:

CR-2024-001
Título: Cambio en la política de contraseñas
Justificación: Nuevos requisitos de seguridad
Impacto:
- REQ-015: Aumentar complejidad de contraseña
- ARCH-007: Ajustar Password Validator
- TEST-045: Agregar nuevos casos de prueba
Estimación de costo: 8 horas
Prioridad: Alta
Aprobado: ✅

Comparación con otros Modelos de Procesos

Cascada Clásica vs. Cascada Extendida

Criterio	Cascada Clásica	Cascada Extendida
Realimentación	Ninguna	Retrocesos controlados
Detección de errores	Tardía (fase de pruebas)	Temprana (prototipos/revisiones)
Flexibilidad	Muy baja	Moderada
Esfuerzo de planificación	Bajo	Alto
Gestión de riesgos	Limitada	Exhaustiva
Documentación	Extensa	Muy extensa

Cascada vs. Modelo V

Modelo Cascada:
Requisitos → Diseño → Implementación → Pruebas → Lanzamiento
    ↓
    ↑
   (Sin conexión directa)

Modelo V:
Levantamiento de Requisitos ←─────── Prueba de Aceptación
        ↓                      ↑
Diseño del Sistema ←─────── Prueba del Sistema
        ↓                      ↑
Diseño de Arquitectura ←─── Prueba de Integración
        ↓                      ↑
Diseño de Módulos ←─────── Prueba de Módulos
        ↓                      ↑
Implementación ────────────────

Cascada vs. Métodos Ágiles

Aspecto	Cascada	Ágil (Scrum/Kanban)
Planificación	Anticipada, detallada	Iterativa, adaptativa
Cambios	Costosos, formales	Simples, bienvenidos
Riesgo	Alto (al final)	Bajo (temprano)
Transparencia	Basada en fases	Continua
Retroalimentación del cliente	Al final	Cada iteración
Estructura del equipo	Silos	Multidisciplinario

Cuándo es apropiado el Modelo Cascada Extendido

✅ Apropiado para:

• Industrias reguladas (dispositivos médicos, automoción, aviación)
• Sistemas críticos para la seguridad
• Proyectos con requisitos estables
• Proyectos gubernamentales y de administración pública
• Sistemas con altos requisitos de cumplimiento normativo

❌ Menos apropiado para:

• Mercados altamente volátiles
• Startups con cambios frecuentes de dirección
• Proyectos con requisitos inciertos
• Proyectos pequeños y experimentales
• Productos centrados en el usuario con cambios frecuentes de UX

Preguntas Típicas de Examen (con Respuesta Breve)

1. ¿Diferencia entre cascada clásica y extendida? Extendida = retrocesos definidos + aseguramiento de calidad temprano/prototipos.

2. ¿Cuál es el rol de los prototipos? Validar riesgos tempranamente (rendimiento, seguridad, UX).

3. ¿Verificación vs. Validación? Verificación contra la especificación, validación contra el propósito/beneficio.

4. ¿Cómo se controlan los retrocesos? Decisión en compuerta, análisis de impacto, solicitud de cambio, aceptación renovada.

5. ¿Qué es una baseline? Estado establecido de artefactos en un momento específico.

6. ¿Propósito de la trazabilidad? Asegurar que cada requisito se implemente y se pruebe.

7. ¿Proceso de Solicitud de Cambio? Análisis de impacto → Evaluación de CAB → Aprobación → Ejecución.

8. ¿Ventajas respecto a la cascada clásica? Detección temprana de errores, mejor control de riesgos, mayor calidad.

9. ¿Desventajas respecto a métodos ágiles? Menos flexible, esfuerzo de planificación mayor, retroalimentación del cliente tardía.

10. ¿Cuándo usar prototipos? Con riesgos técnicos, requisitos inciertos, interfaces complejas.

Estrategia de Aprendizaje

1. Visualizar Fases con Artefactos y Criterios de Aceptación

Método: Crea un resumen detallado de fases con todos los artefactos relevantes y criterios de compuerta.

Ejercicio Práctico:

Fase 1: Fase de Requisitos
├── Artefactos: Documento de Requisitos, Especificación, Catálogo de Requisitos
├── Actividades: Entrevistas con stakeholders, talleres, priorización
├── Medidas de QA: Revisiones de requisitos, verificaciones de consistencia
└── Criterios de Compuerta: ✅ Todos los requisitos priorizados, ✅ Aceptación de expertos

Objetivo de Aprendizaje: Entiendes qué artefactos se producen en cada fase y cómo funciona el aseguramiento de calidad.

2. Practicar un Escenario de Retroceso Detalladamente

Método: Documenta un escenario completo de realimentación desde el descubrimiento del error hasta la aceptación renovada.

Ejemplo Práctico:

Escenario: Prueba de integración falla
├── Descubrimiento de Error: Falla en prueba de integración, fase 7
├── Análisis de Error: Problema de rendimiento en acceso a base de datos
├── Análisis de Impacto: Identificar componentes afectados
├── Solicitud de Cambio: Crear CR-2024-001 y aprobar
├── Retroceso: Volver a fase 4 (Diseño de Módulos)
├── Corrección: Optimizar diseño de base de datos
├── Nuevas Pruebas: Agregar pruebas de rendimiento
└── Aceptación Renovada: Fase 7 aprobada exitosamente

Objetivo de Aprendizaje: Comprendes cómo se ejecutan los retrocesos de forma controlada y qué pasos son necesarios.

3. Comparar Modelos de Proceso Sistemáticamente

Método: Crea una matriz de comparación de los modelos de proceso más importantes con criterios concretos.

Completar Matriz de Comparación:

Criterio	Cascada Clásica	Cascada Extendida	Modelo V	Scrum
Flujo de fases	Lineal	Lineal con retrocesos	Forma de V	Iterativo
Flexibilidad	Muy baja	Moderada	Baja	Muy alta
Gestión de riesgos	Tardía	Temprana (prototipos)	Temprana	Continua
Documentación	Extensa	Muy extensa	Extensa	Mínima
Retroalimentación del cliente	Al final	Entre fases	Entre fases	Cada iteración

Objetivo de Aprendizaje: Puedes justificar las ventajas y desventajas de cada modelo y seleccionar el más adecuado.

4. Crear una Tabla de Trazabilidad Práctica

Método: Elabora una matriz de trazabilidad completa para un pequeño ejemplo de proyecto.

Ejemplo de Proyecto: Sistema de Registro de Usuarios

Capturar Requisitos:
REQ-001: El usuario debe poder registrarse con correo electrónico y contraseña
REQ-002: La contraseña debe tener 8-20 caracteres
REQ-003: El correo electrónico debe ser validado
REQ-004: Las direcciones de correo duplicadas deben evitarse

Asignar Diseño:
ARCH-001: UserRegistrationController
ARCH-002: PasswordValidator
ARCH-003: EmailService
ARCH-004: UserRepository

Vincular Implementación:
CODE-001: UserRegistrationService.java
CODE-002: PasswordValidator.java
CODE-003: EmailValidator.java
CODE-004: UserRepository.java

Derivar Casos de Prueba:
TEST-001: Registro con datos válidos
TEST-002: Registro con contraseña muy corta
TEST-003: Registro con correo inválido
TEST-004: Registro con correo existente

Objetivo de Aprendizaje: Comprendes cómo se establece la trazabilidad continua y por qué es importante.

5. Practicar Gestión de Cambios

Método: Simula una Solicitud de Cambio para un proyecto en curso.

Escenario de Práctica:

Situación Inicial: Proyecto en fase 5 (Implementación)
Solicitud de Cambio: Agregar funcionalidad "Inicio de Sesión Social"

Ejecución:
1. Completar formulario de Solicitud de Cambio
2. Realizar análisis de impacto:
   - Impacto técnico: Integración OAuth2 requerida
   - Impacto de tiempo: +2 semanas de desarrollo
   - Impacto de costo: +8.000€
3. Evaluar riesgos: Seguridad de la integración OAuth2
4. Tomar decisión: Aprobado con pruebas de seguridad adicionales
5. Actualizar baselines y ajustar trazabilidad

Objetivo de Aprendizaje: Puedes ejecutar y documentar procesos de cambio de forma profesional.

6. Preparación específica para el examen

Método: Prepárate para preguntas típicas del examen IHK con respuestas estructuradas.

Practica preguntas de examen frecuentes:

• “Describe las fases del modelo de cascada extendido con los artefactos principales.”
• “Explica la diferencia entre verificación y validación con un ejemplo práctico.”
• “¿Cómo realizas un análisis de impacto para un cambio de requisitos?”
• “¿Qué papel juegan los prototipos en el modelo de cascada extendido?”

Entrena la estructura de respuesta:

1. Explicar definición/concepto
2. Dar un ejemplo práctico
3. Mostrar ventajas/desventajas
4. Enfatizar aspectos relevantes para el examen IHK

7. Plan de estudio para la preparación del examen

Fases de aprendizaje recomendadas:

Semana 1: Comprensión de fundamentos

• Aprende las fases y artefactos
• Domina verificación vs. validación
• Repasa conceptos básicos

Semana 2: Profundización

• Practica escenarios de retroalimentación
• Estudia gestión de cambios
• Trabaja con trazabilidad

Semana 3: Aplicación

• Analiza ejemplos prácticos
• Compara con otros modelos
• Responde preguntas de examen

Semana 4: Revisión

• Revisa todos los conceptos
• Identifica debilidades
• Realiza simulación de examen

Consejo de estudio: Enfócate en los aspectos relevantes para IHK: estructura, documentación, aseguramiento de calidad y trazabilidad.

Fuentes principales

1. https://de.wikipedia.org/wiki/Wasserfallmodell
2. https://dl.acm.org/doi/10.1145/360248.360251

Preguntas típicas de examen que tu evaluador podría hacerte