🔄 Metodologías de desarrollo

1. ¿Quién publicó en 1970 el artículo que originó la descripción del modelo de proceso en cascada, presentándolo como un enfoque riesgoso para proyectos grandes?

1. Winston W. Royce
2. Barry Boehm
3. Philippe Kruchten
4. Kent Beck

Winston W. Royce describió el modelo secuencial en su artículo de 1970, advirtiendo sus riesgos para proyectos grandes; Boehm propuso el espiral, Kruchten el RUP y Beck se asocia a TDD/XP. (W. W. Royce, 'Managing the Development of Large Software Systems', Proc. IEEE WESCON, 1970.)

2. En su artículo original de 1970, ¿qué recomendó realmente Winston Royce respecto del modelo secuencial de fases que había descrito?

1. Que se ejecutara de forma estrictamente secuencial, sin retroceder nunca a una fase anterior
2. Que se iterara entre fases adyacentes, porque el modelo puramente secuencial resultaba riesgoso en proyectos grandes
3. Que se sustituyera por completo el desarrollo por prototipos desechables antes de programar
4. Que se limitara el trabajo en curso mediante un tablero visual de tareas

Royce señaló en su propio artículo que el modelo puramente secuencial era riesgoso en proyectos grandes y recomendó iterar entre fases contiguas, al contrario de la lectura popular del 'cascada' como proceso rígido. (W. W. Royce, 'Managing the Development of Large Software Systems', Proc. IEEE WESCON, 1970.)

3. ¿Cuál es el orden convencional de las fases en el modelo de proceso en cascada?

1. Diseño, requerimientos, verificación, implementación, mantenimiento
2. Requerimientos, implementación, diseño, mantenimiento, verificación
3. Requerimientos, diseño, implementación, verificación, mantenimiento
4. Implementación, diseño, requerimientos, mantenimiento, verificación

El modelo en cascada organiza el desarrollo en fases secuenciales que van de la definición de requerimientos hasta el mantenimiento, cada una concluyendo antes de iniciar la siguiente. (Modelo en cascada, descripción estándar derivada de W. W. Royce (1970).)

4. Un equipo debe desarrollar el software de control de un dispositivo médico con requerimientos regulatorios fijos, documentación exhaustiva obligatoria y nula tolerancia a cambios de diseño una vez aprobado. ¿Qué modelo de proceso conviene aplicar?

1. Kanban, porque limita el trabajo en curso sin necesidad de definir fases formales
2. Modelo incremental, porque permite entregar funcionalidad parcial del sistema cuanto antes
3. Programación extrema (XP), porque prioriza el cambio continuo de los requerimientos del cliente
4. Modelo en cascada, por la estabilidad de los requerimientos y la exigencia de documentación formal

Con requerimientos regulatorios estables y exigencia de documentación formal, el modelo en cascada es el más adecuado; los marcos ágiles asumen cambio frecuente y el incremental prioriza entregas parciales que aquí no aportan ventaja regulatoria. (Caracterización estándar del modelo en cascada (Royce, 1970) aplicada a la selección de metodología.)

5. ¿Qué caracteriza principalmente al modelo de proceso incremental?

1. El sistema se divide en compilaciones (builds) sucesivas que agregan funcionalidad hasta completar el producto
2. Todas las fases del ciclo de vida se ejecutan una sola vez y en un único bloque
3. El nivel de riesgo de cada ciclo decide si el proyecto continúa o se cancela
4. El producto se entrega completo al usuario solo hasta el final del proyecto

El modelo incremental construye el sistema mediante compilaciones sucesivas que van sumando funcionalidad; decidir por riesgo describe al modelo en espiral y la entrega única al final describe al modelo en cascada. (Descripción estándar del modelo de proceso incremental en ingeniería de software.)

6. Una empresa necesita comenzar a usar cuanto antes el módulo de facturación de un ERP, mientras los módulos de inventario y reportes siguen en desarrollo con equipos escalonados. ¿Qué modelo de proceso conviene aplicar?

1. Modelo en cascada puro, completando el análisis de todos los módulos antes de programar cualquiera
2. Modelo incremental, entregando cada módulo como una compilación funcional independiente
3. Modelo en espiral, evaluando el riesgo antes de iniciar cada módulo del sistema
4. Modelo en cascada con una única entrega general al final de todo el proyecto

El escenario exige poner en uso partes del sistema antes de terminar todo el proyecto, lo cual corresponde al modelo incremental; el en cascada retrasaría el uso del módulo de facturación y el espiral se centra en riesgo, no en entregas parciales por módulo. (Descripción estándar del modelo de proceso incremental en ingeniería de software.)

7. ¿Cuál es una condición necesaria para aplicar exitosamente el modelo incremental en un proyecto de software?

1. Congelar por completo los requerimientos antes de iniciar cualquier incremento del proyecto
2. Evitar cualquier documentación de diseño hasta entregar el último incremento del sistema
3. Definir desde el inicio una arquitectura capaz de acomodar incrementos sin reescribir lo ya construido
4. Sustituir las pruebas de integración por pruebas unitarias de manera exclusiva

Para que los incrementos se sumen sin retrabajo mayor se requiere una arquitectura base capaz de acomodarlos; congelar requerimientos totales o eliminar documentación y pruebas de integración contradice la naturaleza incremental. (Descripción estándar del modelo de proceso incremental en ingeniería de software.)

8. ¿Cuál de las siguientes NO es una característica típica del modelo en cascada?

1. Fases secuenciales con entregables claramente definidos al final de cada una
2. Documentación formal y extensa elaborada en cada una de las fases
3. Dificultad para incorporar cambios de requerimientos una vez avanzado el proyecto
4. Retroalimentación temprana y continua del cliente en cada iteración corta

La retroalimentación continua en iteraciones cortas es propia de marcos ágiles, no del modelo en cascada, que se caracteriza por fases secuenciales, documentación formal y poca flexibilidad ante cambios tardíos. (Contraste entre el modelo en cascada (Royce, 1970) y las prácticas ágiles iterativas.)

9. En comparación con el modelo en cascada, ¿qué ventaja ofrece el modelo incremental para reducir el impacto de malentendidos con el cliente sobre el sistema?

1. Permite validar cada incremento con el usuario para corregir el rumbo a tiempo
2. Elimina por completo la necesidad de documentar el diseño del sistema
3. Garantiza que el costo de corregir cualquier defecto sea idéntico en cualquier etapa
4. Reduce a cero el riesgo de integración entre los módulos del sistema

Al validar y entregar incrementos de forma temprana, el modelo incremental permite corregir el rumbo antes de construir todo el sistema; las demás opciones son afirmaciones absolutas que ningún modelo de proceso garantiza. (Descripción estándar del modelo incremental frente al modelo en cascada.)

10. El Proceso Unificado de Rational (RUP), citado como ejemplo de proceso iterativo e incremental, organiza el desarrollo en cuatro fases secuenciales. ¿Cuál es el orden correcto de esas fases?

1. Análisis, Diseño, Construcción y Prueba
2. Inicio, Elaboración, Construcción y Transición
3. Elaboración, Inicio, Transición y Construcción
4. Inicio, Construcción, Elaboración y Transición

RUP define las fases Inicio (Inception), Elaboración, Construcción y Transición, en ese orden, como ejemplo de proceso iterativo e incremental estructurado. (P. Kruchten, 'The Rational Unified Process: An Introduction' (Rational Software / IBM).)

11. Un equipo divide el desarrollo de un sistema de nómina en cuatro incrementos. Al entregar el segundo incremento, el cliente solicita un cambio que afecta la arquitectura definida en el primer incremento, obligando a retrabajar código ya entregado. ¿Qué conclusión es válida sobre este caso?

1. Esto demuestra que el modelo incremental equivale a aplicar el modelo en cascada una sola vez
2. Esto es normal y esperado, pues el modelo incremental no requiere ningún diseño arquitectónico previo
3. El riesgo se materializó porque la arquitectura inicial no anticipó bien los incrementos futuros
4. Esto indica que el equipo debió usar el modelo en cascada puro, que nunca genera retrabajo

El caso ilustra el riesgo característico del modelo incremental cuando la arquitectura inicial no soporta bien los cambios futuros; el modelo incremental sí requiere planeación arquitectónica previa y el en cascada no elimina el retrabajo, solo lo detecta más tarde. (Descripción estándar del modelo incremental y sus riesgos arquitectónicos.)

12. A diferencia del modelo incremental, en el modelo en cascada clásico el software se pone a disposición del cliente...

1. Al finalizar cada incremento funcional previamente planificado y aceptado
2. Cada vez que se libera una nueva rama en el control de versiones
3. Al final de cada sprint de duración fija
4. Hasta que concluye la última fase del proyecto, como entregable único

El modelo en cascada clásico contempla un solo entregable al final del proyecto, mientras que el incremental libera funcionalidad por partes; las otras opciones describen prácticas ajenas al modelo en cascada. (Contraste estándar entre el modelo en cascada y el modelo incremental.)

13. ¿Qué miden los story points (puntos de historia) en la estimación ágil?

1. El esfuerzo relativo, la complejidad y la incertidumbre de una historia de usuario
2. El número exacto de horas-hombre necesarias para completar una historia de usuario
3. El costo monetario directo de desarrollar una historia de usuario
4. El número de líneas de código que deberá escribir el equipo

Los story points expresan tamaño relativo (esfuerzo, complejidad, incertidumbre) y no una medida directa de tiempo, costo o líneas de código. (Práctica estándar de estimación ágil (Mike Cohn, 'Agile Estimating and Planning', 2005).)

14. ¿La Guía Scrum (Scrum Guide) 2020 define formalmente el uso de story points como técnica de estimación obligatoria?

1. Sí, la Guía Scrum 2020 exige registrar en story points cada elemento del Sprint Backlog
2. No, los story points son una práctica popular de la comunidad ágil, ajena al marco oficial de Scrum
3. Sí, pero únicamente permite emplearlos durante la reunión de Sprint Retrospective del equipo
4. No, porque la Guía Scrum prohíbe expresamente cualquier técnica de estimación relativa

La Guía Scrum 2020 no menciona ni exige story points; son una práctica ampliamente adoptada por equipos ágiles pero externa al marco oficial de Scrum, que tampoco prohíbe la estimación relativa. (The Scrum Guide (2020), Ken Schwaber y Jeff Sutherland (no hace referencia a story points).)

15. En la técnica de planning poker, ¿qué tipo de escala numérica se utiliza comúnmente para asignar story points?

1. Una escala de calificación de 1 a 5 estrellas
2. Una escala lineal exacta de 1 a 10 en incrementos de uno
3. Una secuencia similar a Fibonacci que refleja mayor incertidumbre en tareas de mayor tamaño
4. Una escala de porcentajes que va de 0% a 100% del avance total

Planning poker suele usar una escala tipo Fibonacci, que separa más los valores altos para reflejar la mayor incertidumbre al estimar historias grandes. (Práctica estándar de planning poker en estimación ágil.)

16. ¿Cómo se define la velocidad de un equipo Scrum?

1. El número de reuniones diarias (Daily Scrum) realizadas durante el sprint
2. El porcentaje de historias de usuario que el Product Owner aprueba sin cambios
3. La cantidad total de horas trabajadas por el equipo durante todo el proyecto
4. La cantidad promedio de story points completados por sprint, cumpliendo la Definición de Terminado

La velocidad se calcula con los story points de historias efectivamente terminadas, según la Definición de Terminado, en sprints anteriores, no con horas trabajadas ni con métricas de reuniones o aprobación. (Práctica estándar de estimación ágil; Definición de Terminado según The Scrum Guide (2020).)

17. Un equipo completó 24, 28 y 32 story points en sus últimos tres sprints, respectivamente. Si el Product Backlog restante suma 168 story points, ¿aproximadamente cuántos sprints adicionales necesitará el equipo para terminarlo, usando su velocidad promedio?

1. 6 sprints
2. 7 sprints
3. 5 sprints
4. 8 sprints

La velocidad promedio es (24+28+32)/3 = 28 puntos por sprint, y 168 entre 28 da 6 sprints; usar solo el sprint más lento (24) sobreestima a 7 y usar solo el más rápido (32) subestima a 5. (Cálculo estándar de velocidad promedio en estimación ágil.)

18. Durante sus primeros cuatro sprints, un equipo completó 20, 22, 18 y 24 story points, respectivamente. ¿Cuál es la velocidad promedio del equipo?

1. 84 story points por sprint
2. 21 story points por sprint
3. 18 story points por sprint
4. 24 story points por sprint

La velocidad promedio se obtiene sumando los puntos de los cuatro sprints (84) y dividiendo entre 4, lo que da 21; sumar sin dividir (84) es un error común, igual que tomar el valor mínimo o máximo. (Cálculo estándar de velocidad promedio en estimación ágil.)

19. ¿Por qué la velocidad de un equipo NO debe usarse para comparar el desempeño entre distintos equipos Scrum?

1. Porque los story points deben expresarse siempre en horas y no en puntos
2. Porque la velocidad únicamente puede calcularse una vez concluido todo el proyecto
3. Porque cada equipo calibra sus story points de forma relativa y propia, sin escala común entre equipos
4. Porque la Guía Scrum prohíbe expresamente calcular la velocidad de más de un equipo

Como cada equipo calibra su propia escala relativa de story points, un mismo número de puntos no representa el mismo esfuerzo entre equipos distintos, por lo que comparar sus velocidades directamente es inválido. (Práctica estándar de estimación ágil sobre las limitaciones de la velocidad como métrica comparativa.)

20. Un equipo reporta que completó 40 story points en el sprint recién terminado; sin embargo, 10 de esos puntos corresponden a una historia que quedó parcialmente codificada y aún no pasa las pruebas de aceptación, es decir, no cumple la Definición de Terminado. ¿Qué velocidad debería registrar el equipo para ese sprint?

1. 40 story points, pues toda historia iniciada en el sprint cuenta, cumpla o no la Definición de Terminado
2. 35 story points, ponderando el avance parcial de la historia según el porcentaje de código completado
3. 10 story points, contando únicamente el trabajo que aún no satisface la Definición de Terminado
4. 30 story points, pues la velocidad solo debe incluir historias que cumplen la Definición de Terminado

La velocidad solo debe contabilizar historias que cumplen la Definición de Terminado; como la historia de 10 puntos quedó incompleta, la velocidad real del sprint es 40 menos 10, es decir 30 puntos. (The Scrum Guide (2020), artefacto Increment y su compromiso de Definición de Terminado.)

21. ¿Por qué muchos equipos ágiles prefieren estimar historias de usuario en story points en lugar de horas u horas-hombre?

1. Porque la estimación relativa entre historias suele ser más rápida y consistente que estimar tiempo absoluto
2. Porque la Guía Scrum exige que toda estimación se exprese exclusivamente en puntos
3. Porque los story points garantizan una precisión matemática exacta del tiempo de desarrollo
4. Porque los story points eliminan por completo la necesidad de planificar el sprint

Estimar de forma relativa, comparando historias entre sí, suele ser más rápido y menos sesgado por diferencias individuales que estimar horas absolutas; la Guía Scrum no exige story points ni estos garantizan precisión de tiempo. (Mike Cohn, 'Agile Estimating and Planning' (2005).)

22. ¿Cuál es el propósito principal de la técnica de planning poker en la estimación ágil?

1. Determinar de manera automática la fecha exacta de entrega del proyecto completo
2. Lograr consenso entre los miembros del equipo sobre el tamaño relativo de una historia
3. Asignar de forma aleatoria las historias de usuario a cada integrante del equipo
4. Sustituir por completo la necesidad de contar con un Sprint Backlog

Planning poker busca que el equipo converja en una estimación de consenso, revelando las cartas simultáneamente para evitar que la opinión de una sola persona ancle al resto. (Práctica estándar de planning poker en estimación ágil.)

23. Un Product Owner necesita estimar cuántos sprints tomará completar un release de 90 story points. El equipo ha mantenido una velocidad estable de 15 story points por sprint durante los últimos cinco sprints. ¿Cuántos sprints debe planificar el Product Owner?

1. 5 sprints
2. 90 sprints
3. 6 sprints
4. 7 sprints

Dividiendo el tamaño del release entre la velocidad estable del equipo (90 entre 15) se obtiene 6 sprints; olvidar dividir entre la velocidad llevaría erróneamente a 90 sprints. (Cálculo estándar de planeación de release con velocidad en estimación ágil.)

24. ¿Cuál es la característica esencial que distingue a un modelo de proceso iterativo e incremental de un modelo puramente secuencial (cascada)?

1. El software se construye y libera en ciclos sucesivos, refinando requerimientos y diseño en cada uno
2. Todas las actividades de análisis, diseño, codificación y prueba se ejecutan una sola vez y en orden fijo
3. El equipo documenta el 100% de los requerimientos antes de iniciar cualquier actividad de codificación
4. La evaluación de riesgos del proyecto se realiza únicamente al concluir la última fase

El enfoque iterativo-incremental construye el producto en ciclos repetidos que permiten refinar requerimientos y diseño, a diferencia del enfoque secuencial de una sola pasada que Royce (1970) señaló como riesgoso. (W. W. Royce, 'Managing the Development of Large Software Systems', Proc. IEEE WESCON, 1970 (contraste con el enfoque iterativo).)

25. El artículo de 1970 de Winston W. Royce se cita con frecuencia como el origen del modelo en cascada. ¿Qué planteaba en realidad ese artículo respecto de ejecutar el desarrollo en una sola pasada secuencial?

1. Que ese enfoque era el método ideal y no debía tener retornos a fases anteriores
2. Que ese enfoque era riesgoso y que el proceso debía iterar entre fases para reducirlo
3. Que ese enfoque solo era aplicable a proyectos de mantenimiento correctivo
4. Que ese enfoque debía sustituirse de inmediato por el uso exclusivo de prototipos desechables

Royce presentó el desarrollo secuencial de una sola pasada como riesgoso y recomendó incorporar iteración y retroalimentación entre fases, al contrario de la interpretación popular de una 'cascada ideal'. (W. W. Royce, 'Managing the Development of Large Software Systems', Proc. IEEE WESCON, 1970.)

26. ¿Qué autor propuso el modelo espiral de desarrollo de software y en qué año?

1. Winston Royce, en 1970
2. Philippe Kruchten, en 1998
3. Barry Boehm, en 1988
4. Ivar Jacobson, en 1992

Barry Boehm propuso el modelo espiral en 1988 como un modelo de proceso guiado por el análisis de riesgos en cada ciclo. (B. W. Boehm, 'A Spiral Model of Software Development and Enhancement', IEEE Computer, 1988.)

27. En el modelo espiral de Boehm, ¿qué actividad se lleva a cabo en cada ciclo antes de decidir si el proyecto avanza a la siguiente vuelta de la espiral?

1. La certificación externa de calidad del producto final entregado al cliente
2. El congelamiento definitivo de todos los requerimientos del sistema completo
3. La entrega del incremento al cliente sin ninguna revisión previa del equipo
4. La identificación y el análisis de riesgos del ciclo actual

Cada ciclo de la espiral incluye una etapa dedicada a identificar y analizar los riesgos del ciclo actual, la cual determina si conviene continuar, ajustar el plan o detener el proyecto. (B. W. Boehm, 'A Spiral Model of Software Development and Enhancement', IEEE Computer, 1988.)

28. Si en un ciclo del modelo espiral el análisis de riesgos detecta una incertidumbre técnica alta sobre un componente clave, ¿qué acción es consistente con el enfoque de Boehm antes de continuar con el desarrollo formal?

1. Construir un prototipo para reducir la incertidumbre detectada
2. Omitir el riesgo y continuar con la codificación planeada
3. Congelar los requerimientos restantes hasta el cierre del proyecto
4. Transferir el riesgo íntegramente al área de mantenimiento

El modelo espiral responde a un riesgo técnico alto construyendo prototipos u otras estrategias de reducción de riesgo antes de comprometerse con el desarrollo formal del ciclo. (B. W. Boehm, 'A Spiral Model of Software Development and Enhancement', IEEE Computer, 1988.)

29. ¿Quién documentó el Proceso Unificado de Rational (RUP) como un modelo de proceso iterativo e incremental organizado en fases?

1. Barry Boehm
2. Philippe Kruchten
3. Winston Royce
4. David J. Anderson

Philippe Kruchten describió el RUP como un proceso iterativo e incremental estructurado en fases, en su obra de introducción publicada por Rational Software/IBM. (P. Kruchten, 'The Rational Unified Process: An Introduction', Rational Software / IBM.)

30. ¿Cuáles son, en orden, las cuatro fases en que se organiza el Proceso Unificado de Rational (RUP)?

1. Análisis, Diseño, Codificación y Prueba
2. Planeación, Ejecución, Monitoreo y Cierre
3. Inicio, Elaboración, Construcción y Transición
4. Concepción, Desarrollo, Verificación y Mantenimiento

El RUP organiza el trabajo en cuatro fases secuenciales con iteraciones internas: Inicio, Elaboración, Construcción y Transición. (P. Kruchten, 'The Rational Unified Process: An Introduction', Rational Software / IBM.)

31. ¿Cuál es el objetivo principal de la fase de Inicio (Inception) en el RUP?

1. Definir y estabilizar la arquitectura completa del sistema
2. Codificar e integrar la mayoría de los componentes
3. Capacitar a los usuarios finales y liberar el producto
4. Establecer el alcance del proyecto y evaluar su viabilidad

La fase de Inicio del RUP se centra en delimitar el alcance del proyecto y valorar su viabilidad económica y de riesgo, antes de invertir en el diseño detallado. (P. Kruchten, 'The Rational Unified Process: An Introduction', Rational Software / IBM.)

32. A diferencia de la fase de Inicio del RUP, que se centra en delimitar el alcance y la viabilidad del proyecto, ¿cuál es el objetivo distintivo de la fase de Elaboración?

1. Definir y estabilizar la arquitectura base, mitigando los principales riesgos técnicos
2. Entregar el producto final al cliente y cerrar formalmente el contrato de soporte
3. Ejecutar las pruebas de aceptación únicamente con los usuarios finales del sistema
4. Recopilar la retroalimentación de los usuarios tras el despliegue en producción

La fase de Elaboración del RUP se enfoca en definir y validar una arquitectura estable, atacando los riesgos técnicos más significativos, a diferencia de la fase de Inicio que solo delimita el alcance. (P. Kruchten, 'The Rational Unified Process: An Introduction', Rational Software / IBM.)

33. ¿Cuál es el enfoque principal de la fase de Construcción dentro del RUP?

1. Definir por primera vez el alcance del proyecto y sus principales riesgos
2. Desarrollar de forma iterativa los componentes restantes hasta completar el producto
3. Estabilizar la arquitectura base antes de iniciar cualquier codificación del sistema
4. Capacitar a los usuarios finales y liberar formalmente el producto terminado

La fase de Construcción del RUP desarrolla de manera iterativa el resto de los componentes del sistema, una vez que la arquitectura ya fue estabilizada en la fase de Elaboración. (P. Kruchten, 'The Rational Unified Process: An Introduction', Rational Software / IBM.)

34. ¿Qué actividad caracteriza principalmente a la fase de Transición del RUP?

1. Definir la arquitectura base del sistema y mitigar los riesgos técnicos principales del proyecto
2. Establecer el alcance inicial del proyecto y evaluar su viabilidad económica y de riesgo
3. Entregar el producto a los usuarios finales y realizar el paso a producción
4. Construir de manera iterativa la mayoría de los componentes restantes del sistema completo

La fase de Transición del RUP se centra en entregar el producto a los usuarios finales, incluyendo actividades de despliegue y ajuste posteriores a las pruebas beta. (P. Kruchten, 'The Rational Unified Process: An Introduction', Rational Software / IBM.)

35. De las siguientes opciones, ¿cuál NO corresponde a una de las cuatro fases del Proceso Unificado de Rational (RUP)?

1. Inicio
2. Elaboración
3. Transición
4. Mantenimiento

Las cuatro fases del RUP son Inicio, Elaboración, Construcción y Transición; 'Mantenimiento' no es una fase del RUP, aunque las actividades de soporte pueden ocurrir después de la Transición. (P. Kruchten, 'The Rational Unified Process: An Introduction', Rational Software / IBM.)