Fundamentos de Ingeniería del Software

  • Autor: Arturo Olivares Martos
  • Autor: Lucas Hidalgo Herrera
  • Autor: Laura Mandow Fuentes
  • Autor: José Juan Urrutia Milán
  • Descripción: Recopilación de preguntas Tipo Test de la asignatura de FIS. Se han obtenido de fuentes diversas, por lo que si faltasen, sobrasen o estuviesen mal formuladas, por favor, se ruega nos lo hagan saber para corregirlo.
  • Exámenes Garantizados:
    • Convocatoria Ordinaria DGIIM 2024/2025.

  1. Todos los sustantivos que se identifiquen en los casos de uso se representan como conceptos en el diagrama conceptual.

  2. El diagrama de componentes especifica el hardware físico sobre el que se ejecutará el sistema software.

  3. Uno de los objetivos de la fase de inicio del proceso unificado es el estudio de viabilidad del sistema a desarrollar.

  4. Durante la etapa de definición hay que conseguir encontrar la solución software al sistema analizado.

  5. Las clases del diagrama de clases del diseño toman sus atributos de los diagramas de comunicación.

  6. Todos los enlaces estereotipados con <<L>>, <<P>> o <<G>> estarán en el diagrama de clases del diseño como una asociación.

  7. El usuario es una pieza importante en el proceso de validación de las especificaciones del software.

  8. El uso de mecanismos de abstracción en el diseño permiten obtener la modularidad adecuada de un sistema software.

  9. Uno de los problemas más importantes en el proceso de desarrollo del software es el incumplimiento de la planificación.

  10. El modelo de prototipos es un buen método para validar los requisitos de los usuarios en cualquier proyecto de desarrollo de software.

  11. En la arquitectura multicapa las capas deben estar lo más acopladas posible.

  12. Los requisitos no funcionales definen los criterios de calidad del sistema software.

  13. Las asociaciones de navegación se obtienen a partir de las asociaciones del modelo conceptual.

  14. Los requisitos no funcionales no tienen ninguna relación con los funcionales.

  15. En el diagrama de clases del diseño pueden aparecer clases que no estaban en el diagrama de conceptos construido en el modelo de análisis.

  16. Una de las funciones de la relación de inclusión en los casos de uso es descomponer un caso de uso complejo y largo en varios, para facilitar su comprensión.

  17. Las bases principales para obtener los diagramas de comunicación son los contratos y el modelo conceptual.

  18. Un caso de uso sólo puede tener un actor principal que coincide con el que inicia el caso de uso.

  19. El uso de métodos de desarrollo ágiles rompen con la filosofía de equipos de trabajo organizados de forma jerárquica.

  20. Una de las ventajas al incluir las relaciones entre los casos de uso es que se reduce el texto generado en la descripción de los casos de uso.

  21. Uno de los pasos a realizar en la elaboración del modelo de interacción de objetos es la incorporación de las asociaciones entre las clases de objetos.

  22. Los diagramas de actividad se usan como complemento a la descripción de un caso de uso complejo.

  23. El uso del patrón controlador en la elaboración del modelo de diseño se hace para reducir el nivel de acoplamiento entre los elementos de la interfaz de usuario y los que modelan la solución.

  24. Los proyectos software reales raramente se adaptan a un modelo de ciclo de vida clásico o en cascada.

  25. Durante el análisis no se estudia la solución que se va a proponer al problema planteado, eso se deja a la fase de diseño.

  26. Con el análisis orientado a objetos sólo se modelan las propiedades estáticas del ámbito del problema.

  27. Los casos de uso “esenciales” son los procedimientos comunes más importantes del sistema.

  28. No se deben usar atributos de un concepto como clave de acceso desde otro concepto.

  29. El modelo conceptual se representa usando un diagrama de clases que contiene las clases con sus atributos, métodos y asociaciones.

  30. En un diagrama de secuencia del sistema pueden aparecer tantos objetos como se necesiten para modelar la interacción entre ellos.

  31. Un caso de uso puede generar más de una operación en el diagrama de secuencia del sistema.

  32. Los patrones de diseño para la asignación de responsabilidades a objetos ayudan a obtener el diagrama de clases del diseño.

  33. Una asociación es una conexión significativa y relevante entre conceptos.

  34. El modelo estructural del análisis está representado por el/los diagramas de secuencia del sistema.

  35. Antes de definir una subclase en un modelo conceptual se debe comprobar que cumple las reglas del 100% y del “es-un”.

  36. El diseño es una tarea clave para la calidad del producto software.

  37. Un cambio de estado que se describe en las poscondiciones de un contrato es la creación de un atributo.

  38. Cuando se construye un modelo conceptual es mejor añadir el mayor número posible de asociaciones entre conceptos.

  39. Un participante en un diagrama de secuencia puede ser un objeto individual o un multiobjeto.

  40. La diferencia entre una precondición y una excepción es que la precondición no tiene que comprobarse en la operación que se está definiendo.

  41. En el diagrama de clases del diseño, la multiplicidad se obtiene de la existencia o no de multiobjetos en los diagramas de comunicación.

  42. La etnografía es una técnica de obtención de requisitos que consiste en preguntar a los trabajadores de un negocio sobre la forma en que realizan sus tareas.

  43. El incumplimiento de la planificación lleva de forma inmediata al aumento de personal en el equipo de desarrollo.

  44. Una característica de los métodos ágiles es las entregas frecuentes.

  45. Un diagrama de secuencia del sistema es un diagrama de secuencia de UML en el que se muestran los eventos generados por los actores.

  46. Los requisitos de un proyecto software pueden cambiar continuamente, pero esto no es un problema ya que los sistemas software son flexibles (se adaptan a los cambios).

  47. Para obtener un buen diseño, cada módulo debe presentar un bajo nivel de cohesión.

  48. La arquitectura de un sistema software facilita la comprensión de la estructura global del sistema.

  49. Los modelos del análisis pueden contener tantas inconsistencias como consideremos oportunas, puesto que no son la solución del problema.

  50. Uno de los objetivos del análisis es conseguir los requisitos del software a partir de los requisitos de usuario mediante un proceso de refinamiento.

  51. Un Diagrama de Secuencia del Sistema se puede corresponder con un caso de uso, con un diagrama de casos de uso o con todo el sistema.

  52. El nombre que le demos al sistema en el DSS se va a corresponder con el nombre de una clase que va a formar parte de nuestra solución.

  53. El Contrato de una operación debe indicar qué hace una operación sin decir cómo lo hace.

  54. Los modelos de AER son: Modelo conceptual, diagramas de casos de uso y los contratos de las operaciones principales.

  55. El modelo conceptual debe representar cualquier tipo de relación que se dé entre los conceptos que forman parte de él.

  56. Un concepto debe incluir los atributos que indiquen las asociaciones que tienen otros conceptos.

  57. En un contrato si está relleno el apartado de las excepciones, el apartado de las precondiciones debe estar vacío.

  58. Lo siguiente es una poscondición correcta: "se creó una lista en la que se incluye el nombre del cliente, dirección y teléfono, que se proporciona como salida de la operación".

  59. A la hora de elaborar el diagrama de comunicación de una operación son esenciales los siguientes apartados del contrato correspondiente: excepciones, precondiciones y poscondiciones.

  60. Con la abstracción de datos se abstraen sobre el funcionamiento para conseguir una estructura modular basada en procedimientos.

  61. El análisis de la productividad permite realizar una buena gestión de proyectos.

  62. El diagrama de clases de diseño se deduce de los diagramas de comunicación. Se elaboran los diagramas de comunicación y después el diagrama de clases del diseño.

  63. EL diseño es el proceso de refinamiento, en el que partiendo de modelos del análisis vamos añadiendo información hasta completar el diseño.

  64. El mayor esfuerzo durante el proceso de producción del software se realiza en la etapa de desarrollo.

  65. El mayor esfuerzo realizado durante el mantenimiento de un software es para adaptar el software a nuevos requisitos.

  66. El modelado de casos de uso solo puede ser usado en la etapa de detección de requisitos.

  67. El modelo conceptual no debe incluir los nombres de rol de las asociaciones.

  68. El modelo conceptual no puede contener las navegabilidades de las asociaciones.

  69. El modelo conceptual o modelo de dominio es básico para especifiar las postcondiciones de un contrato.

  70. El modelo de casos de uso permite determinar con facilidad los requisitos no funcionales del sistema.

  71. El modelo de casos de uso se usa exclusivamente para la obtención de requisitos.

  72. El número de módulos de un sistema software debe ser cuantos más mejor, pues así garantizamos la independencia modular de cada uno de ellos.

  73. El número de operaciones principales de un sistema es el mismo que el número de casos de usos que tengamos.

  74. El proceso unificado es un modelo de proceso dirigido por casos de uso.

  75. El resultado del diseño de la arquitectura del software es un conjunto de subsistemas y las relaciones entre ellos.

  76. En el modelo conceptual hay que definir los atributos y los métodos de todas las clases.

  77. En los diagramas de clases de diseño no se deben representar las relaciones de dependencia entre clases, solo se deben representar las de asociación y de generalización.

  78. En los diagramas de clases de diseño pueden aparecer relaciones de dependencia.

  79. Es posible que en un caso de uso no tenga que intervenir el sistema software a modelar.

  80. La arquitectura cliente-servidor favorece la escalabilidad de los sistemas software, porque permite la reconfiguración añadiendo clientes y servidores extra.

  81. La forma más directa de identificar casos de uso es identificando los objetivos y necesidades de los actores del sistema.

  82. La navegabilidad de las asociaciones en el diagrama de clases del diseño se obtiene teniendo en cuenta la dirección en los envíos de mensaje en los diagramas de comunicación.

  83. La primera tarea del diseño es encontrar el diseño de la arquitectura del sistema.

  84. Las relaciones entre actores y casos de uso son la asociación y la dependencia.

  85. Las relaciones entre los casos de uso pueden ser asociación, generalización y dependencia.

  86. Las relaciones que se dan entre casos de uso es la dependencia y la generalización.

  87. Las tareas principales de la ingeniería de requisitos son detección, análisis, especificación, revisión y reacción de requisitos.

  88. Las vías de comunicación o enlaces entre objetos en un diagrama de colaboración son bidireccionales.

  89. Lo siguiente es un requisito funcional "las reservas de préstamos de libros caducan a los 10 días a partir del momento que el libro esté a disposición del usuario".

  90. Lo siguiente es un requisito NO funcional de facilidad de uso "el entorno debe avisar al usuario mediante email tres días antes de que finalice el plazo del préstamo".

  91. Los actores representan roles que son interpretados por personas, dispositivos, otros sistemas... cuando el sistema está en uso.

  92. Los actores tienen que ser necesariamente los identificados como usuarios del sistema.

  93. Los diagramas de actividad de UML es una herramienta muy adecuada para el diseño del flujo de control.

  94. Los diagramas de interacción y los diagramas de actividad UML son herramientas de diseño que permiten representar lo mismo, son equivalentes.

  95. Los prototipos siempre se transforman hasta convertirse en el programa que se entrega al cliente.

  96. Los requisitos no funcionales determinan los objetivos del diseño.

  97. Los requisitos no funcionales suponen limitaciones para el diseño de un sistema software.

  98. Los tipos de requisitos son funcionales, no funcionales y FURPS+.

  99. Para elaborar el modelo de análisis es fundamental el modelo de casos de uso.

  100. Para incorporar generalizaciones es necesario encontrar clases conceptuales con elementos comunes.

  101. Si una función del sistema no cambia nada de lo especificado en el modelo conceptual su contrato no tendrá poscondiciones.

  102. Un caso de uso esencial describe qué hace el sistema como respuesta a una petición de algún actor, pero no cómo lo hace.

  103. Un caso de uso produce algo de valor para un actor.

  104. Un caso de uso puede ser iniciado por un actor o por un usuario.

  105. Un modelo de casos de uso lo componen los diagramas de casos de uso y la especificación de actores y casos de uso.

  106. Un modelo de casos de uso se centra en las necesidades que el usuario espera lograr al utilizar el sistema.

  107. Un nivel de acoplamiento alto y de cohesión bajo en un módulo garantiza un diseño de calidad.

  108. Una mala solución para remediar el retraso en la entrega de un proyecto software es la llamada "horda mongoliana".

  109. En los diagramas de clases no pueden aparecer relaciones de generalización.

  110. El principio de modularidad es básico, sin él no tienen sentido los demás principios.

  111. El tipo de relación entre actor y CU es de asociación.

  112. En el MC (modelo conceptual) se deben incluir las relaciones de generalización entre conceptos.

  113. El acoplamiento indica dependencia entre módulos. Cuanto más alto mejor es el diseño.

  114. La cohesión es indicador de la unión formal de los elementos que forman un módulo.

  115. Un patrón de diseño es la descripción del problema con su solución en un determinado contexto.

  116. Hacer diagramas de comunicación es sitemático, no interviene la creatividad del diseñador.

  117. Nivel de acoplamiento nulo de un módulo nos garantiza un diseño de calidad.

  118. Diseño es el proceso de aplicar distintos métodos, herramientas y principios con el propósito de definir un dispositivo, proceso o sistema con el suficiente detalle como para permitir su realización física.

  119. El patrón experto en información propone asignar una responsabilidad a la clase que conoce la información necesaria para llevarla a cabo.

  120. El uso de los diagramas de comunicación o de secuencia UML para representar el modelo de interacción de objetos nos va a proporcionar distintos resultados de diseño.

  121. Las relaciones de dependencia en el diagrama de clases del diseño se obtienen de las asociaciones de tipo agregación fuerte.

  122. Un enlace entre objetos estereotipado como local <<L>> nos está indicando que esa vía de comunicación queda establecida para cualquier otra colaboración entre esos objetos.

  123. El uso del patrón controlador aumenta el número de conexiones entre las capas de interfaz de dominio. Esto implica que aumenta su acoplamiento.

  124. Una de las principales tareas del diseño de la arquitectura es refinar la descomposición del sistema en subsistemas.

  125. El patrón experto en información nos dice que el objeto responsable de hacer las cosas es el que tiene el control.

  126. El patrón experto en información nos ayuda a conocer qué clases son las encargadas de crear y destruir objetos en un DC (diagrama de comunicación).

  127. Contra del patrón experto en información: va en contra de principios de acoplamiento y cohesión.

  128. Un enlace entre objetos en un diagrama de colaboración especifica un camino a lo largo del cual un objeto puede enviar mensajes a otro o a sí mismo.

  129. La restricción de UML {new} se usa en los DC (diagramas de comunicación) para representar la creación de un objeto o la creación de un enlace entre 2 objetos.

  130. El ocultamiento de información limita el impacto global de las decisiones de diseño locales.

  131. Las clases que aparezcan en el modelo de dominio son las únicas que tendrán el diagrama de clases del diseño.

  132. Cuando un objeto se pasa como parámetro, en el diagrama de comunicación de la operación los enlaces con ese objeto tendrán una visibilidad del tipo <<A>>.

  133. La herramienta para representar el modelo de diseño de la interacción de objetos son los diagramas de clases UML.

  134. Las clases del diagrama de clases del diseño toman todos sus atributos de los diagramas de conceptos.

  135. ¿Qué principio del diseño facilita el trabajo independiente y concurrente de un equipo software?

  136. En el proceso de diseño, a mayor refinamiento...

  137. ¿Cuál de las siguientes acciones empeoran el ocultamiento de información?

  138. Respecto a la independencia modular, rasgos en diseño de un módulo:

  139. El diagrama de clases del diseño describe la estructura:

  140. ¿Cuál de los siguientes modelos es más importante para realizar el diagrama de clases de diseño?

  141. En el diagrama de clases del diseño:

  142. En el diagrama de clases del diseño, los métodos:

  143. Las relaciones de generalización en el diagrama de clases del diseño son:

  144. ¿Cuándo el diseño de la arquitectura no es conveniente?

  145. Los estereotipos de visibilidad representan tipo de acceso que se da entre objetos en los DC.

  146. La validación de la especificación no forma parte de la Ingeniería de requisitos.

  147. El modelo de casos de uso puede ser usado como guía para el diseño de la interfaz de usuario y para facilitar la construcción de prototipos.

  148. La entrevista es una técnica encaminada a obtener información sobre el sistema mediante el diálogo con los expertos en el dominio del problema.

  149. La Especificación de Requisitos es un documento en el que se dice qué debe hacer el sistema software.

  150. Un sistema informático externo a la aplicación con el que ésta debe interaccionar puede definirse como actor.

  151. Ejemplo de requisito funcional: La aplicación debe ser fácil de utilizar, e incluir ayudas en línea fáciles de entender.

  152. Es mejor que las actividades de verificación las lleve a cabo el mismo equipo que haya hecho el desarrollo.

  153. Los actores de un modelo de casos de uso son siempre humanos.

  154. Un caso de uso esencial describe una actividad que es imprescindible para el funcionamiento del sistema que modela.

  155. El numero de iteraciones en las fases de elaboración y construcción del proceso unificado deben ser las mismas.

  156. La identificación de los implicados facilita la obtención de requisitos.

  157. La clasificación de los requisitos según su ámbito distingue entre requisitos funcionales, no funcionales y de información.

  158. El nodo 5 es un nodo join.
    Diagrama Actividad

  159. Cuando se alcanza el nodo 6 termina la actividad "Carrera de F1".
    Diagrama Actividad

  160. Cuando comienza la actividad "Carrera de F1" se activan las calles "Dirección de carrera" y SI "Dirección de equipo".
    Diagrama Actividad

  161. Este modelo conceptual está mal, faltaría incluir la navegabilidad que hay entre Pizza y Masa, pues una pizza es la que está formada por la masa, igualmente ocurre entre Pizza e Ingrediente.
    Modelo Conceptual

  162. Un objeto pedido puede incluir más de una pizza.
    Modelo Conceptual

  163. Un ingrediente puede tener un precio diferente dependiendo de la pizza en la que esté.
    Modelo Conceptual

  164. Un diagrama de conceptos sin operaciones es incorrecto.

  165. La semántica de la composición no permite que las partes existan independientemente del compuesto

  166. En el DSS tratamos el sistema como si fuera una caja negra.

  167. Cuando establecemos una relación de generalización entre clases todas las subclases deben cumplir con la regla “es-un”.

  168. En el diagrama de conceptos no deben aparecer atributos no primitivos.

  169. Los paquetes durante el diseño arquitectónico son una representación física de los subsistemas.

  170. En la arquitectura MVC (Model View Controller) para cambiar la interfaz de usuario es necesario cambiar el subsistema del modelo ya que este incluye la lógica de funcionamiento del programa.

  171. El rendimiento es uno de los problemas importantes del diseño arquitectónico usando multicapas.

  172. En la arquitectura MVC (Model View Controller) los subsistemas de vista y controlador son los que hacen uso más extensivo de componentes reutilizables.

  173. Al usar una arquitectura cliente-servidor es necesario diseñar e implementar los servidores previamente a poder probar los clientes.

  174. ¿En cuál de las siguientes relaciones de asociación entre conceptos no es conveniente aplicar el patrón creador?

  175. ¿Por qué en el diseño de la operación incluirAsignatura la clase GEA tiene baja cohesión?
    Diagrama Comunicación

  176. Un mensaje enviado a un multi-objeto de la clase X:

  177. ¿Es obligatorio incluir los tipos de datos de los atributos y los parámetros en los diagramas de clases del diseño?

  178. ¿Por qué hay doble navegabilidad en la asociación entre Profesor y Proyecto?
    Diagrama Comunicación

  179. El análisis y especificación de requisitos es una de las fases de la ingeniería de requisitos.

  180. El modelo de casos de uso utiliza un lenguaje próximo al desarrollador, mientras que el modelo de análisis usa un lenguaje más próximo al cliente.

  181. En el diagrama de conceptos se indican las multiplicidades de las asociaciones.

  182. En el diagrama de secuencia del sistema también se representa la interacción entre actores.

  183. En las poscondiciones de un contrato únicamente hay que indicar los objetos que se construyen y los atributos que se modifican.

  184. El Diagrama de Secuencia del Sistema (DSS) forma parte del modelo estático de análisis.

  185. El software de gestión se caracteriza por la complejidad de sus algoritmos.

  186. El proceso unificado lo componen 5 fases que son: inicio, elaboración, construcción, transición y producción.

  187. Los casos de uso los empieza el sistema.

  188. Lo siguiente es un requisito no funcional "El sistema debe cumplir las disposiciones recogidas en la ley orgánica de datos personales y en el régimen de medidas de seguridad".

  189. Un sistema basado en computadora incluye sistemas software.

  190. Definición de Ingeniería del Software: Disciplina de ingeniería que se interesa por todos aspectos de la producción de software, desde las primeras etapas de la especificación hasta el mantenimiento del sistema después de su puesta en operación.

  191. Los requisitos no funcionales describen la estructura de la información que se debe almacenar en el sistema.

  192. Ejemplo de requisito no funcional: la aplicación se encargará de gestionar los alquileres de material deportivo en una tienda.

  193. La única clasificación de tipos de requisitos aceptada por la comunidad de Ingenieros de Requisitos son los requisitos funcionales y los no funcionales.

  194. Conocer el vocabulario propio del sistema forma parte de la preparación y realización de las sesiones de elicitación/negociación.

  195. Durante la obtención de requisitos ha de obtenerse información sobre el alcance del sistema o producto

  196. La demanda creciente de nuevo software hizo evidente la necesidad de adoptar un enfoque de desarrollo informal.

  197. En el modelo de los prototipos no se hace especificación de requerimientos.

  198. Tanto principio como heurística son reglas que se han obtenido a través del conocimiento/experiencia.

  199. Llamamos "Software hecho a medida" al desarrollado bajo pedido a un desarrollador específico.

  200. Un requisito es una propiedad o restricción, determinada con precisión, que un producto software debe satisfacer.

  201. Un prototipo nunca llega a ser el producto final.

  202. Un caso de uso sólo puede tener un actor secundario.

  203. Un modelo es una representación de un sistema en un determinado lenguaje.

  204. Un diagrama de secuencia del sistema muestra la interacción entre los objetos más importantes del sistema software para llevar a cabo una operación.

  205. El atributo numeroUnidades representa el número de ingredientes de una pizza
    Modelo Conceptual

  206. Obligatoriamente uno de los atributos que debe incluir un concepto es su identificador que permita identificar al objeto de forma única.

  207. En un diagrama de comunicación, todos los enlaces estereotipados con <<P>> estarán en el diagrama de clases del diseño como una dependencia.

  208. Una técnica es un instrumento que permite la representación de modelos.

  209. Una característica de los métodos ágiles es la abundante documentación que se genera durante el proceso.

  210. La detección de conflictos entre los requisitos no es una de las principales actividades del diseño arquitectónico.

  211. Un diagrama de secuencia del sistema es un diagrama de secuencia de UML en el que se muestran los eventos generados por el sistema.

  212. Para obtener un buen diseño, entre otras cosas, cada módulo debe presentar un alto nivel de cohesión.

  213. En el proceso de desarrollo del software, una tarea se centra en un objetivo pequeño, pero bien definido que no produce un resultado tangible.