Bloque 3

Indique qué afirmación es FALSA: Según se trate de forma suficiente o no, la Ingeniería de Requisitos influye decisivamente en el éxito o fracaso de un proyecto software. La Ingeniería de Requisitos requiere de nociones de Ingeniería del Software. La Ingeniería de Requisitos se concentra en el estudio de aproximaciones para operar y mantener software de un modo sistemático, disciplinado y cuantificable. La Ingeniería de Requisitos abarca la gestión y definición de necesidades, restricciones y atributos de calidad para sistemas nuevos o actuales.

Según el “Software Engineering Institute”, ¿qué estructura tiene la Ingeniería del Software?. Una estructura bi-dimensional basada en las visiones “proceso” y “producto”. Una estructura uni-dimensional basada en el ciclo de vida típico: “requisitos”, “especificación”, “diseño”, “implementación”, “testing” y “mantenimiento”. Una estructura dinámica, que se adapta en función del tipo de software a desarrollar. desarrollar D:.

¿Cuáles son las dimensiones de la visión proceso según la estructura bi-dimensional de la Ingeniería del Software?. Dimensión “desarrollo” y dimensión “gestión”. Dimensión “actividad” y dimensión “aspecto”. Dimensión actividad y dimensión requisitos del sistema. Ninguna de las anteriores.

Según varios estudios llevados a cabo por expertos en Ingeniería de Requisitos, en relación con un conjunto de proyectos analizados: No existe ningún tipo de correlación entre el esfuerzo y tiempo dedicado a los requisitos y el tiempo empleado en un proyecto de desarrollo software. A menor esfuerzo y tiempo dedicado a los requisitos, mayor rapidez en la terminación de los proyectos. A mayor esfuerzo y tiempo dedicado a los requisitos, mayor rapidez en la terminación de los proyectos. Ninguna de las anteriores.

En Ingeniería de Requisitos, ¿qué se entiende por “stakeholder”?. Persona que sujeta una estaca (por ejemplo, para controlar al equipo de desarrollo). Persona que apuesta en un casino por el éxito de un proyecto, frente a otros que apuestan por lo contrario. Persona, no grupo ni organización, con un interés directo o indirecto en un producto o proyecto. Persona, grupo u organización con un interés directo o indirecto en un producto o proyecto.

De acuerdo con el Vocabulario estándar de la I.S. y de sistemas de ISO/IEC/IEEE, “Requisito” es: Una representación documentada de una condición o capacidad relativa a una necesidad de un usuario o las características de un sistema o componente de sistema. Una condición o capacidad que debe ser cumplida, o poseída, por un sistema o componente de sistema, para satisfacer un contrato, estándar, especificación u otros documentos impuestos formalmente. Una condición o capacidad necesitada por un usuario para resolver un problema o alcanzar un objetivo. Todas las anteriores.

Indique, con respecto a diversos estudios publicados, qué afirmación es FALSA: El problema más difícil de corregir, relacionado con los requisitos, es que no sean descubiertos a tiempo requisitos que son relevantes para el proyecto. Los errores relacionados con los requisitos son los más caros de corregir durante la construcción del software. Una de las causas más comunes de proyectos descontrolados es la inestabilidad de los requisitos. Al pasar de los requisitos del problema a los requisitos del diseño, se produce una reducción de “requisitos derivados”.

De acuerdo con el Vocabulario estándar de la I.S. y de sistemas de ISO/IEC/IEEE, ¿qu. Programas de computador, procedimientos, y, posiblemente, la documentación asociada y los datos pertenecientes a las operaciones de un sistema de computación. La aplicación sistemática de conocimiento científico y tecnológico, métodos y experiencia al diseño, implementación, pruebas y documentación del software. A y B son correctas. Ninguna de las anteriores.

Según los datos de la encuesta de Scott W. Ambler: Las metodologías de desarrollo de software “ad-hoc” son las que producen un porcentaje superior de proyectos que resultan exitosos. Las metodologías de desarrollo de software tradicionales son las que producen un porcentaje superior de proyectos que resultan exitosos. A y B son correctas. Ninguna de las anteriores.

De acuerdo con el Vocabulario estándar de la I.S. y de sistemas de ISO/IEC/IEEE, “Análisis de Requisitos” es: El proceso de estudiar y refinar requisitos de software, hardware o de sistemas. El proceso de estudiar las necesidades de los usuarios para conseguir una definición de requisitos de software, hardware o de sistemas. A y B son correctas. Ninguna de las anteriores.

En Ingeniería del Software, ¿cuál es la diferencia entre el ciclo de vida y el ciclo de desarrollo?. El ciclo de vida engloba desde la concepción del software hasta su retirada mientras que el ciclo de desarrollo va desde el análisis hasta la entrega al usuario. En ambos casos, el ciclo comienza al inicio del desarrollo del software, pero el ciclo de desarrollo engloba hasta el fin de su uso mientras que el ciclo de vida llega hasta la entrega al cliente. En ambos casos, el ciclo finaliza con la retirada del software, pero el ciclo de vida comienza en la concepción del producto mientras que el ciclo de desarrollo comienza al inicio del desarrollo. No existen diferencias entre estos conceptos, hacen referencia a lo mismo.

La sentencia “La aplicación mostrará la información actualizada sobre los alumnos que hayan adquirido en préstamo un determinado libro” DESCRIBE: No es un requisito válido, al no ser posible su comprobación de forma medible. Un requisito no funcional. Un requisito que limita las acciones asociadas con un objeto, función o estado. Un requisito que define relaciones entre objetos, funciones o estados.

En cuanto al impacto (coste) de los cambios según la fase en que se producen, ¿En qué fase es mayor este impacto?. Definición/Requisitos. Desarrollo (Análisis, Diseño, Programación). Pruebas unitarias y de integración. Después de la entrega.

En Ingeniería de Requisitos, “especificación de requisitos software” se entiende como: Representación de los requisitos esenciales (funciones, rendimiento, restricciones de diseño y atributos) del software y de sus interfaces externas. Una representación documentada de una condición o capacidad necesitada por un usuario para resolver un problema o alcanzar un objetivo. El proceso de estudiar y refinar requisitos de software, hardware o de sistema. Ninguna de las anteriores.

En qué deriva una especificación de requisitos errónea: En un producto con funciones correctas. En un producto con errores difíciles de corregir. En un producto con errores ocultos. En un producto con errores corregibles.

¿Qué estrategia de desarrollo de software sería conveniente EVITAR en caso de requisitos poco claros y cambiantes?. Modelo de ciclo de vida incremental e iterativo. Modelo de ciclo de vida en cascada. Metodologías ágiles. Ninguna de las anteriores es una estrategia adecuada en este contexto.

Indique qué afirmación es FALSA: El modelado mediante determinados diagramas está incluido en la disciplina de Ingeniería de Requisitos, como una alternativa para la representación de los requisitos. Se pueden definir métricas sobre los requisitos. Cuando la decisión es comprar un producto ya existente en el mercado es inútil realizar una especificación de requisitos previa. La comunicación de los requisitos forma parte de la disciplina de Ingeniería de Requisitos y facilita la incorporación de una cultura de requisitos en la organización.

Entre los objetivos de los requisitos, NO se encuentra: Documentar los cambios realizados sobre los modelos de diseño. Servir como soporte para la verificación y validación de los productos obtenidos. Proporcionar la base para el diseño de software. Ninguna de las anteriores constituye un objetivo de los requisitos.

El requisito de un SRS “la aplicación mostrará un menú emergente con publicidad de la empresa, en los dos segundos siguientes a la selección del producto para su detalle informativo”: Limita la ocurrencia de la función “mostrar menú emergente”. Es un requisito de empresa y como tal no puede figurar en el SRS. Sólo define un objeto de interfaz, no funcional. Ninguna de las anteriores.

¿A quién se dirigen los requisitos y con qué finalidad?. A usuarios potenciales o clientes, que requieren una descripción muy específica y detallada. A programadores de software, que requieren una descripción muy general que les permita adoptar distintas soluciones. A y B son falsas. A y B son verdaderas.

En cuanto a la relación entre distintos tipos de requisitos,. Los requisitos de usuario son más generales que los requisitos de empresa. Los requisitos de empresa son más generales que los requisitos software. Los requisitos de software son más generales que los requisitos de usuario. Ninguna de las anteriores.

El llamado “documento de visión” está compuesto por: La especificación de requisitos software (SRS) y la especificación de tests software (STS). La especificación de requisitos hardware y la especificación de tests hardware. Las necesidades del usuario y el documento de requisitos del producto (PRD). Todas las anteriores.

La versión de especificación de requisitos denominada "baseline" se acuerda y fija en el acto llamado: Sign-off, cierre de capítulo o aprobación de requisitos. JAD, o Joint Application Development. FAST, o Desarrollo rápido a término de la aprobación de requisitos. Brainstorming, o cierre de tormenta de ideas.

Los principales tipos de requisitos considerados por CMMi v 1.3 son: Requisitos del cliente, de producto y de componentes de producto. Requisitos del cliente, de empresa y de producto. Requisitos funcionales, no funcionales y específicos de producto. Ninguna de las anteriores.

El requisito “La sala de servidores dispondrá de extintores y armarios ignífugos” y en relación con lo que indica el estándar IEEE 830-1998: No puede aparecer en el SRS, ya que es un requisito de sistema y por tanto debería estar solamente en el SyRS. No puede aparecer en el SRS, debido a que no es un requisito de software. Puede estar incluido en el SRS, como un requisito de seguridad. A y B son ciertas.

En Ingeniería de Requisitos, ¿qué se entiende por “baseline”?. Objetivos de alto nivel de la organización o del cliente del sistema o producto. Conjunto de requisitos identificados y acordados en un instante de tiempo determinado. El acto de aprobación de los requisitos por parte del cliente. Ninguna de las anteriores.

De acuerdo al estándar IEEE Std. 830-1998, un documento de especificación de requisitos software NO debe incluir: Requisitos de restricciones de diseño. Requisitos de proyecto. Requisitos de rendimiento. Todas las anteriores.

En el documento de requisitos de la aplicación Cruceristas.com, queremos decir que “la aplicación tendrá versiones instalables tanto en entornos WINDOWS como en LINUX”: Tal y como está en el enunciado es la única manera de expresar ese requisito. No podemos decir esto, son requisitos incompatibles en un mismo documento para un proyecto concreto. Deberán generarse dos proyectos diferentes. Podemos expresar el requisito como está en el enunciado, o bien como dos requisitos separados, uno indicando que la aplicación funcionará en WINDOWS y otro indicando que lo hará también en LINUX. Como en C, pero marcando esos dos requisitos separados como exclusivos.

En el contexto de la relación que existe entre las reglas de negocio y los requisitos de software: Cuando el software ignore, controle o fuerce la regla de negocio, esta debe aparecer obligatoriamente como requisito software en el documento de especificación. En caso de inconsistencia, puede ser conveniente reformular la regla de negocio para que los posibles requisitos derivados sean consistentes. A y B son correctas. Ninguna de las anteriores.

Para software y sistemas de información convencionales de gestión, no críticos, la especificación de requisitos debe hacerse: Exclusivamente usando texto en lenguaje natural. Combinando exclusivamente técnicas formales con figuras y diagramas. Usando texto en lenguaje natural y combinándolo con técnicas formales basadas en teorías matemáticas, pues dan la precisión necesaria para estos sistemas. Usando texto en lenguaje natural y combinándolo con figuras o diagramas para complementar la informacion.

El requisito “El editor resaltará en un color llamativo las palabras no reconocidas” es: Inconsistente. Correcto. Completo y no ambiguo. Incompleto y ambiguo.

Las listas de comprobación (checklists) en Ingeniería de Requisitos: Ayudan en la actividad de inspección de requisitos a detectar posibles problemas en los documentos de requisitos. Ayudan en la actividad de inspección de requisitos a detectar posibles problemas en los requisitos. Estas listas no se usan en Ingeniería de Requisitos, sino sólo en la fase de pruebas del software ya implementado, por ello se denominan checklists. A y B son ciertas.

El requisito "el sistema de búsqueda de empleo proporcionará las siguientes respuestas en función del número de meses (N) que el trabajador lleva parado." no-aceptado (N mayor que 0 y menor que 3), pendiente (N mayor que 3 y menor que 6), aceptado (N mayor que 6) es: Inconsistente. Correcto y no ambiguo. Ambiguo. Incompleto.

Cuando tratamos de trazabilidad en relación con los requisitos (como por ejemplo, en CMMi): Nos referimos exclusivamente a trazabilidad entre requisitos del mismo o de distintos documentos de requisitos. b) Nos referimos a las relaciones entre requisitos en general, y entre estos y cualquier otro artefacto del desarrollo que sea posterior a la especificacion de requisitos. Nos referimos exclusivamente a trazabilidad entre requisitos del mismo documento. Como en B, y además a la trazabilidad de los requisitos con cualquier otro elemento relacionado, existente de forma previa a la especificación de requisitos.

La sentencia “La aplicación mostrará un listado de los alumnos que hayan adquirido en préstamo un determinado libro” describe: Un requisito que define relaciones entre objetos, funciones o estados. Un requisito que limita las acciones asociadas con un objeto, función o estado. Un requisito no funcional. No es un requisito válido, al no ser posible su comprobación de forma medible.

Indica la sentencia VERDADERA entre las siguientes: La relación de trazabilidad de Exclusión es la inversa a la relación de trazabilidad inclusiva (también llamada de refinamiento). La relación de trazabilidad de Exclusión NO debe aparecer en los llamados documentos de requisitos que son catálogos reutilizables. La relacion de trazabilidad de Exclusión NO debe aparecer en el documento de requisitos de un proyecto concreto, pues generaría conflictos. La relacion de trazabilidad de Exclusión puede aparecer en cualquier tipo de documento de requisitos.

El estándar IEEE 29148-2011 sobre ingeniería de requisitos ofrece guías para los siguientes tipos de documentos de requisitos: SRS (Software requirements specification), SyRS (System requirements specification) y StRS (Stakeholder requirements specification). SRS (Software requirements specification), SyRS (System requirements specification), StRS (Stakeholder requirements specification) y StS (Software test specification). Sólo SRS (Software requirements specification). Sólo SRS (Software requirements specification) y SyRS (System requirements specification).

La Metainformación asociada a los requisitos: Se refiere a la información general que sobre el proyecto se aporta en la introducción y texto, por ejemplo en el estándar IEEE 830-1998, secciones 1 y 2. La Metainformación del requisito describe exclusivamente su identificación (código), nombre y descripción, que puede ser textual o bien gráfica. La Metainformación es lo mismo que la trazabilidad, y solo se refiere a este atributo del requisito, en caso de que exista. Se refiere a los atributos que podemos asociar a cada requisito, como nombre, prioridad, fuente, fecha,etc.

Las restricciones de diseño impuestas en una implementación (políticas sobre estándares, lenguajes de programación, entornos operativos,...): Se incluyen en el documento TST, donde se especifica además cómo verificar los requisitos una vez implementado el sistema. Se incluyen en el documento SRS de acuerdo con el estándar IEEE 830-98. No se incluyen en el documento SRS de acuerdo con el estándar IEEE 830-98, sino en el plan del proyecto, en documento aparte. No se incluyen en el documento SRS de acuerdo con el estándar IEEE 830-98, sino en los correspondientes modelos de diseño.

En relación con el estándar de requisitos de IEEE 830-98 indica la sentencia VERDADERA: Ofrece 7 plantillas posibles para organizar los requisitos específicos de un proyecto, que no pueden combinarse en ningún caso, hay que elegir y decidirse por una de ellas. Ofrece 8 plantillas posibles para organizar los requisitos específicos de un proyecto, siendo la octava la que permite combinar dos o más de las anteriores. Ofrece 8 plantillas posibles para organizar los requisitos específicos de un proyecto, de las que deben combinarse al menos 2 de forma obligatoria. Ninguna de las anteriores es cierta.

Indica de los siguientes elementos, cuáles NO formarían parte de una Historia de Usuario (HU) típica de los métodos ágiles. El diagrama de Caso de Uso que describe la secuencia de interacciones con el usuario, ya que ésta es otra técnica diferente a los HUs. Las pruebas de aceptación. Éstas se describen en otro documento separado de las HUs. Atributos como las dependencias (trazabilidad), que no deben incluirse en la HU. Atributos como la estimación de esfuerzo o la prioridad, que corresponden más a la descripción del proyecto que al requisito que describe la HU.

La principal ventaja de usar técnicas formales en el desarrollo de software consiste en: Su interés como alternativa para sustituir completamente a las técnicas intuitivas más al uso, pero poco rigurosas, como los DFD, ER, etc. Su capacidad para describir sistemas con precisión y poder comprobar el cumplimiento o no de propiedades sobre los mismos, a modo de demostración de teoremas, por ejemplo. La existencia de numerosas y potentes herramientas CASE en el mercado con facilidades de edición, gráficos y ayudas muy usables. Su facilidad de aprendizaje.

La técnica de “historias de usuario” (HU): Es una técnica de recopilación de información en grupo, bajo el esquema FAST/JAD. Se usa exclusivamente bajo un método ágil como SCRUM. También se denomina “instancia de caso de uso” y describe la interacción con el usuario. Se puede usar como alternativa para escribir requisitos en métodos ágiles y también en métodos tradicionales.

“FAST” (Facilitated Application Specification Techniques): Es una técnica ágil de desarrollo de software. Es un enfoque orientado a equipos de trabajo para la recogida de requisitos. Es una técnica de recogida de información donde el analista es el único responsable de detectar posibles errores. Es una técnica de recogida de información basada en entrevistas individuales limitadas en el tiempo.

Una técnica formal matemática, aplicada a la especificación de software, incluye necesariamente: Una notación o lenguaje formal, basado en una teoría matemática o lógica. Una notación o lenguaje formal y un procedimiento o modelo de proceso indicando los pasos a seguir en su aplicación. Una notación o lenguaje formal que sea ejecutable, para poder construir prototipos funcionales. La utilización de especificaciones algebraicas, basadas en lógica ecuacional.

En relación con las técnicas de recogida de información para identificar requisitos, en una empresa donde hemos identificado 15 stakeholders para que participen en el proceso de elicitación: Con ese número, sólo es posible aplicar FAST (o JAD, que es un caso particular). Con ese número, lo ideal es que los ingenieros de requisitos elaboren directamente los casos de uso, evitando así el tiempo necesario para cualquiera de las técnicas anteriores (FAST,JAD,entrevistas). Las técnicas basadas en entrevistas exigen mayor dedicación en tiempo a los ingenieros de requisitos que las basadas en técnicas FAST (o JAD, que es un caso particular). Las técnicas FAST (o JAD, que es un caso particular) exigen mayor dedicación en tiempo a los ingenieros de requisitos que las basadas en entrevistas.

Indica la respuesta VERDADERA: Las técnicas formales pueden garantizar que el software construido basado en ellas sea perfecto, completamente libre de errores, especialmente en sistemas de gestión convencionales. Las técnicas formales sólo pueden utilizarse en un equipo de desarrollo que incluya matemáticos muy entrenados en su uso. Las técnicas formales son especialmente útiles para sistemas de seguridad crítica y también para otros sistemas, como los de alta calidad por requerimientos comerciales. Las técnicas formales no se usan en la práctica del desarrollo de software.

¿Qué características introduce las especificaciones formales en ingeniería de software?. Crear un contrato sin ambigüedades entre proveedores y clientes. Comprensión de propiedades intrínsecas del software a construir. Reducción significativa de tiempos y costes de desarrollo en las etapas tempranas. A y B son verdaderas.

¿Qué componentes debe tener un lenguaje para que una especificación realizada en dicho lenguaje se considere formal?. Sintaxis, semántica y teoría de prueba. Representación gráfica, representación textual y una representación mixta que una a ambas. Actores, escenarios, sistema y límites del mismo. Ninguna de las anteriores.

Indique, con respecto a los casos de uso, qué afirmación es VERDADERA: Los casos de uso normalmente representan requisitos no funcionales. Los casos de uso son fáciles de comprender y validar por parte de los usuarios. Los casos de uso se emplean como técnica para la especificación de requisitos pero no son de utilidad como técnica de recogida de requisitos. Los casos de uso, a diferencia de otras técnicas de especificación de requisitos, guían todo el proceso de desarrollo.

El lenguaje Z es una técnica formal que: Usa sólo la teoría de especificaciones algebraicas como base formal matemática. Está basado en lógica de predicados de primer orden y especificaciones algebraicas. Usa, básicamente, teoría de conjuntos y lógica de predicados de primer orden. Se caracteriza por la existencia de numerosos lenguajes ejecutables que permiten la edición y representación de diagramas y gráficos expresados en esta notación.

Las unidades de especificación de sistemas o software en Z son: Operaciones, denotando los cambios de estado, exclusivamente. Esquemas y Operaciones, denotando respectivamente estados y sus cambios. Esquemas denotando los estados, exclusivamente. No existen unidades de especificación en Z, ésta se realiza de forma compacta, n.

Indique, con respecto a las especificaciones formales, qué afirmación es VERDADERA: Las especificaciones formales aumentan el coste de la fase de especificación. Las especificaciones formales hacen que el coste de desarrollo total disminuya en todos los casos. Las especificaciones formales aumentan el coste de la fase de validación. Las especificaciones formales hacen que el coste de desarrollo total aumente en todos los casos.

De las siguientes técnicas para modelar requisitos, indica cuál es más expresiva, en función de los tipos de requisitos que se pueden representar con ellas: Teoría de Especificaciones Algebraicas. Diagrama de casos de uso de UML. Diagramas Entidad-Relación extendidos. Diagramas de clases de UML.

¿Qué es ReqIF?. Un método de ingeniería de requisitos que se utiliza especialmente para la definición de sistemas que proceden de la integración de otros existentes con anterioridad. Una técnica de elicitación (o captura) de requisitos, que se puede utilizar como alternativa a las entrevistas. Un formato de intercambio de requisitos entre herramientas CARE, que es un estándar de facto del OMG. Una herramienta CARE, basada en técnicas formales, que permite seleccionar de manera automática los requisitos más adecuados para sistemas de enclavamiento ferroviario.

Para la especificación de un nuevo sistema de información de gestión de nóminas de socios en una cooperativa de enseñanza de inglés, con aproximadamente 37 miembros, la mejor técnica de especificación de requisitos a usar sería: Z o especificaciones algebraicas, ambos proporcionan el máximo rigor en la especificación. No usaría una técnica formal, sino cualquier otra más convencional e intuitiva, basada en texto y notaciones diagramáticas, como UML o AE (Análisis Estructurado). Lo ideal sería una solución intermedia en la que intervengan especificaciones algebraicas (con Maude para los prototipos evolutivos), texto y notaciones diagramáticas como UML o AE. Especificaciones algebraicas, pues dispone de herramientas que ejecutan directamente las especificaciones y se pueden generar directamente los prototipos evolutivos.

Si participas en un proyecto de software para un sistema de enclavamiento ferroviario ¿Cuál de las siguientes herramientas CARE sugerirías utilizar?. PROVER. Caliber. Doors. Requisite.

¿Qué son las herramientas CARE?. Herramientas que facilitan el trabajo mediante la representación de requisitos con métodos formales. Herramientas que facilitan el trabajo, permitiendo la definición y organización de requisitos en un determinado lenguaje formal. Herramientas que facilitan el trabajo, permitiendo la definición, organización, almacenamiento y gestión de los requisitos. Son exactamente lo mismo que las denominadas CASE, de uso por ingenieros de software.

¿Cuál de los siguientes servicios NO son habituales en una herramienta CARE convencional (como Requisite, ReqView o Caliber?. Integración con otras herramientas. Detección de errores en el contenido de los requisitos introducidos. Generación de informes de alto nivel. Permitir el uso de plantillas para la documentación del proyecto.

Para el desarrollo de un sistema de información aeroportuario se requiere potenciar los aspectos de reutilización y es prioritario asegurar la calidad de los requisitos, ¿Qué herramienta CARE seleccionarías entre las siguientes?. PROVER. CALIBER. SIRENc, conjuntamente con SIRENd. TRC Systems Engineering Suite.

Si trabajamos en un proyecto donde hay involucrados numerosos interesados y queremos detectar rápidamente la existencia de conflictos entre los intereses de cada uno de ellos, debemos utilizar un método de ingeniería de requisitos: Basado en la reutilización de requisitos. Basado en el enfoque orientado a objetivos (goal-oriented). Basado en la técnica de puntos de vista (viewpoints). Ninguna de las anteriores.

¿Qué obstáculos podemos encontrar en la reutilización de requisitos?. Los requisitos existentes no se mantienen actualizados. Los requisitos existentes son incompletos. Los requisitos existentes están mal estructurados. Todas las anteriores.

El enfoque orientado a objetivos (goal-oriented): Es un enfoque de Ingeniería de Requisitos, donde los objetivos pueden ser tanto funcionales como no funcionales. Es un enfoque de Ingeniería de Requisitos, donde los objetivos pueden ser sólo no funcionales, y donde los requisitos son un tipo especial de objetivos. Es un enfoque de Ingeniería de Requisitos, donde los objetivos son siempre requisitos funcionales. Es un método de planificación de proyectos, a nivel gerencial y con escasa relación con los requisitos.

KAOS es un método de ingeniería de requisitos: Basado en la estrategia de orientación a aspectos. Basado en la reutilización de requisitos. Basado en el enfoque orientado a objetivos (goal-oriented). Basado en la técnica de puntos de vista (viewpoints).

El método de “patrones de requisitos” está: Basado en la estrategia de orientación a aspectos. Basado en la reutilización de requisitos. Basado en el enfoque orientado a objetivos (goal-oriented). vista (viewpoints).

Indica cuál de los siguientes es un método de Ingeniería de Requisitos orientado a “puntos de vista”: VIEWPEER. PREVIEW. VOSE. Los indicados en B y C lo son.

El enfoque i* define dos modelos: VOSE (Viewpoint Oriented Software Engineering) y VORD (Viewpoint Oriented Requirements Definition). IRENc (desarrollo con reuso) y SIRENp (desarrollo para reuso). Modelo de dependencia estratégica (SD, Strategic Dependency) y modelo de razonamiento estratégico (SR, Strategic Rationale). Ninguna de las anteriores.

En el enfoque SIREN, ¿cuál de las siguientes afirmaciones es FALSA?. Se basa en estándares internacionales de ingeniería de requisitos. Se basa en el uso de catálogos de requisitos reutilizables, almacenados en un repositorio de requisitos. Es un enfoque incompatible con otros métodos de Ingeniería de Requisitos. Está dirigido fundamentalmente a la reutilización de requisitos, tanto funcionales como no funcionales.

En relación con MAGERIT indica la respuesta verdadera: Es un método exclusivo de Ingeniería de Requisitos, especializado en requisitos de seguridad. Es un método de Análisis y Gestión de Riesgos en Sistemas de Información, que puede usarse como fuente de requisitos de seguridad. Se utiliza en combinación con CMMi y PMBOK, no siendo posible su uso de forma independiente. B y C son verdaderas.

Para tratar con los requisitos de un nuevo sistema que resultará de la unión de los actuales sistemas de información de dos cajas de ahorro que se van a fusionar en los próximos meses, indica el método o enfoque de Ingeniería de Requisitos a utilizar más apropiado, entre los siguientes: El enfoque i*, para tratar específicamente con los intereses de las diferentes partes que intervienen. La metodología SIREN, utilizada de forma totalmente independiente, para no ser contaminada por otras prácticas de Ingeniería de Requisitos que no explotan bien la reutilización. El método MAGERIT, dado que la seguridad es fundamental en este tipo de sistemas. El método VOLERE, de Chung, utilizado como guía general en el proceso de desarrollo software.

Con las debidas precauciones, la reutilización de requisitos puede tener el(los) siguiente(s) beneficio(s): Mejoras en la calidad. Mejoras en la productividad. Mejoras en la sostenibilidad. Todas las anteriores.

¿Qué obstáculos podemos encontrar en la reutilización de requisitos?. Los requisitos existentes no están actualizados. Los requisitos existentes están incompletos. Los requisitos existentes están pobremente estructurados. Todas las anteriores.

La mejora de la sostenibilidad ambiental en organizaciones TIC se puede reflejar en: Evitar el retrabajo y tener menos errores. Gastar menos tiempo y esfuerzo de desarrollo. Ahorro de recursos utilizados y menor mantenimiento posterior. Todas las anteriores.

Cuál de las siguientes es una situación favorable para la reutilización de requisitos: Requisitos frecuentes que expresan restricciones sobre el sistema o sobre el funcionamiento del sistema, derivadas del dominio de la aplicación. Requisitos relacionados con el estilo de presentación de la información. Requisitos relacionados con ciertas políticas de la empresa o normas legales. Todas las anteriores.

El método de “patrones de requisitos” es un método: Basado en las cinco dimensiones de Karlskrona, al ser un método propio de Naciones Unidas. Propio de la reutilización basada en requisitos. Basado en el enfoque orientado a objetivos. Basado en la técnica FAST, o en una de sus variantes, JAD de IBM.

¿Cuál de los siguientes es un enfoque basado en la reutilización?. a) Patrones de requisitos. Método MAGERIT. c) Método SIREN. A y C son correctas.

¿Cuál de los siguientes enfoques propone encontrar modelos comunes o genéricos, puntos de variabilidad y modos de instanciación para generar modelos concretos?. Análisis de dominio. Patrones de requisitos. Desarrollo ágil. Ninguno de los anteriores.

En el enfoque SIREN, ¿cuál de las siguientes afirmaciones es FALSA?. Se basa en estándares internacionales de ingeniería de requisitos. Se basa en el uso de catálogos de requisitos reutilizables, almacenados en un repositorio de requisitos. Es un enfoque incompatible con otros métodos de Ingeniería de Requisitos. Está dirigido principalmente a la reutilización de requisitos, tanto funcionales como no funcionales.

En relación a MAGERIT indica la respuesta verdadera: Es un método exclusivo de Ingeniería de Requisitos, especializado en requisitos de seguridad. Es un método de Análisis y Gestión de Riesgos en Sistemas de Información, que puede ser utilizado como fuente de requisitos de seguridad. Se utiliza en combinación con CMMi y PMBOK, no siendo posible utilizarlo de forma independiente. B y C son ciertas.

Con respecto a la información de trazabilidad¿Cuál de las siguientes afirmaciones es verdadera?. Puede facilitar la reutilización de los componentes del producto mediante la identificación de paquetes de requisitos, diseños, códigos, pruebas y otros artefactos relacionados. Puede facilitar la reutilización de los componentes del producto al identificar solo los paquetes de diseños y códigos relacionados. Puede facilitar la reutilización de los componentes del producto al identificar solo los paquetes de identificación del código y las pruebas relacionadas. Ninguna de las anteriores.

Indica la respuesta FALSA entre las siguientes. El software se puede construir con criterios de sostenibilidad, para ayudar a conseguir los objetivos de desarrollo sostenible de Naciones Unidas. El software no puede ayudar a mejorar el medio ambiente, ya que no es algo físico, ni genera residuos. La dimensión social y la dimensión medioambiental son categorías posibles de requisitos software a tener en cuenta para mejorar la sostenibilidad. Además de la dimensión técnica, hay otras dimensiones que podemos tener en cuenta como fuente de requisitos de sostenibilidad, como la económica entre otras.

¿Cuál(es) de los siguientes requisitos contribuiría más en la mejora de la sostenibilidad en el caso de estudio de los cruceristas?. El pago podrá ser realizado por cualquier medio: tarjetas, transferencia bancaria, etc. La página principal mostrará en la parte superior de la pantalla y centrado, el logotipo del operador turístico. La página principal podrá mostrar publicidad sobre ofertas actuales de otros cruceros del operador turístico. Todos los documentos generados por la aplicación tendrán una versión pdf con la recomendación expresa al mostrarlos de "preferentemente no imprimir en papel".

Aplicar una estrategia de teletrabajo en una empresa de desarrollo de software sería una forma de mejorar la sostenibilidad en la estrategia denominada: El teletrabajo no mejora la sostenibilidad. Green by IT. Green in IT. En ambas: Green by IT y Green in IT.

En la construcción mediante SIRENp de un catálogo de requisitos reutilizables de gestión hotelera, indica qué requisito sería más adecuado incluir: El sistema confirmará al cliente la reserva realizada mediante [medio de comunicación] en un plazo de [tiempo]. El sistema confirmará al cliente la reserva realizada mediante [medio de comunicación] lo antes posible. El sistema confirmará al cliente la reserva realizada mediante SMS, correo electrónico o llamada telefónica en un plazo de 3 días. El sistema confirmará al cliente la reserva realizada.

La herramienta de soporte a MAGERIT recomendada por el centro criptológio nacional, el CNI y el Ministerio de Defensa se denomina: SOCORRO. MARGARITA. PILAR. Todavía no se ha desarrollado ninguna herramienta que esté del todo operativa y que dé soporte a MAGERIT.

Indica cuál de los siguientes requisitos tiene un mayor impacto medioambiental negativo en una aplicación de escritorio de una sucursal bancaria: La aplicación dispondrá de características que faciliten su uso por personas de baja visión. La aplicación mostrará mediante animaciones y/o vídeos con colores llamativos cómo gestionar un préstamo bancario. Al finalizar la jornada de trabajo y desconectarse el usuario, la aplicación recomendará apagar el ordenador. La información sobre cambio de moneda extranjera se presentará en castellano, inglés y árabe, a elección del cliente que lo requiera.

La empresa que desarrolla el caso de estudio "Cruceristas" se ha especializado en aplicaciones software para operadores turísticos, por ello: Para este tipo de desarrollos de aplicaciones de turismo no es interesante aplicar la estrategia de reutilización de requisitos, dado lo cambiante del sector. b) Le interesará utilizar posibles catálogos SIREN disponibles de requisitos no funcionales (seguridad, privacidad, i18n,...). Le interesará construir un catálogo SIREN de requisitos funcionales reutilizables para este tipo de aplicaciones de turismo. B y C son correctas.

Una aplicación de móvil que proporciona informacion en tiempo real sobre los niveles de contaminación atmosférica en las ciudades visitadas por los clientes de un crucero turístico, sería: Al no incidir directamente en mejorar la calidad del aire, sino solo proporcionar información, no pertenecería ni a Green in IT ni a Green by IT. Un instrumento Green in IT. Un instrumento Green by IT. Podría pertenecer a ambas categorias: Green in IT y Green by IT.

Indica cuál de las siguientes categorías NO se corresponde con elementos de MAGERIT. Salvaguardas. Riesgos. Activos y amenazas. Indicadores de sostenibilidad.

Indica la respuesta VERDADERA, en relación con los elementos de MAGERIT. Impacto se define como la estimación de la exposición efectiva de un activo a una amenaza. Impacto se define como la consecuencia que sobre un activo tiene la materialización de una amenaza. Impacto se define como el procedimiento o mecanismo tecnológico que reduce el riesgo. Impacto se define como un evento que puede desencadenar un incidente en la organización, produciendo daños materiales o pérdidas inmateriales en sus activos.

En la construcción a través de SIRENp de un catálogo de requisitos de gestión hotelera reutilizable, indique qué requisito sería más adecuado incluir: El sistema confirmará al cliente la reserva realizada por [medio de comunicación] en un plazo de [tiempo]. El sistema confirmará al cliente la reserva realizada por [medio de comunicación] en el plazo de 3 días. El sistema confirmará al cliente la reserva realizada por SMS, email o llamada telefónica en un plazo de 3 días. El sistema confirmará la reserva realizada al cliente.

Indica cuál de las siguientes entidades da soporte a la herramienta PILAR para el método MAGERIT: Naciones Unidas, a través de su Agenda 2030 para conseguir los 17 ODS (Objetivos de Desarrollo Sostenible). El CNI (Centro Nacional de Inteligencia), España, a través del Centro Criptológico Nacional. No existe ninguna herramienta llamada PILAR para dar soporte al método MAGERIT. La Dirección General de Informática, de la Comunidad Autónoma de la Región de Murcia (CARM).

En MAGERIT, la estimación de la exposición efectiva de un activo a una amenaza se denomina. Vulnerabilidad. Impacto. Riesgo. Nivel, o Grado, de Riesgo efectivo.

¿Cuál de las siguientes afirmaciones es verdadera?. Las estrategias de reutilización pueden constituir en sí mismas un proceso de Ingeniería de Requisitos, pero no pueden integrarse con otros métodos, estándares o enfoques de RE (tradicionales, ágiles). Las estrategias de reutilización no pueden constituir en sí mismas un proceso de Ingeniería de Requisitos, y deben integrarse con otros métodos, estándares o enfoques de RE (tradicionales, ágiles). Las estrategias de reutilización pueden constituir en sí mismas un proceso de Ingeniería de Requisitos, o pueden integrarse con otros métodos, estándares o enfoques de RE (tradicionales, ágiles). Las estrategias de reutilización solo pueden integrarse con otros métodos, estándares o enfoques de RE tradicionales o prescriptivos.