¿Qué es un método de desarrollo de software? Un conjunto de técnicas y un proceso guiado para ayudar en la construcción de software Un conjunto de técnicas y herramientas de ayuda para la construcción de software Un proceso guiado, ayudado por la herramienta CASE (COMPUTER-AIDED SOFTWARE ENGINEERING), para la construcción de software.
¿Qué es el software? Exclusivamente el código de los programas Programas de computador, procedimientos y, posiblemente, la documentación asociada y los datos pertenecientes a las operaciones de un sistema de computación. Las aplicaciones correspondientes a los sistemas de escritorio. El resto de las aplicaciones se denominan sistemas de información web.
Un programa o conjunto de programas escritos para dar servicio a otros programas (compiladores, sistemas operativos, drivers, software de redes…) es: Software de sistemas Software de aplicaciones Software científico/de ingeniería.
Un programa de contabilidad es: Software de sistemas Software de aplicaciones Software científico/de ingeniería.
Software embebido o empotrado (embedded software) es el que: Se utiliza especialmente en el ámbito de la restauración y de la construcción Es cualquier aplicación incluida en un producto o sistema, usada para implementar y controlar ese mismo producto o sistema (e.g. panel de control de horno microondas, consumo de gasolina en automóvil) Cualquier aplicación incluida en un PC de escritorio.
El software legado (en ingles legacy software) Se refiere al sistema operativo residente en un pc, portátil o incluso mainframe Es el software heredado por los nuevos propietarios de una empresa, cuando esta cambia de dueños Se refiere al conjunto de programas existentes en una organización, desarrollados anteriormente, incluso con varias decenas de años de antigüedad.
¿Qué entiendes por ciclo de vida de una aplicación? El conjunto de actividades asociadas al desarrollo y mantenimiento de la aplicación, incluyendo análisis, diseño, construcción, pruebas e implantación Es exactamente lo mismo que el ciclo de desarrollo de una aplicación Como en 1, pero excluyendo el mantenimiento, es decir el ciclo de vida termina cuando se entrega la aplicación al usuario.
¿Es lo mismo el proceso software que el producto software? Si, ambos conceptos coinciden No, el producto software es el programa o conjunto de programas que es resultado de la aplicación de un proceso software A veces sí, pero otras veces no, no se puede generalizar.
¿Qué es MÉTRICA? Un método de desarrollo de software, basado inicialmente en técnicas de análisis estructurado Una técnica para estimar la complejidad de los algoritmos incluidos en un programa. Un estándar oficial de gestión y dirección de proyectos.
¿Qué es RUP? Reality Unitary Program, una aplicación de simulación basada en técnicas de Realidad Virtual Risk Uniform Plattform, una plataforma de Gestión de Riesgos de Seguridad Rational Unified Process, un método de desarrollo de software basado en objetos, que utiliza la notación UML como técnica.
En el contexto de la Ingeniería del Software, ¿Qué es un artefacto? Se refiere al hardware especifico utilizado como plataforma para el desarrollo de software Exclusivamente código, o partes del código, de la aplicación final Cualquier elemento, modelo o entregable producido a lo largo del desarrollo de un producto software (e.g., diagrama E-R, código, manual de usuario, …).
¿Crees que es necesaria una planificación y gestión formal del proyecto de desarrollo de software? No es necesaria, ya que los programas y aplicaciones son productos bien definidos, que no requieren perder el tiempo en planificar y preparar los trabajos. Es necesaria, pero solamente en proyectos cuyas características así lo requieran, incluyendo actividades de planificación, coordinación, medición, monitorización y control, entre otras Es necesaria en todos los casos, con independencia del tipo y tamaño de la aplicación o aplicaciones a construir.
Indica la respuesta CORRECTA, sobre quien puede realizar el desempeño de la gestión y dirección de proyectos de Ingeniería del software Es una labor propia de economistas y gestores de empresa, pero no de ingenieros ni de graduados en Informática En todos los casos requiere estar certificado por los organismos internacionales autorizados para ello, como el OMG. Lo puede realizar cualquier persona con una formación técnica adecuada en gestión de proyectos y en Ingeniería en Software.
Indica que afirmación es FALSA entre las siguientes Los proyectos de Ingeniería de Software tienen que ser abordados, en todos los casos, por métodos desarrollados específicamente para esta disciplina Hay métodos de gestión de proyectos, como PMBOK, que sirven como base tanto para proyectos de Ingeniería de Software como para otras disciplinas (construcción, eléctricas, fabricación, …) Los proyectos de Ingeniería de Software pueden ser abordados tanto por métodos generales prescriptivos adaptados, como PMBOK, como métodos agiles, como SCRUM.
¿Qué indicadores definen mejor el éxito de un proyecto de Ingeniería de Software? El coste final del producto conseguido, exclusivamente. Esto es lo que mide al final el éxito de la empresa. La funcionalidad, con una calidad aceptable para el cliente, el coste y el cumplimiento de los plazos. Solo el coste y la funcionalidad conseguida, con una calidad aceptable, del producto final.
¿En relación a un modelo de proceso, indique que afirmación es VERDADERA? Es una colección estructurada de prácticas que describen las características de procesos efectivos Es un conjunto de criterios bien definidos y documentados que encaminan una actividad o tarea Es un proceso utilizado en una organización para satisfacer las tareas de desarrollo y mantenimiento Ninguna de las anteriores.
CMMi es útil como: Guía para mejorar los procesos de desarrollo de software Guía para mejorar los procesos de mantenimiento del software Criterio para determinar el nivel de madurez de una organización Todas las anteriores.
¿Qué es MMIS 2.0? Es un modelo de mejora y evaluación de procesos software pensado para PYMES. Es el modelo de madurez de ingeniería del software que adapta la norma ISO/IEC 33000. Es el modelo de ciclo de vida del proceso software de referencia que usa SPICE Es un método para realizar las evaluaciones de CMMI.
¿Cuántos “niveles de madurez” se definen en CMMi? 4 niveles, donde organizaciones del nivel 1 dirigen sus proyectos de manera informal y sin ninguna disciplina de desarrollo 6 niveles, donde organizaciones del nivel 5 dirigen sus proyectos de manera informal y sin ninguna disciplina de desarrollo. 4 niveles, donde organizaciones del nivel 3 dirigen sus proyectos de manera informal y sin ninguna disciplina de desarrollo 6 niveles, donde organizaciones del nivel 1 dirigen proyectos de manera informal y sin ninguna disciplina de desarrollo.
¿Qué es Itmark? Un método para realizar las evaluaciones de SPICE. Una certificación internacional orientada a PYMES. Un método para realizar las evaluaciones de CMMi El modelo de ciclo de vida software de referencia para SPICE.
De acuerdo con los estudios realizados por el CMMI Institute publicados en 2020, la mayoría de las organizaciones que han participado en el estudio se encuentran en el nivel de madurez: Inicial (1) Definido (3) Optimizado (5) Gestionado (2).
Una organizado que adopta CMMI y que desea mejorar el “nivel de capacidad” relacionada con el área de practica “Desarrollo y Gestión de Requisitos” debe: Esa área de practica no existe en CMMI v2.0 Debe contemplar conjuntamente las áreas de practica dentro del área de capacidad a la que pertenece “Desarrollo y Gestión de Requisitos” Debe contemplar conjuntamente las áreas de practica dentro de la categoría a la que pertenece “Desarrollo y Gestión de Requisitos” Debe contemplar conjuntamente las áreas de practica de “Infraestructura de Implementación” y “Gobernanza”, además de “Desarrollo y Gestión de Requisitos”.
De acuerdo con los resultados sobre certificaciones CMMI, publicados por el CMMI Institute en 2020, en España se ha realizado: Un número elevado de certificaciones, encontrándose en posiciones muy relevantes con respecto a otros países Un numero bajo de certificaciones, encontrándose en posiciones nada relevantes con respecto a otros países España esta la primera en cuanto a número de certificaciones en el estudio citado, siendo la primera en el ranking mundial. Un número medio de certificaciones, encontrándose en posiciones poco relevantes con respecto a otros países europeos.
Los métodos de evaluación y las propias evaluaciones para determinar y certificar un determinado nivel de madurez o capacidad en CMMI: No forman parte de la Suite de CMMi, sino que se realizan exclusivamente por examinadores externos, que deben estar convenientemente certificados. No forman parte de la Suite de CMMi, sino que se realizan exclusivamente por examinadores externos, que no necesitan estar certificados. No se aplican en la versión 2.0 de CMMi, en la que estas evaluaciones han evolucionado hacia métodos propios de autoevaluación de cada organización. Forman parte de la Suite de CMMi, que aporta el material y guías necesarias para su realización.
¿A qué camino de mejora da soporte CMMI? Mejorar de forma incremental los procesos que corresponden a un área de practica individual (o grupo de áreas de practica) seleccionada por la organización Mejorar un conjunto de procesos relacionados tratando, de forma incremental, conjuntos sucesivos de áreas de práctica. A y B son correctas Ninguna de las anteriores.
En el modelo CMMI v2.0, indica cuantas áreas de practica expresamente dedicadas a los requisitos existen: Ninguna 3 2 1.
Para alcanzar el nivel 5 de madurez en CMMi v2.0, en la vista de desarrollo (DEV) Basta con conseguir el mayor nivel de capacidad (CL3) en las áreas de practica que disponen de nivel 5 de evolución. Es necesario conseguir el mayor nivel de evolución (hasta EL5) en TODAS las áreas de practica del modelo para esta vista Basta con conseguir el mayor nivel de evolución en las áreas de practica que disponen de nivel 4 y 5 de evolución, para permitir el paso sencillo desde el nivel 3 al 5 de madurez. Como en B, pero extendido además a todas las áreas de la vista de CMMi v2.0 para Servicios, con la que está muy ligada.
Las áreas de capacidad en CMMi v2.0 se puede agrupar en Las áreas de practica de Desarrollo, Gestión de Suministros y Servicios Las categorías de Desarrollo, Gestión de Suministros y Servicios Las categorías Hacer, Mejorar, Gestionar y Habilitar Los grupos de practica de Hacer, Mejorar, Gestionar y Habilitar.
¿Cuáles son las áreas de practica que expresan mas directamente el nivel de “institucionalización” es una organización que adopta CMMi v2.0? Todas las de Planificación de Proyectos y Gestión de Requisitos, que son las más cruciales en relación con el éxito de los proyectos software Infraestructura de Implementación y Gobernanza Solo las de Planificación de Proyectos, Gestión de Requisitos, Infraestructura de Implementación y Gobernanza Ninguna de las demás respuestas son ciertas .
Los tipos de evaluaciones que se definen en relación con CMMI v2.0 son: Benchmark Appraisal, Sustainment Appraisal, Action Plan Reappraisal, SCAMPI A y SCAMPI B Benchmark Appraisal, Sustainment Appraisal, Action Plan Reappraisal, SCAMPI A Benchmark Appraisal, Sustainment Appraisal, Action Plan Reappraisal, Evaluation Appraisal Solo hay una: Evaluation Appraisal.
En relación con los “grupos de prácticas” en CMMI v2.0, indique que afirmación es VERDADERA: Se trata de una colección de prácticas similares que en un conjunto logran una intención, valor e información requerida. Se trata de un grupo de áreas de practica relacionadas que pueden proporcionar un mejor rendimiento en las habilidades y actividades de una organización o proyecto. Se trata de una estructura organizativa de las practicas dentro de un área de practica para ayudar a su comprensión y adopción. Se trata de una agrupación de áreas de capacidad para abordar un problema común detectado en las empresas durante el desarrollo de los entregables.
En cuanto al impacto (coste) de los cambios según la fase en que se producen, ¿Qué relación es VERDADERA? Después de la entrega > Desarrollo/Pruebas > Definición/Requisitos Desarrollo/Pruebas > Definición/Requisitos > Después de la entrega Definición/Requisitos > Desarrollo/Pruebas > Después de la entrega Ninguna de las anteriores.
En Ingeniería de Requisitos, “especificación de requisitos software” se entiende como: Una presentació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. Documentación de los requisitos esenciales (funciones, rendimiento, restricciones de diseño y atributos) del software y de sus interfaces externas Ninguna de las anteriores.
Entre los objetivos de los requisitos, NO se encuentra: Servir como soporte para la verificación y validación de los productos obtenidos Proporcionar la base para el diseño de software Documentar los cambios realizados sobre los modelos de diseño. Ninguna de las anteriores constituye un objetivo de los requisitos.
La sentencia “La aplicación mostrara la información actualizada sobre los alumnos que hayan adquirido en préstamo un determinado libro” describe: Un requisito no funcional Un requisito que define relaciones entre objetos, funciones o estados Un requisito que limita las acciones asociadas con un objeto, función o estado No es un requisito valido, al no ser posible su comprobación de forma medible.
El requisito de un SRS “la aplicación mostrara un menú emergente con publicidad de la empresa, en los dos segundos siguientes a la selección del producto para su detalle informativo”: Solo define un objeto de interfaz, no funcional Limita la ocurrencia de la función “mostrar menú emergente” Es un requisito de empresa y como tal no puede figurar en el SRS Ninguna de las anteriores.
Según varios estudios llevados a cabo por expertos en Ingeniería de Requisitos, A mayor esfuerzo y tiempo dedicado a los requisitos, mayor rapidez en la terminación de los proyectos. A menor esfuerzo y tiempo dedicado a los requisitos, mayor rapidez en la terminación de los proyectos 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. Ninguna de las anteriores.
En ingeniería del Software, ¿Cuál es la diferencia entre el ciclo de vida y el ciclo de desarrollo? No existen diferencias entre estos conceptos, hacen referencia a lo mismo 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. 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 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.
¿Qué estrategia de desarrollo de software sería conveniente EVITAR en caso de requisitos pocos claros o cambiantes? Metodologías agiles Modelo de ciclo de vida incremental e iterativo Modelo de ciclo de vida en cascada Ninguna de las anteriores es una estrategia adecuada en este contexto.
Indica cuál de los siguientes es un objetivo de los requisitos en un proyecto concreto: Mejorar las técnicas de programación utilizadas en la empresa u organización y definir los requisitos de formación previa recibida por el personal que ingresa en la empresa (programadores) Servir como soporte para la verificación y validación de los productos obtenidos. Servir como sustituto de la especificación de diseño de la arquitectura a emplear Incluir la información sobre planificación económica y temporal, cuando se sigue IEEE 830-98.
Indica cuál de las siguientes actividades no es aplicable a los requisitos (queda fuera de su ámbito): Análisis de los requisitos usando determinadas métricas Identificación de los requisitos, así como su posterior documentación Gestión y mantenimiento (de los documentos de requisitos) Todas las anteriores son aplicables a los requisitos.
¿A quién se dirigen los requisitos? A productores de software o sistema, que requieren una descripción muy general que les permita adoptar distintas soluciones A usuarios potenciales o clientes, que requieren una descripción muy específica y detallada. A y B son verdaderas A y B son falsas.
En relación a las actividades en Ingeniería de Requisitos, indique que afirmación es FALSA: Como parte de la documentación y comunicación, es conveniente facilitar la incorporación de una “cultura de requisitos” en la organización El prototipado y la simulación del sistema es útil durante el análisis Sera necesario identificar y seleccionar las técnicas de representación y modelado más apropiados En caso de apostar por la adquisición de un producto, la Ingeniería de Requisitos no es aplicable.
Dentro del ámbito de la ingeniería de requisito, las Métricas: Permiten derivar estimaciones del coste de desarrollo, recursos necesarios y refinar la planificación Tratan de realizar un seguimiento de la vida de los requisitos “forward” y “backward”. Tratan sobre la validación de los modelos construidos con los requisitos establecidos (usar los modelos) Ninguna de las anteriores.
Dentro del ámbito de la ingeniería de requisitos, ¿Cuál de las siguientes actividades forman parte del trabajo preliminar de la fase de identificación y consenso? Gestionar las trazas de requisitos Mantener la integridad de los requisitos durante la evolución del sistema Identificar interlocutores concretos y suministradores de información Verificar la corrección interna y externa de los modelos.
Indique que afirmación es FALSA: Los requisitos funcionales definen como debe funcionar el sistema (eficiencia, fiabilidad, seguridad, rendimiento, …) Los requisitos no funcionales pueden dividirse en requisitos del producto, requisitos organizacionales y requisitos externos. Las propiedades emergentes derivan del modo en que el sistema en su conjunto funciona, pero no pertenecen a ningún componente del sistema en particular. Los requisitos de usuario se definen en un alto nivel de abstracción mientras que los requisitos del sistema son más detallados.
¿A que llama “poder expresivo” de una técnica de modelado? A la variedad de tipos de requisitos que pueden ser capturados A la capacidad para suministrar mucha información en pocas líneas o espacio A y B son correctas A y B son falsas.
De acuerdo al estándar IEEE Std. 830-1998, un documento de especificación de requisitos software NO debe incluir: Requisitos de proyecto Requisitos de rendimiento Requisitos de restricciones de diseño Ninguna de las anteriores debe aparecer en el documento de especificación de requisitos.
Un documento de especificación de requisitos software es “consistente” si, y solo si, Cada requisito enunciado será cumplido por el software y cumple con lo establecido en documentos de nivel superior Ningún subconjunto de requisitos individuales descritos está en conflicto Cada requisito descrito tiene una única interpretación Define la respuesta del software a todas las posibles clases de datos de entrada y en todas las posibles situaciones.
En un documento de especificación de requisitos software de un proyecto concreto, serian relaciones permisibles entre requisitos: Jerarquía o refinamiento, trazabilidad (inclusiva) y exclusión Solo jerarquía o refinamiento Solo jerarquía o refinamiento y trazabilidad (inclusiva) 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: Puede estar incluido en el SRS, como un requisito de seguridad No puede aparecer en el SRS, ya que es un requisito de sistema y por tanto debería está solamente en el SyRS No puede aparecer en el SRS, debido a que no es un requisito de software B y C son ciertas.
La versión del documento de requisitos que constituye un principio para el resto de las actividades de un proyecto informático y que contiene un conjunto de requisitos consensuado y acordado entre los stakeholders se denomina: SRS Básico Baseline o documento de punto de arranque del proyecto SyRS preliminar Se conoce con el nombre conjunto y genérico de SRS + SyRS de inicio.
La trazabilidad que implica a los requisitos se produce: Solo entre requisitos de un mismo tipo de documento (SRS, SyRS ó STS) Solo entre requisitos de los documentos SRS y SyRS, y entre estos, en ambas direcciones Solo entre requisitos de los documentos SRS, SyRS ó STS, y entre estos, en cualquier dirección Los indicados en C, añadiendo además trazabilidad entre requisitos y otros artefactos software.
En un documento de requisitos de un proyecto software de construcción de una aplicación concreta queremos decir que “la aplicación tendrá versiones instalables tanto en entornos WINDOWS como en LINUX”: 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 esta en el enunciado, o bien como dos requisitos separados, uno indicando que la aplicación podrá funcionar en entornos WINDOWS y otro para entornos LINUX Como en B, pero marcando esos dos requisitos separados como exclusivos Tal y como esta en el enunciado es la única manera de expresar ese requisito.
Un buen documento de especificación de requisitos software permite: Aumentar el esfuerzo de desarrollo Servir como base para posteriores mejoras del producto Dificultar transferencias a nuevos usuarios/maquinas Todas las anteriores.
El requisito “el sistema de búsqueda de empleo proporcionara las siguientes respuestas en función del número de meses (N) que el trabajador lleva parado”: no-aceptado (0 < N < 3); pendiente (3 < N < 6); aceptado (N > 6)” es: Correcto y no ambiguo Ambiguo Incompleto Inconsistente.
El requisito “El editor resaltara en un color llamativo las palabras no reconocidas” es: Inconsistente Incompleto y ambiguo Correcto Completo y no ambiguo.
El llamado “documento de visión” esta compuesto por: 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) La especificación de requisitos software (SRS) y la especificación de tests software (STS) Todas las anteriores.
En cuanto a la relación entre distintos tipos de requisitos: Los requisitos de software son más generales que los requisitos de usuario 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 Ninguna de las anteriores.
En Ingeniería de Requisitos, ¿Qué se entiende por “baseline”? El acto de aprobación de los requisitos por parte del cliente 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 Ninguna de las anteriores.
En el contexto de la relación que existe entre las reglas de negocio y los requisitos de software: En caso de inconsistencia, puede ser conveniente reformular la regla de negocio para que los posibles requisitos derivados sean consistentes Cuando el software ignore, controle o fuerce la regla de negocio, esta debe aparecer obligatoriamente como requisito software en el documento de especificación. A y B son correctas Ninguna de las anteriores.
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 requisitos Estas listas no se usan en Ingeniería de Requisitos, sino solo en la fase de pruebas del software ya implementando, por ello se denominan checklists Ayudan en la actividad de inspección de requisitos a detectar posibles problemas en los documentos de requisitos A y C son ciertas.
El estándar IEEE 830 sobre especificación de requisitos ofrece varias alternativas para organizar la sección 3 de Requisitos específicos del SRS. Algunas de esas alternativas son: Por Bases de Datos, Seguridad y Mantenimiento Por Clases de Usuario, Jerarquía Funcional y Múltiples Organizaciones Por Aspectos, Jerarquía Funcional y Clases de Usuario Ninguna de las anteriores, no es la sección 3 sino la 2, la que se puede organizar de esas formas.
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 relación de trazabilidad de Exclusión NO debe aparecer en el documento de requisitos de un proyecto concreto, pues generaría conflictos La relación 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 guias 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) Solo SRS (Software requirements specification) Solo 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 grafica 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 como 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.
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 información.
Cuando identificamos que un requisito de la especificación es ambiguo debemos: Decidir por nosotros mismos la interpretación mas sensata del requisito y reescribirlo en consecuencia Dejar el requisito tal cual; el equipo de diseño y desarrollo lo interpretara de la forma mas oportuna para trasladarlo al sistema a desarrollar. Preguntar a quienes originaron el requisito para aclarar el significado real Ninguna de las anteriores.
Un grupo de requisitos es “asequible” si: Mantiene el alcance identificado para la solución prevista El conjunto de requisitos puede ser satisfecho por una solución alcanzable dentro de las restricciones impuestas El conjunto de requisitos no contiene requisitos individuales que se contradigan entre si El grupo de requisitos contiene todos los requisitos pertinentes para la definición del sistema.
¿Cuándo puede ser apropiado aplicar reutilización de requisitos? Cuando trabajamos en el desarrollo de varias aplicaciones pertenecientes a un determinado dominio Cuando hay requisitos relacionados con el estilo de presentación de la información Cuando hay requisitos relacionados con determinadas políticas de empresa o normas legales Todas las anteriores.
¿Qué obstáculos podemos encontrar en la reutilización de requisitos? Los requisitos existentes son incompletos Los requisitos existentes están mal estructurados Los requisitos no se mantienen actualizados Todas 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 Es un enfoque incompatible con otros métodos de Ingeniería de Requisitos Se basa en el uso de catálogos de requisitos reutilizables, almacenados en un repositorio de requisitos Propone el uso de unas plantillas de documentos de requisitos jerarquizadas.
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 A y B son ciertas.
En MAGERIT se define “riesgo” como: Estimación de la exposición efectiva de un activo a una amenaza Consecuencia que sobre un activo tiene la materialización de una amenaza Estimación del grado de exposición a que una amenaza se materialice sobre uno o más activos Eventos que pueden desencadenar un incidente en la organización, produciendo daños materiales o perdidas inmateriales en sus activos.
La empresa que desarrolla el caso de estudio “Cruceristas” se ha especializado en aplicaciones software para operadores turísticos, por ello: Le interesara construir un catalogo SIREN de requisitos funcionales reutilizables para este tipo de aplicaciones de turismo Le interesara utilizar posibles catálogos SIREN disponibles de requisitos no funcionales (seguridad, privacidad, i18n, …) 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 A y B son correctas.
En la construcción mediante SIRENp de un catalogo de requisitos reutilizables de gestión hostelera, indica que requisito seria más adecuado incluir: El sistema confirmara al cliente la reserva realizada El sistema confirmara al cliente la reserva realizada mediante [medio de comunicación] lo antes posible El sistema confirmara al cliente la reserva realizada mediante [medio de comunicación] en un plazo de [tiempo] El sistema confirmara al cliente la reserva realizada mediante SMS, correo electrónico o llamada telefónica en un plazo de 3 días.
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 Unidad 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. 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.
¿Cuál(es) de los siguientes requisitos contribuiría más en la mejor de la sostenibilidad en el caso de estudio de los cruceristas? “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” “El pago podrá ser realizado por cualquier medio: tarjetas, transferencia bancaria, etc.” “La pagina principal mostrara 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”.
Aplicar una estrategia de teletrabajo en una empresa de desarrollo de software seria una forma de mejorar la sostenibilidad en la estrategia denominada: Green by IT Green in IT En ambas: Green by IT y Green in IT El teletrabajo no mejora la sostenibilidad.
Una aplicación de móvil que proporciona información en tiempo real sobre los niveles de contaminación atmosférica en las ciudades visitadas por los clientes de un crucero turístico seria: Un instrumento Green in IT Un instrumento Green by IT Podría pertenecer a ambas categorías: Green in IT y Green by IT 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.
Indica cual de los siguientes requisitos tiene un mayor impacto medioambiental negativo en una aplicación de escritorio de una sucursal bancaria: “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 aplicación dispondrá de características que faciliten su uso por personas de baja visión” “La aplicación mostrara mediante animaciones y/o videos con colores llamativos como gestionar un prestamos bancario” “Al finalizar la jornada de trabajo y desconectarse el usuario, la aplicación recomendara apagar el ordenador”.
Indica cual de las siguientes categorías NO se corresponde con elementos de MAGERIT Activos y amenazas Indicadores de sostenibilidad Salvaguardas Riesgos.
Indica la respuesta VERDADERA, en relación con los elementos de MAGERIT 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 la estimación de la exposición efectiva de un activo a una amenaza Impacto se define como un evento que puede desencadenar un incidente en la organización, produciendo daños materiales o perdidas inmateriales en sus activos. .
La herramienta de soporte a MAGERIT recomendada por el centro criptológico nacional, el CNI y el Ministerio de Defensa se denomina: MARGARITA PILAR SOCORRO Todavía no se ha desarrollado ninguna herramienta que este del todo operativa y que de soporte a MAGERIT.
Una empresa de desarrollo de software desea abordar rigurosamente la Gestión de Proyectos. Para ello: Hará uso exclusivamente de PMBOK, pero no de CMMi, que es un modelo de calidad del proceso Hará uso exclusivamente de CMMi, en relación con las áreas de practica que tratan con Gestión de Proyectos, pero no de PMBOK, pues este es mucho más amplio. Podrá hacer uso tanto de PMBOK, como de las áreas de practica relacionadas en CMMi. Podrá hacer uso tanto de PMBOK, como de las áreas de practica relacionadas en MAGERIT.
Todas son características de un proyecto excepto: Temporal Elaboración gradual Resultado único Se repite cada mes.
Indica la respuesta correcta ITIL, al igual que PMBOK, es un método de Gestión y Dirección de Proyectos PMBOK es tanto un método de Gestión y Dirección de Proyectos, como de Gestión de las operaciones de una organización ITIL es un método asociado a las operaciones de una organización, pero no a la Gestión de Proyectos ITIL y PMBOK no pueden usarse simultáneamente en una misma organización, al ser incompatibles.
Indica la respuesta FALSA PMBOK es una guía para la gestión y dirección de proyectos en cualquier ámbito (ingeniería, software, construcción, …) PMBOK es una guía para la gestión y dirección de proyectos de software exclusivamente. PMBOK se organiza en torno a dominios de desempeño PMBOK pone énfasis en la adaptación de las actividades en función del contexto.
Indica la relación DIRECTA que es correcta entre portafolio, programa y proyecto: Portafolio incluye a otros portafolios, programas y subprogramas, pero no proyectos individuales Portafolio incluye solo programas y otros portafolios, pero no proyectos individuales Portafolio incluye a otros portafolios, programas y proyectos Portafolio incluye directamente solo programas y estos, directamente, incluyen sus proyectos.
¿Quién asume normalmente la responsabilidad de la gestión del portafolio en una organización? La alta gerencia o los altos equipos de dirección El director del proyecto exclusivamente El director del proyecto, asesorado por los miembros más veteranos de su equipo de dirección De forma cooperativa, entre todos los miembros del proyecto, excepto en los métodos agiles.
Para estimar los costes de un proyecto informático disponemos de Tecnicas basadas en analisis y gestion de riesgo, como MAGERIT Tecnicas basadas en la experiencia como Delphi o COCOMO Técnicas especificas para proyectos informáticos, desde un punto de vista ágil, como SCRUM Cualquiera de las anteriores seria valida.
Las reservas de gestion de un proyecto Forman parte tanto del presupuesto del proyecto como de su Linea Base de coste Estan incluidas en el presupuesto del proyecto, pero no de su Linea Base de Coste Forman parte de la Linea Base de Coste del proyecto, pero no del presupuesto del proyecto No se incluyen ni en el presupuesto ni en la Linea Bae de Coste del proyecto, se asignan solo a la Gestion de Riesgos.
En un proyecto de tamaño pequeño conocemos muy bien la división del trabajo en actividades individuales, su duración, valoración y asignación de recursos, pero no contamos con personal experimentado, ni disponemos de un modelo de
análisis inicial suficiente. Para la estimación de costes será mejor usar Una estimación basada en Delphi Una estimación basada en Puntos Función Una estimación basada en COCOMO Una estimación tarea a tarea.
Un modelo de estimación de costes de distribución porcentual Es compatible exclusivamente con un modelo tarea a tarea Es compatible exclusivamente con el uso de técnicas basadas en la experiencia Es compatible tanto con un modelo tarea a tarea, como con el uso de técnicas basadas en la experiencia Es incompatible tanto con un modelo tarea a tarea, como con el uso de técnicas basadas en la experiencia.
Disponemos de datos históricos de proyectos anteriores. Para la estimación de costes de un nuevo proyecto grande, complejo y crítico es preferible usar una técnica Paramétrica, como COCOMO De estimación por Analogías (ROM) Basada en la experiencia, como Delphi Tarea a tarea, y para cada tarea, usar ROM o bien distribución porcentual.
En la técnica de puntos de función de Albrecht Se calcula primero el coste estimado del proyecto, y a partir de ahí el esfuerzo requerido (en líneas de código) y finalmente los puntos función Se calcula primero los puntos función ajustados, a continuación los puntos función sin ajustar y finalmente el esfuerzo en líneas de código Se calcula primero los puntos de función sin ajustar, a continuación los puntos de función ajustados, el esfuerzo, la duración y finalmente el presupuesto total Es independiente el orden en que calculemos todos los elementos citados anteriormente, al final el resultado es el mismo.
Indica qué elemento o componente de los siguientes NO forma parte de la información de entrada necesaria para aplicar la técnica de puntos de función de Albrecht Entradas Externas, procesos en los que se introducen datos y que suponen la actualización de ficheros internos Ficheros Externos, o grupos lógicos de datos de interfaz Salidas Externas, procesos en los que se envían datos al exterior de la aplicación con algún tratamiento previo (derivados) Todos los anteriores forman parte de la información de entrada necesaria.
Identifico en mi proyecto los siguientes Ficheros lógicos internos (ILF) de la complejidad que se indica: 1 baja; 1 media; 0 alta. Los pesos asignados a ILF en la tabla de ponderaciones según complejidad son: baja(7); media(10); alta (15). El Ajuste de
Complejidad Técnica (ACT) es 10. Los Puntos de Función sin Ajustar relativos a ILF son 2 170 12,75 17.
Indica la relación entre COCOMO II y el nivel de CMMi de la empresa que desarrollará el proyecto El nivel CMMi es un factor de escala usado en la ecuación básica para los modelos EDM y PAM de COCOMO II El nivel CMMi es un facor de escala usado en la ecuación básica solo para el modelo EDM de COCOMO II El nivel CMMi es un factor de escala usado en la ecuación basica solo para el modelo PAM de COCOMO II No existe ninguna relación, COCOMO II no tiene en consideración esta información en ningún caso.
En relación con la información sobre el rendimiento del proyecto, un valor de SPI (Índice de rendimiento del cronograma) = 0,50 indica Estamos cumpliendo exactamente con la planificación temporal del proyecto Estamos cumpliendo exactamente con la planificación económica del proyecto Estamos retrasados con respecto a la planificación temporal del proyecto Estamos adelantados con respecto a la planificación temporal del proyecto.
En relación con la información sobre el rendimiento de un proyecto, el Valor Ganado (EV) es: El importe que llevamos ganado (como Beneficio) hasta la fecha en la realización del proyecto El valor del trabajo completado hasta la fecha (Trabajo Realizado), expresado en términos del presupuesto aprobado asignado a dicho trabajo El importe que llevamos realmente gastado (Coste Real) en el proyecto, por el trabajo completado hasta la fecha El valor del trabajo presupuestado hasta la fecha, se haya completado o no (Presupuesto).
Las estimaciones económicas en los proyectos software tienen un nivel de incertidumbre Mayor al principio del proyecto, menor según vamos avanzando en el mismo Menor al principio del proyecto, mayor según vamos avanzando en el mismo Se mantiene constante a lo largo de todo el proyecto, cuando la estimación está hecha con técnicas matemáticas Puede ocurrir cualquiera de las situaciones anteriores en la mayoría de los proyectos, no hay pautas.
En la preparación del presupuesto de costes de un proyecto Los conceptos de costes directos y de costes indirectos coinciden Las costes directos hacen referencia a los relacionados directamente para beneficio y con motivo exclusivo del proyecto Los costes indirectos hacen referencia a la reserva de gestión necesaria para afrontar posibles riesgos que acontezcan en el proyecto Los costes directos hacen referencia a los costes generales de la organización pero asignados en parte al proyecto (agua, luz, administración, alquiler de locales, ...).
En relación con la preparación del presupuesto de costes de un proyecto El valor de los costes directos e indirectos coinciden Los costes directos se calculan normalmente a partir de costes indirectos, como un porcentaje de estos Los costes indirectos se calculan normalmente a partir de los costes directos, como un porcentaje de estos Los costes indirectos se calculan normalmente a partir de los costes directos, sumando a estos la cantidad de reserva de gestión para contingencias por riesgos acontecidos.
Indica cuál de los siguientes elementos NO formaría parte de la memoria de descripción de un proyecto que se va a realizar, presentada para solicitar una ayuda pública Diseño de la Arquitectura de la Solución detallado Presupuesto de Costes detallado por actividades o etapas importantes de su ciclo de vida Resumen e Introducción Metodología y Plan de Trabajo.
¿Por qué son necesarias las actividades de seguimiento y control de proyectos? Porque las planificaciones realizadas están basadas en estimaciones, no en datos definitivos. Porque los objetivos definidos inicialmente pueden cambiar. Cualquiera de las anteriores. No son necesarias si hemos realizado adecuadamente la planificación y estimación de costes especialmente en proyectos grandes y complejos.
Indica qué acciones se recomienda tomar en caso de un proyecto descontrolado (proyecto en crisis): Mantener el máximo secreto evitando que se conozca la situación real por parte de los miembros del equipo del proyecto o del cliente, para evitar que cunda el pánico. Mantener el máximo secreto, evitando que se conozca la situación real por parte de los miembros del proyecto, pero informando al momento y detalladamente, al cliente sobre el problema. Cancelar el proyecto en el momento en que se detectan las primeras desviaciones, pues es un síntoma de que se ha planificado mal. Comunicar a todos los miembros del equipo del proyecto el problema existente para que ayuden sin reservas e interioricen la situación.
Indica qué acciones se recomienda tomar en caso de un proyecto descontrolado (proyecto en crisis): Establecer una fecha límite de finalización de la crisis, a partir de la cual, si se sobrepasa, debería replantearse la viabilidad del proyecto. Realizar un estudio “postmortem” de la crisis, para examinar qué fue mal, identificar problemas sistemáticas y documentar lo aprendido. Reasignar recursos permitiendo la utilización en su caso de equipos más rápidos de otros proyectos. Todas las anteriores.
Indica la respuesta que mejor describe las acciones a realizar una vez terminado un proyecto que ha estado en crisis (Recuperación tras la crisis) Detección del desfase, Gestión de la Crisis, Recuperación tras la crisis. Realizar estudio “postmortem” del proyecto. Anuncio y publicidad general tanto al equipo de desarrollo como al cliente. Reasignación de responsabilidades y autoridad. Eliminar al personal que ya no es necesario, Establecer la fecha de terminación de la crisis.
¿En qué reuniones de Scrum se presenta el incremento del producto y se orientan las discusiones hacia el producto y el cliente? En las reuniones de planificación del Sprint En las reuniones diarias de Scrum En las reuniones de revisión del Sprint En las reuniones de retrospectiva del Sprint.
En relación con la Lista de Producto (PB, Product Backlog) en SCRUM, indica la respuesta FALSA: El Product Owner es el principal responsable del PB El Scrum Master es el principal responsable del PB El PB puede contener tanto Historias de Usuario como Tareas, incluso podría contener requisitos textuales ordinarios o casos de uso. Los elementos del PB pueden estar priorizados de manera ordenada, usando técnicas como la llamada "MoSCoW".
Un diagrama de BurnDown del Sprint muestra, cada día: El coste efectivo del trabajo realizado hasta ese día, según su valor económico Mediante tarjetas o "post it", el estado en que se encuentra cada Historia de Usuario o Tarea (pendiente, en proceso, terminada,...) Una estimación de cuánto trabajo queda, hasta que el equipo haya terminado El nivel de desgaste o cansancio físico, de cada miembro del equipo de desarrollo, de forma individualizada.
Indica cuál de los siguientes elementos NO forma parte expresa de los conceptos manejados en KANBAN Tableros de tareas, para visualizar los estados del proceso de desarrollo, mediante tarjetas El llamado WIP (Work in Progress), que se usa para describir el número máximo de tareas que se puede realizar en cada fase de Kanban La medición de los flujos de trabajo, con indicadores como el denominado "lead time" Ciclo de desarrollo, o modelo de proceso, estrictamente secuencial (sin iteraciones).
¿Cuál de los siguientes elementos es un elemento de seguridad pasiva? Criptografía RAID Cortafuegos Sistema de detección de intrusos.
Indica el principio de seguridad que, para garantizarlo, se utilizan ACLs: Autenticación Autorización No repudio Integridad.
Sobre el fingerprinting, indica la respuesta VERDADERA: Consiste en la utilización de herramientas OSINT para obtener información sobre los usuarios del sistema Consiste en obtener información del dominio por medio de técnicas OSINT Supone la utilización del Google para obtener información de la empresa Consiste en realizar un escaneo de puertos y obtener información de los servicios desplegados.
El payload de tipo Stager se encarga de: Ejecutar un Shell Descargar información del usuario Ejecutar un ataque de Denegación de Servicio Descargar un payload de tipo Staged.
¿Cuál de las siguientes actividades se corresponde con la fase de post-explotación? Footprinting Google Hacking Pivoting Generación de informe de la fase de exploiting.
La siguiente sentencia: “Consiste en realizar un análisis de los daños producidos durante un ataque a la red interna” se corresponde con: Auditoría de seguridad interna Auditoría de seguridad perimetral Análisis forense Test de penetración.
Un ataque de SQL injection consiste en: Utilizar un exploit de la base de datos para insertar información en la base de datos Ejecutar comandos o acceder a información de la base de datos a través de aplicaciones que hacen uso de la base de datos Comprometer la base de datos a partir de información OSINT Utilizar un rootkit para insertar información en la base de datos.
¿Cuál sería la forma adecuada de prevenir un ataque de inyección? Conectarse a la BBDD como superusuario para tener un mayor control de las peticiones que recibe El uso de una API segura para la ejecución de las consultas Introducir un firewall que filtre las peticiones TCP Utilizar una herramienta de análisis de vulnerabilidades.
Un ataque Cross-Site Scripting (XSS) consiste en: El robo de la información de sesión o credenciales por una mala gestión de la sesión del usuario en el código de script Provocar un buffer overflow en un programa o aplicación de tipo script Que un atacante consigue inyectar código malicioso de tipo script en las páginas Web que visita un usuario Conseguir que el usuario ejecute acciones no deseadas cuando está autenticado en una aplicación Web.
Con respecto a un firewall, indica la respuesta VERDADERA: Un firewall únicamente separa dos dominios de seguridad El firewall solo se utiliza para securizar la red perimetral Todo el tráfico desde dentro hacia fuera y viceversa debe pasar a través de un firewall No es una tarea del firewall la monitorización de eventos de seguridad.
Los tipos de firewall según el ámbito de aplicación: Cortafuegos de filtrado de paquetes y de conexión Cortafuegos de red y a nivel de sistema Cortafuegos de nivel de aplicación, red, transporte y aplicación Cortafuegos de filtrado de paquetes, estado de conexiones, gateway de aplicación y proxy de nivel de circuito.
Indica el tipo de firewall que realiza un filtrado basándose en que conoce e interpreta los mensajes a nivel de aplicación Firewall por filtrado de paquetes Firewall por estado de conexión Gateway de nivel de aplicación Proxy de nivel de circuito.
Con respecto a una DMZ, indica la respuesta VERDADERA: La DMZ permite acceso a los servidores Web de la red interna Si el atacante consigue acceder al bastión, entonces tiene acceso a la red interna En la DMZ no se realiza filtrado de paquetes en los routers, solo en los bastiones Desde el exterior solo permite conexiones hacia el bastión .
La tarea de configuración del firewall, ¿dentro de qué parte del ciclo de vida del cortafuegos se encuentra? Diseño Despliegue Gestión Retirada/Sustitución.
¿Cuáles son los ataques, en general, más difíciles de detectar? Los ataques DoS Los ataques a la seguridad perimetral Los ataques basados en Web Los ataques internos.
El tipo de IDS que se basa en detectar variaciones con respecto a patrones se domina: IDS basado en detección de abusos IDS basado en detección de anomalías IDS reactivo IDS proactivo.
Un sistema que se encarga de detectar intrusiones en un equipo final se le denomina: NIDS DNIDS WIDS HDS.
|
