Conceptos Fundamentales de Ingeniería del Software

Principios y Conceptos Clave

52. Un síntoma que puede indicar que es conveniente segregar interfaces es: Que haya clases que implementen métodos que no necesitan.

53. Los cambios en los requisitos de los clientes se pueden abordar en los desarrollos, pero es importante seguir una metodología apropiada.

54. Las pruebas de aceptación las ejecuta el cliente para aceptar la entrega de una nueva versión del sistema por parte del equipo de desarrollo.

55. Un proceso de desarrollo de software indica las actividades y el orden en el que se deben hacer en el desarrollo.

56. Un módulo con un acoplamiento alto con otros muchos módulos:

Hace más difícil que se pueda reutilizar ese módulo en otro entorno.

57. En la terminología de pruebas, los caminos base son:

Las posibles secuencias fundamentales de ejecución de un código.

58. Un prototipo puede usarse para: Dividir el desarrollo en mini proyectos, del que cada uno resulta una versión parcial funcional.

59. Entre las actividades habituales de un proceso de desarrollo están:

• Especificación
• Desarrollo
• Validación

60. En el patrón Singleton: El constructor se define privado, para que solo pueda instanciar la misma clase.

61. En el diagrama de secuencia ABC: La clase A tiene un atributo de la clase B y otro atributo de la clase C.

62. Si pensamos en la búsqueda de información en la web en un buscador como Google como un problema MapReduce: La operación Map consiste en buscar la ocurrencia de los términos buscados en las páginas indexadas por el buscador.

63. Los requisitos no funcionales: Suelen indicar cuestiones relacionadas con los criterios de calidad del sistema.

64. En la terminología de pruebas, los caminos base son:

Las posibles secuencias fundamentales de ejecución de un código.

65. El patrón Estrategia ayuda a cumplir el principio de:

Responsabilidad única.

66. El software no se desgasta por el uso, pero puede dejar de ser útil por cambios en los requisitos de los clientes.

67. El principio de responsabilidad única establece que: Una clase debe centrarse en realizar una sola tarea.

Casos de Uso y Diagramas

68. 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.

69. 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.

70. En una prueba de caja blanca: Se prueba el sistema sabiendo cuál es su estructura interna y su código.

71. Los requisitos de un sistema de software indican cuáles son las características que debe cumplir el sistema.

72. Un escenario de un caso de uso describe las actividades y el orden en el que se deben hacer en el desarrollo.

73. En el diagrama de casos de uso MemosUCD: El manager puede ejecutar los casos de uso “Escribir Memorando” y “Leer Memorando”.

74. El uso del lenguaje natural para describir requisitos:

Se puede admitir para describir versiones preliminares de los requisitos.

75. Para que una clase B que especializa a otra clase A cumpla el principio de sustitución de Liskov: La clase B no puede lanzar, en un método modificado, una excepción que no lance la clase A.

76. En la fase de diseño: Se empieza a definir la estructura interna del sistema informático.