Cuestionario Ingenieria de Software

¿Qué son los requerimientos funcionales según Sommerville (2011)?. a) Restricciones generales sobre el sistema. b) Limitaciones impuestas por estándares externos. c) Enunciados acerca de servicios que el sistema debe proveer y su comportamiento en situaciones específicas. d) Restricciones sobre el proceso de desarrollo del software.

¿Qué NO es descrito típicamente por los requerimientos funcionales?. a) Servicios que el sistema debe ofrecer. b) Reacciones del sistema a entradas particulares. c) Restricciones generales sobre servicios del sistema. d) Comportamientos específicos en determinadas situaciones.

¿Cuál de los siguientes es un ejemplo de requerimiento no funcional?. a) El sistema debe permitir a los usuarios iniciar sesión. b) Los usuarios no autorizados deben ser restringidos. c) El sistema debe completar las consultas en menos de 2 segundos. d) Los datos deben ser almacenados en una base de datos relacional.

¿Qué caracteriza principalmente a los requerimientos no funcionales?. a) Se enfocan en servicios individuales del sistema. b) Restringen servicios o funciones del sistema en general. c) No dependen de estándares o procesos de desarrollo. d) Describen cómo interactúa el sistema con los usuarios.

Según el texto, ¿qué se entiende por la relación entre requerimientos funcionales y no funcionales?. a) Son completamente independientes entre sí. b) Los requerimientos no funcionales pueden derivar en funcionales. c) Los requerimientos funcionales solo dependen de estándares. d) Los requerimientos funcionales imponen restricciones a los no funcionales.

¿Qué incluye normalmente un requerimiento no funcional?. a) Enunciados específicos sobre servicios individuales. b) Restricciones sobre el proceso de desarrollo. c) Indicaciones sobre cómo reaccionar ante entradas particulares. d) Explicaciones de lo que no debe hacer el sistema.

¿Qué se describe sobre los requerimientos del sistema en general?. a) Son completamente independientes entre sí. b) Solo describen servicios o características requeridas. c) Incluyen restricciones de temporización únicamente. d) Explican funcionalidad para asegurar que los servicios sean entregados correctamente.

¿Cuál de las siguientes afirmaciones sobre requerimientos funcionales es correcta?. a) Siempre implican estándares externos. b) Explican lo que el sistema no debe hacer. c) Nunca están relacionados con los no funcionales. d) Incluyen restricciones de tiempo y estándares.

¿Qué refleja el ejemplo de seguridad mencionado en el texto?. a) Los requerimientos funcionales y no funcionales son totalmente independientes. b) Los requerimientos no funcionales no generan funcionales adicionales. c) Un requerimiento inicial puede derivar en otros requerimientos funcionales. d) Los requerimientos funcionales siempre generan no funcionales.

¿Qué distingue a los requerimientos no funcionales respecto a los funcionales?. a) Describen servicios que el sistema debe ofrecer. b) Restringen características o servicios en general. c) Son específicos a servicios individuales del sistema. d) Explican cómo debería reaccionar el sistema ante entradas particulares.

¿Qué tipo de requerimientos suelen aplicarse al sistema como un todo?. a) Requerimientos funcionales. b) Requerimientos no funcionales. c) Requerimientos relacionados con estándares específicos. d) Requerimientos específicos para cada módulo del sistema.

¿Cuál es un aspecto crítico al considerar los requerimientos de un sistema?. a) Garantizar que sean completamente independientes entre sí. b) Describir servicios y características de forma aislada. c) Explicar la funcionalidad necesaria para entregar servicios correctamente. d) Limitar las interacciones entre requerimientos funcionales y no funcionales.

¿Qué describe Sommerville (2011) acerca de los requerimientos funcionales?. a) Se relacionan directamente con la configuración del sistema. b) Son enunciados generales que dependen del tipo de sistema, usuarios y orientación organizacional. c) No tienen niveles de detalle en su descripción. d) Son siempre específicos para evitar confusiones en los desarrolladores.

¿Qué elemento caracteriza a los requerimientos funcionales descritos para un sistema como el MHC-PMS?. a) Definen cómo se organiza la arquitectura global del sistema. b) Permiten realizar búsquedas en las citas de todas las clínicas. c) Están limitados únicamente a las necesidades de almacenamiento. d) No incluyen restricciones ni especificaciones detalladas.

¿Cuál es un ejemplo de un requerimiento funcional específico del sistema MHC-PMS?. a) El sistema debe ser escalable para soportar múltiples usuarios simultáneamente. b) El personal médico debe identificarse con un número de ocho dígitos. c) El sistema debe garantizar un tiempo de respuesta inferior a un segundo. d) Las citas deben estar cifradas para proteger la información de los pacientes.

Según Sommerville (2011), ¿qué puede generar la ambigüedad en los requerimientos funcionales?. a) Mejora en la claridad de la comunicación entre usuarios y desarrolladores. b) Interpretaciones incorrectas que simplifican la implementación para los desarrolladores. c) Reducción de costos y tiempos en la entrega del sistema. d) Implementaciones específicas y consistentes del sistema.

¿Qué se requiere para que las especificaciones de los requerimientos funcionales sean completas y consistentes?. a) Incluir únicamente los servicios sugeridos por los usuarios. b) No considerar las necesidades de diferentes participantes en el proyecto. c) Evitar contradicciones y cubrir todos los servicios en su totalidad. d) Detallar solo las funcionalidades principales del sistema.

¿Qué caracteriza a los requerimientos no funcionales?. a) Se relacionan directamente con los servicios proporcionados a los usuarios. b) Están relacionados con la configuración del sistema, como robustez y escalabilidad. c) Son fáciles de asociar a componentes específicos del sistema. d) No afectan la arquitectura general del sistema.

¿Por qué los requerimientos no funcionales afectan más a la arquitectura del sistema que a componentes individuales?. a) Porque son irrelevantes para los componentes del sistema. b) Porque requieren una organización que minimice comunicaciones entre componentes. c) Porque no influyen en el diseño global del sistema. d) Porque son completamente independientes de los requerimientos funcionales.

¿Qué puede provocar un requerimiento no funcional de seguridad?. a) Generar únicamente nuevos servicios para los usuarios. b) Restringir los requerimientos existentes y definir nuevos servicios. c) No afectar otros requerimientos del sistema. d) Reducir la necesidad de requerimientos funcionales adicionales.

¿Cómo se generan los requerimientos no funcionales?. a) Exclusivamente por los servicios requeridos por los usuarios. b) A través de necesidades del usuario, políticas internas y limitaciones presupuestarias. c) Solo por las regulaciones externas aplicables al sistema. d) Por componentes individuales que afectan la configuración del sistema.

Según el ejemplo del MHC-PMS, ¿qué problema puede surgir al interpretar un requerimiento funcional de búsqueda?. a) El sistema no permite registrar citas de manera adecuada. b) El sistema omite completamente la búsqueda en clínicas. c) La búsqueda puede ser interpretada como dependiente de la selección de una clínica. d) Los pacientes no son registrados en el sistema si asisten a otra clínica.

¿Qué sucede si un requerimiento funcional no se especifica claramente?. a) Se simplifica el proceso de desarrollo. b) Se evita generar costos adicionales. c) Se aplaza la entrega del sistema y aumentan los costos. d) Se mejoran las relaciones entre los usuarios y los desarrolladores.

¿Qué afirmación sobre la implementación de requerimientos no funcionales es correcta?. a) Su implementación se asocia fácilmente con componentes individuales. b) A menudo se propagan a lo largo de todo el sistema. c) No requieren consideraciones arquitectónicas significativas. d) No influyen en los requerimientos funcionales existentes.

¿Cuál de los siguientes ejemplos corresponde a un requerimiento del producto según Sommerville (2011)?. A) Definir el entorno de operación del sistema. B) Establecer los tiempos de respuesta adecuados. C) Especificar los estándares del lenguaje de programación. D) Garantizar que el sistema cumpla con regulaciones externas.

Los requerimientos de la organización están influenciados principalmente por: A) Los factores externos al sistema y su desarrollo. B) Las políticas y procedimientos de las organizaciones involucradas. C) Las expectativas de los usuarios finales. D) Las leyes y regulaciones aplicables al sistema.

¿Cuál de los siguientes es un ejemplo de un requerimiento externo?. A) Especificar los estándares del entorno de desarrollo. B) Reducir el promedio de errores cometidos por hora de uso. C) Cumplir con normativas regulatorias para obtener la aprobación de un regulador. D) Minimizar los errores del usuario mediante la organización del sistema.

¿Por qué es importante escribir los requerimientos no funcionales de forma cuantitativa?. A) Para garantizar que el sistema cumpla con los estándares éticos. B) Para facilitar la identificación de conflictos entre requerimientos funcionales y no funcionales. C) Para permitir su comprobación durante las pruebas del sistema. D) Para definir el entorno de operación del sistema de manera clara.

En el ejemplo del personal médico, ¿qué métrica se utilizó para evaluar la usabilidad del sistema?. A) El porcentaje de usuarios que completan todas las funciones sin errores. B) La cantidad de funciones que pueden utilizar después de cuatro horas de capacitación. C) El promedio de errores cometidos por hora de uso después de la capacitación. D) La reducción en el tiempo necesario para ejecutar las tareas asignadas.

Un conflicto típico entre requerimientos funcionales y no funcionales puede surgir cuando: A) El proceso de desarrollo utiliza estándares del entorno específicos. B) Se requiere un lector de tarjetas, pero también acceso remoto desde dispositivos sin lectores. C) Se establecen tiempos de respuesta adecuados como un objetivo del sistema. D) Los usuarios finales no están involucrados en la especificación de requerimientos.

¿Qué tipo de lenguaje debe evitarse en la especificación de requerimientos?. a. Analogías que faciliten la comprensión. b. Jerga y acrónimos técnicos de software (+). c. Descripciones conceptuales de alto nivel. d. Términos del negocio propios de los usuarios (*).

La comprobación de consistencia en la validación de requerimientos implica: a. Validar que no existan conflictos entre requerimientos. b. Garantizar que sean trazables a través del código fuente. c. Verificar que no haya requerimientos redundantes (*). d. Confirmar que estén completamente documentados.

Una especificación de requerimientos para el desarrollo externalizado de un sistema debe ser: a. Centrada en requerimientos de alto nivel. b. Más detallada para evitar malinterpretaciones. c. Enfocada en el diseño e implementación. d. Menos detallada porque habrá comunicación directa.

¿Qué representan los modelos de interacción sistema a sistema en la ingeniería de software?. a. Los objetos en un sistema. b. Los problemas de comunicación entre sistemas. c. Los componentes que constituyen un sistema (*). d. La organización de un sistema.

¿Qué ventaja proporciona el uso de patrones de diseño?. a. Simplifican la integración de los módulos del sistema. b. Mejoran la legibilidad y facilidad de mantenimiento. c. Permiten reutilizar soluciones de diseño probadas. d. Guían la implementación de los componentes.

¿Qué elemento define a un estilo arquitectónico?. a. Una estructura para los componentes del sistema. b. Un lenguaje de programación específico. c. Una metodología de desarrollo estándar. d. Un protocolo de comunicación determinado.

El principio Abierto-Cerrado en el diseño orientado a objetos significa: a. Los componentes no deben revelar detalles de implementación. b. Los componentes deben ser fáciles de extender sin modificación. c. Los componentes deben usar principios SOLID. d. Los componentes deben tener interfaces bien definidas (*).

¿Cuál es el objetivo de definir géneros arquitectónicos?. a. Estimar el esfuerzo y costo de desarrollo. b. Reusar patrones comunes entre sistemas. c. Prescribir el uso de tecnologías específicas. d. Determinar el tamaño del equipo requerido.

La confiabilidad en el modelo de calidad de ISO 9126 se relaciona con: a. Seguridad de acceso del sistema. b. Exactitud de los resultados generados. c. Disponibilidad del sistema para su uso. d. Facilidad de uso del sistema.

¿Qué producto NO puede ser sujeto de una revisión de calidad?. a. Plan de pruebas (*). b. Especificaciones. c. Diseño. d. Código fuente.

Según el texto, la especificación de requerimientos debe ser: a. Un equilibrio entre detalle técnico y comprensión del negocio. b. Enfocada en requerimientos de muy alto nivel. c. Lo más simple posible para facilitar su lectura (*). d. Centrada en aspectos técnicos y detalles de implementación.

¿Cuál es el objetivo principal de la adquisición de requerimientos?. a. Descubrir y documentar las necesidades de los usuarios. b. Validar que los requerimientos sean consistentes. c. Clasificar y organizar los requerimientos por subsistemas. d. Priorizar y negociar requerimientos con los usuarios.

Según el texto, la principal causa de problemas en el desarrollo de software es: a. La falta de participación de los usuarios finales. b. La ausencia de un documento de requerimientos detallado. c. La mala interpretación de requerimientos por parte de los desarrolladores. d. La evolución y cambio frecuente de requerimientos.

Los modelos estructurales muestran: a. Restricciones no funcionales como seguridad. b. Componentes y relaciones en un momento del tiempo. c. Requerimientos funcionales desde la perspectiva del usuario. d. Comportamiento dinámico y flujos de eventos (*).

El acoplamiento mide: a. La fortaleza funcional interna de los módulos. b. Las dependencias entre diferentes módulos de un sistema. c. La complejidad ciclomática de cada unidad de software. d. La relación entre requerimientos y componentes.

¿Qué elemento caracteriza a las arquitecturas orientadas a datos?. a. Interfaz gráfica de usuario. b. Existencia de una base de datos central. c. Modelamiento orientado a objetos. d. Comunicación mediante paso de mensajes.

¿Cuál es el propósito del diseño de contenido en componentes para aplicaciones web?. a. Describir la semántica de las operaciones. b. Especificar la distribución física de los componentes. c. Modelar la jerarquía de herencia entre componentes. d. Definir la información que manejará cada componente.

¿Qué representa un arquetipo en el diseño de la arquitectura?. a. Una abstracción fundamental del dominio. b. Un requisito funcional crítico. c. Un componente específico del sistema (*). d. Un estándar o convención a seguir.

¿Cuál de los siguientes NO es un beneficio potencial de los estándares de software?. a. Promueven el uso de buenas prácticas. b. Facilitan la consistencia entre proyectos. c. Reducen la necesidad de pruebas. d. Definen expectativas de calidad.

¿Cuál de las siguientes NO es una actividad previa a la revisión de software?. a. Establecer lugar y tiempo de revisión. b. Seleccionar el equipo de revisión. c. Efectuar los cambios acordados. d. Distribuir los documentos a revisar.

¿Qué tipo de sistema requiere una especificación de requerimientos más exhaustiva y detallada?. a. Un sistema desarrollado con metodología ágil. b. Un sistema web sencillo desarrollado internamente. c. Un sistema crítico y complejo. d. Un sistema que interactúa poco con otros sistemas.

¿Qué tipo de requerimientos se derivan principalmente de las entrevistas?. a. Requerimientos funcionales de los usuarios. b. Requerimientos organizacionales y externos. c. Requerimientos no explícitos o implícitos. d. Requerimientos no funcionales del sistema (*).

¿Cuál de los siguientes NO es un lineamiento recomendado para escribir requerimientos en lenguaje natural?. a. Ser lo más técnico posible para no perder precisión. b. Distinguir entre requerimientos obligatorios y deseables. c. Usar un formato estándar para todos. d. Resaltar partes claves del requerimiento.

¿Cuál es el objetivo principal de la modularidad en el diseño de software?. a. Ocultar información entre los componentes. b. Lograr independencia funcional entre módulos. c. Facilitar el refinamiento y las pruebas. d. Particionar el software en componentes manejables.

Los diagramas de secuencia representan: a. Organización estática de componentes y clases. b. Comportamiento dinámico del sistema. c. Restricciones no funcionales como performance. d. Requerimientos funcionales desde la perspectiva del usuario.

¿Qué representan las tablas de decisión en el diseño estructurado?. a. La interfaz de los componentes. b. Casos de uso y actores. c. Diagramas de flujo condensados. d. Reglas de negocio complejas.

Las arquitecturas por capas se caracterizan por: a. Estructura de pipe-and-filter. b. Abstracción creciente en cada capa superior. c. Ausencia de acoplamiento entre capas. d. Paradigma de programación orientada a objetos.

El propósito de los patrones arquitectónicos es: a. Seleccionar herramientas de desarrollo. b. Resolver problemas de diseño específicos. c. Definir estándares de codificación (*). d. Especificar requisitos funcionales.

¿Cuál es la principal diferencia entre los estándares ISO 9001 y CMMI?. a. CMMI es más reciente que ISO 9001. b. ISO 9001 es un marco de trabajo y CMMI define procesos específicos. c. CMMI es específico para software y ISO 9001 es genérico. d. ISO 9001 se enfoca en productos y CMMI en procesos.

Las métricas de software permiten principalmente: a. Predecir atributos de calidad. b. Certificar la ausencia de defectos. c. Comparar productos de diferentes proveedores. d. Todas las anteriores (*).