1. Desarrollar los requisitos con la suficiente calidad y detalle de tal manera que se
pueda proceder con el diseño, construcción y pruebas. Es el objetivo del: a. Análisis b. Especificación c. Validación.
2. Los resultados del análisis están expresados en: a. El software b. Modelos de diseño c. Modelos de requisitos.
3. Cuando necesite conocer ¿Quién supervisará la interactividad con el sistema?,
debe construir: a. Modelos de datos b. Diagrama de estado c. Mapa de diálogo.
4. Cuando se necesita conocer ¿Cómo hacer operar los procesos en el negocio
para alcanzar los objetivos del negocio?, debe construir: a. Diagrama de contexto b. Mapa de procesos c. Casos de uso.
5. Aquellos dominios que sirven para almacenar y analizar datos (por ejemplo:
minería de datos, generar consultas e informes), se los conoce como: a. Estructurales b. Transaccionales de negocio c. Dinámicos.
6. En los dominios estructurales, los modelos más adecuados son: a. Modelos de datos y/o reglas de negocio b. Mapa de procesos c. Casos de uso.
7. A los diagramas que proporcionan una forma de representar los pasos
involucrados en un proceso de negocio o las operaciones de un sistema software
propuesto, se conoce como: a. Mapa de procesos b. Caos de uso c. Contexto.
8. Cuando se modela una tabla evento-respuesta, dónde la persona estimula un
diálogo con el software, ocurre un evento de: a. Señal b. Temporal c. Negocio.
9. Un actor es: a. Solamente las personas b. Persona, otro sistema u dispositivo que interactúa con el sistema c. Un rol que lo determina el patrocinador.
10. Al modelo que describe la secuencia de interacciones entre un sistema y un
actor externo se conoce como: a. Requisito funcional b. Casos de uso c. Entidades.
11. La primera actividad en la fase de especificación de requerimientos consiste en: a. Verificar las necesidades del usuario b. Documentar los requerimientos de usuario c. Documentar los requerimientos de software.
12. El responsable de documentar la especificación de requerimientos es el: a. Cliente b. Usuario c. Analista.
13. Cuando la ERS refleja una necesidad real y el sistema implementado es el
deseado, se refiere a cumplir con el atributo: a. Consistente b. Completo c. Correcto.
14. Las convenciones de interfaz de usuario a seguir cuando se mejora un producto
existente, se describen en la ERS en la sección de: a. Suposiciones y dependencias b. Restricciones de diseño e implementación c. Características del sistema.
15. En los requerimientos de interfaz externa que se requiere una descripción
que incluya los tipos de dispositivos compatibles, las interacciones de datos y
controles entre el software y hardware; es necesario definir la interfaz de: a. Hardware b. Software c. Usuario.
16. Las convenciones de mensaje en la pantalla, se incluyen en las descripciones de: a. Interfaz de hardware b. Interfaz de software c. Interfaz de usuario.
17. El requerimiento: Al abrir una puerta mediante una tarjeta magnética, ésta
se mantenga abierta durante un lapso de 8 segundos. Es un ejemplo de
requerimiento de: a. Desempeño b. Protección c. Seguridad.
18. El requerimiento “El sistema pondrá fin a cualquier operación dentro de 1
segundo, si la presión media del tanque supera el 95% de la presión máxima
especificada”. Es un ejemplo de requerimiento de: a. Desempeño b. Protección c. Seguridad.
19. Es una etapa importante para evitar el riesgo de realizar una mala implementación
debido a que no se hizo una buena especificación de requisitos: a. Validación b. Especificación c. Desarrollo.
20. La revisión de requisitos lo realiza: a. Un grupo de personas que lee, analiza y discute el documento de
especificación de requisitos b. Un proceso automatizado con la ayuda del analista c. El equipo de desarrolladores (programadores).
21. Cuando se requiere realizar prototipos operacionales, se debe: a. Realizar pruebas sobre modelos de requerimientos b. Revisión de pares c. Mostrar partes del sistema.
22. Se utilizan simulaciones de pruebas en lugar de casos de prueba real para pasar
por múltiples modelos de análisis. Esto se denomina: a. Modelos de validación b. Prototipos operacionales c. Pruebas de aceptación.
23. La UTPL, ha decidido implementar un nuevo sistema de matrícula en línea
para lo cual se están definiendo el equipo de trabajo. El estudiante ¿Qué rol
desempeñaría? a. Usuario b. Cliente c. Usuario y Cliente.
24. La revisión de requisitos lo realiza: a. Un grupo de personas que lee, analiza y discute el documento de
especificación de requisitos b. Un proceso automatizado con la ayuda del analista c. El equipo de desarrolladores (programadores).
25. Cuando se requiere realizar pruebas de aceptación por parte del usuario, se
debe: a. Realizar pruebas sobre modelos de requerimientos b. Crear pruebas de validación c. Mostrar partes del sistema.
26. A la revisión en la que un grupo de interesados evalúan la documentación de
los requisitos con el fin de encontrar errores y mejorar la calidad de los mismos,
se conoce como: a. Realizar pruebas sobre modelos de requerimientos b. Revisión de pares c. Mostrar partes del sistema.
27. Para realizar la validación de debe realizar los siguientes pasos: a. Identificar y crear casos de prueba; seleccionar modelos, rastrear los
modelos y corregir los modelos b. Rastrear los modelos a través de los casos de prueba paso a paso c. Corregir los modelos.
28. Es un modelo evolutivo de cómo va quedando la interfaz del usuario en base a
los requisitos o necesidades. Esto es una validación basada en: a. Prototipo de rendimiento b. Prototipo de interfaz de usuario c. Prototipo funcional.
29. Para mostrar los requisitos relacionados con el linaje hacia delante y hacia atrás
con los entregables del proyecto, se debe crear: a. Atributos de requerimientos b. Políticas y procedimientos de control de cambios c. Matrices de trazabilidad de requerimientos.
30. Cuando se desea establecer mecanismos para manejar los cambios de los
requerimientos, se debe crear: a. Atributos de requerimientos b. Políticas y procedimientos de control de cambios c. Matrices de trazabilidad de requerimientos.
El modelo que permite conocer quienes interactúan directamente con el sistema, es: a. Tabla de actores b. Glosario c. Casos de uso.
Cuando se requiere modelar el negocio, es necesario: a. Establecer políticas de negocio b. Combinar entre mapa de relaciones y/o mapa de procesos c. Priorizar requerimientos.
Cuando se desea adicionar detalle a los requerimientos de usuario, es conveniente desarrollar: a. Casos de uso b. Diagrama de contexto c. Políticas de negocio.
Un mapa de procesos permite mostrar: a. El tipo de información y productos que se intercambian entre clientes externos b. Una secuencia de pasos, entradas y salidas necesarias para manejar un proceso de negocio c. El sistema en su entorno.
Son reglas que sirven para limitar las acciones que el sistema o los usuarios deben realizar. Se las conoce como: a. Restricciones b. Hechos c. Inferencias.
uando existe un caso de uso padre del cual uno o más casos de uso hijos heredan sus características y especializan cierto comportamiento, se da una relación de: a. Inclusión b. Extensión c. Generalización.
La tabla de actores, permite a. Identificar interesados b. Identificar y clasificar a los usuarios del sistema en términos de sus funciones y responsabilidades c. Establecer una correspondencia entre actores y detalle de casos de uso.
A los diagramas que muestran al sistema en su entorno, con las entidades externas que
proporcionan y reciben información o material desde y hacia el sistema, se los conoce como: a. Mapa de procesos b. Mapa de relación c. Diagramas de contexto.
Un ejemplo de política de negocio es: a. Incrementar la cantidad de estudiantes nuevos en un 15% en el próximo período b. Ofrecer descuentos a los estudiantes en su matrícula de acuerdo al período de tiempo en que realice la matrícula c. A los estudiantes que pagan al contado su matrícula reciben un descuento del 10%.
Las reglas que se ejecutan usando fórmulas matemáticas o algorítmicas. Se las conoce como: a. Restricciones b. Hechos c. Cálculos.
El documento que sirve como base para el diseño e implementación del sistema se lo conoce como: a. Carta de compromiso b. Visionamiento c. Especificación de Requerimientos de Software.
El responsable directo de la elaboración del documento “Especificación de Requerimientos de Software” es el: a. Analista b. Cliente c. Usuario.
Una de las fuentes para elaborar el documento de requisitos de usuario es: a. Plantilla de requerimientos b. Base de datos c. Visión del producto.
Al documento que actúa entre puente entre la definición del negocio y los requerimientos de software, se lo conoce como: a. Plantilla de requerimientos b. Requerimientos de usuario c. Visión del producto.
Uno de los lectores del documento de requerimientos de usuario es el: a. Patrocinador del proyecto b. Programador c. Diseñador de la base de datos.
Cuando en el ERS todos los requisitos reflejan alguna necesidad real, entonces cumple con el atributo de: a. Clasificado b. Correcto c. No ambiguo.
Las convenciones de interfaz de usuario a seguir cuando se mejora un producto existente, se describen en la ERS en la sección de: a. Suposiciones y dependencias b. Características del sistema c. Restricciones de diseño e implementación.
Las normas para las fuentes, iconos, etiquetas, imágenes, esquemas de color, secuencias de campo de tabulación, entre otros; se describen en la sección de Requerimientos de interfaz externa, en la parte de Interfaz de: a. Hardware b. Software c. Usuario.
Por lo general utilizar lenguaje natural en la especificación de requisitos conlleva a la ambigüedad. Una forma de solventar sería: a. Gráficos o notaciones formales b. Descripción de casos de uso c. Visionamiento adecuado del problema.
“Cuando el profesor no registre la nota dentro del plazo establecido el sistema registrará la nota mínima establecida”, es un ejemplo de requerimiento: a. Con restricción b. Sin restricción c. Con resultado observable.
Al proceso de comprobar que los requisitos fueron especificados de acuerdo a las necesidades de los clientes, se conoce como: a. Especificación b. Análisis c. Validación.
Las etapas de validación de requisitos consisten en: a. Planificar la validación y Validar los requerimientos b. Seleccionar e integrar la técnica, Asegurar la participación del usuario, Validar los requerimientos y Revisar la documentación de requerimientos. c. Documentar los casos de prueba y Elaborar el plan de pruebas.
La participación adecuada del usuario en la etapa de validación de requerimientos requiere que: a. Se definan los interesados b. Se clasifique a los interesados c. Los interesados deben revisar la documentación para asegurarse que los requisitos están completos, completos y sean de calidad.
El costo de corregir un error en las etapas finales es de: a. 1 a 5 veces. b. 10 a 100 veces. c. 95 a 100 veces.
Cuando se requiere revisar y documentar los requerimientos se debe realizar: a. Revisión de pares b. Crear pruebas de validación c. Mostrar partes del sistema.
Cuando se requiere validar los modelos, se debe: a. Realizar pruebas sobre modelos de requerimientos. b. Revisión de pares. c. Mostrar partes del sistema.
La revisión de requisitos lo realiza: a. Un grupo de personas que lee, analiza y discute el documento de especificación de requisitos. b. Un proceso automatizado con la ayuda del analista. c. El equipo de desarrolladores (programadores).
Cuando se requiere realizar prototipos operacionales, se debe: a. Realizar pruebas sobre modelos de requerimientos. b. Revisión de pares. c. Mostrar partes del sistema.
Cuando existen errores en cuanto a colores, fuentes y las demostraciones de interfaz que son menos que deseables pueden ser corregidos en algún tiempo futuro, se refiere a un nivel de severidad: a. Visual. b. Análisis. c. Herramienta.
Se utilizan simulaciones de pruebas en lugar de casos de prueba real para pasar por múltiples modelos de análisis. Esto se denomina: a. Modelos de validación. b. Prototipos operacionales. c. Prototipos visuales.
Al proceso de seguimiento de la situación y control de cambios de los requerimientos basados en una línea base, se conoce como: a. Gestión de requerimientos b. Desarrollo de requisitos c. Mantenimiento de sistema.
La correcta administración de los requisitos, permite: a. Planificar el cronograma b. Gestionar los costos c. Minimizar los errores en las etapas posteriores a la especificación de requisitos.
Una de las herramientas que permiten realizar la gestión de requerimiento de software tenemos: a. Microsoft Visio b. Open Project c. Rational Requisite Pro.
Elegir una técnica de gestión de requerimientos depende de: a. Tipo de proyecto b. Software a utilizar c. Interesados.
A la tarea de realizar un seguimiento de los requisitos, conociendo el ciclo de vida de los mismo, se conoce como: a. Control de cambios. b. Definir requisitos. c. Trazabilidad.
Al aplicar el control de cambios se: a. Adapta el negocio al sistema b. Establecen restricciones c. Alinea el proyecto de software con el cambio a las necesidades del negocio.
7. Los atributos de los requerimientos a los nuevos miembros les permite: a. Conocer la organización b. Educarse acerca de los requerimientos c. Desarrollar el proyecto.
Para crear las matrices de seguimiento de requerimientos se debe: a. Especificar los requerimientos b. Establecer los atributos de calidad c. Determinar qué resultados de desarrollo de software se debe dar seguimiento.
Para mostrar los requisitos relacionados con el linaje hacia delante y hacia atrás con los entregables del proyecto, se debe crear: a. Atributos de requerimientos. b. Políticas y procedimientos de control de cambios. c. Matrices de trazabilidad de requerimientos.
En cuanto a visibilidad la matriz de seguimiento, ayuda a: a. Priorizar requerimientos b. Identificar funcionalidades y restricciones que tendrá un proyecto o sistema c. Cancelar requisitos duplicados.
Cuando se realiza al análisis de requisitos, tanto el cliente como el usuario participan: a. Aprobando los modelos de análisis, para su posterior implementación. b. Validando, corrigiendo y aclarando la especificación de requisitos si se encuentran errores o ambigüedades. c. Si es necesario cambiar la especificación de requisitos y se requiere de información adicional.
El objetivo del análisis de requisitos consiste en: a. Construir los mapas de procesos con el diagrama de contexto. b. Desarrollar los requisitos con la suficiente calidad y nivel de detalle. c. Escribir utilizando plantillas los requisitos funcionales y no funcionales.
El ciclo del análisis de requisitos consiste en realizar el: a. Modelado de negocios, definir el alcance, modelos al detalle y priorizar requisitos. b. Proceso de obtención, análisis, especificación y validación. c. Modelado de negocios y priorizar requisitos.
Para definir el alcance del proyecto se puede: a. Crear una combinación de modelos. b. Reunir a los interesados para negociar los requisitos. c. Definir los criterios para priorizar los requisitos.
Cuando en la descripción de los requisitos se hace referencia a un “verbo” el componente de análisis se podría expresar en: a. Actores b. Procesos c. Decisión .
Considerando el enfoque de modelo de usuario, que diagrama permite conocer ¿Qué información entre y sale del sistema? a. Proceso b. Estado c. Contexto.
Para un contexto dinámico, el modelo más adecuado es: a. Tabla evento-respuesta y diagramas de estado. b. Casos de uso c. Autores.
Dada una gran cantidad de información donde se desea obtener indicadores en base al análisis mediante algoritmos de minería de datos. Este corresponde al dominio de: a. Dinámico b. Estructural c. Transaccional de negocio .
Cuando existe un caso de uso padre del cual uno o más casos de uso hijo heredan sus características y especializan cierto comportamiento, se da una relación de: a. Inclusión b. Generalización c. Extensión .
Un ejemplo de regla de negocio es: a. Incrementar la cantidad de estudiantes nuevos en un 15% en el próximo período b. Ofrecer descuentos a los estudiantes en su matrícula de acuerdo al período de tiempo en que realice la matrícula c. A los estudiantes que pagan al contado su matrícula reciben un descuento del 10%.
El “Documento de requerimiento de usuario”, permite establecer un puente entre: a. Las necesidades del usuario y la especificación de requisitos de software b. Las necesidades del usuario y la arquitectura de componentes. c. El visionamiento y las necesidades de los usuarios.
Una fuente para documentar los requisitos de usuario podría ser: a. Arquitectura candidata b. Los modelos de análisis c. La infraestructura tecnológica .
El documento de especificación de requerimientos se debe incluir, requisitos: a. Solo funcionales b. Funcionales y No Funcionales c. Solo necesidades.
El estándar que se recomienda para documentar los requisitos de software es: a. IEEE 830 b. IEEE 2120 c. IEEE 25000.
El responsable directo de la elaboración del documento “Especificación de Requerimientos de Software” es el: a. Analista b. Gerente del Proyecto c. Desarrollador.
Uno de los lectores del documento de requerimientos de usuario es: a. Programador b. Patrocinador del Proyecto c. Diseñador de base de datos.
Las convenciones de interfaz de usuario a seguir cuando un producto existente, se describe en la ERS en la sección de: a. Suposiciones y dependencias b. Características del sistema c. Restricciones de diseño e implementación .
“Cualquiera que lea el requisito llega a la misma interpretación que cualquier lector” es uno de los objetivos de: a. La estimación de actividades del proyecto b. El desarrollo de requisitos c. La redacción de requisitos.
El requisito “Si el producto no se encuentra en el almacén, el sistema deberá mostrar la disponibilidad del producto en las demás sucursales”, es una definición desde la perspectiva del: a. Sistema b. Usuario c. No es un requisito.
La declaración “Tras el envío de la actualización del producto, el número de serie se actualizará en la línea del contrato”, está escrito en voz. a. Pasiva b. Activa c. No se identifica.
|
