Captulos 8, 9 y 10

1 - Principio de la Ingeniera del Diseo - Un programa no debe tener ningn

error que impida su funcionamiento.
Resistencia.
2. Principio de la Ingeniera del Diseo - Un programa debe ser apropiado para
los fines que persigue.
Funcionalidad.
3. Principio de la Ingeniera del Diseo - La experiencia de usar el programa
debe ser placentera.
Belleza.
4. Forma parte del modelo del diseo.
Diseo en el nivel de componentes - Diseo de interfaz - Diseo
arquitectnico.
5. Atributo de calidad - Funcionalidad.
Conjunto de caractersticas y capacidades del programa, la generalidad
de las funciones que se entregan y la seguridad general del sistema.
6. Atributo de calidad - Usabilidad.
Factores humanos, esttica general, consistencia y documentacin.
7. Atributos de calidad - Confiabilidad.
Frecuencia y gravedad de las fallas, exactitud de los resultados que salen,
el tiempo medio para que ocurra una falla, capacidad de recuperacin
ante sta y lo predecible del programa.
8. Atributo de calidad - Rendimiento.
Velocidad de procesamiento, tiempo de respuesta, uso de recursos,
conjunto y la eficiencia.

9. Atributo de calidad - Mantenibilidad.

Capacidad del programa para ser ampliable, adaptable y servicial, que
pueda probarse, compatible y configurable, facilidad para instalarse en el
sistema y para que se detecten los problemas.
10. Qu caractersticas son comunes en todos los mtodos de diseo?
Mecanismo - Notacin - Heurstica - Lineamientos.
11. Es una de las formas fundamentales en las que el humano se enfrenta a la
complejidad.
Abstraccin.
12. Secuencia de instrucciones que tiene una funcin especfica y limitada.
Abstraccin de Procedimiento.
13. Es una coleccin nombrada de datos que describe un objeto de datos.
Abstraccin de Datos.
14. Se aboca a un problema de aplicacin especfica dentro de un contexto
dado y sujeto a limitaciones y restricciones.
Patrn Arquitectnico.
15. Qu es Modularidad?
El software se divide en componentes con nombres independientes y que
es posible abordar en forma individual.
16. Qu es Divisin de problemas?
Cualquier problema complejo puede manejarse con ms facilidad si se
subdivide en elementos susceptibles de resolverse u optimizarse de manera
independiente.
17. Qu es Ocultacin de informacin?
Sugiere que los mdulos se caracterizan por las decisiones de diseo que
cada uno oculta a los otros.
18. En el diseo de software, debe buscarse el mnimo acoplamiento posible.
V/F

19. Caractersticas de una clase de diseo bien formada.

Completa y suficiente - Primitivismo - Cohesin alta.
20. En la evaluacin de las arquitecturas de software el tipo de dependencia
compartida es aquella que:
Representa relaciones de dependencia entre consumidores que usan el
mismo recurso o los productores que producen para los mismos
consumidores.
21. En la evaluacin de las arquitecturas de software el tipo de dependencia de
flujo es aquella que:
Representa las relaciones de dependencia entre productores y
consumidores de recursos.
22. En la evaluacin de las arquitecturas de software el tipo de dependencia de
restriccin es aquella que:
Representa restricciones al flujo relativo de control entre un conjunto de
actividades.
23. En el Diseo de Componentes Basados en Clase, el principio donde
cualquier clase derivada de una clase de base debe respetar cualquier contrato
implcito entre la clase de base y los componentes que la usan es:
Principio de sustitucin de Liskov.
24. En el Diseo de Componentes Basados en Clase, el principio donde debe
especificarse el componente en forma tal que permita extenderlo sin necesidad
de hacerle modificaciones internas:
Principio Abierto-Cerrado.
25. En el Diseo de Componentes Basados en Clase, el principio donde las
abstracciones son el lugar en el que es posible ampliar un diseo sin muchas
dificultades:
Principio de Inversin de la Dependencia.

26. En el Desarrollo Basado en Componentes, la adaptacin de componentes

donde un equipo de software tiene acceso total al diseo y cdigo interno de
un componente es:
Envoltura de caja blanca.
27. En el Desarrollo Basado en Componentes, la adaptacin de componentes
cuando la biblioteca de componentes proporciona un lenguaje de extensin del
componente o API que permite que los conflictos se eliminen o se anulen:
Envoltura de caja gris.
28. En el Desarrollo Basado en Componentes, la adaptacin de componentes
que requiere la introduccin de procesamiento previo y posterior en la interfaz
del componente para eliminar o anular los conflictos:
Envoltura de caja negra.

Captulos 11, 12 y 13
29. Crea un medio eficaz de comunicacin entre los seres humanos y la
computadora.
Diseo de la Interfaz de Usuario.
30. En el Diseo de la Interfaz de Usuario, esta es una de las Reglas Doradas.
Dejar el control al usuario.
31. Es un aspecto del diseo de la Interfaz de Usuario.
Tiempo de respuesta.
32. Como principios del diseo de la interfaz para Webapp, una webapp debe
disearse de modo que prevea el siguiente movimiento del usuario.
Previsin.
33. Como principios del diseo de la interfaz para Webapp, la interfaz debe
comunicar el estado de cualquier actividad iniciada por el usuario.
Comunicacin.

34. Como principios del diseo de la interfaz para Webapp, el uso de controles
de navegacin, mens, conos y esttica debe ser consistente en la webapp.
Consistencia.
35. Como principios del diseo de la interfaz para Webapp, la interfaz debe
facilitar el movimiento del usuario a travs de la webapp, pero lo debe hacer
de manera que obligue a respetar las convenciones que se hayan establecido
para la aplicacin.
Autonoma controlada.
36. Como principios del diseo de la interfaz para Webapp, el diseo de la
webapp y su interfaz deben optimizar la eficiencia del trabajo del usuario, no
la del desarrollador que la disea y construye ni del ambiente cliente-servidor
que la ejecuta.
Eficiencia.
37. Como principios del diseo de la interfaz para Webapp, la interfaz debe
tener flexibilidad suficiente para permitir que algunos usuarios realicen tareas
directamente, y que otros exploren la webapp en forma aleatoria.
Flexibilidad.
38. Como principios del diseo de la interfaz para Webapp, la interfaz de la
webapp debe mantenerse centrada en las tareas en curso del usuario.
Centrarse.
39. Como principios del diseo de la interfaz para Webapp, el tiempo para
llegar a un objetivo est en funcin de la distancia que hay hasta l y del tamao
que tenga.
Ley de Fitt.
40. Como principios del diseo de la interfaz para Webapp, se ha desarrollado
una vasta biblioteca de objetos reutilizables de interfaces humanas para
webapps. selas.
Objetos de la interfaz humana.

41. Como principios del diseo de la interfaz para Webapp, la webapp debe
usar tareas mltiples, de manera que permita que el usuario contine con su
trabajo mientras finaliza la operacin.
Reduccin de la latencia.
42. Como principios del diseo de la interfaz para Webapp, una interfaz de
webapp debe disearse para minimizar el tiempo de aprendizaje y, una vez
aprendida, minimizar el que se dedique a reaprender cuando se regrese a la
webapp.
Aprendizaje.
43. Como principios del diseo de la interfaz para Webapp, una interfaz que
use una metfora de interaccin es ms fcil de aprender y de usar, en la medida
en la que la metfora sea apropiada para la aplicacin y el usuario.
Metforas.
44. Como principios del diseo de la interfaz para Webapp, un producto del
trabajo debe guardarse en forma automtica, de modo que no se pierda si
ocurriera un error.
Mantener la integridad de los productos del trabajo.
45. Como principios del diseo de la interfaz para Webapp, toda la informacin
presentada en la interfaz debe ser legible para jvenes y viejos.
Legibilidad.
46. Como principios del diseo de la interfaz para Webapp, cuando resulte
apropiado, debe darse seguimiento al estado de la interaccin del usuario y
guardarlo, de modo que ste pueda salir y volver ms tarde para recuperarlo de
donde lo haya dejado.
Dar seguimiento al estado.
47. Como principios del diseo de la interfaz para Webapp, una interfaz de
webapp bien diseada da la ilusin de que los usuarios estn en el mismo
lugar, con el trabajo llevado a ellos.
Navegacin visible.

48. En los criterios de evaluacin del diseo, stos permitirn dar una
indicacin de la cantidad de aprendizaje requerido por los usuarios del sistema.
La longitud y complejidad del modelo de requerimientos o
especificaciones escritas del sistema y su interfaz.
49. En los criterios de evaluacin del diseo, stos indicarn el tiempo de
interaccin de la eficiencia general del sistema.
El nmero de tareas del usuario especificadas y el nmero promedio de
acciones por tarea.
50. En los criterios de evaluacin del diseo, stos implicarn la carga de
memoria para los usuarios del sistema.
El nmero de acciones, tareas y estados del sistema indicados por el
modelo del diseo.
51. En los criterios de evaluacin del diseo, stos darn una indicacin general
de la complejidad de la interfaz y de su grado de aceptacin por parte del
usuario.
El estilo de la interfaz, las herramientas de ayuda y el protocolo del manejo
de errores.
52. Describe un contexto y un problema, pero no ofrece ninguna solucin clara.
Patrn no generativo.
53. Describe un aspecto importante y repetitivo de un sistema, y provee una
manera de construir dicho aspecto dentro de un sistema de fuerzas que son
nicas en un contexto determinado.
Patrones generativos.
54. Describen problemas de diseo de base amplia que se resuelven con el
empleo de un enfoque estructural.
Patrones arquitectnicos.
55. Describen problemas recurrentes orientados a datos y las soluciones de
modelado de datos que pueden emplearse para resolverlos.
Patrones de datos.

56. Se enfocan a problemas asociados con el desarrollo de subsistemas y

componentes, as como a la manera en la que se comunican entre s y su
ubicacin dentro de una arquitectura mayor.
Patrones de componentes.
57. Describen problemas comunes de interfaz de usuario y su solucin con un
sistema de fuerzas que incluye las caractersticas especficas de los usuarios
finales.
Patrones de diseo de la interfaz.
58. Describen la forma de implementar todo un algoritmo especfico o una
parte de l, o bien una estructura de datos, para un componente de software en
el contexto de un lenguaje de programacin especfico.
Idiomas.
59. Se centran en la creacin, composicin y representacin de objetos.
Patrones creacionales.
60. Se centran en problemas y soluciones asociados con la manera en la que se
organizan e integran las clases y objetos para construir una estructura ms
grande.
Patrones estructurales.
61. Se enfocan a problemas asociados con la asignacin de responsabilidad
entre los objetos y a la manera en la que se efecta la comunicacin entre ellos.
Patrones conductuales.
62. En el formato de diseo del patrn es aquel que describe la esencia del
patrn con un nombre corto pero expresivo.
Nombre del patrn.
63. En el formato de diseo del patrn es aquel que describe el problema al que
se dirige el patrn.
Problema.

64. En el formato de diseo del patrn es aquel que proporciona un ejemplo

del problema.
Motivacin.
65. En el formato de diseo del patrn es aquel que describe el ambiente en el
que reside el problema.
Contexto.
66. En el formato de diseo del patrn es aquel que lista el sistema de fuerzas
que afectan la manera en la que debe resolverse el problema.
Fuerzas.
67. En el formato de diseo del patrn es aquel que hace la descripcin
detallada de la solucin propuesta para el problema.
Solucin.
68. En el formato de diseo del patrn es aquel que describe el patrn y lo que
hace.
Objetivo.
69. En el formato de diseo del patrn es aquel que describe la manera en la
que otros patrones contribuyen a la solucin.
Colaboraciones.
70. En el formato de diseo del patrn es aquel que describe los intercambios
potenciales que deben de ser considerados cuando se implementa el patrn, y
las consecuencias de usarlo.
Consecuencias.
71. En el formato de diseo del patrn es aquel que identifica los aspectos
especiales que deben considerarse cuando se implemente el patrn.
Implementacin.
72. En el formato de diseo del patrn es aquel que da ejemplos de usos reales
del patrn de diseo en aplicaciones reales.
Usos conocidos.

73. En el formato de diseo del patrn es aquel que menciona referencias de

patrones de diseo relacionados.
Patrones relacionados.
74. Apareamiento.
Control de acceso. El acceso a cierta parte de la arquitectura del software debe
controlarse de manera rigurosa.
Concurrencia. Manejar tareas mltiples de manera que simule paralelismo.
Distribucin. Manera en la que los sistemas o componentes de los sistemas se
comunican entre s en un ambiente distribuido.
Persistencia. Los datos persisten si sobreviven a la ejecucin del proceso que
los cre.
75. Apareamiento.
Definen la estructura general de la webapp. Patrones arquitectnicos.
Se abocan a un elemento especfico del diseo a fin de resolver algn problema
de diseo, relaciones entre los elementos de una pgina, o mecanismos para
efectuar la comunicacin entre componentes. Patrones de diseo.
Se relaciona con elementos individuales de pequea escala de una webapp.
Patrones de componentes.
76. Atributo principal de la calidad del diseo de webapp: Capacidad para
rechazar los accesos no autorizados o para detener un ataque proveniente del
exterior.
Seguridad.
77. Atributo principal de la calidad del diseo de webapp: Medida porcentual
del tiempo que una webapp puede utilizarse.
Disponibilidad.
78. Atributo principal de la calidad del diseo de webapp: Asimilar la carga
del xito y que tenga an ms xito.
Escalabilidad.

79. Atributo principal de la calidad del diseo de webapp: La primera webapp

que llega a un segmento especfico del mercado obtenga un nmero
desproporcionado de usuarios finales.
Tiempo para llegar al mercado.
80. Metas del Diseo: El contenido debe ser informativo pero sucinto y debe
utilizar un modo de entrega que resulte apropiado para la informacin que se
enve.
Simplicidad.
81. Metas del Diseo: El contenido debe construirse de modo congruente.
Consistencia.
82. Metas del Diseo: El diseo de la esttica, la interfaz y la navegacin de
una webapp deben ser consistentes con el dominio de la aplicacin para la que
se va a elaborar.
Identidad.
83. Metas del Diseo: Contenido y funciones robustas que sean relevantes para
sus necesidades.
Robustez.
84. Metas del Diseo: Debe estar diseada en forma tal que sea intuitiva y
predecible.
Navegabilidad.
85. Metas del Diseo: Una webapp se usar en varios ambientes y debe
disearse para que sea compatible con cada uno.
Compatibilidad.
86. En el Diseo Arquitectnico, esta arquitectura del contenido se encuentra
cuando es comn una secuencia predecible de interacciones.
Estructuras lineales.

87. En el Diseo Arquitectnico, esta arquitectura del contenido se aplica

cuando es posible organizar el contenido de una webapp en forma categrica
en dos (o ms) dimensiones.
Estructuras de malla.
88. En el Diseo Arquitectnico, esta arquitectura del contenido se disea en
forma tal que permite que el flujo del control sea en el sentido horizontal a
travs de las ramas verticales de la estructura.
Estructuras jerrquicas.
89. En el Diseo Arquitectnico, en esta arquitectura del contenido los
componentes arquitectnicos se disean de modo que pasan virtualmente el
control a cada componente del Sistema.
Estructura de red.

Captulos 14, 15 y 16
90. Dimensiones de la Calidad: El software entrega todo el contenido, las
funciones y las caractersticas especificadas como parte del modelo de
requerimientos, de manera que da valor al usuario final?
Calidad del desempeo.
91. Dimensiones de la Calidad: El software tiene caractersticas que
sorprenden y agradan la primera vez que lo emplean los usuarios finales?
Calidad de las caractersticas.
92. Dimensiones de la Calidad: El software proporciona todas las
caractersticas y capacidades sin fallar?
Confiabilidad.
93. Dimensiones de la Calidad: El software concuerda con los estndares
locales y externos que son relevantes para la aplicacin?
Conformidad.

94. Dimensiones de la Calidad: El software puede recibir mantenimiento o

corregirse sin la generacin inadvertida de eventos colaterales?
Durabilidad.
95. Dimensiones de la Calidad: Existe la posibilidad de que el software reciba
mantenimiento o correcciones en un periodo de tiempo aceptablemente breve?
Servicio.
96. Dimensiones de la Calidad: Posee cierta elegancia, un flujo nico y una
presencia obvia.
Esttica.
97. Factores de la Calidad de McCall: Grado en el que un programa satisface
sus especificaciones y en el que cumple con los objetivos de la misin del
cliente.
Correccin.
98. Factores de la Calidad de McCall: Grado en el que se espera que un
programa cumpla con su funcin y con la precisin requerida.
Confiabilidad.
99. Factores de la Calidad de McCall: Cantidad de recursos de cmputo y de
cdigo requeridos por un programa para llevar a cabo su funcin.
Eficiencia.
100. Factores de la Calidad de McCall: Grado en el que es posible controlar el
acceso de personas no autorizadas al software o a los datos.
Integridad.
101. Factores de la Calidad de McCall: Esfuerzo que se requiere para aprender,
operar, preparar las entradas e interpretar las salidas de un programa.
Usabilidad.
102. Factores de la Calidad de McCall: Esfuerzo requerido para detectar y
corregir un error en un programa.
Facilidad de recibir mantenimiento.

103. Factores de la Calidad de McCall: Esfuerzo necesario para modificar un

programa que ya opera.
Flexibilidad.
104. Factores de la Calidad de McCall: Esfuerzo que se requiere para probar
un programa a fin de garantizar que realiza la funcin que se pretende.
Susceptibilidad de someterse a pruebas.
105. Factores de la Calidad de McCall: Esfuerzo que se necesita para transferir
el programa de un ambiente de sistema de hardware o software a otro.
Portabilidad.
106. Factores de la Calidad de McCall: Grado en el que un programa puede
volverse a utilizar en otras aplicaciones.
Reusabilidad.
107. Factores de la Calidad de McCall: Esfuerzo requerido para acoplar un
sistema con otro.
Interoperabilidad.
108. Factores de la Calidad ISO 9126: Grado en el que el software satisface las
necesidades planteadas segn las establecen los atributos siguientes:
adaptabilidad, exactitud, interoperabilidad, cumplimiento y seguridad.
Funcionalidad.
109. Factores de la Calidad ISO 9126: Cantidad de tiempo que el software se
encuentra disponible para su uso, segn lo indican los siguientes atributos:
madurez, tolerancia a fallas y recuperacin.
Confiabilidad.
110. Factores de la Calidad ISO 9126: Grado en el que el software es fcil de
usar, segn lo indican los siguientes subatributos: entendible, aprendible y
operable.
Usabilidad.

111. Factores de la Calidad ISO 9126: Grado en el que el software emplea

ptimamente los recursos del sistema, segn lo indican los subatributos
siguientes: comportamiento del tiempo y de los recursos.
Eficiencia.
112. Factores de la Calidad ISO 9126: Facilidad con la que pueden efectuarse
reparaciones al software, segn lo indican los atributos que siguen: analizable,
cambiable, estable, susceptible de someterse a pruebas.
Facilidad de recibir mantenimiento.
113. Factores de la Calidad ISO 9126: Facilidad con la que el software puede
llevarse de un ambiente a otro segn lo indican los siguientes atributos:
adaptable, instalable, conformidad y sustituible.
Portabilidad.
114. Atributos de la Interfaz: Intuitiva.
Grado en el que la interfaz sigue patrones esperados de uso, de modo que
hasta un novato la pueda utilizar sin mucha capacitacin.
115. Atributos de la Interfaz: Eficiencia.
Grado en el que es posible localizar o iniciar las operaciones y la
informacin.
116. Atributos de la Interfaz: Robustez.
Grado en el que el software maneja entradas errneas de datos o en el que
se presenta interaccin inapropiada por parte del usuario.
117. Atributos de la Interfaz: Riqueza.
Grado en el que la interfaz provee un conjunto abundante de
caractersticas.
118. El costo de la calidad.
Costos en los que se incurre al buscar la calidad o al realizar actividades
relacionadas con ella y los costos posteriores de la falta de calidad.

119. Costos de prevencin.

Costo de las actividades de administracin requeridas para planear y
coordinar todas las actividades de control y aseguramiento de la calidad.
120. Costos de evaluacin.
Incluyen las actividades de investigacin de la condicin del producto la
primera vez que pasa por cada proceso.
121. Costos de falla.
Son aquellos que se eliminaran si no hubiera errores antes o despus de
enviar el producto a los consumidores.
122. Defecto es un problema de calidad descubierto despus de haberse
liberado el software a los usuarios finales. V/F.
123. Error es un problema de calidad descubierto por ingenieros de software
antes de entregar el software al usuario final. V/F.
124. Esfuerzo (en horas-hombre) requerido para revisar un producto del trabajo
antes de la reunin de revisin real.
Esfuerzo de preparacin.
125. Esfuerzo requerido (en horas-hombre) que se dedica a la revisin real.
Esfuerzo de evaluacin.
126. Esfuerzo (en horas-hombre) que se dedica a la correccin de los errores
descubiertos durante la revisin.
Esfuerzo de la repeticin.
127. Apareamiento.
Tiempo medio entre fallas. Tiempo medio para la falla ms tiempo medio
para la reparacin.
Fallas en el tiempo. Medicin estadstica de cuntas fallas tendr un
componente en mil millones de horas de operacin.
Disponibilidad del software. Probabilidad de que un programa opere de
acuerdo con los requerimientos en un momento determinado de tiempo.