🏗️ Ingeniería de software

1. El modelo en cascada (waterfall) organiza el desarrollo de software en fases secuenciales, de manera que cada fase debe completarse y validarse antes de iniciar la siguiente. ¿Cuál es la secuencia típica de fases que describe este modelo?

1. Planeación, análisis de riesgos, ingeniería, prototipado y evaluación
2. Historias de usuario, planeación del sprint, sprint, revisión y retrospectiva
3. Requerimientos, diseño, implementación, verificación y mantenimiento
4. Inicio, elaboración, construcción, transición y despliegue

El modelo en cascada plantea fases secuenciales de requerimientos, diseño, implementación, verificación y mantenimiento; las otras secuencias evocan al modelo espiral, a Scrum y a RUP respectivamente. (W. W. Royce, "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON, 1970.)

2. Un equipo de ingeniería debe construir el software de control para un sistema embebido bajo un contrato gubernamental que fija por completo los requerimientos desde el inicio, exige documentación formal en cada etapa y no contempla cambios de alcance durante el desarrollo. ¿Qué modelo de proceso conviene aplicar en este contexto?

1. El modelo en cascada
2. El modelo ágil Scrum
3. El modelo espiral
4. El modelo iterativo RUP

Con requerimientos completos y estables desde el inicio y exigencia de documentación formal por etapa, el modelo en cascada, con fases secuenciales validadas antes de avanzar, es el más adecuado; los modelos ágil, espiral e iterativo están orientados a manejar cambio o incertidumbre. (W. W. Royce, "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON, 1970.)

3. El artículo de Winston W. Royce de 1970, frecuentemente citado como el origen documental del modelo en cascada puro, en realidad presentaba ese esquema secuencial señalando un defecto importante. ¿Cuál es ese señalamiento central del artículo original de Royce?

1. Que las pruebas deben ejecutarse antes que el diseño para reducir el costo de los defectos
2. Que el esquema secuencial sin retroalimentación entre fases resulta riesgoso y requiere iteración
3. Que la fase de mantenimiento puede omitirse si el análisis de requerimientos fue exhaustivo
4. Que el modelo funciona mejor en proyectos con equipos de menos de cinco integrantes

Royce (1970) presentó el esquema secuencial pero advirtió que, sin retroalimentación entre fases adyacentes, el modelo es riesgoso para proyectos grandes y recomendó incorporar iteración; la versión "pura" que se popularizó después ignoró esa advertencia. (W. W. Royce, "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON, 1970.)

4. El modelo espiral, propuesto por Barry Boehm, organiza el desarrollo en ciclos repetidos que combinan planeación, análisis y construcción incremental. ¿Cuál es el elemento que guía la decisión de continuar o replantear cada ciclo en este modelo?

1. La cantidad de líneas de código ya escritas
2. El número de sprints completados por el equipo
3. La aprobación final del cliente al cierre del proyecto
4. El análisis y la mitigación del riesgo del proyecto

El modelo espiral de Boehm es "risk-driven": cada vuelta de la espiral incluye explícitamente una etapa de identificación y mitigación de riesgos que determina si conviene continuar, ajustar o detener el proyecto. (B. W. Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, vol. 21, no. 5, 1988.)

5. Una empresa desarrolla un producto de software con tecnología poco probada, integraciones externas inciertas y requerimientos que se espera evolucionen conforme se conozcan resultados de prototipos tempranos. ¿Qué modelo de proceso resulta más apropiado para gestionar explícitamente la incertidumbre técnica de este proyecto?

1. El modelo espiral
2. El modelo en cascada
3. El modelo ágil Scrum
4. El modelo iterativo RUP

El modelo espiral se distingue por dedicar un paso explícito de análisis de riesgo en cada ciclo, lo que lo hace idóneo cuando existe alta incertidumbre técnica; Scrum y RUP también son iterativos, pero no centran su ciclo en el análisis formal de riesgo como elemento estructurante. (B. W. Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, vol. 21, no. 5, 1988.)

6. El Proceso Unificado de Rational (RUP) organiza el ciclo de vida del proyecto en cuatro fases sucesivas. ¿Cuál es el orden correcto de esas fases?

1. Elaboración, inicio, transición, construcción
2. Inicio, construcción, elaboración, transición
3. Inicio, elaboración, construcción, transición
4. Planeación, diseño, construcción, cierre

RUP define las fases de Inicio (Inception), Elaboración (Elaboration), Construcción (Construction) y Transición (Transition), en ese orden secuencial de hitos. (Kruchten, "The Rational Unified Process: An Introduction", Addison-Wesley; IBM Rational Unified Process.)

7. En un proyecto que sigue el Proceso Unificado de Rational, el equipo ya delimitó el alcance y los casos de uso críticos del sistema, y ahora dedica el esfuerzo principal a definir y validar la arquitectura candidata, además de mitigar los riesgos técnicos más significativos antes de construir el sistema completo. ¿En qué fase de RUP se encuentra el proyecto?

1. La fase de Inicio
2. La fase de Elaboración
3. La fase de Construcción
4. La fase de Transición

La fase de Elaboración de RUP tiene como objetivos centrales definir y validar la arquitectura del sistema y mitigar los riesgos técnicos principales, a partir de los casos de uso ya delimitados en la fase de Inicio. (Kruchten, "The Rational Unified Process: An Introduction", Addison-Wesley; IBM Rational Unified Process.)

8. De acuerdo con la Guía de Scrum (versión 2020), el Scrum Team se compone de tres responsabilidades distintas. ¿Cuáles son esas tres responsabilidades?

1. Product Owner, Project Manager y Testers
2. Scrum Master, Arquitecto de software y Developers
3. Product Owner, Scrum Master y Stakeholders
4. Product Owner, Scrum Master y Developers

La Guía de Scrum 2020 define exactamente tres responsabilidades dentro del Scrum Team: Product Owner, Scrum Master y Developers (este último término sustituyó a "Development Team" en la versión 2020). (Ken Schwaber y Jeff Sutherland, "La Guía de Scrum", noviembre de 2020.)

9. La Guía de Scrum 2020 define cinco eventos formales dentro del marco de trabajo. ¿Cuál de las siguientes actividades NO forma parte de esos cinco eventos oficiales de Scrum?

1. Revisión de código entre pares
2. Reunión diaria del equipo
3. Planeación del sprint
4. Retrospectiva del sprint

Los cinco eventos oficiales de Scrum son el Sprint, la Sprint Planning, el Daily Scrum, la Sprint Review y la Sprint Retrospective; la revisión de código entre pares es una práctica técnica común en equipos ágiles, pero no un evento definido por la Guía de Scrum. (Ken Schwaber y Jeff Sutherland, "La Guía de Scrum", noviembre de 2020.)

10. Durante la ejecución de un proyecto con Scrum, distintos integrantes del equipo proponen agregar, reordenar y priorizar elementos del Product Backlog según su propio criterio. ¿Quién tiene la responsabilidad final sobre el contenido y el orden del Product Backlog según la Guía de Scrum?

1. El Scrum Master
2. Los Developers
3. El Product Owner
4. El cliente externo

La Guía de Scrum asigna al Product Owner la responsabilidad de gestionar el Product Backlog, incluyendo su contenido, disponibilidad y ordenamiento; el Scrum Master facilita el proceso y los Developers ejecutan el trabajo, pero no poseen esa responsabilidad final. (Ken Schwaber y Jeff Sutherland, "La Guía de Scrum", noviembre de 2020.)

11. Un Scrum Master observa que las reuniones diarias del equipo se extienden más de una hora y se usan para resolver a detalle problemas técnicos particulares de cada integrante. ¿Qué corrección debería sugerir para alinear la reunión con el propósito y el timebox que la Guía de Scrum establece para el Daily Scrum?

1. Suspender la reunión diaria y sustituirla por reportes escritos semanales al Product Owner
2. Limitar la reunión a 15 minutos y enfocarla en inspeccionar el avance hacia el objetivo del sprint
3. Extender la reunión a dos horas para resolver por completo los problemas técnicos detectados
4. Delegar la reunión al Scrum Master para que decida individualmente las tareas del día

La Guía de Scrum fija el Daily Scrum en un timebox de 15 minutos, enfocado en inspeccionar el avance hacia el objetivo del sprint y ajustar el plan, no en resolver a detalle problemas técnicos individuales. (Ken Schwaber y Jeff Sutherland, "La Guía de Scrum", noviembre de 2020.)

12. El Manifiesto para el Desarrollo Ágil de Software, publicado en 2001, establece un conjunto de valores y principios que orientan a los enfoques ágiles como Scrum. ¿Cuántos valores y cuántos principios establece este manifiesto?

1. 5 valores y 10 principios
2. 4 valores y 10 principios
3. 3 valores y 12 principios
4. 4 valores y 12 principios

El Manifiesto Ágil (2001) define exactamente 4 valores fundamentales y 12 principios que los desarrollan. ("Manifesto for Agile Software Development" (Manifiesto Ágil), 2001, agilemanifesto.org.)

13. El catálogo de patrones de diseño de la "Banda de los Cuatro" (GoF), publicado en 1994, clasifica sus patrones en tres categorías según su propósito. ¿Cuántos patrones contiene el catálogo en total y cómo se distribuyen por categoría?

1. 23 patrones: 5 creacionales, 7 estructurales y 11 de comportamiento
2. 21 patrones: 5 creacionales, 6 estructurales y 10 de comportamiento
3. 23 patrones: 7 creacionales, 5 estructurales y 11 de comportamiento
4. 25 patrones: 6 creacionales, 8 estructurales y 11 de comportamiento

El catálogo GoF define 23 patrones en total, organizados en 5 creacionales, 7 estructurales y 11 de comportamiento. (Gamma, Helm, Johnson y Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley, 1994.)

14. ¿Cuál de los siguientes patrones de diseño pertenece a la categoría creacional dentro del catálogo GoF?

1. El patrón Adapter
2. El patrón Observer
3. El patrón Builder
4. El patrón Bridge

Builder es uno de los cinco patrones creacionales del catálogo GoF, junto con Abstract Factory, Factory Method, Prototype y Singleton; Adapter y Bridge son estructurales, y Observer es de comportamiento. (Gamma et al., "Design Patterns" (1994), sección de patrones creacionales.)

15. ¿Cuál de los siguientes patrones de diseño pertenece a la categoría estructural dentro del catálogo GoF?

1. El patrón Singleton
2. El patrón Facade
3. El patrón Strategy
4. El patrón Command

Facade es uno de los siete patrones estructurales del catálogo GoF; Singleton es creacional, mientras que Strategy y Command son de comportamiento. (Gamma et al., "Design Patterns" (1994), sección de patrones estructurales.)

16. ¿Cuál de los siguientes patrones NO pertenece a los patrones estructurales del catálogo GoF?

1. El patrón Composite
2. El patrón Flyweight
3. El patrón Proxy
4. El patrón Memento

Composite, Flyweight y Proxy son tres de los siete patrones estructurales del catálogo GoF; Memento pertenece a la categoría de comportamiento. (Gamma et al., "Design Patterns" (1994), sección de patrones estructurales.)

17. Dentro del catálogo de patrones GoF, el patrón Prototype se utiliza para crear nuevos objetos copiando una instancia existente que funciona como modelo. ¿A qué categoría de patrones pertenece Prototype?

1. Patrón creacional
2. Patrón estructural
3. Patrón de comportamiento
4. Patrón arquitectónico

Prototype es uno de los cinco patrones creacionales del catálogo GoF, junto con Abstract Factory, Builder, Factory Method y Singleton. (Gamma et al., "Design Patterns" (1994), sección de patrones creacionales.)

18. El catálogo GoF asigna la mayor cantidad de patrones a una sola categoría, muy por encima de las otras dos. ¿Cuál es esa categoría y cuántos patrones agrupa?

1. Estructural, con 11 patrones
2. Creacional, con 9 patrones
3. De comportamiento, con 11 patrones
4. De comportamiento, con 9 patrones

La categoría de comportamiento agrupa 11 de los 23 patrones del catálogo GoF, más que las categorías creacional (5) y estructural (7). (Gamma, Helm, Johnson y Vlissides, "Design Patterns" (1994).)

19. Un sistema necesita garantizar que exista una única instancia de su administrador de configuración global, accesible desde cualquier módulo de la aplicación sin posibilidad de crear una segunda instancia por error. ¿Qué patrón de diseño GoF resuelve directamente este requerimiento?

1. El patrón Prototype
2. El patrón Singleton
3. El patrón Builder
4. El patrón Flyweight

Singleton garantiza que una clase tenga una única instancia y proporciona un punto de acceso global a ella, justo lo que requiere un administrador de configuración compartido; Flyweight, en cambio, comparte muchos objetos de grano fino, no una única instancia. (Gamma et al., "Design Patterns" (1994), sección de patrones creacionales.)

20. Un framework debe construir documentos complejos —con encabezado, cuerpo, pie de página y metadatos opcionales— siguiendo siempre el mismo proceso de ensamblado, pero permitiendo generar representaciones finales distintas (PDF, HTML, texto plano) a partir de ese proceso. ¿Qué patrón de diseño GoF conviene aplicar?

1. El patrón Abstract Factory
2. El patrón Factory Method
3. El patrón Prototype
4. El patrón Builder

Builder separa la construcción de un objeto complejo, mediante un proceso paso a paso constante, de su representación final, permitiendo obtener distintos resultados con el mismo proceso de ensamblado. (Gamma et al., "Design Patterns" (1994), sección de patrones creacionales.)

21. Un desarrollador debe elegir entre dos patrones creacionales que ambos delegan la creación de objetos evitando el acoplamiento a clases concretas: en un caso, una subclase decide qué clase concreta instanciar sobrescribiendo un método; en el otro, una interfaz agrupa varios métodos para crear una familia completa de objetos relacionados entre sí. ¿A qué par de patrones corresponde, respectivamente, esta descripción?

1. Factory Method y Abstract Factory
2. Abstract Factory y Factory Method
3. Builder y Factory Method
4. Prototype y Abstract Factory

Factory Method delega en una subclase, mediante sobrescritura de un método, la decisión de qué clase concreta instanciar; Abstract Factory define una interfaz para crear familias completas de objetos relacionados, típicamente combinando varios factory methods. (Gamma et al., "Design Patterns" (1994), sección de patrones creacionales.)

22. Una aplicación nueva necesita reutilizar una biblioteca externa cuya interfaz de métodos no es compatible con la interfaz que el resto del sistema espera, sin modificar el código fuente de esa biblioteca. ¿Qué patrón de diseño GoF permite conectar ambas interfaces?

1. El patrón Facade
2. El patrón Bridge
3. El patrón Adapter
4. El patrón Decorator

Adapter convierte la interfaz de una clase existente en otra interfaz que el cliente espera, permitiendo que clases con interfaces incompatibles colaboren sin modificar el código original. (Gamma et al., "Design Patterns" (1994), sección de patrones estructurales.)

23. Dos patrones estructurales comparten la misma técnica —envolver un objeto dentro de otro que implementa la misma interfaz—, pero con propósitos distintos: uno añade responsabilidades adicionales al objeto envuelto de forma dinámica y transparente, mientras que el otro controla o restringe el acceso al objeto envuelto sin modificar su funcionalidad. ¿A qué patrones corresponde, respectivamente, esta descripción?

1. Proxy y Decorator
2. Decorator y Proxy
3. Decorator y Adapter
4. Bridge y Proxy

Decorator agrega responsabilidades a un objeto de forma dinámica sin alterar su interfaz; Proxy, con la misma técnica de envoltura, controla el acceso al objeto real sin añadirle nuevas funciones. (Gamma et al., "Design Patterns" (1994), sección de patrones estructurales.)

24. Un subsistema de procesamiento de pagos está formado por múltiples clases especializadas (validación, conversión de moneda, autorización y registro contable) que un módulo cliente debe invocar en un orden preciso. Para simplificar su uso, el equipo desea ofrecer un único punto de entrada que oculte esa complejidad interna al módulo cliente. ¿Qué patrón de diseño GoF cubre este requerimiento?

1. El patrón Composite
2. El patrón Mediator
3. El patrón Bridge
4. El patrón Facade

Facade proporciona una interfaz unificada y simplificada a un conjunto de interfaces de un subsistema, ocultando su complejidad interna al código cliente; Mediator, en cambio, coordina la comunicación entre objetos pares y pertenece a los patrones de comportamiento. (Gamma et al., "Design Patterns" (1994), sección de patrones estructurales.)

25. En una aplicación de hojas de cálculo, cuando el valor de una celda cambia, todas las gráficas y celdas que dependen de ese valor deben actualizarse automáticamente, sin que la celda modificada conozca de antemano cuántos ni cuáles elementos dependen de ella. ¿Qué patrón de diseño GoF describe esta relación de notificación entre objetos?

1. El patrón Observer
2. El patrón Mediator
3. El patrón Command
4. El patrón State

Observer define una dependencia de uno a muchos entre objetos, de manera que cuando el objeto observado cambia de estado, todos sus dependientes son notificados y actualizados automáticamente, sin que el sujeto conozca sus detalles concretos. (Gamma, Helm, Johnson y Vlissides, "Design Patterns" (1994), catálogo de 11 patrones de comportamiento.)

26. Un analista redacta el requerimiento: 'El sistema debe permitir registrar un nuevo cliente capturando nombre, correo electrónico y teléfono.' Este requerimiento se clasifica como...

1. un requerimiento funcional
2. un requerimiento de usabilidad
3. un requerimiento de desempeño
4. un requerimiento de dominio

Describe una función concreta que el sistema debe ejecutar, por lo que es un requerimiento funcional; los no funcionales (usabilidad, desempeño) restringen atributos de calidad y los de dominio provienen de reglas del entorno de negocio. (Sommerville, 'Ingeniería de software', clasificación de requerimientos funcionales, no funcionales y de dominio; ISO/IEC/IEEE 29148)

27. De acuerdo con las normas para especificación de requerimientos de software (IEEE 830 / ISO/IEC/IEEE 29148), una especificación de requerimientos (SRS) no ambigua exige que cada requerimiento admita...

1. una interpretación que cambia en las pruebas
2. una interpretación distinta por módulo
3. una sola interpretación posible
4. varias interpretaciones válidas

La no ambigüedad exige que cada requerimiento tenga una interpretación única para todos los lectores; permitir varias interpretaciones, una distinta por módulo o una que cambie durante las pruebas es justo el defecto que esta característica evita. (IEEE Std 830-1998 / ISO/IEC/IEEE 29148:2018, características de una SRS de calidad)

28. Un ingeniero de requerimientos organiza una sesión conjunta con usuarios, clientes y desarrolladores para identificar y priorizar requerimientos en un solo evento facilitado. Esta técnica de elicitación se conoce como...

1. una observación etnográfica
2. una lluvia de ideas individual
3. un prototipo desechable
4. un taller de requerimientos (JAD)

Los talleres de requerimientos (JAD) reúnen a todos los interesados en sesiones facilitadas para elicitar y priorizar rápidamente; la observación y el prototipado son técnicas distintas y la lluvia de ideas individual no implica una sesión conjunta. (Sommerville, 'Ingeniería de software', técnicas de elicitación de requerimientos)

29. En un proyecto ágil, el equipo redacta la historia de usuario: 'Como cliente, quiero recuperar mi contraseña por correo electrónico para poder ingresar de nuevo al sistema.' Para que esta historia pueda desarrollarse y liberarse sin que su implementación dependa de que primero se complete otra historia del backlog, debe cumplir sobre todo con...

1. el criterio de independencia (Independent)
2. el criterio de estimabilidad (Estimable)
3. el criterio de tamaño reducido (Small)
4. el criterio de negociabilidad (Negotiable)

El criterio 'Independent' de INVEST exige que la historia pueda desarrollarse y valorarse sin depender obligatoriamente de otras; 'estimable', 'pequeña' y 'negociable' son criterios distintos del mismo acrónimo. (Bill Wake, criterios INVEST para historias de usuario)

30. Durante una auditoría de un proyecto de software, se requiere comprobar que cada requerimiento aprobado por el cliente esté implementado en al menos un módulo de código y verificado por al menos un caso de prueba. La herramienta de ingeniería de requerimientos que permite esta comprobación es...

1. el prototipo evolutivo del sistema
2. la matriz de trazabilidad de requerimientos
3. la lista de verificación de estilo de código
4. el diagrama de casos de uso del sistema

La matriz de trazabilidad vincula cada requerimiento con los elementos de diseño, código y pruebas que lo satisfacen, permitiendo verificar la cobertura completa; las demás opciones no cumplen esa función de rastreo. (ISO/IEC/IEEE 29148; práctica de gestión de requerimientos (trazabilidad))

31. Al priorizar requerimientos con la técnica MoSCoW, un requerimiento clasificado como 'Should have' (debería tener) se interpreta como un requerimiento...

1. de prioridad todavía indefinida
2. deseable y excluido del alcance
3. importante pero no crítico
4. obligatorio para el sistema

'Should have' designa requerimientos importantes que aportan valor significativo, pero cuya ausencia no impide el funcionamiento básico, a diferencia de 'Must have' (obligatorio) o 'Won't have' (excluido del alcance). (Técnica de priorización MoSCoW (Must/Should/Could/Won't have), Clegg y Barker, 'Case Method Fast-Track')

32. Un cliente redacta el requerimiento: 'El sistema debe ser fácil de usar para cualquier tipo de usuario.' Un revisor de la especificación objeta que este requerimiento incumple la característica de...

1. trazabilidad, por no vincularse a una prueba
2. consistencia, por contradecir otro requerimiento
3. completitud, por falta de un diagrama de flujo
4. verificabilidad, por falta de un criterio medible

Un requerimiento es verificable cuando existe un procedimiento razonable para comprobar su cumplimiento; 'fácil de usar para cualquier usuario' carece de un criterio medible, sin que esto implique necesariamente problemas de completitud, consistencia o trazabilidad. (IEEE Std 830-1998, características de una SRS de calidad (verificabilidad))

33. Durante la revisión de la especificación de requerimientos con el cliente, el equipo confirma que el documento describe realmente lo que el negocio necesita, y no solo que el documento esté bien redactado internamente. Esta actividad corresponde a...

1. la validación de requerimientos
2. la gestión de la configuración
3. el análisis de riesgos del proyecto
4. la verificación de requerimientos

La validación responde a si se está construyendo el producto correcto (satisface las necesidades del usuario); la verificación comprueba la conformidad interna con la especificación, y las otras dos son actividades distintas. (B. W. Boehm (1979/1984); ISO/IEC/IEEE 24765, Vocabulario de ingeniería de sistemas y software)

34. Un equipo construye un prototipo únicamente para que el cliente aclare requerimientos ambiguos de la interfaz, con la intención de desecharlo una vez elicitada la información y comenzar el desarrollo formal desde cero. Este tipo de prototipo se conoce como...

1. prototipo de datos
2. prototipo desechable
3. prototipo operacional
4. prototipo evolutivo

El prototipo desechable se construye solo para explorar o clarificar requerimientos y se descarta, a diferencia del evolutivo, que se refina de manera incremental hasta convertirse en el sistema final. (Sommerville, 'Ingeniería de software', tipos de prototipado de requerimientos)

35. El requerimiento 'el sistema debe responder a cualquier consulta del usuario en menos de dos segundos bajo carga normal' es un requerimiento no funcional de la categoría...

1. un requerimiento de mantenibilidad
2. un requerimiento de portabilidad
3. un requerimiento de eficiencia de desempeño
4. un requerimiento de seguridad

Un límite de tiempo de respuesta bajo carga es un atributo de eficiencia de desempeño, una de las características de calidad de ISO/IEC 25010, distinta de seguridad, portabilidad o mantenibilidad. (ISO/IEC 25010:2011 (SQuaRE), característica 'eficiencia de desempeño')