Ing. Requicitos

En el análisis de requisitos se revisan los requisitos que se han documentado. VERDARERO. FALSO.

La ingeniería de requisitos en esencia consiste en: Gestionar las actividades de análisis de necesidades. Especificar requisitos de software. Definir las estrategias para elicitar requisitos. No answer text provided.

En la etapa de "obtención" , se negocian las prioridades de implementación del producto. VERDADERO. FALSO.

Al incorporar nuevas funcionalidades a un producto, cuándo éste ya está en etapa de implementación, tenemos: Retraso en la entrega y mayor costo del producto. Proyecto inviable. Cliente descontento.

Se puede decir que un requisito es "claro" , cuándo proporciona la información suficiente para su comprensión. VERDADERO. FALSO.

Cuando en un riesgo existe la probabilidad de que ocurra es baja y su impacto también es bajo, entonces se puede decir que es un riesgo "insignificante". VERDADERO. FALSO.

Los riesgos de clasifican de acuerdo a su probabilidad de ocurrencia y el impacto que causan. VERDADERO. FALSO.

En el proyecto se ha determinado que el riesgo "Falta de involucramiento del usuario", está entre 26% y 74% de probabilidad que pueda ocurrir, entonces el riesgo esta en un rango bajo. VERDADERO. FALSO.

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: La especificación. El visionamiento. La validación.

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

Las especificaciones de los servicios y restricciones que el sistema debe considerar, se conoce como requisito funcional del sistema. VERDADERO. FALSO.

Las especificaciones de los servicios y restricciones que el sistema debe considerar, se conoce como requisito funcional del sistema. Sponsor. Gerente. Cliente.

Los requisitos de negocio se los describe en el documento de visión y alcance. VERDADERO. FALSO.

En el proyecto se ha determinado que el riesgo "Falta de involucramiento del usuario", está entre 26% y 74% de probabilidadque pueda ocurrir, entonces el riesgo esta en un rango bajo. VERDADERO. FALSO.

Las oportunidades de negocio, los objetivos de negocio, las métricas de éxito y una declaraciónde visión, determinan los requisitos de: Usuario. Software. Negocio. No answer text provided.

Determinar lo que está dentro y lo que esta fuera del proyecto, se conoce como: Requisito. Visión. Alcance. No answer text provided.

Uno de los resultados del visionamiento tenemos: Requisitos de software. Interesados del producto de forma general. Métricas para validar requisitos. No answer text provided.

El diagrama de contexto ayuda a los Interesados a: Obtener modelos de requisitos. Definir el alcance del proyecto, y centrarse en los insumos como en las salidas. El flujo de información de los procesos. No answer text provided.

Cuando se ha detectado el riesgo “Expectativas poco realistas de los clientes”, la mejor alternativa para mitigar sería: Priorizar los requisitos. Crear la visión del producto. Formalizar el documento de visión. No answer text provided.

En un diagrama de contexto, el círculo representa: Sistema. Entidades. Flujo. No answer text provided.

¿En qué difiere un mapa del ecosistema con un diagrama de contexto?. En el mapa de ecosistema se representa la relación de todos los sistemas con respecto al sistema a desarrollar. En el mapa de ecosistema se representa a todos los sistemas con sus respectivas interacciones entre sí. No answer text provided. No hay diferencia.

El IESS, para la UTPL con respecto al sistema de rol de pagos de sus profesores es un: Usuario. Consejero. Patrocinador. No answer text provided.

En el siguiente ejemplo "Paciente", es: Entidad externa. Sistema. Flujo de información. No answer text provided.

¿Cuál de los siguientes ejemplos, es un mapa de ecosistema?. Figura (a). Figura (b). Figura (c). No answer text provided.

Cuando el proyecto está en etapa de Implementación y los directivos deciden incorporar un nuevo requerimiento, entonces tenemos: Mala calidad del producto. Retraso en la entrega y sobrecosto del producto. Proyecto cancelado.

Cuando los interesados continuamente están cambiando las necesidades durante el desarrollo del proyecto, tenemos: Clientes descontentos. Proyecto viable. Miembros del equipo de desarrollo desmoralizados.

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

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 servicios. Ingeniería de software. Ingeniería de requisitos.

Cuando el equipo de desarrollo se asegura que el software satisface los requisitos especificados, se conoce como: Validación. Verificación. Requerimiento.

Demostrar que las necesidades del cliente se cumplen, es una actividad que se la conoce como: Validación. Verificación. Requerimiento.

Los requerimientos no funcionales se los puede clasificar en: Usuario y sistema. Producto y organización. Producto, organización y externos.

A las especificaciones de los servicios y restricciones que el sistema debe considerar, se conoce como requerimiento: Funcional de usuario. No funcionales. Funcional de sistema.

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: Funcional de usuario. Funcional de sistema. No funcionales.

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

En un proyecto sobre “Punto de venta” que cuenta con el recurso humano necesario, se ha levantado información preliminar y se ha elaborado el documento de visión y alcance, mismo que debe ser aprobado. ¿Quién debería aprobar?. Gerente del proyecto. Sponsor del proyecto. Experto en la materia.

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?. Usuario. Cliente. Usuario y Cliente.

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

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

Al que define o aprueba la visión y alcance del producto, se lo conoce como: Sponsor del proyecto. Gerente del proyecto. Analista.

En general a los que deciden los objetivos cuando se mejora el negocio al hacer uso del producto software, se los conoce como: Interesados. Desarrolladores. Analistas.

Desde el punto de vista de desarrollo del producto software, a los interesados son importantes debido a que son: Los que pagan el producto. Potenciales fuentes de requisitos. Interactúan con el sistema.

El que tiene la principal responsabilidad para obtener, analizar, documentar y validar las necesidades de los interesados del proyecto, se conoce como: Patrocinados. Gerente del proyecto. Analista de negocio.

Al que se encarga de comunicar las actividades e información del proyecto se conoce como: Patrocinados. Gerente del proyecto. Analista de negocio.

El analista, al desarrollar un producto. ¿Qué es lo que tiene que considerar para que el usuario compre o acepte el producto de software?. Que no sea costoso. Que la organización se adapte al software. Que el producto se valioso, útil y satisfactorio.

En el visionamiento el “Cliente objetivo”, se refiere a: Describir lo que hace el cliente. Las personas que usarán o comprarán el software. Quienes afecta el problema.

En la definición de la problemática en la parte de “Afecta a:”, se debe incluir: Los sistemas afectados. Personas, organización o clientes. Los analistas.

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

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

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

Los requisitos de negocio y usuario se definen desde la perspectiva del usuario. VERDADERO. FALSO.

El patrocinador del proyecto es uno de los que define los requisitos de negocio. VERDADERO. FALSO.

La declaración de la problemática como una ampliación al visionamiento es necesario cuando la solución que va a desarrollar necesita hacer un cambio en el proceso actual. VERDADERO. FALSO.

El visionamiento y la problemática para proyecto pequeños y medianos son la misma cosa. FALSO. VERDADERO.

El diagrama de contexto permite determinar los procesos de negocio de la organización. VERDADERO. FALSO.

La obtención es un: Proceso colaborativo y analítico. Actividad de gestión de requisitos. Herramienta de modelado.

La obtención permite descubrir requisitos: Negocio. Usuario. Negocio, usuario funcionales y no funcionales.

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: Entrevista. Prototipos. Taller.

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

En el enfoque pasivo de la observación, el ingeniero de requisitos: 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.

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

El usuario no interviene en el proceso de obtención. VERDADERO. FALSO.

Cuando se realiza la entrevista no estructurada, no es necesario una comprensión por parte del entrevistador. VERDADERO. FALSO.

Una meta-pregunta que el entrevistador podría utilizar es: ¿Estoy haciendo demasiadas preguntas?. VERDADERO. FALSO.

Cuando realiza las actividades de obtención “Educar a los interesados” es una de las actividades a realizar. VERDADERO. FALSO.