Banco de Preguntas IBim-Ing de Requisitos

INGENIERIA DE REQUISITOS IBIM PERIODO ABRIL 2015 - AGOSTO 2015 1.- Cuando el equipo de desarrollo se asegura que el soft

Views 44 Downloads 0 File size 18KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

INGENIERIA DE REQUISITOS IBIM PERIODO ABRIL 2015 - AGOSTO 2015 1.- Cuando el equipo de desarrollo se asegura que el software satisface los requisitos especificados, se conoce como: V-5 P-1 Validación Verificación Requerimiento

2.- Los requerimientos no funcionales se los puede clasificar en: V-5 P-3 Producto, organización y externos Usuario y sistema Producto y organización

3.- Al proceso de establecer los servicios que el cliente requiere de un sistema y los límites bajo los cuales opera y se desarrolla, se conoce como Ingeniería de: V-5 P-4 Servicios Software Requisitos

4.- Para determinar requisitos de calidad se requiere que, del costo total del proyecto se asigne entre el: V-5 P-5 10% al 15% 50% al 75% 35% al 60%

5.- Al proceso mediante el cual se obtiene una comprensión precisa de los requisitos, se conoce como: V-5 P-6 Elicitación Análisis Especificación

6.- "El responsable de la protección de datos de la organización debe certificar que todos los datos se mantienen de acuerdo a la legislación vigente", es un ejemplo de requisito de: V-5 P-7 Producto Organización Externo

7.- “El sistema debe permitir al usuario buscar un empleado por nombre, cédula o código”, es un ejemplo de requerimiento: V-5 P-8 Funcional de usuario Funcional de sistema No funcional

8.- "Se utilizará RUP como metodología, para el desarrollo del sistema", es un ejemplo de requisito de: V-5 P-9 Producto Organización Externo

9.- Cuando se describen las tareas que los usuarios necesitan llevar a cabo con el software y las características de calidad necesarias del software, se hace referencia a requerimientos de: V-5 P-12 Negocio Usuario Software

10.- A los requerimientos que describen el propósito y las necesidades de alto nivel que el producto debe satisfacer, se los conoce como requerimientos de: V-5 P-13 Negocio Usuario Software

11.- Cuando los directivos de la empresa deciden incorporar un nuevo requerimiento, cuando el proyecto esta en etapa de implementación, tenemos: V-5 P-14 Miembros del equipo de desarrollo desmoralizados Mala calidad del producto Retraso en la entrega y sobrecosto del producto

12.- Los riesgos se deben clasificar de acuerdo V-5 P-15 Su probabilidad y su impacto La cantidad El impacto del proyecto

13.- Un riesgo es INSIGNIFICANTE cuando, la probabilidad e impacto respectivamente es: V-5 P-17 Ato y bajo Baja y alto Baja y bajo

14.- Cuando se ha detectado el grado en que el riesgo afecta negativamente al proceso de requisitos, entonces se habla de: V-5 P-20 Estrategia Probabilidad Impacto

15.- El patrocinador esta en la categoría de: V-5 P-24 Cliente Usuario Otros

16.- Una vez que se han establecidos las metas, expectativas y se ha preparado las técnicas de elicitación el próximo paso es: V-5 P-25 Elegir y planificar las técnicas de elicitación de requerimientos Verificar y corregir los hallazgos Elicitar los requerimientos

17.- Cuando se crea una lista de fuentes de requerimientos se lo realiza en función de: V-5 P-28 Requerimientos Interesados Personas, documentos específicos y fuentes externas

18.- EL estudiante con respecto al sistema financiero de la UTPL, es un: V-5 P-29 Usuario directo Usuario Indirecto Cliente

19.- Son reglas que sirven para limitar las acciones que el sistema o los usuarios deben realizar. Se las conoce como: V-5 P-33 Restricciones Hechos Inferencias

20.- Cuando se requiere modelar el negocio, es necesario: V-5 P-36

Establecer políticas de negocio Combinar entre mapa de relaciones y/o mapa de procesos Priorizar requerimientos

21.- Cuando 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: V-5 P-38 Generalización Extensión Inclusión

22.- Incrementar las ventas en un 40% en el presente año, es un ejemplo de: V-5 P-39 Objetivos del negocio Políticas de negocio Reglas de negocio

23.- Cuando se desea especificar sobre la información que entra y sale de un sistema, se recomienda construir un: V-5 P-40 Diagrama de contexto Tabla evento-respuesta Mapa de diálogo

24.- La interfaz de usuario será implementado como HTML simple sin frames ni applets Java", es un ejemplo de requisito de: V-6 P-10 Organización Externo Producto

25.- Aquellos requisitos que describen detalladamente los requerimientos funcionales y no funcionales que el software debe cumplir para satisfacer las necesidades del negocio y usuario, se conoce como requerimientos de: V-6 P-12 Negocio Usuario Software

26.- Los interesados se pueden clasificar en: V-6 P-21 Usuarios directos e indirectos Sponsor, Proveedor y otros Clientes, Usuarios y otros

27.- En las entrevistas estructuradas: V-6 P-23 Se discuten de temas abiertos Se elaboran preguntas acordes a un propósito asociado al entrevistado No se elaboran preguntas

28.- Para obtener información general sobre las necesidades de los interesados, es conveniente realizar: V-6 P-26 Entrevista Prototipos Mapa de relación

29.- Cuando se desea adicionar detalle a los requerimientos de usuario, es conveniente desarrollar: V-6 P-33 Casos de uso Diagrama de contexto Políticas de negocio

30.- Un mapa de procesos permite mostrar: V-6 P-34 El sistema en su entorno El tipo de información y productos que se intercambian entre clientes externos Una secuencia de pasos, entradas y salidas necesarias para manejar un proceso de negocio

31.- A las personas encargadas de investigar, desarrollar, diseñar, fabricar, aprovisionar, probar los productos en la organización, se los conoce como: V-6 P-36 Patrocinadores Directores de portafolio Gerentes operacionales

32.- El análisis de requerimientos se representan en los modelos de: V-6 P-38 Requisitos Negocio Diseño

33.- Un ejemplo de Dominio transaccional de negocio, es un sistema de: V-6 P-39 Georeferenciación Identificación de indicadores Punto de venta

34.- Cuando un requerimiento puede ser entendido de la misma manera por todas las partes interesadas con un mi´nimo de explicacio´n complementaria, entonces es: V-7 P-2 Completo Correcto Claro

35.- A las personas u organizaciones que tienen influencia directa, indirecta o se ven influenciados por un proceso de software, se los conoce como: V-7 P-3 Gestores Analistas Interesados

36.- "El sistema debe permitir a los usuarios buscar el producto por nombre o código de barras”, es un ejemplo de requerimiento: V-7 P-7 Funcional de usuario Funcional de sistema No funcional

37.- En el visionamiento el "Cliente objetivo", se refiere a: V-7 P-18 Describir lo que hace el cliente Las personas que usarán o comprarán el software Quienes afecta al problema

38.- Aquellos que están en contacto con el software o son afectados por éste de alguna manera, se los conoce como: V-7 P-22 Clientes Proveedores Usuarios

39.- El vicerrector académico de modalidad a distancia de la UTPL, es un interesado cuya responsabilidad es: V-7 P-32 Detallar los casos de uso Especificar requerimientos de software Aprobar el proyecto

40.- Cuando el caso de uso base invoca explícitamente al caso de uso añadido y su comportamiento depende de él, pero ninguno de los dos tiene acceso a los atributos del otro, se refiere a la: V-7 P-39 Inclusión Extensión Generalización

41.- A las actividades de: diferenciar y documentar los requisito funcionales y no funcionales, identificar los atributos de calidad, restricciones y documentar los requisitos; se conoce como: V-8 P-1 Elicitación Análisis Especificación

42.- Es un proceso para examinar el documento de los requisitos para asegurar que se define el software correctamente. Esta fase se la conoce como: V-8 P-2 Elicitación Análisis Validación

43.- A las declaraciones en lenguaje natural y en diagramas, de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales se debe operar, se conoce como requerimiento: V-8 P-3 Funcional de usuario Funcional de sistema No funcionales

44.- A la actividad que tiene que ver con el punto de vista del cliente, asegurándose que las necesidades del cliente se cumplan, se lo conoce como: V-8 P-4 Validación Verificación Requerimiento

45.- Cuando al requerimiento es posible cuantificarlo, entonces es un requerimiento: V-8 P-5 Factible Necesario Verificable

46.- Cuando al prescindir de un requerimiento, provoca deficiencias en el sistema a construir, entonces el requerimiento es: V-8 P-6 Factible Necesario Verificable

47.- "El sistema debe permitir al usuario registrar los datos de clientes nuevos”, es un ejemplo de requerimiento: V-8 P-7 Funcional de usuario Funcional de sistema No funcional

48.- "El software se escribirá en lenguaje Java", es un ejemplo de requisito de: V-8 P-8 Producto Organización Externos

49.- "La aplicación se instalará en un dispositivo móvil por lo que deberá ocupar máximo 10MB", es un ejemplo de requisito de: V-8 P-9

Producto Organización Externo

50.- "El sistema bancario solamente proveerá del nombre de los clientes", es un ejemplo de requisito: V-8 P-10 Producto Organización Externo

51.- Cuando se han definido requerimientos que no reflejan las necesidades reales de los clientes, se debe a: V-8 P-11 Documentos mal redactados La metodología de desarrollo no es la apropiada No se ha recolectado la información necesaria

52.- A los requisitos que determinan el comportamiento del producto obtenido, se los conoce como requisitos de: V-8 P-12 Producto Organización Externo

53.- Aquellos requisitos que son una consecuencia de las políticas y procedimientos existentes en una organización, se los conoce como requisitos de: V-8 P-13 Producto Organización Externo

54.- Cuando los interesados (stakeholders) continuamente están cambiando las necesidades durante el desarrollo del proyecto, tenemos: V-8 P-14 Clientes descontentos Proyecto viable Miembros del equipo de desarrollo desmoralizados

55.- Al que actúa como enlace entre el equipo de software y el administrador del negocio, se lo conoce como: V-8 P-15 Sponsor del proyecto Gerente del proyecto Analista

56.- Un riesgo es CRITICO cuando la probabilidad y el impacto es: V-8 P-16 Bajo Medio Alto

57.- Al que define o aprueba la visio´n y alcance del producto, se lo conoce como: V-8 P-17 Sponsor del proyecto Gerente del proyecto Analista

58.- Para el riesgo "Poco interés de la secretaria de titulación", una estrategia de mitigación sería: V-8 P-18 Realizar reuniones para informar del nuevo proceso Hacer un taller para determinar los casos de uso de negocio Enviar documento de visión

59.- Cuando se a detectado el riesgo “Falta de participación del usuario”, la mejor alternativa para mitigar sería: V-8 P-19 Crear un plan de participación de interesados Desarrollar modelos de alcance Formalizar el documento de visión

60.- Cuando se a detectado el riesgo “Expectativas poco realistas de los clientes”, la mejor alternativa para mitigar sería: V-8 P-20 Crear la visión del producto Priorizar requerimientos Formalizar el documento de visión

61.- En un taller, la primera actividad que se debe realizar es: V-8 P-21 Identificar las reglas Conducir la reunión Determinar el propósito y los participantes

62.- A los que conocen las reglas del negocio que deben ser incorporadas dentro del software, se los conoce como: V-8 P-22 Usuarios Consejeros Patrocinador

63.- El primer paso que se debe hacer para realizar una entrevista es: V-8 P-23 Preparar las preguntas de la entrevista Identificar las personas que se entrevistará Realizar la entrevista

64.- A quienes diseñan y producen el software transformando los requerimientos en el producto final, se los conoce como: V-8 P-24 Clientes Proveedores Usuarios

65.- En el enfoque pasivo de la observación, el ingeniero de requisitos: V-8 P-25 Se involucra en las tareas, pasando a formar parte del equipo de trabajo Realiza el análisis en base a notas, videos, etc. Realiza el análisis en base a documentos

66.- Los prototipos que involucra al detalle cuestiones de interfaz y/o la funcionalidad, se conoce como: V-8 P-26 Horizontal Vertical Horizontal y Vertical

67.- Se desea empezar a obtener los requerimientos de forma adecuada, ¿Qué actividad se debe empezar a realizar? V-8 P-27 Establecer metas, expectativas y preparar Elicitar los requerimientos Elegir y planificar las técnicas de elicitación de requerimientos

68.- Categorizar los interesados, es una estrategia para identificar a los: V-8 P-28 Interesados del producto Requisitos del negocio Requisitos no funcionales

69.- El IESS, para la UTPL con respecto al rol de pagos de sus profesores es un: V-8 P-29 Usuario Consejero Patrocinador

70.- El estudiante con respecto al EVA, es un: V-8 P-30 Usuario directo Usuario Indirecto Cliente

71.- Al SRI (Servicio de Rentas Internas), con respecto a un sistema de facturación se lo puede catalogar como: V-8 P-31 Cliente Usuario Consejero

72.- Los documentos de procesos que dispone una organización, sirven de: V-8 P-32 Fuentes de requerimientos Categorización de interesados Perfiles de interesados

73.- La tabla de actores, permite: V-8 P-33 Identificar interesados Identificar y clasificar a los usuarios del sistema en términos de sus funciones y responsabilidades Establecer una correspondencia entre actores y detalle de casos de uso

74.- 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: V-8 P-34 Mapa de procesos Mapa de relación Diagramas de contexto

75.- Estas reglas se ejecutan usando fórmulas matemáticas o algorítmicas. Se las conoce como: V-8 P-35 Restricciones Hechos Cálculos

76.- A los dominios que responden a los acontecimientos en constante cambio para almacenar datos y actuar en función de su estado en un punto en el tiempo, a estos dominios se los conoce como: V-8 P-36 Dinámicos Transaccionales de negocio Estructurales

77.- Los modelos de análisis permiten validar el proceso de requerimientos de: V-8 P-37 Usuario Software Negocio

78.- Un ejemplo de política de negocio es: V-8 P-38 Incrementar la cantidad de estudiantes nuevos en un 15% en el próximo período Ofrecer descuentos a los estudiantes en su matrícula de acuerdo al período de tiempo en que realice la matrícula A los estudiantes que pagan al contado su matrícula reciben un descuento del 10%

79.- Un ejemplo de regla de negocio es: V-8 P-39

Incrementar la cantidad de estudiantes nuevos en un 15% en el próximo período Ofrecer descuentos a los estudiantes en su matrícula de acuerdo al período de tiempo en que realice la matrícula A los estudiantes que pagan al contado su matrícula reciben un descuento del 10%

80.- Cuando el equipo de desarrollo conjuntamente con el patrocinador del proyecto se ponen de acuerdo sobre los requisitos que se desarrollaran, entonces se define el: V-8 P-40 Alcance del proyecto Modelo de negocio Modelo de requerimientos

81.- Cuando un requerimiento proporciona la información suficiente para su comprensión ,entonces es: V-9 P-3 Completo Correcto Claro

82.- "El sistema debe permitir al usuario conocer el estado de su préstamo”, es un ejemplo de requerimiento: V-9 P-8 Funcional de usuario Funcional de sistema No funcional

83.- Cuando el analista describe las definiciones y la problemática del producto de acuerdo a las metas y objetivos del negocio, entonces a logrado realizar: V-9 P-20 El visionamiento La especificación La validación

84.- A la reunión de interesados cuidadosamente seleccionadas que trabajan bajo la guía de un experto neutral que produce y documenta modelos de requerimientos, se la conoce como: V-9 P-22 Entrevista Prototipos Taller

85.- Son afirmaciones verdaderas acerca del negocio, describen asociaciones o relaciones entre los términos del negocio. A estas reglas se las conoce como: V-9 P-33 Restricciones Hechos Inferencias

86.- Al reunir a los interesados para negociar acerca de los requerimientos, existe la posibilidad de: V-9 P-40 Definir el alcance del proyecto Crear un modelo de desarrollo Priorizar los requerimientos

87.- A las propiedades que el producto debe tener y que no es evidente para el usuario, incluyendo atributos de calidad, coacciones e interfaces externas, se conoce como requerimiento: V-10 P-1 Funcional de usuario Funcional de sistema No funcionales

88.- Cuando la probabilidad que ocurra un riesgo esta entre 26% y 74%, entonces el riesgo esta en un rango: V-10 P-19

Alto Medio Bajo

89.- A los que son responsables de aceptar o pagar por el producto software, se los conoce como: V-10 P-24 Clientes Proveedores Usuarios

90.- El modelo que permite conocer quienes interactúan directamente con el sistema, es: V-10 P-37 Casos de uso Tabla de actores Glosario

91.- A las especificaciones de los servicios y restricciones del sistema, se conoce como requerimiento: V-11 P-2 Funcional de usuario Funcional de sistema No funcionales

92.- Para promover un conocimiento compartido del dominio del negocio a todo el equipo de desarrollo, se requiere elaborar: V-11 P-19 El glosario La especificación Los riesgos

93.- Para elicitar, se puede considerar como fuente de información externa de la UTPL a: V-11 P-24 Código fuente del sistema académico Ley de educación superior Procesos para realizar los trámites

94.- Consiste en la generación de nuevo conocimiento en base a unas reglas que cumplen con ciertas condiciones. A estas reglas se las conoce como: V-11 P-36 Restricciones Hechos Inferencias

95.- Dada una base de datos con una gran cantidad de información, se desea obtener indicadores en base al análisis mediante algoritmos de minería de datos. Este caso se cataloga dentro de un dominio: V-11 P-39 Dinámicos Transaccionales de negocio Estructurales

96.- Los modelos de análisis de requerimientos se los representa mediante: V-11 P-40 Algoritmos Casos de uso de negocio Diagramas y/o texto estructurado