==> Capítulo 1

1. Apareamiento.
Es el conjunto de los programas de cómputo, procedimientos, reglas,
documentación y datos asociados, que forman parte de las operaciones de un
sistema de computación. * Software

Está formada por un proceso, un conjunto de métodos (prácticas) y un arreglo

de herramientas que permite a los profesionales elaborar software de cómputo
de alta calidad. * Ingeniería de Software

Es el conjunto de conocimientos y técnicas científicas aplicadas al desarrollo,

implementación, mantenimiento y perfeccionamiento de estructuras (tanto
físicas como teóricas) para la resolución de problemas que afectan la actividad
cotidiana de la sociedad. * Ingeniería

2. Cualquier acción humana, especialmente las que envuelven o afectan a

grupos humanos extensos, tendrá consecuencias no anticipadas o calculadas.
Ley de las consecuencias inesperadas. *

3. Una característica del Software Heredado.

Soporte de las funciones centrales de negocios. *

4. Un atributo de la Webapp.
Inmediatez. *

5. El software se manufactura. V/F

6. El software se deteriora. V/F

7. El software distribuye el producto más importante de nuestro tiempo.

Información. *

8. Conjunto de programas escritos para dar servicio a otros programas.

Software de sistemas. *
9. Programas aislados que resuelven una necesidad específica de negocios.
Software de aplicación. *

10. Se ha caracterizado por algoritmos "devoradores de números".

Software de ingeniería y ciencias. *

11. Reside dentro de un producto o sistema y se usa para implementar y

controlar características y funciones para el usuario final y para el sistema en
sí.
Software incrustado. *

12. Es diseñado para proporcionar una capacidad específica para uso de

muchos consumidores diferentes.
Software de línea de productos. *

13. Conjunto de archivos de hipertexto vinculados que presentan información

con uso de texto y gráficas. Presentan un ambiente de cómputo sofisticado.
Están integradas con bases de datos corporativas y aplicaciones de negocios.
Aplicaciones web. *

14. Hace uso de algoritmos no numéricos para resolver problemas complejos

que no son fáciles de tratar computacionalmente o con el análisis directo.
Software de inteligencia artificial. *

15. Una característica del Software Heredado.

Código confuso. *

16. Una característica del Software Heredado.

Soporte de las funciones centrales de negocios. *

17. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: Si un usuario de la webapp debe esperar demasiado (para
entrar, para el procesamiento por parte del servidor, para el formado y
despliegue del lado del cliente), él o ella quizá decidan irse a otra parte.
Rendimiento. *
18. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: Cuando se necesita atender las necesidades de una
comunidad diversa de clientes. Permitir acceso y comunicación mundiales (por
ejemplo, internet) o permitir acceso y comunicación limitados (por ejemplo,
una intranet corporativa).
Uso intensivo de redes. *

19. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: A la webapp puede acceder un gran número de usuarios a
la vez. En muchos casos, los patrones de uso entre los usuarios finales varían
mucho.
Concurrencia. *

20. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: El número de usuarios de la webapp cambia en varios
órdenes de magnitud de un día a otro.
Carga impredecible. *

21. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: Es frecuente que los usuarios de webapps populares
demanden acceso las 24 horas de los 365 días del año.
Disponibilidad. *

22. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: La función principal de muchas Webapp es el uso de
hipermedios para presentar al usuario final contenido en forma de texto,
gráficas, audio y vídeo.
Orientadas a los datos. *

23. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: La calidad y naturaleza estética del contenido constituye
un rasgo importante de la calidad de una webapp.
Contenido sensible. *
24. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: No es raro que ciertas webapp (específicamente su
contenido) se actualicen minuto a minuto o que su contenido se calcule en cada
solicitud.
Evolución continua. *

25. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: Es frecuente que las webapps tengan plazos de algunos
días o semanas para llegar al mercado.
Inmediatez. *

26. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: Debido a que las webapps se encuentran disponibles con
el acceso a una red, es difícil o imposible limitar la población de usuarios
finales que pueden acceder a la aplicación.
Seguridad. *

27. Qué atributo de una aplicación Web debe ser tomado en cuenta en el
siguiente escenario: Parte innegable del atractivo de una webapp es su
apariencia y percepción.
Estética. *

28. Dentro de las capas de la Ingeniería de Software es la que establece el

contexto en el que se aplican métodos técnicos, se generan productos del
trabajo (modelos, documentos, datos, reportes, formatos, etc.), se establecen
puntos de referencia, se asegura la calidad y se administra el cambio de manera
apropiada.
Proceso. *

29. Dentro de las capas de la Ingeniería de Software es la que proporciona la

experiencia técnica para elaborar software.
Métodos. *

30. Dentro de las capas de la Ingeniería de Software es la que proporciona un

apoyo automatizado o semiautomatizado.
Herramientas. *
31. Apareamiento.
Conjunto de actividades, acciones y tareas que se ejecutan cuando va a crearse
algún producto del trabajo. * Proceso

Busca lograr un objetivo amplio y se desarrolla sin importar el dominio de la

aplicación, tamaño del proyecto, complejidad del esfuerzo o grado de rigor con
el que se usará la ingeniería de software. * Actividad

Es un conjunto de tareas que producen un producto importante del trabajo. *

Acción

Se centra en un objetivo pequeño pero bien definido que produce un resultado

tangible. * Tarea

32. Es una actividad estructural donde se busca entender los objetivos de los
participantes respecto del proyecto, y reunir los requerimientos que ayuden a
definir las características y funciones del software.
Comunicación. *

33. Es una actividad estructural donde se busca describir las tareas técnicas por
realizar, los riesgos probables, los recursos que se requieren, los productos del
trabajo que se obtendrán y una programación de las actividades.
Planeación. *

34. Es una actividad estructural donde se busca entender mejor los

requerimientos del software y el diseño que los satisfará.
Modelado. *

35. Es una actividad estructural donde se realiza la generación de código y las

pruebas que se requieren para descubrir errores en éste.
Construcción. *

36. Es una actividad estructural donde el software se entrega al consumidor

que lo evalúa y que le da retroalimentación.
Despliegue. *
37. Describe en un orden lógico la esencia de la solución de problemas y, en
consecuencia, la esencia de la práctica de la ingeniería de software.
Entender el problema - Planear la solución - Ejecutar el plan - Examinar
la exactitud del resultado. *

==> Capítulo 2

38. Describe la manera en que están organizadas las actividades estructurales

y las acciones y tareas que ocurren dentro de cada una con respecto de la
secuencia y el tiempo.
Flujo del proceso. *

39. Ejecuta cada una de las cinco actividades estructurales en secuencia,

comenzando por la comunicación y terminando con el despliegue.
Flujo de proceso lineal. *

40. Repite una o más de las actividades antes de pasar a la siguiente.

Flujo de proceso iterativo. *

41. Realiza las actividades en forma “circular”. A través de las cinco

actividades, cada circuito lleva a una versión más completa del software.
Flujo de proceso evolutivo. *

42. Ejecuta una o más actividades en paralelo con otras.

Flujo de proceso paralelo. *
43. No forma parte de las actividades estructurales del proceso.
Medición. *

44. No forma parte de las actividades sombrilla del proceso.

Despliegue. *

45. Al modelo en cascada también se le conoce como:

Ciclo de vida clásico. *

46. Son dos modelos comunes de proceso evolutivo.

Hacer prototipos y el modelo espiral. *
47. Dentro de las fases del proceso unificado, en esta fase se vigila el uso que
se da al software, se brinda apoyo para el ambiente de operación
(infraestructura) y se reportan defectos y solicitudes de cambio para su
evaluación.
La fase de producción. *

48. Forma en la cual los elementos del proceso se interrelacionan entre sí.
Flujo de trabajo. *

49. Se implementa cuando los requerimientos para cierto problema se

comprenden bien: cuando el trabajo desde la comunicación hasta el despliegue
fluye en forma razonablemente lineal.
Modelo en cascada. *

50. Ejecuta una serie de avances, llamados incrementos, que en forma

progresiva dan más funcionalidad al cliente conforme se le entrega cada
incremento.
Modelo incremental. *

51. Genera en cada interacción una versión final cada vez más completa del
software.
Modelo del proceso evolutivo. *

52. Con frecuencia es más apropiado para proyectos de ingeniería de productos

en los que se involucran varios equipos de trabajo.
Modelo de desarrollo concurrente. *
53. Apareamiento.
Contiene una notación robusta para el modelado y desarrollo de los sistemas
orientados a objetos. * Lenguaje de modelado unificado.

Permiten especificar, desarrollar y verificar un sistema basado en computadora

por medio del empleo de una notación matemática rigurosa. * Modelo de
métodos formales.

Estructura para la ingeniería de software orientado a objetos que utiliza UML.

* Proceso unificado.

54. Dentro de las fases del proceso unificado, esta fase agrupa actividades tanto
de comunicación con el cliente como de planeación.
La fase de concepción. *

55. Dentro de las fases del proceso unificado, esta fase mejora y amplía los
casos de uso preliminares desarrollados como parte de la fase de concepción y
aumenta la representación de la arquitectura.
La fase de elaboración. *

56. Dentro de las fases del proceso unificado, esta fase desarrolla o adquiere
los componentes del software que harán que cada caso de uso sea operativo
para los usuarios finales.
La fase de construcción. *

57. Dentro de las fases del proceso unificado, esta fase incluye las últimas
etapas de la actividad general de construcción y la primera parte de la actividad
de despliegue general.
La fase de transición. *

==> Capítulo 3

58. En el manifiesto por el desarrollo ágil de software, indique cuál enunciado

es falso.
Apegarse a un plan, mejor que responder al cambio. *
59. Seleccione una metodología ágil.
Crystal. *

60. Dentro de los principios que guían la práctica ¿qué indica el principio
"Divide y vencerás"?
Un problema grande es más fácil de resolver si se divide en un conjunto
de elementos. *

61. El objetivo de las estimaciones es obtener un índice del esfuerzo, costo y

duración de las tareas, con base en la comprensión que tenga el equipo sobre
el trabajo que va a realizar. V/F

==> Capítulo 4

62. No es un elemento de la práctica de la ingeniería de software.

Proceso. *

63. Principios Fundamentales a nivel del Proceso.

Establecen un fundamento filosófico que guía al equipo de software. *

64. Principios Fundamentales a nivel de la Práctica.

Definen un conjunto de valores y reglas que sirven como guía. *

65. Este principio que guía el proceso indica que el objetivo son las personas.
Formar un equipo eficaz. *

66. Este principio que guía el proceso indica que es esencial establecer planes
de contingencia.
Evaluar el riesgo. *

67. Es la simplificación de algún elemento complejo de un sistema usado para

comunicar significado en una sola frase.
Abstracción. *

68. Sugiere que un contexto familiar hace que el software sea más fácil de usar.
Principio de coherencia. *
69. Nivel de detalle que se adopta cuando se desarrolla un plan.
Granularidad. *

70. Cada módulo debe centrarse exclusivamente en un aspecto bien delimitado

del sistema.
Construir software que tenga modularidad eficaz. *

71. Principios de comunicación que se centra en las palabras del hablante en

lugar de formular su respuesta a dichas palabras.
Escuchar. *

72. Centrarse en una y sólo una función o subfunción.

Cohesiva. *

73. El acoplamiento de componentes debe mantenerse tan bajo como sea

razonable. V/F

74. En los principios de codificación el objeto de la prueba es:

Encontrar un error. *

75. En los principios de codificación un caso de prueba es:

La probabilidad de encontrar un error no detectado hasta el momento. *

76. En los principios de codificación una prueba exitosa es:

Descubrir un error no detectado hasta el momento. *

==> Capítulo 5

77. En la Ingeniería de Requerimientos en la tarea de Concepción:

Se identifica una necesidad del negocio o se descubre un nuevo mercado o
servicio potencial. *

78. En la Ingeniería de Requerimientos en la tarea de Indagación:

Se pregunta al cliente, a los usuarios y a otras personas cuáles son los
objetivos para el sistema o producto. *
79. En la Ingeniería de Requerimientos en la tarea de Elaboración:
Se centra en desarrollar un modelo refinado de los requerimientos que
identifique distintos aspectos de la función del software, su
comportamiento e información. *

80. En la Ingeniería de Requerimientos en la tarea de Negociación:

Se pide a clientes, usuarios y otros participantes que ordenen sus
requerimientos según su prioridad y que después analicen los conflictos. *

81. En la Ingeniería de Requerimientos en la tarea de Especificación:

Se crea un documento escrito, conjunto de modelos gráficos, modelo
matemático formal, conjunto de escenarios de uso, prototipo. *

82. En la Ingeniería de Requerimientos en la tarea de Validación:

Se analiza la especificación. *

83. El despliegue de la función de calidad identifica tres tipos de

requerimientos. Los requerimientos normales son:
Objetivos y metas que se establecen para un producto o sistema durante
las reuniones con el cliente. *

84. El despliegue de la función de calidad identifica tres tipos de

requerimientos. Los requerimientos esperados son:
Están implícitos en el producto o sistema y quizá sean tan importantes que
el cliente no los mencione de manera explícita. *

85. El despliegue de la función de calidad identifica tres tipos de

requerimientos. Los requerimientos emocionantes son:
Estas características van más allá de las expectativas del cliente y son muy
satisfactorias si están presentes. *
==> Capítulos 6 y 7

86. Elementos del modelo de requerimientos donde el sistema se describe

desde el punto de vista del usuario.
Elementos basados en el escenario. *

87. Elementos del modelo de requerimientos donde cada escenario de uso

implica un conjunto de objetos que se manipulan cuando un actor interactúa
con el sistema.
Elementos basados en clases. *

88. Elementos del modelo de requerimientos que tienen un efecto profundo en

el diseño que se elija y en el enfoque de implementación que se aplique.
Elementos de comportamiento. *

89. Elementos del modelo de requerimientos donde el sistema acepta entradas

en varias formas, aplica funciones para transformarla y produce salidas en
distintos modos.
Elementos orientados al flujo. *

90. Modelo de requerimientos desde el punto de vista de distintos “actores” del

sistema.
Modelos basados en el escenario. *

91. Modelo de requerimientos que ilustra el dominio de información del

problema.
Modelos de datos. *

92. Modelo de requerimientos que representan clases orientadas a objetos y la

manera en la que las clases colaboran para cumplir con los requerimientos del
sistema.
Modelos orientados a clases. *

93. Modelo de requerimientos que representa los elementos funcionales del

sistema y la manera como transforman los datos a medida que se avanza a
través del sistema.
Modelos orientados al flujo. *
94. Modelo de requerimientos que representa ilustran el modo en el que se
comporta el software como consecuencia de “eventos” externos.
Modelos de comportamiento. *

95. Durante el modelado de los requerimientos, la atención se centra en cómo,

no en qué. V/F

96. Este enfoque del modelado de requerimientos considera que los datos y los
procesos que los transforman son entidades separadas.
Análisis estructurado. *

97. Este enfoque del modelado de requerimientos se centra en la definición de

las clases y en la manera en la que colaboran uno con el otro para cumplir los
requerimientos.
Análisis orientado a objetos. *

98. Los escenarios secundarios:

Forman parte del caso de uso original, pero representan comportamientos
alternativos. *

99. El Caso de uso:

Capta las interacciones que ocurren entre los productores y consumidores
de la información y el sistema en sí. *

100. Una excepción:

Describe una situación que ocasiona que el sistema presente un
comportamiento algo distinto. *

101. Al realizar una escritura de un caso de uso formal, ¿qué elemento

identifica el alcance general del caso de uso?
Objetivo en contexto. *

102. Al realizar una escritura de un caso de uso formal, ¿qué elemento describe
lo que se sabe que es verdadero antes de que inicie el caso de uso?
Precondición. *
103. Al realizar una escritura de un caso de uso formal, ¿qué elemento
identifica el evento o condición que “hace que comience el caso de uso”?
Disparador. *

104. Al realizar una escritura de un caso de uso formal, ¿qué elemento enlista
las acciones específicas que requiere el actor, y las respuestas apropiadas del
sistema?
Escenario. *

105. Al realizar una escritura de un caso de uso formal, ¿qué elemento

identifica las situaciones detectadas cuando se mejora el caso de uso
preliminar?
Excepciones. *

106. En el diagrama de actividad UML se usa para denotar una función

específica del sistema:
Rectángulos redondeados. *

107. En el diagrama de actividad UML se usa para representar flujo a través

de éste:
Flechas. *

108. En el diagrama de actividad UML se usa para ilustrar una ramificación de

las decisiones:
Rombos de decisión. *

109. En el diagrama de actividad UML se usa para indicar que están ocurriendo
actividades en paralelo:
Líneas continuas. *

110. ¿Qué se entiende por CRC?

Clase-Responsabilidad-Colaborador. *

111. En el modelado CRC, las clases de entidad:

Se extraen directamente del enunciado del problema. *
112. En el modelado CRC, las clases de frontera:
Se utilizan para crear la interfaz que el usuario mira y con la que
interactúa cuando utiliza el software. *

113. En el modelado CRC, las clases de controlador:

Administran una “unidad de trabajo” de principio a fin. *

114. ¿En el modelado CRC, qué indica la relación es-parte-de?

Todas las clases forman parte de una clase agregada. *

115. ¿En el modelado CRC, qué indica la relación tiene-conocimiento-de?

Una clase debe adquirir información de otra. *

116. ¿En el modelado CRC, qué indica la relación depende-de?

Significa que dos clases tienen una dependencia que no se determina por
tiene-conocimiento-de ni por es-parte-de. *

117. ¿En el modelado basado en clases, qué define una relación entre clases?
Asociación. *

118. ¿En el modelado basado en clases, qué define cuántas de una clase se
relacionan con cuántas de otra clase?
Multiplicidad. *

119. En el modelado basado en clases, qué determina cuando una clase cliente
depende de algún modo de la clase servidor.
Relación de dependencia. *

120. En el modelado basado en clases, es un “mecanismo extensible” dentro

del UML que permite definir un elemento especial de modelado con semántica
y especialización determinadas.
Estereotipo. *

121. Los paquetes de análisis se utilizan para ensamblar un conjunto de clases

relacionadas. ¿Qué indica la categorización?
Se clasifican distintos elementos del modelo de análisis de manera que se
agrupen en un paquete al que se da un nombre representativo. *
122. Los paquetes de análisis se utilizan para ensamblar un conjunto de clases
relacionadas. ¿Qué indica el signo más (+)?
Las clases tienen visibilidad pública, por lo que son accesibles desde otros
paquetes. *

123. Los paquetes de análisis se utilizan para ensamblar un conjunto de clases

relacionadas. ¿Qué indica el signo menos (-)?
Un elemento queda oculto desde todos los demás paquetes. *

124. Los paquetes de análisis se utilizan para ensamblar un conjunto de clases

relacionadas. ¿Qué indica el símbolo #?
Un elemento es accesible sólo para los paquetes contenidos dentro de un
paquete dado. *

125. Considera como entidades separadas los datos y los procesos que los
transforman.
Análisis estructurado. *

126. Se centra en la definición de clases y en el modo en el que colaboran una

con otra para cumplir con los requerimientos del cliente.
Análisis orientado a objetos. *

127. Adopta un punto de vista del tipo entrada-proceso-salida para el sistema.

Diagrama de flujo de datos. *

128. Indica la forma en la que responderá el software a eventos o estímulos

externos.
Modelo de comportamiento. *

129. En el modelado de requerimientos para webapps, este modelo identifica

el espectro completo de contenido que dará la webapp.
Modelo de contenido. *

130. En el modelado de requerimientos para webapps, este modelo describe la

manera en que los usuarios interactúan con la webapp.
Modelo de interacción. *
131. En el modelado de requerimientos para webapps, este modelo define las
operaciones que se aplicarán al contenido de la webapp y describe otras
funciones de procesamiento que son independientes del contenido pero
necesarias para el usuario final.
Modelo funcional. *

132. En el modelado de requerimientos para webapps, este modelo define la

estrategia general de navegación para la webapp.
Modelo de navegación. *

133. En el modelado de requerimientos para webapps, este modelo describe el

ambiente e infraestructura en la que reside la webapp.
Modelo de configuración. *