EVALUACIÓN INGENIERIA DE REQUISITOS DE SOFTWARE. Ing. Luis Armando Amaya QVersion en ligne
Evaluación tipo ICFES sobre ingeniería de Requisitos de Software. Elaboró Ing. Luis Armando Amaya Q. Seleccionar una (1) única opción de respuesta. No usar dispositivo celular o PC.
1
Durante la fase de elicitación de requisitos, es crucial seleccionar las técnicas adecuadas para obtener información precisa de los stakeholders. ¿Cuál de las siguientes técnicas es más efectiva para obtener requisitos detallados de los usuarios finales?
a
Observación pasiva sin interacción directa con los usuarios.
b
Uso de cuestionarios con preguntas cerradas
c
Entrevistas estructuradas que permitan profundizar en las necesidades específicas de los usuarios
d
Revisión de documentación técnica sin consultar a los usuarios
2
El análisis de requisitos implica la evaluación y refinamiento de los requisitos obtenidos durante la elicitación. ¿Qué técnica es fundamental para identificar inconsistencias y ambigüedades en los requisitos?
a
Recolección de datos sin análisis posterior.
b
Modelado de casos de uso para visualizar las interacciones del sistema.
c
Implementación directa de los requisitos sin revisión.
d
Documentación de requisitos sin validación
3
La validación de requisitos asegura que los requisitos definidos cumplen con las necesidades y expectativas de los stakeholders. ¿Cuál es una técnica efectiva para validar los requisitos con los stakeholders?
a
Implementación del sistema sin retroalimentación de los usuarios
b
Revisión de requisitos sin participación de los stakeholders.
c
Documentación de requisitos sin pruebas
d
Prototipos que permitan a los usuarios interactuar con una versión preliminar del sistema
4
La priorización de requisitos ayuda a determinar cuáles requisitos deben ser implementados primero. ¿Qué técnica es útil para priorizar los requisitos de un proyecto?
a
Análisis de valor para identificar los requisitos más críticos.
b
Implementación de requisitos sin priorización
c
Recolección de requisitos sin análisis de importancia.
d
Documentación de requisitos sin orden de prioridad
5
La elicitación de requisitos es el proceso de obtener información de los stakeholders sobre sus necesidades y expectativas. ¿Cuál de las siguientes técnicas es más adecuada para obtener requisitos de un grupo grande de usuarios?
a
Entrevistas individuales con cada usuario.
b
Talleres de trabajo que involucren a múltiples stakeholders.
c
Observación pasiva sin interacción directa.
d
Revisión de documentación técnica sin consultar a los usuarios
6
En la fase de elicitación de requisitos, es crucial identificar correctamente los actores que interactuarán con el sistema. ¿Cuál es el propósito principal de identificar actores en los casos de uso?
a
Definir los requisitos técnicos del sistema.
b
) Establecer el presupuesto del proyecto
c
Determinar quiénes interactuarán con el sistema y qué funciones realizarán
d
Crear el diseño gráfico del sistema
7
Los casos de uso describen cómo los actores interactúan con el sistema para lograr un objetivo específico. ¿Qué elemento es esencial en la descripción o documentación de un caso de uso?
a
El diseño de la interfaz de usuario.
b
Los pasos detallados que los actores deben seguir para completar una tarea
c
La estructura de la base de datos
d
El presupuesto del proyecto
8
Los casos de uso deben incluir escenarios alternativos para cubrir diferentes situaciones que pueden ocurrir durante la interacción con el sistema. ¿Qué representan los escenarios alternativos en un caso de uso?
a
Los requisitos técnicos del sistema.
b
El diseño gráfico del sistema.
c
Variaciones en el flujo principal de eventos que pueden ocurrir bajo ciertas condiciones
d
El presupuesto del proyecto
9
Los diagramas de casos de uso son herramientas visuales que ayudan a representar las interacciones entre los actores y el sistema. 4. ¿Cuál es la función principal de un diagrama de casos de uso?
a
Definir los requisitos técnicos del sistema
b
Establecer el presupuesto del proyecto
c
Crear el diseño gráfico del sistema
d
Visualizar las interacciones entre los actores y el sistema.
10
Los requisitos funcionales describen las funciones que el sistema debe realizar y se pueden representar mediante casos de uso. ¿Cómo se relacionan los requisitos funcionales con los casos de uso?
a
Los casos de uso definen el diseño gráfico del sistema.
b
Los casos de uso detallan cómo se implementarán los requisitos funcionales
c
Los casos de uso establecen el presupuesto del proyecto.
d
Los casos de uso describen la estructura de la base de datos
11
La validación de casos de uso asegura que los requisitos definidos cumplen con las necesidades y expectativas de los stakeholders. ¿Cuál es una técnica efectiva para validar los casos de uso con los stakeholders?
a
Implementación del sistema sin retroalimentación de los usuarios
b
Revisión de casos de uso sin participación de los stakeholders
c
Documentación de casos de uso sin pruebas
d
Prototipos que permitan a los usuarios interactuar con una versión preliminar del sistema
12
Las historias de usuario son una herramienta utilizada para capturar los requisitos desde la perspectiva del usuario. ¿Qué elemento es esencial en una historia de usuario?
a
El diseño gráfico del sistema
b
Una descripción clara del objetivo que el usuario quiere alcanzar
c
La estructura de la base de datos.
d
El presupuesto del proyecto
13
Las historias de usuario suelen seguir un formato específico para asegurar que los requisitos sean claros y comprensibles. ¿Cuál es el formato comúnmente utilizado para escribir historias de usuario?
a
Como [desarrollador], quiero [acción] para [beneficio].
b
Como [administrador], quiero [acción] para [beneficio].
c
Como [cliente], quiero [acción] para [beneficio].
d
Como [usuario], quiero [acción] para [beneficio].
14
El análisis de historias de usuario implica la evaluación y refinamiento de las historias de usuario obtenidas durante la elicitación. ¿Qué técnica es fundamental para identificar inconsistencias y ambigüedades en las historias de usuario?
a
Recolección de datos sin análisis posterior.
b
Implementación directa de las historias de usuario sin revisión
c
Modelado de casos de uso para visualizar las interacciones del sistema.
d
Documentación de historias de usuario sin validación
15
¿Qué método puede ayudar a identificar requisitos no funcionales durante la validación?
a
Entrevistas con los stakeholders
b
Pruebas de rendimiento del sistema
c
Revisión de la documentación técnica
d
Implementación de un sistema piloto
16
¿Qué técnica puede ser utilizada para validar requisitos de usabilidad?
a
Implementación sin retroalimentación
b
Revisión de código
c
Documentación
d
Pruebas de usuario
17
En una empresa de desarrollo de software, la configuración adecuada de herramientas de recolección de datos es esencial para cumplir con el modelo organizacional y las técnicas de elicitación. ¿Qué aspecto es fundamental para asegurar que la configuración de herramientas de recolección esté alineada con el modelo organizacional y las técnicas de elicitación?
a
Usar herramientas sin considerar su integración con el modelo organizacional
b
Seleccionar herramientas que se integren bien con los procesos organizacionales y que utilicen técnicas de elicitación adecuadas para recopilar datos relevantes y precisos.
c
Implementar técnicas de recolección sin alineación con el modelo organizacional
d
Configurar herramientas sin tener en cuenta las técnicas de elicitación
18
¿Cuál es una ventaja de utilizar casos de uso en la documentación de requisitos?
a
Facilitan la identificación de requisitos técnicos
b
Permiten a los stakeholders visualizar escenarios de uso del sistema
c
Reducen el tiempo de desarrollo del sistema.
d
Eliminan la necesidad de pruebas de usuario
19
¿Cuál es el objetivo principal de los casos de uso en la ingeniería de requisitos?
a
Asegurar que el sistema se desarrolla dentro del presupuesto
b
Garantizar que el sistema se entrega a tiempo
c
Documentar todos los cambios realizados en los requisitos
d
Describir cómo los usuarios interactuarán con el sistema
20
En una empresa de desarrollo de software, la identificación y documentación adecuada de los requerimientos funcionales y no funcionales es esencial para asegurar que el sistema cumpla con las expectativas de los stakeholders y funcione correctamente. ¿Qué aspecto es fundamental para asegurar que los requerimientos funcionales estén claramente definidos?
a
Ignorar las necesidades del usuario
b
Describir detalladamente las funcionalidades que el sistema debe realizar.
c
Documentar sin retroalimentación
d
Implementar sin pruebas requeridas
21
En una empresa de desarrollo de software, la identificación y documentación adecuada de los requerimientos funcionales y no funcionales es esencial para asegurar que el sistema cumpla con las expectativas de los stakeholders y funcione correctamente. ¿Qué aspecto es fundamental para asegurar que los requerimientos no funcionales estén claramente definidos?
a
Ignorar las necesidades del usuario
b
Documentar sin retroalimentación
c
Describir detalladamente los criterios de rendimiento y seguridad
d
Implementar con algunas pruebas
22
¿Cuál de las siguientes técnicas es más adecuada para obtener información directa de los usuarios finales sobre sus necesidades y expectativas?
a
Diagramas de flujo
b
Entrevistas
c
Pruebas unitarias
d
Implementación directa del prototipo
23
¿Qué técnica de recolección de información permite observar el comportamiento real de los usuarios en su entorno de trabajo?
a
Encuestas
b
Observación
c
Revisión documental
d
Lluvia de ideas
24
¿Cuál es una ventaja clave de utilizar cuestionarios en la recolección de información?
a
Permiten una interacción profunda con cada usuario
b
Requieren poco análisis posterior
c
No necesitan planificación previa
d
Son útiles para recopilar datos de un gran número de personas en poco tiempo
25
¿Cuál de las siguientes opciones describe mejor el propósito de realizar una revisión de documentación existente durante la recolección de información?
a
Crear nuevos requerimientos desde cero
b
Validar el código fuente del sistema
c
Comprender procesos actuales y antecedentes del sistema
d
Sustituir la opinión de los usuarios
26
¿Cuál es el objetivo principal de la fase de análisis de requisitos en el desarrollo de software?
a
Validar que los requisitos sean completos, consistentes y factibles antes del diseño.
b
Traducir los requisitos en código fuente para iniciar la programación.
c
Elaborar pruebas unitarias para garantizar la calidad del producto
d
Configurar la infraestructura tecnológica para la implementación del sistema.
27
¿Qué característica define a un requisito funcional en un sistema de software?
a
Describe cómo debe comportarse el sistema ante fallos de hardware.
b
Indica las restricciones de tiempo y presupuesto del proyecto.
c
Especifica las funciones que el sistema debe realizar para cumplir con las necesidades del usuario.
d
Detalla las métricas de rendimiento y escalabilidad del sistema
28
¿Qué herramienta ayuda a mantener la trazabilidad de requisitos en todas las fases del proyecto?
a
Matriz de trazabilidad, ya que permite relacionar cada requisito con su diseño, implementación y prueba.
b
Diagrama de casos de uso en UML, porque muestra la estructura lógica del sistema
c
Manual de usuario, porque describe cómo interactuar con el sistema.
d
Informe de validación, dado que confirma la calidad del producto final.
29
¿Cuál de las siguientes afirmaciones describe mejor un requisito no funcional?
a
Define la lógica de negocio que debe implementar el sistema.
b
Indica los módulos que deben desarrollarse en la primera fase del proyecto.
c
Describe los casos de uso que representan las interacciones del usuario con el sistema.
d
Establece las condiciones de seguridad, rendimiento y usabilidad que debe cumplir el sistema.
30
¿Por qué es importante la trazabilidad de requisitos en proyectos de software?
a
Facilita la creación de diagramas UML para representar la arquitectura del sistema.
b
Permite identificar el origen y evolución de cada requisito, asegurando su cumplimiento en todas las fases.
c
Garantiza que el código fuente esté alineado con las pruebas unitarias.
d
Reduce el tiempo de desarrollo al eliminar la necesidad de documentación.
31
¿Cuál es la técnica más adecuada para priorizar requisitos cuando existen limitaciones de tiempo y presupuesto?
a
Análisis de impacto, porque evalúa el efecto de cada requisito en el sistema.
b
Método MoSCoW, ya que clasifica los requisitos en categorías de importancia (Must, Should, Could, Won’t)
c
Prototipado rápido, porque permite validar la interfaz gráfica antes del desarrollo.
d
Benchmarking, dado que compara el sistema con soluciones similares en el mercado.
32
¿Qué documento formaliza los requisitos acordados entre el cliente y el equipo de desarrollo?
a
Especificación de requisitos de software (SRS).
b
Plan de pruebas del sistema.
c
Manual de usuario final.
d
Informe de validación del sistema.
33
¿Cuál es el riesgo más común al no involucrar a los usuarios en la fase de elicitación de requisitos?
a
Incremento en la calidad del producto por falta de interferencias externas.
b
Reducción del tiempo de desarrollo por menor interacción con stakeholders.
c
Mayor claridad en los objetivos del proyecto debido a menos opiniones.
d
Desarrollo de funcionalidades irrelevantes que no satisfacen las necesidades reales del usuario.
34
¿Qué herramienta es más utilizada para representar visualmente los requisitos funcionales?
a
Diagrama de despliegue UML.
b
Diagrama de casos de uso UML.
c
Diagrama de clases UML.
d
Diagrama de componentes UML.
35
¿Cuál es la diferencia principal entre validación y verificación de requisitos?
a
La validación se realiza únicamente en la fase de pruebas, mientras que la verificación ocurre en la fase de diseño.
b
La verificación implica pruebas funcionales, mientras que la validación se limita a revisiones documentales
c
La validación asegura que el sistema cumple con las expectativas del cliente, mientras que la verificación confirma que se construyó correctamente según las especificaciones.
d
Ambas son procesos idénticos que garantizan la calidad del software.
36
¿Cuál es el propósito del análisis de stakeholders en la ingeniería de requisitos?
a
Elaborar diagramas UML para representar la arquitectura del sistema.
b
Definir métricas de rendimiento y escalabilidad del sistema
c
Identificar actores clave y sus intereses para priorizar requisitos y evitar conflictos durante el desarrollo
d
Establecer los casos de prueba que se aplicarán en la fase de validación.
37
¿Cuál es la ventaja principal del prototipado en la elicitación de requisitos?
a
Garantiza que el sistema cumpla con todas las métricas de rendimiento desde el inicio.
b
Elimina la necesidad de realizar pruebas funcionales posteriores.
c
Sustituye la documentación formal de requisitos, simplificando el proceso.
d
Permite validar la interfaz y funcionalidades antes del desarrollo completo, reduciendo riesgos de insatisfacción del cliente
38
¿Qué significa que un requisito sea verificable?
a
Que se puede modificar fácilmente durante el desarrollo sin afectar el sistema.
b
Que está alineado con las expectativas del cliente, aunque no se pueda medir.
c
Que se puede comprobar mediante pruebas o inspecciones objetivas, asegurando que se cumpla lo especificado
d
Que no requiere validación porque es evidente para el equipo de desarrollo.
39
¿Qué representa un caso de uso en la ingeniería de requisitos?
a
Un conjunto de métricas que evalúan el rendimiento del sistema.
b
Un diagrama que muestra la arquitectura física del sistema.
c
Una interacción específica entre el usuario y el sistema para lograr un objetivo definido.
d
Un documento que describe las restricciones presupuestarias del proyecto.
40
¿Por qué es importante la gestión de cambios en requisitos durante el ciclo de vida del software?
a
Para eliminar la necesidad de pruebas funcionales.
b
Para reducir la documentación necesaria en el proyecto.
c
Para garantizar que el sistema cumpla con todas las métricas de seguridad.
d
Para controlar el impacto de modificaciones en tiempo, costo y alcance, evitando desviaciones críticas.
41
¿Cuál es el objetivo principal de la validación de requisitos?
a
Verificar que el código fuente cumple con los estándares de programación
b
Garantizar que el sistema se ejecute sin errores en la fase de pruebas.
c
Revisar la documentación para asegurar que esté completa y bien redactada.
d
Confirmar que los requisitos reflejan las necesidades reales del cliente y no solo las interpretaciones del equipo técnico.
42
En el marco de trabajo Scrum, ¿cuál es el rol principal del Product Owner dentro del equipo?
a
Supervisar la programación y garantizar que el código cumpla con los estándares técnicos establecidos.
b
Definir y priorizar los elementos del Product Backlog, asegurando que el equipo trabaje en las funcionalidades que aportan mayor valor al negocio.
c
Coordinar las reuniones diarias y resolver problemas técnicos que surjan durante el desarrollo.
d
Elaborar pruebas unitarias y validar la calidad del producto antes de la entrega final.
43
¿Cuál es el propósito principal de la especificación de casos de uso en el desarrollo de software?
a
Definir la arquitectura física del sistema y los nodos donde se desplegarán los componentes.
b
Establecer métricas de rendimiento y seguridad que debe cumplir el sistema.
c
Describir las interacciones entre los actores y el sistema para cumplir objetivos funcionales, detallando escenarios y flujos alternativos.
d
Documentar los diagramas UML de clases y componentes para el diseño técnico.
44
¿Qué característica define a un Sprint en Scrum?
a
Es un periodo flexible que se ajusta según la complejidad del proyecto, sin límite de tiempo
b
Es una fase de documentación donde se detallan todos los requisitos antes de iniciar el desarrollo.
c
Es una reunión semanal para revisar el progreso del equipo y asignar nuevas tareas.
d
Es un ciclo de desarrollo corto y fijo, generalmente de 2 a 4 semanas, en el que se entrega un incremento funcional del producto.
45
¿Qué elemento NO forma parte de la estructura típica de un caso de uso?
a
Nombre del caso de uso y breve descripción del objetivo.
b
Actores involucrados y precondiciones necesarias para iniciar el flujo.
c
Diagrama de despliegue que muestra la infraestructura física del sistema
d
Flujo principal de eventos y posibles flujos alternativos.
Tissues - Practice Quiz