Tipo Test ADAP

¿Cuál fue una de las principales causas de la crisis del software de 1968?. Falta de lenguajes de programación. Proyectos fuera de presupuesto y con retrasos. Exceso de documentación. Uso de hardware obsoleto.

¿Por qué se dice que el software no se “rompe” físicamente?. Porque no tiene errores. Porque no se usa. Porque su deterioro se debe a cambios continuos. Porque no necesita mantenimiento.

¿Qué porcentaje aproximado del coste total puede suponer el mantenimiento del software?. 20%. 40%. 60%. 80%.

¿Cuál es una ventaja clave de la reutilización de componentes?. Aumenta el acoplamiento. Reduce costes y errores. Elimina la necesidad de pruebas. Evita la documentación.

El software completo está formado por: Código y hardware. Código y pruebas. Código, contexto y conocimiento. Código y usuarios.

¿Qué define el ciclo de vida del software?. Solo la fase de desarrollo. Desde la concepción hasta el retiro. Únicamente el mantenimiento. Solo la fase de pruebas.

El principio KISS significa: Keep It Safe and Secure. Keep It Simple, Stupid. Know It, Solve It. Keep It Structured and Simple.

¿Qué principio indica que no se deben programar funcionalidades innecesarias?. SRP. KISS. YAGNI. DRY.

La ingeniería del software se apoya en: Código, pruebas y usuarios. Hardware, software y redes. Herramientas, métodos y proceso. Análisis, diseño y pruebas.

¿Cuál NO es una fase del proceso de software?. Requisitos. Diseño. Marketing. Mantenimiento.

El modelo en cascada es más adecuado para: Proyectos con requisitos cambiantes. Proyectos simples y bien definidos. Sistemas críticos. Proyectos ágiles.

¿Qué modelo se basa en el análisis de riesgos?. Incremental. Cascada. Espiral. RAD.

El desarrollo incremental se caracteriza por. Una única entrega final. Entregas funcionales por fases. No usar prototipos. Evitar la interacción con el cliente.

Scrum se basa en el empirismo, que incluye: Planificación, control y cierre. Transparencia, inspección y adaptación. Análisis, diseño y pruebas. Velocidad, coste y calidad.

¿Cuál es la duración típica de un Sprint?. 1 día. 1–4 semanas. 3 meses. Indefinida.

¿Qué evento de Scrum se realiza diariamente?. Sprint Review. Sprint Planning. Daily Scrum. Retrospective.

¿Quién prioriza el Product Backlog?. Scrum Master. Developers. Product Owner. Stakeholders.

El resultado de cada Sprint es: Documentación. Un prototipo. Un incremento potencialmente entregable. Un informe de métricas.

¿Qué compromiso está asociado al Sprint Backlog?. Product Goal. Definition of Done. Sprint Goal. Roadmap.

El Scrum Master actúa como: Jefe del equipo. Líder servicial y facilitador. Responsable técnico. Cliente.

La validación responde a la pregunta: ¿Está bien documentado?. ¿Producto correcto?. ¿Código eficiente?. ¿Se terminó a tiempo?.

¿Cuál es el objetivo principal de la gestión de configuración?. Reducir costes. Controlar versiones y trazabilidad. Mejorar la interfaz. Eliminar errores.

¿Qué tipo de documentación está orientada al usuario final?. Técnica. Funcional. De usuario. De mantenimiento.

Un requisito funcional define: Rendimiento del sistema. Seguridad. Qué hace el sistema. Restricciones técnicas.

Un requisito no funcional se centra en: Casos de uso. Funciones del sistema. Atributos de calidad. Historias de usuario.

UML es: Una metodología ágil. Un lenguaje de programación. Un lenguaje de modelado. Un framework.

¿Qué vista UML muestra la arquitectura estática?. Interacción. Comportamiento. Estructural. Escenarios.

Un actor en un caso de uso representa: Una persona concreta. Un rol que interactúa con el sistema. Un módulo interno. Una clase.

La relación «include» indica: Ejecución opcional. Herencia. Inclusión obligatoria. Dependencia débil.

La relación «extends» indica: Ejecución siempre obligatoria. Comportamiento opcional. Composición. Agregación.

¿Qué diagrama UML modela clases y relaciones?. Casos de uso. Secuencia. Clases. Actividades.

La composición implica que: Las partes existen independientemente. Las partes mueren con el todo. No hay relación fuerte. Es una dependencia débil.

Una interfaz UML: Puede instanciarse. Contiene solo atributos. Define operaciones sin implementación. Es una tabla de base de datos.

El modelo 4+1 de Kruchten incluye la vista. Económica. Lógica. Legal. Comercial.

¿Qué atributo de calidad mide el tiempo de respuesta?. Seguridad. Disponibilidad. Rendimiento. Usabilidad.

¿Qué patrón arquitectónico divide en presentación, negocio y datos?. Microservicios. Capas. Cliente-servidor. Eventos.

ATAM es un método para evaluar. Costes. Requisitos funcionales. Arquitectura. Código.

Un diagrama de secuencia muestra. Estados. Clases. Mensajes en el tiempo. Componentes físicos.

Un mensaje asíncrono: Espera respuesta. Bloquea la ejecución. No espera respuesta. Es siempre de retorno.

Los diagramas de colaboración destacan: El tiempo. La estructura de interacción. El flujo de actividades. El ciclo de vida.

Los diagramas de estados son útiles para. Modelar bases de datos. Representar flujos paralelos. Describir ciclos de vida. Diseñar interfaces gráficas.

¿Qué elemento indica una condición para una transición?. Evento. Guardia. Acción. Estado final.

Los diagramas de actividades permiten: Modelar concurrencia. Definir clases. Diseñar BD. Reemplazar código.

Una swimlane indica: Estado. Actor o responsable. Transición. Evento.

La interfaz de sistema define: Colores y tipografías. Contratos de comunicación. Experiencia de usuario. Prototipos visuales.

REST suele usar: XML y SMTP. JSON y HTTP. SOAP. FTP.

La usabilidad se diferencia de la UX porque: Es subjetiva. No se puede medir. Es objetiva. No depende del usuario.

Un affordance es: Un error de diseño. Una restricción técnica. Una pista visual de uso. Un requisito funcional.

DCU significa: Diseño Centrado en el Usuario. Desarrollo Continuo Unificado. Diseño de Casos de Uso. Desarrollo con UML.

Un wireframe es: Código funcional. Diagrama de clases. Prototipo visual. Caso de prueba.

WCAG se relaciona con: Rendimiento. Seguridad. Accesibilidad. Arquitectura.

El patrón Singleton garantiza: Múltiples instancias. Una única instancia. Bajo acoplamiento. Alta cohesión.

Factory Method delega: El diseño. La creación de objetos. El comportamiento. La validación.

Abstract Factory crea: Objetos simples. Algoritmos. Familias de objetos. Interfaces gráficas.

El patrón Builder evita: Interfaces. Constructores gigantes. Herencia. Polimorfismo.

Adapter se utiliza para: Añadir funcionalidad. Traducir interfaces incompatibles. Controlar acceso. Clonar objetos.

Decorator permite. Heredar múltiples clases. Añadir comportamiento dinámicamente. Eliminar responsabilidades. Crear objetos únicos.

Facade proporciona: Acceso directo al código. Interfaz compleja. Interfaz simplificada. Bajo rendimiento.

Proxy controla: Algoritmos. Estados. Acceso a un objeto. Herencia.

Bridge separa. Cliente y servidor. Abstracción e implementación. Datos y lógica. Clases y objetos.

Observer define una relación: 1:1. 1:N. N:N. N:1.

Strategy evita: Interfaces. Herencia. Condicionales repetidos. Polimorfismo.

Command encapsula: Datos. Una petición. Un estado. Un algoritmo base.

State permite. Cambiar de clase. Cambiar comportamiento según estado. Eliminar estados. Crear objetos.

Template Method define: Un algoritmo completo. El esqueleto de un algoritmo. Un patrón estructural. Una interfaz.

Mediator reduce: Cohesión. Rendimiento. Acoplamiento. Funcionalidad.

Iterator permite: Modificar colecciones. Acceso secuencial sin exponer estructura. Eliminar datos. Clonar objetos.

Refactorizar significa: Añadir nuevas funciones. Corregir errores. Mejorar estructura interna. Reescribir el sistema.

Un code smell indica: Un error seguro. Un problema de compilación. Un posible problema de diseño. Código correcto.

Una clase demasiado grande es un: Coupler. Bloater. Dispensable. Mediator.

Extract Method sirve para: Eliminar clases. Reducir complejidad. Añadir parámetros. Aumentar acoplamiento.

Replace Magic Number with Constant mejora: Rendimiento. Seguridad. Legibilidad. Escalabilidad.

Feature Envy indica: Bajo acoplamiento. Exceso de herencia. Dependencia excesiva de otra clase. Código muerto.

Las ternas de Hoare se expresan como: (A, B, C). [P] C [Q]. {P} C {Q}. <P, Q, C>.

La corrección parcial garantiza: Que el programa termine. Que siempre funcione. Que si termina, el resultado es correcto. Que no haya errores.

La corrección total añade: Optimización. Terminación garantizada. Seguridad. Modularidad.

El invariante de bucle debe cumplirse: Solo al inicio. Solo al final. Antes, durante y después. Solo durante.

Los algoritmos recursivos se verifican mediante: Simulación. Pruebas empíricas. Inducción. Debugging.

El objetivo principal de las pruebas es: Demostrar que funciona. Encontrar errores. Documentar código. Optimizar rendimiento.

Las pruebas de caja blanca se centran en: Requisitos. Interfaz. Lógica interna. Experiencia de usuario.

Las pruebas de caja negra se basan en: Código. Requisitos. Diagramas UML. Arquitectura.

La depuración por fuerza bruta es: Muy eficiente. Formal. Poco eficiente. Automática.

El backtracking consiste en: Probar todas las entradas. Avanzar línea a línea. Retroceder desde el error. Reescribir código.

La inducción en depuración parte de: Teoría general. Datos particulares. Código completo. Requisitos.

La deducción elimina: Hipótesis. Casos de prueba. Requisitos. Métricas.

Un stakeholder primario es: El desarrollador. El usuario final. El Scrum Master. El proveedor.

El Product Goal es: Objetivo del Sprint. Meta a largo plazo del producto. Tarea del día. Backlog técnico.

Definition of Done indica: Prioridades. Criterios de finalización. Historias de usuario. Riesgos.

Un incremento debe ser. Documentado. Probado. Potencialmente entregable. Opcional.

El Sprint Review sirve para: Planificar el sprint. Mostrar el incremento. Corregir errores. Asignar tareas.

El Sprint Retrospective se centra en: El producto. El proceso y mejora del equipo. El cliente. El backlog.

Scrum recomienda equipos: Jerárquicos. Autoorganizados. Centralizados. Individuales.

La métrica “velocidad” mide: Errores. Líneas de código. Trabajo completado por sprint. Tiempo de respuesta.

La gestión de riesgos busca: Eliminar pruebas. Reaccionar ante crisis. Anticipar problemas. Reducir documentación.

Un requisito verificable significa: Fácil de entender. Medible y comprobable. Opcional. Flexible.

Un caso de uso describe: Estructura interna. Comportamiento del sistema. Base de datos. Arquitectura física.

Los microservicios destacan por: Baja escalabilidad. Simplicidad operativa. Independencia de servicios. Bajo coste inicial.

El patrón Pipe-and-Filter favorece: Acoplamiento. Reutilización. Seguridad. Herencia.

Un error común de arquitectura es: Documentar. Ignorar atributos de calidad. Usar patrones. Planificar.

El objetivo final del diseño de software es: Escribir código rápido. Reducir documentación. Crear sistemas mantenibles y de calidad. Evitar pruebas.