Test Ingenieria de requisitos UDC

A professional-themed classroom or office setting featuring software development tools, diagrams, and a person engaging with a computer, depicting teamwork and collaboration in software engineering.

Ingeniería de Requisitos en UDC

Este quiz está diseñado para evaluar tus conocimientos en ingeniería de requisitos, un aspecto fundamental del desarrollo de software. A través de múltiples preguntas sobre conceptos clave, podrás poner a prueba tu comprensión y preparación en este campo.

  • Evalúa tus conocimientos teóricos y prácticos.
  • Descubre áreas que pueden necesitar mayor atención.
  • Ideal para estudiantes y profesionales del área.
41 Questions10 MinutesCreated by AnalyzingData42
El sistema es...
El software a desarrollar
El software que también pertenece al entorno
Una representación del mundo real y nuestra aplicación software
Corrupto, cruel y credo por máquinas para obtener energia
El interfaz es
La forma de comunicarse de los usuarios con la aplicación
El teclado y el monitor
La forma de comunicarse entre el sistema y el entorno
Las pantallas de la aplicación
Los requisitos...
Se expresan en términos de entorno
Se expresan en términos de interfaz
Se expresan en términos de sistema
Se expresan en términos de los usuarios
El entorno
Se puede modelar con un diagrama de contexto
Se puede modelar con un diagrama de secuencia
Se puede modelar con un diagrama de Venn
Se puede modelar con un diagrama de casos de uso
El conocimiento del dominio...
Se refiere a los casos de uso que habrá que implementar en el dominio de la aplicación
Es todo aquello del mundo real que se relaciona con la aplicación
Son propiedades del dominio que ayudan a satisfacer los requisitos
Lo tienen los programadores
El lenguaje natural es...
Preciso
Formal
Ambiguo
Todas las anteriores
La mayoría de las especificaciones de requisitos software están escritas...
En lenguaje semiformal
En lenguaje formal
En lenguaje natural
En diagramas
(2 buenas) los cuantificadores universales...
No son críticos
Son útiles
Son peligrosos
Hay que evitarlos a toda costa
Un cuantificador universal en el modo indicativo
Es deseable
Es lógico
Ha de ser desafiado
No importa
(2 buenas) sobre cuantificadores universales...
En modo optativo es probablemente falso
En modo indicativo es probablemente falso
En modo optativo indica que hay que cubrir el caso base y las excepciones
En modo indicativo indica que hay que cubrir el caso base y las excepciones
Cual de las siguientes NO es una relación habitual en el diagrama de clases del dominio
Dependencia
Herencia
Extends
Composición
¿Cuál es la relación entre Aplicación, Frontend y Backend?
La aplicación puede tener fronend, backend o ambos
El frontend es una aplicación, y el backend otra.
La aplicación tiene frontend y tiene backend
Aplicación rombito frontend y backend
El fluwinki makalea un puffon kitana petaristicamente. Fluwinki es un sustantivo. Lo pondríamos como...
Un atributo
Un requisito no funcional
Una relación
Una clase
De manera informal, un caso de uso es...
Una secuencia de pasos para obtener un objetivo
Lo que el usuario no administrador puede hacer en el sistema
Cada forma de utilizar el sistema
Cada función del sistema
Un escenario es...
Un conjunto de casos de uso
Donde voy a estar yo en 3 años, que le den por saco a la carrera. Voy a ser una estrella
La lista de actores que intervienen en un caso de uso
Una secuencia de pasos concretos que ocurren entre el usuario y el sistema
(2 buenas) un caso de uso puede tener...
Alternativas
Atributos
Excepciones
La definición formal de un caso de uso es que...
Es una generalización de varios escenarios
Es una forma de utilizar una aplicación
Es un conjunto de actores y relaciones
Es un diagrama
Un caso de uso es una abstracción parametrizada de uno o más escenarios de tal forma que cada escenario se obtiene aplicando una serie de parámetros específica al caso de uso. ¿Cómo nos puede ayudar esta definición a la hora de establecer especificaciones de requisitos??
Permite establecer límites a los requisitos
Nos ayuda a definir todos los escenarios posibles
El caso de uso tiene que cubrir cualquier parametrización - I.e, excepciones, entradas no esperadas...
A nada, se hace la especificación antes que los diagramas de casos de uso
¿cuándo tiene que estar el cliente disponible para resolver dudas?
Al inicio del proyecto cuando se discute el alcance
Durante toda la etapa planificada de ingeniería de requisitos
En la fase de obtención de requisitos
Durante toda la etapa real de Ingeniería de requisitos
Actualmente se tiende más y más a ciclos de vida iterativos, con iteraciones cortas (una o dos semanas). Una de las ventajas que tiene es adaptarse a cambios de requisitos, o requisitos no especificados de forma fácil. Como mínimo, en cada iteración el equipo tiene una reunión con un stakeholder. ¿Qué participantes son esenciales en estas reuniones?
Algún tester y algún desarrollador
El jefe de proyecto
El representante de ventas
El usuario final del cliente
Moviéndonos a especificación de requisitos software. ¿Cuál NO es una restricción de diseño?
El lenguaje de programación a utilizar
El sistema operativo con el que tiene que ser compatible
Tener en el equipo al menos 2 testers
Límites de cuotas de la aplicación
En el estándar ISO de especificación de requisitos, ¿podemos customizarlo al proyecto - por ejemplo, usar diagramas no estándar?
Sí, siempre que lo indiquemos en el apartado correspondiente de la sección 1
No, es necesario seguir el estándar
Sí, siempre que los cambios sean intuitivos
Sí, indicando en cada sección qué customizaciones incluye.
¿qué tipo de diagrama puede ser útil en la sección 2.1. Perspectiva del producto?
El diagrama de clases
El diagrama de contexto
El diagrama de modelado de recursos
El diagrama de casos de uso
¿Cuál NO sería una restricción general (apartado 2.4.)?
Los usuarios administradores tienen acceso a la base de datos
Auditar las acciones de los usuarios
Utilizar Role Based Access Control (RBAC)
Limitar cada instancia de la aplicación a 32GB de RAM (las máquinas que tenemos están limitadas)
¿Con qué tipo de requisitos están relacionadas las restriccioes generales?
Requisitos de mantenimiento
Requisitos de usuario
Requisitos funcionales
Requisitos no funcionales
Suposiciones y dependencias...(2.5). ¿Cuál de las siguientes NO es correcta en una aplicación de e-commerce
Sólo los usuarios registrados pueden comprar
La aplicación está funcionando 24x7
Las bases de datos nunca fallan
¿cuál no es una forma típica de organizar los requisitos funcionales?
Por tipo de interfaz
Por usuarios
Por características
Por casos de uso
¿Cuál de los siguientes requisitos de rendimiento es incorrecto en la especificación??
El sistema manejará 200GB de datos diarios
El sistema procesará 500 registros por segundo
El sistema admitirá 200 usuarios simultáneos
El sistema ejecutará las consultas de manera eficiente
¿Cuál de los siguientes requisitos no funcionales es correcto?
Un usuario administrador puede modificar el perfil de cualquier usuario
La aplicación web ofrece interfaz web encriptado (sólo HTTPS
Un usuario puede hacer apuestas sólo si tiene suficiente saldo
La aplicación diariamente reporta a los usuarios los resultados de los partidos
Las entidades del interfaz...
Son habitualmente controladas o detectadas por el sistema o el entorno, pero no por ambos
Se corresponden con elementos físicos del entorno
Se controlan con el ratón
No pertenecen al sistema
(3 buenas) ¿Qué opciones tenemos si nuestra especificación junto al dominio NO satisface los requisitos?
Fortalecer la especificación
Relajar los requisitos
Fortalecer el conocimiento del dominio
Eliminar el requisito
(2 buenas) ¡Sección 3 de la especificación de requisitos! Obligatoriamente tiene que contener...
Todas las funciones que realiza el sistema
Todos los interfaces del sistema
El listado de harware necesario para aplicación
Todos los servicios externos que usarán el software
La sección de características del usuario nos permite...
Definir que características son deseables que tengan los usuarios
Establecer los requisitos mínimos que cada usuario tiene que cumplir para usar la aplicación de forma autónoma
Limitar el acceso a ciertos componentes de la aplicación según el tipo de usuario
Conocer el perfil de cada usuario individual de la aplicación de cara a mejorar su experiencia
En la sección 2.2, Características del producto, se incluye:
Las características del logo
Los diagramas de secuencia de los casos de uso
Los requisitos no funcionales
Un listado exhaustivo de los casos de uso
Si llega a un desarrollador/tester una especificación de requisitos incompleta...
Tiene que posponer la tarea hasta que el project manager la aclare
Toma una decisión, ya que conoce la aplicación y el código
Debería de preguntar a las personas relevantes para aclarar la especificación
Debería de pasarle la tarea a un compañero con más experiencia
El fluwinki makalea un puffon kitano petarísticamente. Kitano es un adjetivo. Lo pondríamos como...
Un atributo
Una relación
Una clase
Un requisito no funcional
El fluwinki makalea un puffon kitano petarísticamente. Makalea es un verbo. Lo pondríamos como...
Un atributo
Una relación
Una clase
Un requisito no funcional
¿Cuál NO es un paso recomendado a la hora de crear un diagrama de clases de dominio?
Añadir las asociaciones a las clases en el diagrama de clases
Listar las clases conceptuales relacionadas con el proyecto y las operaciones que pueden hacer
Añadir los atributos a las clases en el diagrama de clases
Incluir los casos de uso como clases
¿Cuál es la relación entre aplicación, frontend y backend?
La aplicación se compone, opcionalmente, de un frontend y un backend
No podemos tener una aplicación sin frontend y backend
La aplicación tiene que ser o frontend o backend
Tenemos una clase genérica de aplicación: a su vez hay 2 tipos de aplicaciones específicas, frontend y backend
Imagina una frase extraída de una especificación de requisitos. Si se la damos a 10 personas, y hay más de una interpretación, es probable que sea ambigua. Si una frase tiene una interpretación ambigua, habitualmente...
El lector se queda con la última acepción
El lector se queda con la primera acepción
El lector evalúa todas las posibilidades
El lector no la entiende
En el modo optativo (requisitos), un cuantificador universal es...
Prohibido
Deseable
Ignorable
Inútil
{"name":"Test Ingenieria de requisitos UDC", "url":"https://www.quiz-maker.com/QPREVIEW","txt":"Este quiz está diseñado para evaluar tus conocimientos en ingeniería de requisitos, un aspecto fundamental del desarrollo de software. A través de múltiples preguntas sobre conceptos clave, podrás poner a prueba tu comprensión y preparación en este campo.Evalúa tus conocimientos teóricos y prácticos.Descubre áreas que pueden necesitar mayor atención.Ideal para estudiantes y profesionales del área.","img":"https:/images/course1.png"}
Powered by: Quiz Maker