Ingeniería de software y requerimientos - Momento 2

Test

Parties jouées 2

Créer une copie

À propos de cette activité

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.

Créé par

E-learning UCC Actividades de Aprendizaje

Colombia

Téléchargez la version pour jouer sur papier

Top 10 résultats

Il n'y a toujours pas de résultats pour ce jeu. Soyez le premier à apparaître dans le classement! Connectez-vous pour vous identifier.

Créez votre propre jeu gratuite à partir de notre créateur de jeu

Affrontez vos amis pour voir qui obtient le meilleur score dans ce jeu

Créer un défi

		%
	Anonyme	%
		%
		%

Imprimez votre jeu

Ingeniería de software y requerimientos - Momento 2


Ingeniería de software y requerimientos - Momento 2Version en ligne 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. par 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.

Vous pouvez intégrer le jeu dans un LMS compatible avec LTI 1.1 ou LTI 1.3 comme Canvas, Moodle ou Blackboard. Les scores seront ainsi automatiquement enregistrés dans le carnet de notes de la plateforme.

Ingeniería de software y requerimientos - Momento 2

Test

À propos de cette activité

Créé par

Téléchargez la version pour jouer sur papier

Top Jeux

Test

Tissues - Practice Quiz

Test

Photosynthesis vs Cellular Respiration - Practice Quiz

Test

UPS 5 Seeing Habits Quiz

Test

Practice Quiz - Punnett Square, Variation, and Mutations

Test

Spanish Alphabet Listening

Ingeniería de software y requerimientos - Momento 2Version en ligne

par 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