Ingeniería de software y requerimientos - Momento 2

Test

Jugadas 2

Crear copia

Sobre esta actividad

Este cuestionario consta de 5 preguntas de selección múltiple con única respuesta que te permitirán valorar tu aprendizaje obtenido en el momento 2:

1. UML y modelado de sistemas de software.

2. Casos de uso y análisis de sistemas.

3. Diagramas de comportamiento en UML.

4. Historias de usuario y desarrollo ágil.

5. Técnicas de priorización, prototipado y trazabilidad.

Cada pregunta tiene 4 opciones de respuesta, de las cuales solo una es correcta. Lee cuidadosamente cada pregunta y selecciona la respuesta más adecuada. Al finalizar encontrarás la retroalimentación para cada pregunta.

Creada por

E-learning UCC Actividades de Aprendizaje

Colombia

Descarga la versión para jugar en papel

Top 10 resultados

Todavía no hay resultados para este juego. ¡Sé el primero en aparecer en el ranking! Inicia sesión para identificarte.

Crea tu propio juego gratis desde nuestro creador de juegos

Compite contra tus amigos para ver quien consigue la mejor puntuación en esta actividad

Crear reto

		%
	Anónimo	%
		%
		%

Imprime tu juego

Ingeniería de software y requerimientos - Momento 2


Ingeniería de software y requerimientos - Momento 2Versión en línea Este cuestionario consta de 5 preguntas de selección múltiple con única respuesta que te permitirán valorar tu aprendizaje obtenido en el momento 2: 1. UML y modelado de sistemas de software. 2. Casos de uso y análisis de sistemas. 3. Diagramas de comportamiento en UML. 4. Historias de usuario y desarrollo ágil. 5. Técnicas de priorización, prototipado y trazabilidad. Cada pregunta tiene 4 opciones de respuesta, de las cuales solo una es correcta. Lee cuidadosamente cada pregunta y selecciona la respuesta más adecuada. Al finalizar encontrarás la retroalimentación para cada pregunta. por E-learning UCC Actividades de Aprendizaje 1 ¿Cuál es el propósito principal de un diagrama de casos de uso dentro del proceso de especificación de requerimientos? a Definir la arquitectura técnica y componentes de software del sistema. b Mostrar las interacciones entre actores (usuarios) y el sistema, especificando qué casos de uso son necesarios sin detallar cómo se implementan. c Documentar el código fuente y algoritmos de programación. d Reemplazar completamente la necesidad de escribir requerimientos textuales. 2 En una especificación detallada de un caso de uso, ¿Cuál es la diferencia crítica entre el flujo principal y los flujos alternativos? a El flujo principal es más importante y debe programarse primero. b El flujo principal es la secuencia normal cuando todo funciona correctamente. los flujos alternativos son variaciones o excepciones. Por ejemplo: Qué pasa si falla, qué pasa si el usuario cancela. c Son exactamente lo mismo, solo con nombres diferentes. d Los flujos alternativos son para documentación, el flujo principal es lo que realmente se implementa. 3 ¿Cuál de las siguientes historias de usuario está mejor redactada según los estándares revisados en el momento 2? a Como usuario, quiero que el sistema sea bueno. b Como cliente de e-commerce, quiero buscar productos por nombre, categoría o precio para que encuentre rápidamente lo que necesito. Criterios: puedo escribir en un campo; resultados en <2 seg; puedo filtrar por rango de precio. c El sistema debe tener búsqueda de productos. d Necesitamos implementar búsqueda porque la competencia lo tiene. 4 En la técnica MoSCoW de priorización, ¿cuál es la diferencia clave entre una historia clasificada como must have versus should have? a Must have se implementa primero en tiempo, should have después en tiempo. b Must have: Sin esto el sistema no es viable y no puede lanzarse. Should have: Mejora significativamente la experiencia, pero el sistema sin esto puede funcionar de forma limitada. c Must have es para usuarios; should have es para administradores. d Must have y should have son sinónimos en la práctica. 5 ¿Cuál es el propósito principal de una matriz de trazabilidad bidireccional en la especificación de requerimientos? a Crear un documento bonito para entregar a los stakeholders. b Rastrear cada requerimiento desde su origen (usuario/negocio) hacia componentes de código y pruebas, permitiendo verificar que todo se implementó, nada se olvidó, y cualquier cambio de requerimiento se detecta rápidamente. c Reemplazar la necesidad de escribir especificaciones detalladas. d Solo es útil en proyectos muy grandes; los pequeños no la necesitan. Explicación 1 El diagrama de casos de uso es el primer paso de especificación visual que comunica a todos los stakeholders sobre qué funcionalidades ofrece el sistema desde la perspectiva del usuario. 2 Esta es la distinción esencial: flujo principal = camino feliz; flujos alternativos = casos especiales, errores y variaciones que el sistema debe manejar. 3 Sigue el formato correcto (Como-quiero-para que) con criterios medibles y verificables que definen exactamente cuándo la historia está completa. 4 Must have es mandatorio para viabilidad. Should have es importante pero no crítico. Esta distinción permite tomar decisiones de alcance cuando hay restricciones. 5 La trazabilidad es el seguro del proyecto: Permite gestionar cambios, verificar cobertura completa, entender impacto de modificaciones y mantener control durante todo el ciclo de vida.

Puedes integrar el juego en un LMS compatible con LTI 1.1 o LTI 1.3 como Canvas, Moodle, o Blackboard. De esta manera podrás guardar las puntuaciones automáticamente en el libro de calificaciones de esa plataforma.

Ingeniería de software y requerimientos - Momento 2

Test

Sobre esta actividad

Creada por

Descarga la versión para jugar en papel

Top juegos

Test

Verbos irregulares en Inglés

Test

cuanto sabes de Futbol

Test

Brawl stars preguntas

Test

Tipos de sintagmas (II)

Test

Cultura general española

Ingeniería de software y requerimientos - Momento 2Versión en línea

por E-learning UCC Actividades de Aprendizaje

¿Cuál es el propósito principal de un diagrama de casos de uso dentro del proceso de especificación de requerimientos?

En una especificación detallada de un caso de uso, ¿Cuál es la diferencia crítica entre el flujo principal y los flujos alternativos?

¿Cuál de las siguientes historias de usuario está mejor redactada según los estándares revisados en el momento 2?

En la técnica MoSCoW de priorización, ¿cuál es la diferencia clave entre una historia clasificada como must have versus should have?

¿Cuál es el propósito principal de una matriz de trazabilidad bidireccional en la especificación de requerimientos?

Explicación