🧩 Ingeniería de software

1. ¿Cuál es la característica distintiva del modelo de proceso de cascada (waterfall) en el desarrollo de software?

1. Las fases se ejecutan de manera secuencial y cada una debe concluir antes de iniciar la siguiente
2. El trabajo se organiza en ciclos cortos y de duración fija llamados sprints
3. El sistema se construye mediante versiones incrementales que se entregan al cliente en cada iteración
4. El equipo prioriza la respuesta al cambio por encima de seguir un plan detallado

El modelo de cascada organiza el desarrollo en fases secuenciales (análisis, diseño, codificación, pruebas, mantenimiento) donde cada fase se completa antes de pasar a la siguiente; los sprints son propios de Scrum y las entregas incrementales del modelo iterativo. (Royce, W., 'Managing the Development of Large Software Systems', 1970 (modelo de cascada))

2. En el modelo de desarrollo iterativo e incremental, ¿cómo se construye el sistema final?

1. En una sola secuencia lineal de fases, sin posibilidad de regresar a una fase anterior
2. A partir de un plan de alcance fijo definido por completo antes de iniciar la programación
3. Mediante ciclos repetidos que agregan funcionalidad y producen versiones cada vez más completas del sistema
4. Mediante reuniones diarias de quince minutos donde el equipo reporta su avance

El modelo iterativo-incremental entrega el software en ciclos sucesivos, cada uno añadiendo funcionalidad sobre la versión anterior; la última opción describe el Daily Scrum, propio de un marco ágil distinto. (Pressman, R., 'Ingeniería del Software: Un Enfoque Práctico', 8a ed. (modelos de proceso iterativo))

3. En Scrum, ¿qué rol es responsable de gestionar y priorizar el backlog del producto para maximizar el valor del trabajo del equipo?

1. El Scrum Master
2. El Product Owner
3. El equipo de desarrollo
4. El patrocinador del proyecto (stakeholder)

El Product Owner es responsable único del backlog del producto y de ordenar sus elementos por valor; el Scrum Master facilita el proceso, pero no prioriza el backlog. (Schwaber, K. y Sutherland, J., 'The Scrum Guide', 2020)

4. ¿Cuál es el propósito principal de la retrospectiva de sprint en Scrum?

1. Presentar el incremento terminado a los interesados para recoger su retroalimentación
2. Planificar en detalle las tareas técnicas que se ejecutarán durante el siguiente sprint
3. Reflexionar sobre el proceso y las prácticas de trabajo del equipo para identificar mejoras
4. Revisar el avance diario de cada integrante frente al objetivo del sprint

La retrospectiva se enfoca en inspeccionar cómo trabajó el equipo (personas, relaciones, proceso, herramientas) y planear mejoras; presentar el incremento corresponde a la revisión de sprint (Sprint Review). (Schwaber, K. y Sutherland, J., 'The Scrum Guide', 2020)

5. Una dependencia gubernamental contrata el desarrollo de un sistema cuyos requisitos están completamente definidos desde el inicio, no se prevén cambios durante el proyecto y la normativa exige que la documentación de cada fase sea revisada y aprobada formalmente antes de iniciar la siguiente. ¿Qué modelo de proceso conviene aplicar?

1. Un marco ágil como Scrum, con entregas incrementales cada dos semanas
2. El modelo de cascada, con fases secuenciales y documentación formal por etapa
3. Un modelo de prototipado evolutivo sin documentación previa
4. Un modelo iterativo con ciclos cortos de retroalimentación del cliente

Cuando los requisitos son estables y existe una exigencia normativa de aprobar formalmente cada fase antes de avanzar, el modelo de cascada es el más adecuado, a diferencia de los enfoques ágiles o iterativos pensados para requisitos cambiantes. (Royce, W., 'Managing the Development of Large Software Systems', 1970; Pressman, R., 'Ingeniería del Software')

6. Un equipo debe construir un producto innovador cuyos requisitos no están completamente definidos y es necesario obtener retroalimentación frecuente del cliente para ajustar el rumbo del desarrollo. ¿Qué enfoque de proceso conviene aplicar?

1. Un marco ágil como Scrum, con entregas incrementales y revisión al final de cada sprint
2. El modelo de cascada, documentando la totalidad de los requisitos antes de programar
3. Un modelo de cascada con una única revisión del cliente al finalizar el proyecto
4. Un modelo de proceso sin iteraciones, prototipos ni entregas parciales

Ante requisitos inciertos y necesidad de retroalimentación frecuente, un marco ágil como Scrum permite adaptar el producto en cada sprint; el modelo de cascada fija los requisitos antes de programar, lo que dificulta el cambio. (Schwaber, K. y Sutherland, J., 'The Scrum Guide', 2020)

7. De acuerdo con la Guía Scrum, ¿cuál es la duración máxima recomendada de un sprint, la cual además se mantiene constante durante todo el proyecto?

1. Un mes
2. Seis meses
3. Una semana
4. Un trimestre

La Guía Scrum establece que los sprints duran un mes o menos y su duración se mantiene fija a lo largo del proyecto para conservar un ritmo constante de inspección y adaptación. (Schwaber, K. y Sutherland, J., 'The Scrum Guide', 2020)

8. ¿Cuál de las siguientes actividades NO forma parte de los eventos oficiales definidos en la Guía Scrum?

1. La planeación de sprint (Sprint Planning)
2. La revisión formal de la arquitectura del sistema por un comité externo
3. El Scrum diario (Daily Scrum)
4. La retrospectiva de sprint (Sprint Retrospective)

Los eventos oficiales de Scrum son el Sprint, la Planeación de Sprint, el Scrum Diario, la Revisión de Sprint y la Retrospectiva; una revisión formal de arquitectura por un comité externo corresponde a modelos de proceso más tradicionales, no a Scrum. (Schwaber, K. y Sutherland, J., 'The Scrum Guide', 2020)

9. Un equipo Scrum completó 32 puntos de historia durante un sprint de dos semanas. Si el equipo planea el siguiente sprint con una duración de tres semanas y mantiene la misma velocidad semanal, ¿cuántos puntos de historia debería comprometer aproximadamente?

1. 32 puntos
2. 64 puntos
3. 16 puntos
4. 48 puntos

La velocidad semanal es 32/2 = 16 puntos por semana; para un sprint de tres semanas, el equipo debería comprometer alrededor de 16×3 = 48 puntos. Mantener 32 ignora el cambio de duración, y 16 corresponde solo a una semana. (Cohn, M., 'Agile Estimating and Planning', Prentice Hall, 2005 (velocidad de equipo))

10. El libro de la 'Banda de los Cuatro' (Gamma, Helm, Johnson y Vlissides) clasifica los patrones de diseño de software en tres categorías. ¿Cuáles son?

1. Estructurales, funcionales y de concurrencia
2. Creacionales, funcionales y arquitectónicos
3. De comportamiento, de persistencia y de interfaz
4. Creacionales, estructurales y de comportamiento

El catálogo GoF de 1994 organiza sus 23 patrones en creacionales (creación de objetos), estructurales (composición de clases y objetos) y de comportamiento (comunicación entre objetos). (Gamma, Helm, Johnson y Vlissides, 'Design Patterns' (GoF), 1994)

11. Un sistema requiere que exista una única instancia de la clase que administra la conexión a la base de datos, con un punto de acceso global disponible desde cualquier módulo del programa. ¿Qué patrón de diseño es el más adecuado para este caso?

1. Factory Method
2. Composite
3. Singleton
4. Observer

El patrón Singleton garantiza que una clase tenga una sola instancia y ofrece un punto de acceso global a ella, justo lo que requiere una única conexión compartida a la base de datos. (Gamma et al., 'Design Patterns' (GoF), 1994)

12. Una clase base necesita crear objetos durante su ejecución, pero no puede anticipar de qué clase concreta serán esas instancias, dejando esa decisión a las subclases que la extienden. ¿Qué patrón de diseño se aplica en este caso?

1. Factory Method
2. Singleton
3. Decorator
4. Adapter

El Factory Method define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase concreta instanciar, resolviendo exactamente ese escenario. (Gamma et al., 'Design Patterns' (GoF), 1994)

13. ¿Qué patrón de diseño define una dependencia uno a muchos entre objetos, de manera que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados automáticamente?

1. Strategy
2. Observer
3. Facade
4. Adapter

El patrón Observer define esa dependencia uno-a-muchos para notificación automática de cambios de estado; Strategy, en cambio, encapsula algoritmos intercambiables. (Gamma et al., 'Design Patterns' (GoF), 1994)

14. Una aplicación de rutas debe permitir intercambiar en tiempo de ejecución el algoritmo de cálculo utilizado (ruta más corta, más rápida o sin peajes) sin modificar el código del cliente que lo invoca. ¿Qué patrón de diseño conviene aplicar?

1. Observer
2. Facade
3. Strategy
4. Adapter

Strategy encapsula una familia de algoritmos intercambiables y permite variar el algoritmo usado independientemente del cliente, lo que resuelve el escenario descrito. (Gamma et al., 'Design Patterns' (GoF), 1994)

15. ¿Qué patrón de diseño permite que colaboren clases con interfaces incompatibles, convirtiendo la interfaz de una clase en otra que el cliente espera recibir?

1. Facade
2. Composite
3. Decorator
4. Adapter

El Adapter convierte la interfaz de una clase en otra interfaz esperada por el cliente, permitiendo la colaboración entre clases incompatibles; Facade, en cambio, simplifica el acceso a un subsistema completo. (Gamma et al., 'Design Patterns' (GoF), 1994)

16. ¿Qué tipo de diagrama UML representa la vista estática de un sistema mediante clases, sus atributos, operaciones y las relaciones entre ellas?

1. Diagrama de secuencia
2. Diagrama de clases
3. Diagrama de casos de uso
4. Diagrama de actividades

El diagrama de clases es un diagrama estructural que muestra la vista estática del sistema: clases, atributos, operaciones y relaciones como asociación o generalización. (OMG Unified Modeling Language (UML), versión 2.5.1, 2017)

17. Un analista necesita representar el orden cronológico exacto de los mensajes que intercambian un objeto Cliente, un objeto ControladorDePedido y un objeto BaseDeDatos durante el proceso de una compra. ¿Qué diagrama UML debe utilizar?

1. Diagrama de casos de uso
2. Diagrama de componentes
3. Diagrama de clases
4. Diagrama de secuencia

El diagrama de secuencia es un diagrama de interacción que muestra los mensajes entre objetos ordenados en el tiempo a lo largo de líneas de vida, justo lo que requiere el analista. (OMG Unified Modeling Language (UML), versión 2.5.1, 2017)

18. En un diagrama de clases se modela que una habitación no puede existir sin la casa a la que pertenece, de forma que al eliminar la casa se eliminan también todas sus habitaciones. ¿Qué relación UML representa mejor esta situación?

1. Generalización
2. Agregación (rombo hueco)
3. Dependencia
4. Composición (rombo relleno)

La composición representa una relación todo-parte fuerte en la que la parte comparte el ciclo de vida del todo y no puede existir sin él; la agregación, en cambio, permite que la parte exista de forma independiente. (OMG Unified Modeling Language (UML), versión 2.5.1, 2017)

19. ¿Cuál de los siguientes principios NO forma parte de los cinco principios SOLID de diseño orientado a objetos?

1. Principio de sustitución de Liskov
2. Principio de ocultamiento de datos (information hiding)
3. Principio de responsabilidad única
4. Principio de inversión de dependencias

Los cinco principios SOLID son Responsabilidad Única, Abierto/Cerrado, Sustitución de Liskov, Segregación de Interfaces e Inversión de Dependencias; el ocultamiento de datos es un principio clásico de diseño (Parnas), pero no forma parte del acrónimo SOLID. (Robert C. Martin, 'Agile Software Development: Principles, Patterns, and Practices', 2002)

20. ¿Qué mide la métrica de complejidad ciclomática de McCabe en un programa?

1. El número de líneas de código fuente del programa
2. El porcentaje de código cubierto por las pruebas unitarias
3. El número de caminos linealmente independientes en el flujo de control del programa
4. El tiempo promedio que tarda un desarrollador en corregir un defecto

La complejidad ciclomática, propuesta por McCabe, cuenta los caminos linealmente independientes en el grafo de flujo de control de un programa, y se usa como indicador de su dificultad de prueba y mantenimiento. (McCabe, T.J., 'A Complexity Measure', IEEE Transactions on Software Engineering, 1976)

21. El grafo de flujo de control de un módulo tiene 10 nodos (N), 13 aristas (E) y un solo componente conexo (P=1). Usando la fórmula de McCabe V(G) = E − N + 2P, ¿cuál es su complejidad ciclomática?

1. 3
2. 5
3. 7
4. 4

V(G) = 13 − 10 + 2(1) = 5. El resultado 3 surge de omitir el término +2P, y 4 de usar +P en vez de +2P. (McCabe, T.J., 'A Complexity Measure', IEEE Transactions on Software Engineering, 1976)

22. La técnica de puntos de función se utiliza principalmente para...

1. contar el número de clases y métodos definidos en el diseño orientado a objetos
2. medir el tiempo de respuesta promedio de las transacciones del sistema
3. estimar el tamaño funcional del software a partir de sus funciones vistas por el usuario, independientemente del lenguaje de programación
4. medir el número de líneas de código fuente escritas por el equipo de desarrollo

Los puntos de función miden el tamaño funcional del software con base en entradas, salidas, consultas y archivos vistos por el usuario, sin depender del lenguaje de programación usado, a diferencia de métricas como las líneas de código. (Albrecht, A.J., 'Measuring Application Development Productivity', IBM, 1979)

23. Durante las pruebas de un módulo de 2,000 líneas de código se detectaron 8 defectos. ¿Cuál es la densidad de defectos del módulo, expresada en defectos por cada mil líneas de código (KLOC)?

1. 8 defectos por KLOC
2. 0.4 defectos por KLOC
3. 4 defectos por KLOC
4. 16 defectos por KLOC

La densidad de defectos se calcula dividiendo el número de defectos entre el tamaño en KLOC: 8 ÷ 2 = 4 defectos por KLOC. La primera opción es solo el conteo de defectos sin dividir entre el tamaño. (Pressman, R., 'Ingeniería del Software: Un Enfoque Práctico' (métricas de calidad))

24. ¿Cuál es la relación deseable entre la cohesión y el acoplamiento en un buen diseño de software?

1. Baja cohesión dentro de los módulos y alto acoplamiento entre ellos
2. Alta cohesión dentro de los módulos y bajo acoplamiento entre ellos
3. Bajo acoplamiento dentro de los módulos y alta cohesión entre ellos
4. Alta cohesión y alto acoplamiento simultáneamente en todos los módulos

Un buen diseño busca alta cohesión (elementos de un módulo fuertemente relacionados entre sí) y bajo acoplamiento (poca dependencia entre módulos distintos), lo que facilita el mantenimiento y las pruebas. (Pressman, R., 'Ingeniería del Software: Un Enfoque Práctico' (cohesión y acoplamiento))

25. Un gerente de proyecto desea estimar el esfuerzo de desarrollo, en persona-mes, a partir del tamaño estimado del software en miles de líneas de código y de un conjunto de factores de costo relacionados con el producto, el equipo y el proyecto. ¿Qué modelo de estimación está utilizando?

1. Complejidad ciclomática de McCabe
2. Análisis de puntos de función
3. Modelo COCOMO
4. Métricas de Halstead

COCOMO (Constructive Cost Model) estima el esfuerzo de desarrollo en persona-mes a partir del tamaño del software en miles de líneas de código (KLOC) y de multiplicadores de costo del producto, el equipo y el proyecto. (Boehm, B., 'Software Engineering Economics' (modelo COCOMO), 1981)

26. En las pruebas de software, ¿qué mide la métrica de cobertura de código (code coverage)?

1. El número de defectos encontrados por cada caso de prueba ejecutado
2. El porcentaje de líneas, ramas o caminos del código que fueron ejercitados por los casos de prueba
3. El número de módulos que cumplen con los estándares de codificación establecidos
4. El tiempo total invertido en la ejecución de las pruebas del sistema

La cobertura de código mide qué proporción del código fuente (líneas, ramas o caminos) fue ejecutada durante las pruebas, lo cual ayuda a identificar partes del sistema que quedaron sin probar. (Pressman, R., 'Ingeniería del Software: Un Enfoque Práctico' (métricas de prueba))

27. Un requerimiento establece que el sistema debe permitir que un usuario recupere su contraseña mediante un correo de verificación, es decir, describe una función concreta que el sistema debe realizar. Este tipo de requerimiento se clasifica como:

1. Requerimiento no funcional
2. Requerimiento de dominio
3. Requerimiento funcional
4. Requerimiento de usuario

Los requerimientos funcionales describen servicios o funciones específicas que el sistema debe realizar; la recuperación de contraseña es una función del sistema, no una restricción de calidad como los no funcionales. (Ingeniería de requerimientos — clasificación funcional/no funcional (Sommerville, 'Software Engineering'))

28. Un analista documenta el siguiente requerimiento para un sistema de reservaciones en línea: 'El sistema debe soportar 500 usuarios conectados de manera simultánea sin que el tiempo de respuesta de una consulta supere los tres segundos.' Este requerimiento pertenece a la categoría de requerimientos:

1. Funcionales, de negocio
2. No funcionales, de desempeño
3. Funcionales, de dominio
4. No funcionales, de usabilidad

Especificar capacidad de carga y tiempo de respuesta es una restricción de calidad sobre el sistema (desempeño), no una función que el sistema ejecuta ni un atributo de facilidad de uso. (Requerimientos no funcionales, categoría de desempeño (Sommerville, 'Software Engineering'; ISO/IEC 25010))

29. Un equipo de desarrollo organiza una reunión con los usuarios finales para confirmar que el documento de especificación de requerimientos describe correctamente lo que el cliente necesita, antes de iniciar el diseño del sistema. Esta actividad corresponde a:

1. Verificación de requerimientos
2. Gestión de cambios
3. Validación de requerimientos
4. Trazabilidad de requerimientos

La validación confirma que los requerimientos documentados reflejan lo que el cliente realmente necesita, mientras que la verificación comprueba que el sistema construido cumple la especificación ya escrita. (Validación de requerimientos (Sommerville, 'Software Engineering'; ISO/IEC/IEEE 29148))

30. De acuerdo con el estándar clásico de especificación de requerimientos de software IEEE 830, una característica deseable de un documento de especificación es que ningún requerimiento contradiga a otro dentro del mismo documento. A esta característica se le denomina:

1. Trazabilidad
2. Verificabilidad
3. Modificabilidad
4. Consistencia

La consistencia exige que ningún requerimiento entre en conflicto con otro; la trazabilidad se refiere a poder rastrear el origen y uso de cada requerimiento, no a la ausencia de contradicciones. (IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications)

31. Todas las siguientes son características deseables de una especificación de requerimientos de software según IEEE 830, EXCEPTO:

1. Que sea completa
2. Que sea ambigua para permitir flexibilidad en el diseño
3. Que sea verificable
4. Que sea consistente

IEEE 830 exige que la especificación sea NO ambigua, con una sola interpretación posible por requerimiento; la ambigüedad deliberada contradice la norma, mientras que completitud, verificabilidad y consistencia sí son atributos exigidos. (IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications)

32. En un sistema de comercio electrónico, tanto el caso de uso 'Pagar con tarjeta' como el caso de uso 'Pagar con transferencia' requieren obligatoriamente ejecutar el comportamiento 'Verificar identidad del cliente' como parte de su flujo normal. La relación que debe modelarse entre cada caso de uso de pago y 'Verificar identidad del cliente' en el diagrama de casos de uso es:

1. Extiende (extend)
2. Generalización
3. Incluye (include)
4. Asociación de comunicación

La relación 'incluye' modela un comportamiento obligatorio y común que un caso de uso base siempre ejecuta; 'extiende' se reserva para comportamiento opcional o condicional, no para pasos obligatorios. (Diagrama de casos de uso, relaciones include/extend (OMG Unified Modeling Language, versión 2.5.1, 2017))

33. Un equipo aplica la técnica MoSCoW para priorizar requerimientos de un producto mínimo viable con fecha de entrega fija. El cliente acepta posponer un requerimiento para una versión posterior, aunque reconoce que sería deseable incluirlo si el tiempo y los recursos lo permiten. Este requerimiento debe clasificarse como:

1. Must have (debe tener)
2. Won't have (no tendrá esta vez)
3. Should have (debería tener)
4. Could have (podría tener)

'Could have' agrupa requerimientos deseables pero no críticos que se incluyen solo si el tiempo y los recursos alcanzan; 'Should have' implica mayor importancia y 'Won't have' implica exclusión explícita, no una posibilidad condicionada. (Técnica de priorización MoSCoW (Clegg y Barker, DSDM Consortium))

34. El libro 'Design Patterns: Elements of Reusable Object-Oriented Software', escrito por la llamada 'Banda de los Cuatro' (GoF), clasifica los patrones de diseño en tres categorías según su propósito. Dichas categorías son:

1. Arquitectónicos, estructurales y funcionales
2. Creacionales, estructurales y de comportamiento
3. Creacionales, de comportamiento y concurrentes
4. Estructurales, de comportamiento y de integración

El catálogo GoF de 1994 organiza sus patrones en tres categorías: creacionales (creación de objetos), estructurales (composición de clases y objetos) y de comportamiento (interacción y reparto de responsabilidades). (Gamma, Helm, Johnson y Vlissides, 'Design Patterns' (GoF), 1994)

35. El catálogo original de la 'Banda de los Cuatro' (GoF), publicado en 1994, documenta un total de:

1. 22 patrones de diseño
2. 23 patrones de diseño
3. 24 patrones de diseño
4. 15 patrones de diseño

El catálogo GoF describe exactamente 23 patrones repartidos en las tres categorías clásicas; los demás valores son conteos cercanos pero incorrectos frecuentes entre estudiantes. (Gamma, Helm, Johnson y Vlissides, 'Design Patterns' (GoF), 1994)