Tipo Test Introducción a la Ingeniería de Software

¿Qué es el software?. Programas de ordenador. Datos. Documentación asociada. Todas las demás son correctas.

¿Qué suele ser más caro en las aplicaciones software complejas?. Desarrollar la aplicación software. Mantener y evolucionar la aplicación software. Enseñar a los usuarios a usar la aplicación software. Todas las demás son correctas.

En relación al software... Se desgasta con el uso. No existen repuestos para el software. Se fabrica, al igual que una casa. Solo consiste en programar.

Un nuevo software se puede crear…. Desarrollando nuevos programas. Reutilizando software existente. Reconfigurando sistemas software genéricos. Todas las demás son correctas.

¿Qué significan las siglas CASE en nuestro contexto?. Computer-Advanced Software Engineering. Computer-Aided Software Engineering. Computation Analogous Software Enterprise. Ninguna de las demás es correcta.

¿Qué es un requisito?. Cada uno de los modelos del software. Los botones de la aplicación. Las historias de usuario. Descripciones de los servicios que un sistema debe proporcionar.

En relación con los requisitos funcionales (RF) y los requisitos no funcionales (RNF): Los RF describen las capacidades del sistema y los RNF sus cualidades. Los RNF describen las capacidades del sistema y los RF sus cualidades. Los RNF expresan siempre parámetros de seguridad. Todas las demás son falsas.

De qué tipo es el siguiente requisito: “Los enfermeros deben poder dar de alta nuevos pacientes.”. Requisito no funcional. Requisito de dominio. Requisito funcional. Requisito alterado.

¿Qué problemas podemos encontrar al definir los requisitos en lenguaje natural?. Ambigüedad. Todas las demás son correctas. Falta de claridad. Demasiada flexibilidad.

¿Para qué se usan las entrevistas en la toma de requisitos?. Para obtener los requisitos del sistema. Para dibujar los modelos. Para realizar las pruebas del software. Todas las demás son ciertas.

¿Qué NO son las historias de usuario?. Todas las demás son correctas. Casos de uso. Escenarios. Informe de errores.

En el contexto de la ingeniería del software, ¿qué es un modelo?. Es una verificación del sistema. Los requisitos. Es una abstracción del sistema. Son las pruebas.

¿Qué son las siglas “UML”?. United Modeling Language. Unified Modeling Language. Unit Model Location. Ninguna de las demás es correcta.

¿Qué tipo de diagrama muestra las clases de objetos en el sistema y las asociaciones entre esas clases?. Diagrama de actividad. Diagrama de clases. Diagrama de secuencia. Diagrama de casos de uso.

El proceso de ingeniería de requisitos involucra las fases (el orden importa): Obtención -> Estudio viabilidad -> Análisis -> Gestión -> Validación. Estudio viabilidad -> Obtención -> Análisis -> Validación -> Gestión. Estudio viabilidad -> Obtención -> Análisis -> Gestión -> Validación. Estudio viabilidad -> Obtención -> Gestión -> Análisis -> Validación.

¿Qué tipo de diagrama muestra las interacciones entre el sistema y su entorno?. Diagrama de casos de uso. Diagrama de estado. Diagrama de actividad. Diagrama de secuencia.

¿Qué tipo de diagrama muestra las interacciones entre los actores y los componentes del sistema?. Diagrama de casos de uso. Diagrama de estado. Diagrama de actividad. Diagrama de secuencia.

En un diagrama de clases, ¿qué tipos de relaciones entre clases son más “fuertes”, de mayor a menor?. Asociación simple > Composición > Agregación. Composición > Agregación > Asociación simple. Herencia > Agregación > Asociación simple. Agregación > Composición > Asociación simple.

Si un coche tiene instalado un motor, ¿con qué tipo de asociación definirías la relación entre las clases Coche y Motor?. Agregación. Asociación simple. Composición. Clase de asociación.

Un banco administra cuentas bancarias, ¿con que tipo de asociación definirías la relación entre Banco y CuentaBancaria?. Agregación. Asociación simple. Composición. Clase de asociación.

¿Cómo se aprende a ser gestor de proyectos?. Estudiando las guías Pressman. Gestionando proyectos. Diseñando y programando en muchos proyectos. Todas las demás son ciertas.

La planificación de un proyecto…. Abarca desde el concepto inicial del proyecto hasta que éste se entrega. Se realiza tras el diseño del software. Se realiza con el cliente. Se suele hacer rápidamente.

Los hitos (milestones)... Son mitos en la ingeniería del software. Son sinónimos de entregables (deliverables). Marcan puntos importantes en el desarrollo del proyecto. Todas las demás son ciertas.

En un camino crítico…. Las tareas se ejecutan en paralelo. Siempre hay 4 tareas. Si se retrasa alguna tarea del camino, se retrasa todo el proyecto. Están las tareas más importantes del proyecto.

¿Qué es un RIESGO en el contexto de la ingeniería del software?. Las circunstancias adversas que pueden ocurrir durante el desarrollo. Los fallos encontrados durante las pruebas. Los problemas que experimentan los desarrolladores. Todas las demás son ciertas.

¿En qué consiste la planificación de los riesgos?. En clasificar los riesgos. En calcular el coste de los riesgos. En considerar cada riesgo y desarrollar una estrategia para manejarlo. Todas las demás son correctas.

La productividad es proporcional al número de personas trabajando en una tarea. Verdadero. Falso.

En el contexto de la ingeniería del software, entender el problema es tarea de…. La ingeniería de requisitos. La implementación del software. El diseño software. La validación y evolución.

En relación con los modelos de procesos software…. Existe un modelo ideal para cada tipo de sistema. Distintos modelos se adaptan a distintos tipos de sistemas. Son útiles porque los procesos software son algo sencillo. Los ágiles son los únicos válidos.

¿Cómo podemos saber si un modelo de proceso software es adecuado?. Por la calidad del producto resultante. Porque el tiempo de entrega y coste se ajustan al previsto. Por la viabilidad a largo plazo del producto que se construye. Todas las demás son correctas.

¿Qué modelo de proceso software es secuencial, desde la especificación hasta su finalización?. Modelo de prototipado. Modelo en cascada. Modelo en espiral. SCRUM.

El manifiesto ágil propone priorizar…. Individuos e iteraciones frente a procesos y herramientas. La respuesta a los cambios frente a seguir un plan inicial. Colaboración con el cliente frente a negociación del contrato. Todas las demás son correctas.

En la metodología SCRUM…. El diseñador siempre tiene la razón. Se involucra al cliente en todo el proceso. Lo importante son los prototipos. Se empieza por la especificación y ser termina por las pruebas.

En SCRUM, el “Product Backlog”…. a)Reúne los requisitos de proyecto priorizados. b) Es abierto y solo puede ser modificado por el product owner. c) Las respuestas a) y b) son correctas. d) Es una lista con los requisitos de cada Sprint.

Un diagrama de estados muestra: Las interacciones entre el sistema y su entorno. Cómo parte del sistema reacciona ante eventos internos o externos. Las interacciones entre los actores y el sistema.

Para especificar los escenarios de un caso de uso en UML podemos usar: (Múltiple opción). Un diagrama de actividad. Un diagrama de casos de uso. Un diagrama de estados. Un diagrama de secuencia.

Cuales de las siguientes pueden ser relaciones entre las clases de un diagrama de clases: (Múltiple opción). Asociación y Enlace. Agregación y Generalización. Asociación y Agregación.

¿Cuál es el propósito de ...? Cómo funciona un caso de uso cuando todo va correctamente. Normalmente, esto es lo que describe el cliente cuando habla sobre el sistema. Camino principal. Requisito. Caso de uso.

¿Cuál es el propósito de ...? Algo que el sistema debe realizar para funcionar correctamente. Camino principal. Requisito. Caso de uso.

¿Cuál es el propósito de ...? Ayuda a obtener buenos requisitos. Cuenta una historia sobre cómo funciona el sistema. Camino principal. Requisito. Caso de uso.

Empareja los principios SOLID con la frase que mejor se refiera a cada uno: "Una clase debería tener un solo motivo para cambiar". Principio de inversión de dependencias. Principio de responsabilidad única. Principio de sustitución de Liskov. Principio abierto-cerrado. Principio de segregación de interfaces.

Empareja los principios SOLID con la frase que mejor se refiera a cada uno: "Depende de abstracciones: no dependas de implementaciones". Principio de inversión de dependencias. Principio de responsabilidad única. Principio de sustitución de Liskov. Principio abierto-cerrado. Principio de segregación de interfaces.

Empareja los principios SOLID con la frase que mejor se refiera a cada uno: "Las clases deben estar abiertas a la extensión y cerradas a la modificación". Principio de inversión de dependencias. Principio de responsabilidad única. Principio de sustitución de Liskov. Principio abierto-cerrado. Principio de segregación de interfaces.

Empareja los principios SOLID con la frase que mejor se refiera a cada uno: "Las subclases deben poder sustituir a las clases sin que el código cliente lo note". Principio de inversión de dependencias. Principio de responsabilidad única. Principio de sustitución de Liskov. Principio abierto-cerrado. Principio de segregación de interfaces.

@After public void method(). Ejecuta method() después de ejecutar todos los test de la clase. Ejecuta method() antes de cada test de la clase. Ejecuta method() después de cada test de la clase. Ejecuta method() antes de ejecutar todos los test de la clase.

@BeforeClass public static void method(). Ejecuta method() después de ejecutar todos los test de la clase. Ejecuta method() antes de cada test de la clase. Ejecuta method() después de cada test de la clase. Ejecuta method() antes de ejecutar todos los test de la clase.

@AfterClass public static void method(). Ejecuta method() después de ejecutar todos los test de la clase. Ejecuta method() antes de cada test de la clase. Ejecuta method() después de cada test de la clase. Ejecuta method() antes de ejecutar todos los test de la clase.

@Before public void method(). Ejecuta method() después de ejecutar todos los test de la clase. Ejecuta method() antes de cada test de la clase. Ejecuta method() después de cada test de la clase. Ejecuta method() antes de ejecutar todos los test de la clase.

La solución que aporta un método ágil para la impredictibilidad que afecta al desarrollo de un proyecto software es: Usar herramientas de modelado gráficas (UML). Adaptabilidad. Aplicación de métodos formales.

Las cuatro clases de la programación extram (XP) son: Comunicación, simplicidad, trabajo en equipo, rigor. Comunicación, simplicidad, retroalimentación, coraje. Comunicación, flexibilidad, coraje, sincronización.

SCRUM es una metodología ágil: De uso frecuente en la práctica. Que se usa marginalmente. Es un modelo de proceso software de tipo teórico.

Un diseño de alta calidad para un componente software (modulo, paquete, subsistema), ¿cuáles de las siguientes características deberá tener? (Múltiple opción). El conjunto de tareas dentro del componente están lógicamente relacionadas. El componente es fácil de probar. El acoplamiento del componente con otros componentes es bajo.

Si la tecnología en la que se basa un proyecto es superada por otra nueva, el riesgo de que esto ocurra afecta al: Proyecto. Producto. Negocio.

Si queremos hacer un test en el que intervenga una interfaz hemos: Usar Mocking. Crear una clase que implemente la interfaz. Usar JUnit.

La idea básica de las pruebas de caja blanca es: Asegurar que no existen bucles sin fin ni interbloqueos en el caso de programas concurrentes. Comprobar que al menos el 90% de las sentencias y condiciones han sido ejecutadas al menos una vez. Asegurar que todas las sentencias y condiciones han sido ejecutadas al menos una vez.

De los siguientes problemas, indique cuáles se producen durante la obtención de requisitos al tratar con los participantes (stakeholders): (Múltiple opción). Durante el propio procesos de análisis, hay requisitos que cambien porque cambie el entorno del negocio. Conocen realmente lo que desean. Hay requisitos que entran en conflicto, según el grupo de la organización que lo solicite o defina. Expresan los requisitos en su jerga del dominio.

Durante la obtención de los requisitos para un sistema, los clientes plantean que los usuarios tengan identificador y clave de acceso. Suponen, porque es lo habitual, que las claves se almacenan encriptadas en el sistema, pero nunca lo expresan ni comunican a los analistas de la empresa que desarrollará el software. El requisito de almacenar las claves encriptadas es un…. Requisito externo. Requisito implícito. Requisito de la organización.

Cuando un caso de uso siempre necesita la realización de otro caso de uso, la relación que existe entre ellos es de: Generalización. Inclusión (include). Extensión (extend).

Para añadir detalle a un caso de uso, se debe utilizar: Un diagrama de estados. Un diagrama de secuencia. Un diagrama de clases.

La ingeniería de requisitos trata de: Entender el problema. Plantear una primera solución al problema (prototipo). Plantear un plan para resolver el problema.

El tiempo de respuesta es un requisito de tipo: No funcional. Funcional. Del dominio.

Los componentes de una arquitectura software son: Componentes, patrones y conectores. Componentes, conectores y configuración. Cliente, servidor y capas.

Tres ejemplos de arquitectura software son: Cliente/servidor, Singleton, orientado a objetos. Cliente/servidor, MapReduce, Capas. Capas, orientado a objetos, maestro/esclavo.

En la arquitectura de tuberías, la información se procesa según esquema de: Flujo de datos. Flujo de tareas. Flujo de control.

El esquema MapReduce se usa para: Procesamiento masivo de procesos. Procesamiento en la nube. Procesamiento masivo de datos.

Los patrones de diseño se pueden clasificar en tres tipos, que son: Creación, estructurales y de comportamiento. Estructurasles, creación y de pruebas. Creación, arquitectura y de comportamiento.

¿Qué definición se ajusta mejor a patrón de diseño?. Es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el contexto, y los principios que orientan su diseño y evolución. Son bibliotecas de clases probadas y sin errores aplicables aun determinado tipo de problemas. Una solución probada que se puede aplicar a un determinado tipo de problemas que se repiten en el desarrollo software. Son los puntos de acceso a los módulos o sistemas de comunicación.

La siguiente lista es una serie de Estilos arquitectónico y Patrones de diseño. Indique cuales son patrones de diseño: Tubería filtro. Peer to peer. Factoría abstracta. Fachada. Singleton. Por capas. Delegación. Cliente servidor.

El diseño por contrato es una técnica orientada a asegurar el principio SOLID. Principio de sustitución de Liskov. Principio de segregación de interfaces. Principio de responsabilidad única. Principio Abierto-Cerrado.

¿Cuáles de las siguientes características son indicativas de un buen diseño? (Múltiple opción). Implementa todos los requisitos del modelo de análisis. Incluye casos de prueba para todos los componentes. Presenta un fuerte acoplamiento entre sus módulos. Se puede adaptar a nuevas situaciones con facilidad.

¿Qué actividad no forma parte de la gestión de proyectos?. Selección y evaluación del personal. Planificación y programación temporal. Modelado del sistema a desarrollar.

La interfaz debe seguir la normativa de colores e imagen corporativa de la empresa: Requisito Funcional. Requisito No Funcional del producto. Requisito No Funcional de la organización. Requisito No Funcional externo.

Durante un proyecto de desarrollo software se detectaron dos errores de los requisitos. Uno se detectó durante la fase de requisitos y el otro durante la fase de implementación. ¿Cuál de las siguientes afirmaciones es probablemente más cierta?. El error más costoso de corregir es el detectado durante la fase de implementación. No hay relación entre la fase en la que se detecta un error y su coste de reparación. El error más costoso de corregir es el detectado durante la fase de requisitos. El coste de arreglar cualquiera de los errores será aproximadamente similar.

¿En qué actividad del proceso de desarrollo software se establecen las restricciones en el funcionamiento del sistema?. Evolución del software. Validación del software. Diseño e implementación del software. Especificación software.

¿Qué características son aplicables al modelo en cascada?. El cliente ve rápidamente un resultado aproximado de su producto. Los proyectos rara vez siguen un modelo secuencial. Es el mas antiguo. El cliente debe exponer sus requisitos al principio del proceso.

De los siguientes modelos, ¿Cuál no es evolutivo?. Modelo en cascada. Modelo Espiral. SCRUM.

A diferencia de la Ingeniería de Caminos, en la Ingeniería del Software: Los equipos de trabajo están compuestos de gente con distinto perfil. El producto resultante no se desgasta por el uso. El tamaño importa.

Cuando se habla de fiabilidad del software, se hace referencia a: Los recursos que utiliza el software no son malgastados. Es aceptado por los usuarios finales, no los desarrolladores. Puede evolucionar hacia nuevas necesidades. Está libre de errores.

Los diagramas de actividad: Muestran las interacciones entre el sistema y su entorno. Muestran interacciones entre los actores, el sistema y los componentes. Muestran cómo el sistema reacciona ante eventos internos o externos. Muestran las actividades implicadas en un proceso o en un procesamiento de datos.

Un caso de prueba es: Un conjunto de condiciones que ayuda a determinar si se cumplen o no los requisitos. Un caso de uso que se implementa para probar otros casos de uso más importantes. El resultado de una ejecución en la que se han detectado errores en el sistema.

Un requisito no funcional de fiabilidad: Se trata en la parte del diseño detallado, no en la del diseño de alto nivel. Debe resolverse en la parte de análisis, no en la de diseño. Puede afectar al diseño exigiendo redundancia de elementos.

El uso del lenguaje natural para describir requisitos: Se puede admitir para describir versiones preliminares de los requisitos. Ayuda a comunicarse al analista y a los desarrolladores al evitar ambigüedades. Facilita la separación de los aspectos funcionales y los no funcionales.

Un módulo con un acoplamiento alto con otro muchos módulos: Hace más difícil que se pueda reutilizar ese módulo en otro entorno. Permite implementar el sistema con un número menor de módulos. Posibilita que ese módulo sea más versátil.

Si en un diagrama de clases las clases A y B están relacionadas mediante un asociación con cardinales en los extremos de muchos a muchos, quiere decir: Que un objeto de la clase A puede estar asociado en un momento dado con varios objetos de la clase B. Que un objeto de la clase A solo puede estar asociado con un objeto de la clase B, pero que se puede instanciar muchos objetos de las clase A y de las clase B. Que un objeto de la clase B puede estar asociado con varios objetos de la clase A a lo largo de su ciclo de vida, pero con solo uno en cada momento de su ciclo de vida.

La ingeniería del software: Permite que los ingenieros y los desarrolladores hablen un lenguaje común. Ha conseguido que los sistemas software se puedan aplicar al campo de la ingeniería. Aplica técnicas rigurosas al desarrollo de sistemas software para mejorar el proceso de desarrollo.

Para consolidar las modificaciones hechas en el repositorio local se usa: git commit. git consolide. git write.

En el patrón Modelo-Vista-Controlador la función principal del controlador es: Mostrar al usuario los informes generados por el sistema. Encapsula los datos del sistema que se guardan de forma persistente. Implementar la lógica de negocio del sistema.

El patrón Estrategia ayuda a cumplir el principio de: Responsabilidad única. Sustitución de Liskov. Segregación de interfaces.

La completitud de una lista de requisitos se refiere a: Que cada uno de los requisitos está descrito con detalle. Que se ha definido para cada requisito funcional su requisito no funcional asociado. Que describen todas las necesidades e intereses de los participantes.

El modelo en cascada es apropiado para: Productos que están destinados al público en general. Proyectos pequeños y con pocos cambios en los requisitos. c)Proyectos en los que los cambios en los requisitos los deciden los desarrolladores.

Un ejemplo típico de requisito del dominio puede ser: Permitir que un usuario autenticado acceda a sus mensajes. Construir un modelo del dominio con clases que entienda el cliente. Seguir las normas contables nacionales en un programa de contabilidad.

La complejidad ciclomática de un segmento de código indica: El número de cambios base de ese segmento de código. La relación entre el número de errores encontrados y el número de líneas de código. El número de bucles anidados que hay en ese segmento de código.

En un desarrollo bajo control de GIT, una fuente de conflictos habitual es: Que un desarrollador haga commit en su repositorio local. Que dos desarrolladores modifiquen el mismo archivo. Que un desarrollador encuentre un error en una prueba unitaria en su repositorio local.

En la terminología de pruebas, los caminos base son: Los caminos de ejecución de un código que ya han sido probados. Los posibles secuencias fundamentales de ejecución de un código. El conjunto de instrucciones que están incluidos en una sentencia condicional o un bucle.

En una prueba de caja negra solo: Se ejecutan pruebas unitarias que se puedan automatizar. Se prueban los módulo que interaccionan directamente con el usuario. Se ejecutan pruebas del funcionamiento del sistema sin conocer el diseño ni la implementación.

Un prototipo puede usarse: Para añadir modificaciones a los requisitos funcionales iniciales. Para sacar al mercado un producto con funcionalidades adicionales. Dividir el desarrollo en miniproyectos, del que cada uno resulta una versión parcial funcional.

Los cambios en los requisitos de los clientes: Se pueden abordar en los desarrollos, pero es importante seguir una metodología apropiada. Se deben rechazar porque el cliente ha firmado un contrato inicial con la empresa de desarrollo. Son rápidos de incluir en el desarrollo porque el software es fácilmente modificable.

Los requisitos no funcionales. Se emplean para especificar la respuesta del sistema cuando se eleva una excepción. Suelen indicar cuestiones relacionadas con los criterios de calidad del sistema. Habitualmente se implementan en las primeras iteraciones.

En una arquitectura basada en objetos, los objetos se comunican enviándose mensajes. La implementación más habitual de estos envíos de mensajes es: Elevación de excepciones. Definición de interfaces. Llamadas a métodos.

La cobertura de un conjunto de pruebas indica: El porcentaje de código que se ejecuta en las pruebas. El código cubierto que está completamente libre de errores. El número de errores que se ha encontrado por cada módulo del sistema.

Un caso de uso se indica: Una descripción detallada de la interacción entre el usuario y el sistema. El conjunto de requisitos no funcionales asociados al caso de uso. Una descripción del interfaz de usuario en el que se ejecutará el caso de uso.

En el desarrollo dirigido por pruebas (TDD): El cliente es el responsable de probar el sistema antes de que se implemente el código. Las pruebas se escriben y se ejecutan antes de que se implemente el código que se va a probar. Es el equipo de pruebas el que define los requisitos funcionales que ha de ejecutar el sistema.

Un ejemplo de requisito no funcional es: Si el usuario publica un comentario ofensivo, se bloqueará su cuenta. El estilo de las páginas web seguirá las guías de estilo de la empresa. Hay tres tipos de envíos: normal, urgente y exprés.

Los ingenieros de tres empresas de producción de software tienen formas de trabajar diferentes. ¿Cuál de ellas sigue un enfoque de ingeniería del software?. Los ingenieros no siguen ningún proceso concreto, simplemente consultan a su supervisor por la tarea que tienen asignada. Los ingenieros ejecutan las tareas que les asignan diariamente los clientes del proyecto. Los ingenieros adoptan una forma de trabajo sistemática y organizada.

La ingeniería del software cobra especial interés: Cuando se desarrolla software para un cliente particular. Cuando se desarrolla software destinado para un mercado general. Es igualmente necesaria independientemente del destinatario del software.

Según la Ingeniería del Software: Es necesario encontrar un equilibrio entre los recursos disponibles para un proyecto y los resultados que se pueden entregar. Cuando se llega al plazo final de un proyecto hay que cerrarlo en el estado en el que está. Hay que entregar un sistema completamente libre de errores aunque implique superar el presupuesto y el plazo.

Un cliente con el que hemos trabajado durante los últimos cinco años quiere ampliar parcialmente el último sistema que le desarrollamos. Según el estudio inicial, harán falta 3 personas durante 2 meses. Por tanto: Como es un proyecto que necesita muchas pruebas de aceptación, el Proceso Unificado es el más aconsejable. Se puede plantear sin problema con una metodología en cascada porque ya tenemos experiencia y no es complejo. Vamos a escoger una metodología ágil porque no tendremos que ver al cliente durante esos dos meses.

El cliente del nuevo proyecto nos ha avisado de que no será posible reunirse personalmente con frecuencia con los desarrolladores para detallar las historias de usuario cuando empiecen a implementarlas. En ese caso: Se puede usar una metodología iterativa usando herramientas alternativas para detallar las historias de usuario, como casos de uso o reuniones telefónicas. Lo más apropiado es seguir la Programación Extrema, para que puedan ser los desarrolladores quienes definan los casos de prueba unitarios y los de aceptación. Es más conveniente usar una metodología en cascada, con todo el análisis de requisitos al inicio.

Las estimaciones sobre el nuevo sistema que se va a desarrollar en la empresa indican que se va a tardar 30 meses en desarrollarlo, que implicará a 5 de los 7 departamentos de la empresa y que va a suponer un cambio estratégico en el funcionamiento del sistema de la empresa. La metodología de desarrollo que se debería usar es: Ágil, para poder empezar el desarrollo sin tener que hacer análisis de requisitos. Iterativo, porque se pueden incluir mejor los cambios en los requisitos. En cascada, para garantizar que se definen correctamente todos los requisitos antes de implementar.

Hemos desarrollado un prototipo rápido para acordar la interfaz gráfica de usuario para algunos de los requisitos de la siguiente iteración. Al cliente le gusta el aspecto resultante y nos pide incluir el prototipo en el sistema final: Le aconsejamos al cliente no usar el prototipo porque no cumple los criterios de calidad del proyecto. Lo incluimos porque el cliente siempre tiene razón. Lo incluimos aunque no cumpla los criterios de calidad si el proyecto va con retraso.

Como los flujos de trabajo que se hacen en cada iteración coinciden con los flujos de trabajo de la metodología en cascada, el jefe de proyecto ha decidido hacer dos iteraciones de un año en el nuevo proyecto. Esta decisión: Es adecuada porque permite definir con más calma las pruebas de integración y de aceptación. No es adecuada porque aumenta los riesgos porque las iteraciones se aplican a una parte mucho mayor del sistema. Es adecuada porque reduce el tiempo de comunicación y coordinación con el cliente.

Un cliente que quiere que se le construya un sistema informático para una entidad financiera, ha empleado una fórmula matemática en la definición del requisito funcional del cálculo del riesgo a la hora de conceder un préstamo. Es una buena práctica usar esa fórmula, ya que de esa forma se tiene una definición más precisa del requisito. No es una buena idea usar esa fórmula. Las fórmulas se deben reservar para describir requisitos no funcionales detallados. Es muy posible que el equipo de desarrollo no estará familiarizado con ese tipo de fórmulas, por lo que esa fórmula no se puede tener en cuenta al implementar el requisito.

El cliente para el que se va a desarrollar el software ha pedido que el aseguramiento de la calidad del software se siga la norma de ISO 9126. Sin embargo, el jefe del equipo de desarrollo mantiene que van a usar la norma IEEE 730-1998 porque es la que ellos usan habitualmente en sus proyectos. ¿Cuál debe ser la norma que se siga?. Como los requisitos de proyecto no pueden contradecir a los de la organización, se usará la norma ISO 9126. Como los requisitos de proyecto son prioritarios, se usará la norma IEEE 730-1998. Como ambas normas son similares, se puede usar tanto una como la otra.

Si el analista detecta que dos requisitos incoherentes entre sí: Se implementará el requisito que pase antes las pruebas. Debe discutir con el cliente cuál será el requisito que se elimine. Debe escoger el requisito que sea más rápido de implementar.

En un sitio web se permiten varios tipos de autenticación: por DNI electrónico, por usuario/contraseña y por referencia enviada al móvil. El caso de uso "Autenticación" tendrá un relación "extends" con los otros tres casos de uso para asegurar que el usuario puede escoger su opción preferida. Es necesario definir tres tipos de usuario, uno por cada tipo de autenticación, para evitar de ese modo accesos no permitidos. Si el caso de uso "Autenticación" no tiene muchas acciones por sí mismo, los casos de uso de cada tipo de autenticación deben especializar el caso de uso "Autenticación".

Desde el punto de vista arquitectónico, un navegador web: Ejecuta la función de servidor, porque da servicio al usuario, que es el cliente. Ejecuta la función de cliente cuando accede a la página que le pide el usuario y de servidor cuando le muestra el contenido de la página. Ejecuta la función de cliente, que se conecta a un servidor remoto.

Un sistema para compartir archivos como Dropbox: Tiene una arquitectura cliente/servidor. Tiene una arquitectura basada en capas. Tiene una arquitectura basada en filtros y tuberías.

Un sistema informático de análisis taxonómico de proteínas obtiene datos de un experimento de secuenciación de una muestra metagenómica. Esos datos son pasados al módulo de alineamiento, que las alinea con las proteínas presentes en una base de datos. Los alineamientos resultantes sirven de entrada al módulo de asignación taxonómica, que produce un informe con el análisis taxonómico. Este sistema tiene una arquitectura basada en: Cliente/servidor. Filtros y tuberías. Capas.

El patrón Modelo-Vista-Controlador es un caso particular de: Arquitectura basada en capas. Arquitectura basada en filtros y tuberías. Arquitectura basada en Map-Reduce.

Un cuadro de texto acepta valores numéricos en el rango de 18 a 25 ambos incluidos. Identifique cuales de los siguientes valores pertenecen a la misma clase de partición de equivalencia: {17,15,-5}. {18,19,23}. {17,18,19}.

¿Por qué es necesaria la ingeniería del software?. Realmente no es necesaria. Los desarrolladores experimentados no precisan de la ingeniería del software para la producción del mismo. Porque el software suele ser un producto complejo que implica la participación de personal cualificado y que hay que producir con un coste adecuado. Porque cualquier ingeniero de cualquier tipo que siga sus actividades puede producir software de alta calidad.

El principal objetivo de los ingenieros de software es producir software de calidad. Esto quiere decir que: Tienen que procurar producir un software lo más completo posible para minimizar posibles actualizaciones futuras. Los ingenieros determinarán cuáles son los criterios de calidad que tiene que cumplir el sistema requerido por el cliente. Tienen que producir un software que además de cumplir con las funciones del cliente, tenga otras características tales como: mantenibilidad, fiabilidad, eficiencia y adaptación.

Cuál de las siguientes afirmaciones es cierta: Cada vez que se produce un cambio en el software, puede haber un incremento del índice de fallos. Cuando un componente software se deteriora, basta con reemplazarlo por otro igual. Los programas software funcionan y son útiles indefinidamente porque no se desgastan ni dependen de su entorno.

En el proyecto actual estamos usando una metodología en cascada. En la fase de diseño se ha descubierto un error en la especificación de los requisitos. ¿Cómo debemos proceder?. Parar el diseño, arreglar el error en los requisitos y revisar los modelos de análisis y diseño que dependen de esos requisitos. Continuar el desarrollo hasta la implementación y prueba de la primera versión del sistema y posteriormente arreglar el error en los requisitos. Rehacer el diseño para que se ajuste a los requisitos porque la especificación de requisitos está, con seguridad, libre de errores.

En el segundo día de la iteración actual, uno de los tres desarrolladores del grupo ha caído enfermo, y tardará un mes en volver. ¿Qué decisión debe tomar el jefe de proyecto?. Informar al cliente y negociar una reducción del alcance de la iteración. Retrasar la iteración hasta que se incorpore el desarrollador enfermo. Incorporar dos nuevos desarrolladores al equipo para suplir al miembro enfermo.

En medio de una iteración del proyecto actual, en el que estamos usando Scrum, el cliente ha insistido en incluir tres nuevos requisitos. ¿Qué decisión debe tomar el Dueño del Producto (Product Owner) tras evaluar el coste de los nuevos requisitos?. Alargar la duración de la iteración el tiempo necesario. Incluir un nuevo desarrollador en el equipo que se encargue de los nuevos requisitos. Sustituir algunos de los requisitos que estaban planeados y que aún no se habían implementado.

Hemos desarrollado un prototipo rápido para acordar la interfaz gráfica de usuario para algunos de los requisitos de la siguiente iteración. Al cliente le gusta el aspecto resultante y nos pide incluir el prototipo en el sistema final: Le aconsejamos al cliente no usar el prototipo porque no cumple los criterios de calidad del proyecto. Lo incluimos aunque no cumpla los criterios de calidad si el proyecto va con retraso. Lo incluimos porque el cliente siempre tiene razón.

La arquitectura Map-Reduce está especialmente indicada para: Trabajar en sistemas con arquitectura Modelo-Vista-Controlador. Resolver problemas que se pueden resolver con proceso masivo en paralelo. Reducir el espacio de trabajo de un problema muy complejo.

En la arquitectura basada en llamada y retorno funcional: El código de las funciones son los conectores del sistema. Las funciones deben conectarse mediante variables globales. Las llamadas a funciones son los conectores del sistema.

En una arquitectura por capas: Los elementos de una capa acceden a los servicios de los elementos de las capas inferiores con una arquitectura basada en filtros y tuberías. Los elementos de una capa ofrecen servicios a los elemento de las capas superiores. Los servicios que ofrece una capa no dependen de los servicios que ofrecen las capas inferiores.

Uno de los inconvenientes de la arquitectura de tuberías y filtros es: Que es difícil conectar un filtro con el siguiente mediante tuberías. Que es difícil tratar una excepción que ocurra en mitad de la cadena de filtros. Que los filtros solo pueden procesar archivos de texto.

Dividir un sistema de módulos: Permite definir el espacio de diseño del sistema. Facilita la resolución del problema. Es aconsejable solo para arquitecturas Modelo-Vista-Controlador.

El principio de segregación de interfaces permite: Que una clase dependa de menos clases externas. Evitar que una clase dependa de métodos que no usa. Aumentar el número de métodos que implementa una clase.

Una forma de extender un módulo que cumple el principio de abierto/cerrado: Es añadir una nueva clase que implemente un interfaz usado por una clase cliente. Es añadir una nueva condición a una sentencia if-else encadenada. Es añadir una nueva rama a una sentencia switch de un método de una clase.

La cohesión de un sistema: Es difícil de mantener alta porque los elementos de un módulo no deben interaccionar entre sí. Es aconsejable mantenerla baja para que se cumplan los criterios de calidad del sistema. Es conveniente mantenerla alta para que los módulos tengan una función específica.

El patrón Singular: El constructor se define privado, para que solo pueda instanciar la misma clase. El constructor se define público, con un contador de las instancias que ya se han creado. El constructor mantiene una lista de las instancias que están activas.

Si un programa pasa todas las pruebas a las que se le somete: Es una demostración de que el conjunto de pruebas se ha diseñado bien. Se puede asegurar que todos los requisitos funcionales se han implementado correctamente. No podemos afirmar que esté libre de errores.

Cuando un programa pasa positivamente todas las pruebas a las que se le somete, cuales de las siguientes frases son falsas: No se puede asegurar que el software esté libre de errores. Se puede asegurar que todos los requisitos funcionales se han implementado correctamente. El software está libre de errores.

Un requisito no funcional de alto nivel de abstracción (conocido como meta) sirve para: Identificar cuáles son los requisitos funcionales de alto nivel. Definir una métrica para hacer pruebas unitarias de requisitos. Transmitir las prioridades de los clientes y usuarios.

En las metodologías iterativas: Los clientes se encargar de indicar los cambios en los requisitos durante la iteración. Es aconsejable revisar los requisitos después de implementar cada uno. Se recomienda no hacer cambios en los requisitos durante una iteración.

La arquitectura por capas. Favorece la cohesión alta de elementos de distintas capas porque implementan los mismos requisitos funcionales. Favorece el acoplamiento alto de elementos de una misma capa porque cada capa se conecta con la inferior y la superior. Favorece la cohesión alta de los elementos de una misma capa porque tienen funciones relacionadas.

Un escenario de un caso de uso: Especifica cuáles son las partes interesadas y sus necesidades e intereses. Detalla los tipos de datos y las relaciones entre los distintos tipos de datos. Indica cuáles son las acciones en una de las posibles situaciones que se ejecute en un caso de uso.

Un proceso de desarrollo software indica: Las actividades y el orden en el que se deben hacer en el desarrollo. Las tecnologías que se van a usar en el desarrollo del producto. Cuáles van a ser los miembros del equipo de desarrollo del producto.

El principio de responsabilidad única establece que: Una clase debe depender de un única clase externa. En un sistema debe haber una clase que tenga toda la responsabilidad del sistema. Una clase debe centrarse en realizar un sola tarea.

Entre las actividades habituales de un proceso de desarrollo están: Arranque, estabilización y parada. Recepción, habilitación y manufactura. Especificación, desarrollo y validación.

En SCRUM, la reunión diaria sirve, entre otras cosas: Para que los desarrolladores expongan si tienen algún problema. Para entregar una nueva versión a los clientes. Para que los clientes introduzcan cambios en los requisitos.

En el modelo en cascada: No se genera ninguna documentación hasta después de haber completado la implementación. Se van intercalando ciclos de implementación y de documentación. No se inicia una fase hasta tener completamente terminada la anterior.

El objetivo básico del patrón Singular es: Reducir el acoplamiento entre clases. Controlar el número de instancias que se crean de una clase. Proporcionar un mecanismo global de comunicación de datos entre clases.

Las pruebas de aceptación las ejecuta: Los desarrolladores para aceptar nuevos requisitos funcionales por parte del analista. El cliente para aceptar la entrega de una nueva versión del sistema por parte del equipo de desarrollo. El analista para validar que los requisitos funcionales del cliente son correctos.

Los requisitos de un sistema software: Especifican cuáles son las funciones que el sistema necesita de otro sistema externo. Indican cuáles son las características que debe cumplir el sistema. Están más indicados en los proyectos en los que no hay comunicación fluida con el cliente.

Los requisitos deben ser consistentes, lo que implica que: La descripción de todos los servicios y funciones deben estar definidos. No deben existir conflictos o contradicciones en la descripción de las funciones del sistema. Todos los componentes del sistema software deben estar bien definidos.

De las siguientes actividades indique cuáles se producen durante el proceso de especificación del software (Ingeniería de requisitos): (Seleccione una o más de una). Pruebas de aceptación. Diseño arquitectónico. Mantenimiento del software. Validación de requisitos. Elicitación de requisitos. Estudio de viabilidad. Programación y depuración del código. Diseño del interfaz.

Una empresa de producción de Software recibe el encargo de realizar un proyecto de gran envergadura que involucra a varios equipos de desarrollo durante un periodo de varios meses de trabajo. Siguiendo un enfoque de ingeniería del Software, ¿cómo deberían de abordar el proyecto?. Seleccionando un modelo de proceso software y siguiéndolo puntualmente. Seleccionando un modelo de proceso software y adaptándolo a las necesidades del proyecto y de la empresa. No es conveniente considerar ningún modelo de proceso software para este tipo de proyecto, pues ralentizaría el proceso de producción.

Una empresa debe estimar el coste de producción de un software personalizado para un cliente particular. Según conversaciones con el cliente, se pretende dar soporte a dicho software durante un periodo a los 5 años. Bajo estas circunstancias, ¿cómo se espera que esté distribuido el coste total?. Los costes de evolución suelen superar a los costes de desarrollo. Los costes de desarrollo suelen equipararse a los costes de evolución. Los costes de desarrollo suelen superar a los costes de evolución.

En el siguiente desarrollo vamos a usar la Programación Extrema: Gracias a la propiedad compartida del código, facilitaremos la comunicación con los clientes. No podremos usar la programación extrema porque los clientes no tienen conocimientos técnicos. Intentaremos que en las parejas de programadores haya uno más experto y otro más novato.

El principio de inversión de dependencias: Permite reducir el acoplamiento de clases de alto nivel de abstracción respecto a clases más concretas. Permite cambiar el sentido de una relación de herencia si el acoplamiento entre ambas clases es alto. Permite cambiar el sentido de una asociación de una clase a otra si el acoplamiento entre ambas es alto.

El patrón Estrategia nos permite: Evitar tener que cambiar una clase cliente por el hecho de que hayamos extendido el comportamiento de la clase de la que depende. Aplicar el principio de refactorización de Liskov. Evitar tener que aplicar el principio de segregación de interfaces.

En una prueba de caja blanca: El usuario sólo prueba los requisitos funcionales de alto nivel. El sistema tiene que proporcionar el resultado antes de un límite de tiempo. Se prueba el sistema sabiendo cuál es su estructura interna y su código.

La mejor forma de describir el siguiente requisito no funcional es: "El sistema debe poder dar una respuesta en menos de un segundo”, porque permite definir pruebas para validarlo. “El sistema debe responder rápido”, porque de esa forma lo entiende mejor el cliente. “El tiempo de respuesta del sistema puede variar en función del tamaño de la entrada”, porque permite un abanico más amplio de soluciones.

En el análisis de requisitos del nuevo sistema, cuyo desarrollo se va a hacer de manera iterativa, el cliente ha pedido un requisito que es “Manejo de los pagos a proveedores”. ¿Qué debe hacer el analista?. Pedirle que detalle todos los requisitos de usuario relacionados con ese requisito, para poder hacer una planificación global del desarrollo. Proponerle al cliente cuáles serán los requisitos de nivel de usuario relacionados con ese requisito. Si el cliente lo ha puesto en la categoría de requisitos de poca importancia, se puede iniciar el desarrollo y detallarlo más tarde, en una iteración posterior.

Respecto a los desarrollos industriales, en los desarrollos software: El porcentaje de trabajo que se emplea en hacer pruebas es mayor porque el software es etéreo y no se puede probar fácilmente. El coste unitario de cada copia del software es mucho menor porque es más fácil hacer copias. Los cambios introducidos en un producto existente están libres de errores.

En el desarrollo dirigido por pruebas, por norma general: Dependiendo del requisito a implementar, las pruebas se codifican antes o después que el código. Las pruebas se codifican después que el código. Las pruebas se codifican antes que el código.

Un software de reconocimiento facial usa una cámara RGB-D. Cuando la persona está a menos de 1.8 metros lanza una excepción notificando que la persona está muy cerca, cuando una persona está a una distancia superior a 2.4 metros, lanza una excepción notificando que la persona está muy lejos. Entre estos valores, la detección facial se realiza correctamente. Identifique cuales de los siguientes valores pertenecen a la misma clase de partición de equivalencia. Seleccione una o más: {1.79, 1.92, 2.05}. {1.81, 2.39, 2.4}. {-1.81, 2.05, 2.41}. {1.80, 2.05, 2.39}.

En los diagramas de clases de UML, para indicar en un extremo de una asociación que la relación es opcional se usa: 1…?. 1…*. 0…1.

Un diagrama de secuencia en UML: Modela el comportamiento de una determinada clase. Modela la interacción entre componentes del sistema. Modela la estructura estática del sistema.

El uso del patrón Método Fábrica (Factory Method): Permite a una clase cliente crear instancias de una clase implementada con el patrón Singular. Permite a una clase cliente construir instancias de un interfaz o de una clase abstracta. Permite a una clase cliente no estar acoplada con una clase concreta a la hora de crear nuevas instancias.

En el análisis de requisitos de un sistema, el analista ha detectado que un cliente ha pedido “que el inicio de sesión en el sistema se haga exclusivamente mediante certificado digital”, mientras que otro cliente ha pedido “que el inicio de sesión en el sistema se haga exclusivamente con el sistema Active Directory Domain que ya tiene implementado la empresa”. Para resolver el conflicto, el analista debe: Plantear el conflicto a los clientes y proporcionales la información necesaria para que ellos decidan. Incluir ambos requisitos funcionales en el sistema. Elegir la opción “Active Directory Domain” porque ya está implementada.

En los diagramas de clases de UML, una asociación de composición se representa con: Un rombo blanco. Un rombo negro. Un triángulo.

¿Cuál de los siguientes analistas lo ha hecho mejor?. El analista C ha hecho una primera descripción de los requisitos funcionales con lenguaje natural y una descripción posterior con lenguaje natural estructurado. El analista B ha descrito tanto los objetivos globales del sistema como los requisitos funcionales detallados a nivel de usuario con lenguaje natural para que el usuario los entienda mejor. El analista A ha descrito los objetivos globales del sistema en lenguaje natural estructurado y los requisitos funcionales detallados a nivel de usuario los ha descrito como lenguaje natural.

El patrón Estrategia se basa en: Usar la vinculación dinámica para escoger la versión adecuada de un algoritmo en tiempo de ejecución. Dividir la responsabilidad del método en varias clases usando la estrategia de “divide y vencerás”. Probar varias estrategias hasta conseguir la respuesta que necesita la clase cliente.

En los diagramas de clases de UML, una asociación de agregación se representa con: Un triangulo. Un rombo negro. Un rombo blanco.

En el pliego de contratación de la nueva web del Senado de España se incluye el requisito “Dada la naturaleza de este sistema de información, es requisito indispensable que la solución trabaje en alta disponibilidad”. Es un buen requisito, permite a los desarrolladores escoger la solución que crean más conveniente. Es un mal requisito, es ambiguo, por lo que la solución dada puede no gustar al cliente. Es un requisito que se definirá de forma más detallada creando nuevos requisitos funcionales.

Una de las ventajas de la arquitectura basada en objetos sobre la arquitectura de llamada y retorno funcional es que: Las funciones representan elementos del mundo real. Los datos están mejor encapsulados. Los objetos no dependen de otros objetos.

¿Qué es un proceso software?. La evolución del software. Actividades cuyo objetivo es el desarrollo/evolución de un sistema software. El modelado del software para su posterior implementación. Pruebas sobre el software para comprobar su correcto funcionamiento.

¿Para qué sirven las clases de asociación en un diagrama de clases?. Para poder indicar los roles de asociación. Para definir las propiedades de asociación. Para indicar la multiplicidad de forma correcta. Todas las demás son falsas.

¿Qué son las pruebas del software?. Un método para demostrar que no hay errores. Un método para demostrar que el software es liviano. Un método para demostrar que el software funciona correctamente. Todas las demás son falsas.

¿Qué consideramos un buen caso de prueba?. Aquel que tiene una alta probabilidad de encontrar un error. El que se ejecuta rápidamente. Aquel que está escrito en JUnit. El que implementamos en Phyton.

¿Qué tratan de probar las pruebas unitarias?. El sistema completo. Varios componentes a la vez. Componentes aislados. Todas las demás son ciertas.

Las pruebas de caja blanca... Comprueba el funcionamiento interno y la lógica del código. Son pruebas guiadas por los datos de entrada y salida. No tienen en cuenta los detalles de implementación. Se escriben en Java.

En el "Test-Driven Development"... Se prueba el sistema completo. Se usa C++. Se usa Java. Se escriben las pruebas antes de escribir el código.

¿De qué tratan las particiones de equivalencia?. De probar el sistema con caja blanca. De partir el software en métodos. De dividir el dominio de entrada de un programa en clases de datos. Todas las demás son falsas.

¿Dónde tienden a darse más errores?. En los constructores. En las condiciones. En las bibliotecas importadas. En los valores límite de los datos de entrada.

¿Qué indica la complejidad ciclomática de un programa?. El número de líneas de código. El número de caminos base de un grafo de ejecución de un programa. El número de clases de un programa. El número de clases y métodos de un programa.

¿Qué significa la notación @BeforeEach en un método en JUnit 5?. Que el método se ejecuta una sola vez antes de todas las pruebas unitarias. Que el método de ejecuta después de todas las pruebas. Que el método implementa una prueba unitaria. Que el método se ejecuta siempre antes de cada prueba unitaria.

¿Cuál es la complejidad ciclomática del siguiente algoritmo? public static int minElevado(int n1, int n2, int e){ int resultado = 1; int cont = 0; int min = n1; if(n1>n2){ min = n2; } while(cont < e){ resultado *= min; cont++; } return resultado; }.

Dado el siguiente código: public final class String2Double{ public static boolean esNuloOVacio(String st){ return (st == null || st.compare("v") == 0); } Y la siguiente prueba JUnit5: @Test public void testesNuloOVacio(){ String input = null; assertTrue(String2Double.esNuloOVacio(input)); input = "abc"; assertFalse(String2Double.esNuloOVacio(input)); input = " "; assertTrue(String2Double.esNuloOVacio(input)); } Revisa su funcionamiento y responde a la siguiente pregunta: ¿Cuántos asserts pasan correctamente?. 1. 2. 3. 0.

Un cuadro de texto acepta valores numéricos en el rango 18 a 25 inclusive. Identifica las particiones o clases de equivalencia válidas: Valores entre 18 y 25. Valores mayores que 25. Valores menores que 18.

En el diagrama de clases de la figura: En los objetos de la clase A habrá una colección de referencias a objetos de la clase B. Hay que introducir una clase intermedia para normalizar el diagrama de clases. Los objetos de la clase B se encargan de crear los objetos de la clase A.

La figura "Diagrama de casos de uso de web de recetas" representa una parte de la funcionalidad para una web de recetas de cocina. Esta web tiene la particularidad de que incluye programas descargables para diferentes máquinas (robots de cocina), pero solo los usuarios identificados pueden descargar los programas asociados a las recetas. Indique la respuesta correcta para el diagrama: Para "Descargar Programa" hay que "Consultar Recetas" porque ese caso de uso está relacionado mediante una relación "Extend". Para "Consultar Recetas" siempre hay que "Indentificarse" porque ese caso de uso está relacionado mediante una relación "Include". Para "Descargar Programa" hay que hacerlo mediante "Consultar Recetas" porque no hay asociación de uso directa entre el "Usuario Web" y "Descargar Programa".

En el diagrama de secuencia de la figura: El usuario introduce su pin. Si el pin es correcto, el sistema ATM permite el acceso. Si se equivoca varias veces al introducir el pin, se bloquea el acceso. El usuario introduce dígitos hasta llegar al número necesario. El sistema ATM comprueba si son válidos. Si lo son, da acceso al menú principal. Si no lo son, bloquea el acceso. El usuario introduce su pin tantas veces como sea necesario hasta que el sistema ATM valida que es correcto.

La figura "Diagrama de secuencia de las clases A y B y mensaje(parámetro)" muestra un diagrama de secuencia donde interactúan un objeto de la clase A y un objeto de la clase B. Atendiendo al diagrama y sabiendo que mensaje(parámetro) es un método definido en nuestra aplicación, ¿dónde debe definirse dicho método?. En la clase A y en la clase B. En la clase A. En la clase B. Ni en la clase A ni en la clase B.

La figura "Diagrama de clases de una secuencia enlaza" muestra un diagrama de clases que representa una lista enlazada. El diagrama es: Correcto. Incorrecto porque en UML no hay relaciones recursivas. Incorrecto porque la relación recursiva de Nodo no tiene caso base. Incorrecto porque la relación recursiva de la clase Nodo no nombra los roles.

En el patrón Modelo-Vista-Controlador, la función principal del modelo es: Almacenar los datos que se guardan de manera persistente en el sistema. Implementar el modelo de negocio del sistema. Modelar los requisitos funcionales que tiene que ejecutar el sistema.

Un ejemplo de requisito de un sistema software es: La clase Agente especializa a la clase UsuarioActivo. Los desarrolladores ejecutarán las pruebas unitarias. La base de datos del sistema será no SQL.

La figura "Diagrama de clases de web de recetas" representa el modelo estructural para una web de recetas de cocina. Esta web tiene la particularidad de que incluye programas descargables para diferentes máquinas (robots de cocina). Se desea que en la web se puedan hacer búsquedas de recetas de cocina por sus ingredientes, por su dificultad, por las máquinas para las que hay programa y por las técnicas culinarias usadas en la receta. Escoja la respuesta correcta para el sistema: No se puede buscar por "Técnica” porque la asociación entre "Paso” y "Receta” esdireccional. Una búsqueda de receta por "Máquina” puede dar como resultado 5 "Recetas”. No se puede buscar por "Técnica” porque no hay una asociación directa con "Receta”.

En el diagrama de clases de la figura: Las personas solo pueden tener hijos varones. El diagrama es incorrecto porque no puede haber dos asociaciones entre dos clases. Solo las personas casadas pueden tener hijos.

Si los objetos de la clase de la clase A necesitan acceder al valor devuelto por el método metodoC de la clase C, para modificar el diseño cumpliendo la Ley de Demeter: La clase C debería especializar B. La clase B debería ofrecer un método para acceder al valor devuelto por el método metodoC. La clase B debería ofrecer un método para acceder al objeto de la clase C: C getC().

La cohesión de un sistema: Es mala porque indica que los elementos de un mismo módulo estén muy relacionados y los de otros no. Indica hasta qué punto los elementos de un módulo o clase están relacionados. No indica nada sobre la relación de diferentes módulos entre sí. Mide la relación entre los elementos de dos módulos entre los que hay dependencias.

El principio de sustitución de Liskov permite: Evitar problemas en este supuesto: una clase cliente A tiene un método con un parámetro formal de la clase B, pero a veces se le llama con objetos de subclases de B como parámetros actuales. Redefinir en una clase B que especializa a otra clase A el código de métodos privados de la clase A. Garantizar que una clase B que especializa a otra clase A implementa todos los interfaces que implementa la clase A.

El interruptor de un aire acondicionado está programado para apagarse cuando cae por debajo de 18 (grados) y luego se enciende cuando la temperatura es superior a 21 (grados). Identifica las particiones o clases de equivalencia inválidas. Valores entre 18 y 21 ambos incluidos. Valores inferiores a 18. Valores entre 18 y 21 ambos no incluidos. Valores superiores a 21.

En un proceso de producción de software: Son importantes tanto el programa generado como la documentación correspondiente al mismo. Si el programa resultante no contiene errores, no es necesaria ninguna documentación. Los ingenieros de software tienden a escribir grandes cantidades de documentación que no sirve para nada.

La figura "Diagrama de clases Habitación - Puerta" muestra un diagrama de clases con las clases Habitación y Puerta. Para el posterior diagrama de clases podemos afirmar: Pueden haber objetos de clase Puerta sin que se hayan creado objetos de clase Habitación. Siempre que se cree un objeto de clase Habitación se tiene que crear un objeto de clase Puerta. Puede haber objetos de clase Habitación sin que se hayan creado objetos de clase Puerta. No se pueden crear objetos de clase Habitación ni objetos de clase Puerta.

La figura "Diagrama de casos de uso de Web de Fotos" presenta el diagrama de casos de uso de una web para almacenar fotos. La web saca periódicamente copias de seguridad de las fotos almacenadas, sin intervención del usuario. El diagrama es: Incorrecto porque la web no aparece como actor secundario. Correcto. Incorrecto porque hay un caso de uso que no está asociado a ningún actor. Incorrecto porque no muestra la frontera del sistema.

En la figura "Diagrama de casos de uso con actor secundario" se muestra un diagrama de casos de uso en el que el actor principal, el Usuario, usa el sistema en un caso de uso en el que el actor "Sistema Externo" es un actor secundario. Indique la respuesta correcta para el diagrama: El actor secundario actúa de interfaz entre el actor principal y el sistema. El actor secundario ayuda al sistema a conseguir el objetivo del actor principal. El objetivo del actor principal coincide plenamente con el objetivo del actor secundario.

En el diagrama de clases de la figura: Solo es posible saber los clientes de los managers. No es posible saber directamente cuáles son los clientes de un asesor en una empresa. Para saber cuáles son los clientes de una asesor basta con saber la empresa en la que trabaja.

¿Cuál es la complejidad ciclomática del siguiente algoritmo? public static int maxArray(int arr[]) { int resultado = Integer.MIN_VALUE; //a if (arr.length>0){ //b resultado = arr[0]; //c int i = 1; //d while (i<arr.length){ //e if (arr[i]>resultado){ //f resultado = arr[i]; //g } //h i++; //i } //j } //k return resultado; //l }.

Dado el siguiente código: public final class String2Double{ public static Double toDouble(String str){ if(str==null){ return null; } return Double.valueOf(str); } } Y la siguiente prueba en JUnit5: @Test public void testConvertToDoubleOK() { String age = "1990"; Double expAge = Double.valueOf(age); Double actual = String2Double.toDouble(age); assertNotNull(actual, "The actual is null"); assertEquals(expAge, actual); } Revisa su funcionamiento y responde a la siguiente pregunta: ¿Pasa el código descrito esta prueba?. Si, pasan todos los asserts correctamente. No, el primer assert falla. No, fallan todos los asserts. No, el segundo assert falla.

En el diagrama de secuencia ABC: La clase A tiene un atributo de la clase B y otro atributo de la clase C. Hay una relación de composición entre A y B y otra relación de composición entre B y C. Las clases B y C especializan a una clase común, por lo que A puede escoger el método al que llamar.

El cliente ha pedido como nuevo requisito no funcional de seguridad que se respete la privacidad de los datos que se almacenen de los pacientes de la clínica. Como consecuencia: Se añaden nuevos requisitos funcionales, como el inicio de sesión autenticado, y se adaptan otros, como la anonimización de los datos a la hora de generar informes estadísticos. Se añaden un a nueva iteración al final del desarrollo dedicada en exclusiva a implementar este requisito no funcional. El analista renegocia los requisitos funcionales con el cliente para eliminar otros requisitos funcionales que tengan una complejidad similar.