UNIVERSIDAD TECNOLÓGICA COSTARRICENSE

U.T.C.

NOMBRE: CARLOS QUIROS DIAZ CÉDULA:114600294

TOTAL DEL PUNTOS: PUNTOS OBTENIDOS: NOTA: PORCENTAJE:

TTTTOTALTTTTtOTALTOTALES
CARRERA: ASIGNATURA: DOCENTE: Lic. Mario Pereira Granados
Bachillerato en Ingeniería en Ing del Software
Sistemas Computacionales

INSTRUCCIONES Y OBSERVACIONES
a) Este examen corresponde al segundo parcial del tercer cuatrimestre del 2021.
b) La prueba tiene un valor de 60 puntos.
c) El tiempo de duración de la prueba será de 1 semana.
d) El examen es en grupos de exposición
e) Será causal de anulación del examen las siguientes situaciones:

 Facilitar respuestas o comentarios a otros compañeros lo cual dará potestad

al profesor para la anulación de la prueba a quien solicite la información y a
quien la facilite.

Desarrollo

1- Lea el capítulo 15 detenidamente y desarrolle las 10 preguntas del

capítulo 15, que se encuentra en la página 367.

15.1. Explique la diferencia entre un error y un defecto.

Un defecto se podría definir como la versión incorrecta de algo. Es una imperfección.
Generalmente un defecto aparece una vez se ha puesto en producción un producto y
Un error una equivocación cometida por el desarrollador. Algunos ejemplos de errores
son: un error de digitación, una malinterpretación de un requerimiento o de la
funcionalidad de un método. Un error puede definirse como una idea falsa o
equivocada. Un programa no puede tener o estar en un error, ya que los programas no
tienen ideas; las ideas las tienen la gente.

15.2. ¿Por qué no puede esperarse a las pruebas para encontrar y corregir todos los
errores del software?
Es de buenas prácticas hacer las pruebas individuales y revisiones informales ya que si
el proyecto es demasiado grande y contiene muchas líneas de código se dificultaría
buscar un error especifico. Lo que afectaría el tiempo de entrega del proyecto y
disconformidad del cliente.
 15.3. Suponga que en el modelo de requerimientos se han cometido 10 errores y
que cada uno se amplificará en un factor de 2:1 en el diseño, y que se cometerán
otros 20 errores de diseño adicionales que luego se amplificarán en un factor de
1.5:1 en el código, donde se cometerán otros 30 errores adicionales. Suponga que
todas las pruebas unitarias encontrarán 30 por ciento de todos los errores, que la
integración descubrirá 30 por ciento de los restantes y que las pruebas de validación
hallarán 50 por ciento de los que queden. No se efectuarán revisiones. ¿Cuántos
errores saldrán al público?
Solo un 20% del proyecto es funcional y un 80% de todo el proyecto se encuentra
errores de programación, lógica y funcionalidad.

15.4. Vuelva a considerar la situación descrita en el problema 15.3, pero ahora

suponga que se realizan revisiones en los requerimientos, diseño y código, con 60
por ciento de eficacia en el descubrimiento de todos los errores en esa etapa.
¿Cuántos errores saldrán al público?
Tendríamos alrededor de un 20% de errores en dicho proyecto.

15.5. Estudie de nuevo la situación descrita en los problemas 15.3 y 15.4. Si cada
uno de los errores que salen al público tiene un costo de $4 800 por ser detectado y
corregido, y hacer lo mismo para cada error descubierto en la revisión cuesta $240,
¿cuánto dinero se ahorra por efectuar revisiones?
80 x 4800 = 384000
80 x 240 = 19200
$364 800 efectuando revisiones.

15.6. En sus propias palabras, describa el significado de la figura 15.4.

Hacer revisiones ayuda detectar y reducir los errores a la hora de entregar un
proyecto. Esto da confianza al cliente para nuevos proyectos.

15.7. ¿Cuál de las características del modelo de referencia piensa usted que tiene el
mayor efecto en la formalidad de la revisión? Explique por qué.
Ad-Hoc porque es una forma rápida de obtener otra perspectiva para encontrar
problemas programador no puede ver por sí mismo.
Revisión de pares esta involucra a una sola persona (de calidad) quien recibe una
copia del producto para su revisión. El revisor puede utilizar. checklists u otras técnicas
de análisis que incrementen la efectividad del proceso.
Revisión de pares múltiple es una revisión de pares realizada concurrentemente. El
producto a revisar es distribuido entre 3 y 15 personas quiénes revisan y dan su
devolución por separado. Una variante es compartir un documento donde los
revisores realicen sus comentarios para minimizar la redundancia y mostrar diferentes
interpretaciones de lo revisado.
Programación de a pares esta técnica consiste en dos desarrolladores trabajando en
un mismo producto simultáneamente, en una sola computadora, compartiendo un
teclado y un monitor. Uno hace de controlador y es el que efectivamente programa; el
otro es el navegador que observa el trabajo del controlador e identifica errores.
Presentación es una técnica donde el diseñador o desarrollador guía a los miembros
de un equipo a través del artefacto a revisar. Los participantes hacen preguntas o
comentarios sobre posibles anomalías, violación de estándares u otros problemas.
Revisión en equipo Comienza con una planificación seguida de una de preparación
donde los participantes reciben el material necesario varios días antes. Luego el
equipo (con roles definidos) se reúne para discutir los resultados donde participan el
 líder de revisión (puede ser el propio autor del artefacto revisado), registrador y
moderador (no puede ser del propio autor).

15.8. ¿Se le ocurren algunos casos en los que una verificación de escritorio genere
problemas en lugar de beneficios?
Si no se conoce el software, si no conocer la interfaz, si no se conocen los
requerimientos y no se diseña como tal. Se omitirían cosas. Lo cual generaría
disconformidad al cliente.

15.9. Una revisión técnica formal es eficaz sólo si cada quien se prepara por
adelantado. ¿Cómo se reconoce a un participante que no se haya preparado? ¿Qué
haría si usted fuera el líder de la revisión?
A cada participante se le entrega previamente copias del código o producto para que
lo conozca y lo examine. Si se cuestiona sobre algún tipo de funcionalidad o deja pasar
algún error que otro participante sí detectó, posiblemente no se haya preparado bien.
El líder de revisión, no debería tomar en cuenta su opinión y ni sus observaciones en
tal reunión, sin tocar el tema durante la revisión, por aparte debería pedir cuentas al
revisor para que se enfoque en sus obligaciones de calidad.

15.10. Al considerar todos los lineamientos para la revisión presentados en la sección

15.6.3, ¿cuál piensa que sea el más importante y por qué?
Todos son importantes para un buen resultado de revisión, debemos mantener
siempre un ambiente sano, enfocarse en el producto, establecer una agenda, evitar el
debate, hallar y listar los errores, asignar recursos de tiempo y personal especializado,
volver a revisar para hallar omisiones, todo esto es importante.
Sin embargo, la prioridad es hallar errores, sin buscar solucionarlos. Así el tiempo rinde
durante la sesión de revisión.

2- Lea el capítulo 21 detenidamente y desarrolle las siguientes

preguntas 21.1, 21.2, 21.3, 21.8, 21.9, 21.10, 21.11, 21.12.
21.1. Si tuviera que elegir un aspecto de la ingeniería del software de cuarto limpio
que la haga radicalmente diferente de los enfoques de ingeniería del software
convencional o de la orientada a objeto, ¿cuál sería?
Generación, inspección y verificación de código.  Para mis las revisiones técnicas aumentan la
calidad del software, limpian y optimizan el código y las estructuras de código, Las verificaciones
o inspecciones nos dan exactitud para el código fuente.

21.2. ¿Cómo trabajan en conjunto un modelo de proceso incremental y la

certificación para producir software de alta calidad? Como sabemos el modelo
incremental tiene como objetivo un crecimiento progresivo de la funcionalidad. El
producto va evolucionando con cada una de las entregas previstas hasta que se
amolda a lo requerido por el cliente o destinatario. Establece entregas parciales
mediante un calendario de plazos. Una de las claves para que esto se haga efectivo es
la evaluación de las etapas. Los responsables del proyecto deben analizar si los
resultados parciales son los esperados y si apuntan al objetivo principal. El producto
siempre debe mostrar una evolución con respecto a la fecha anterior; nunca puede ser
igual. También, es cabe mencionar características de este modelo que producen
calidad como lo son, los incrementos pequeños, la fácil administración de las tareas en
cada iteración, la inversión materializada a corto plazo y un modelo adaptado a
cambios o modificaciones.
 21.3. Con la especificación de estructura de cajas, desarrolle modelos de análisis y
diseño de “primer paso” para el sistema Casa Segura.

Desarrollo de un escenario preliminar de uso

La escena: Una sala de juntas, donde continúa la primera reunión para recabar los requerimientos.
Participantes: Jaime Lazar, integrante del equipo de software; Vinod Roman, miembro del equipo de
software; Ed Robbins, miembro del equipo software; Doug Miller, gerente de ingeniería del software;
tres personas de mercadotecnia; un representante de ingeniería del producto, y un facilitador.
La conversación:
Facilitador: Hemos estado hablando sobre la seguridad para el acceso a la funcionabilidad de
CasaSegura si ha de ser posible el ingreso por internet. Me gustaría probar algo. Desarrollemos un
escenario de uso para entrar a la función de seguridad.
Jamie: ¿Cómo?
Facilitador: Podríamos hacerlo de dos maneras, pero de momentos mantengamos las cosas informales.
Díganos (señala a una persona de mercadotecnia), ¿cómo visualiza el acceso al sistema.
Persona de mercadotecnia: Um… bueno, es la clase de cosa que haría si estuviera fuera de casa y
tuviera que dejar entrar a alguien a ella –por ejemplo, una trabajadora doméstica o un técnico de
reparaciones- que no tuviera el código de seguridad.
Facilitador (sonríe): Esa es la razón por la que lo hace… dígame, ¿cómo lo haría en realidad?
Persona de mercadotecnia: Bueno… lo primero que necesitaría sería una PC. Entraría a un sitio web que
mantendríamos para todos los usuarios de CasaSegura. Daría mi identificación de usuario y…
Vinod (interrumpe): La página web tendría que ser segura, encriptado, para garantizar que
estuviéramos seguros y…
Facilitador (interrumpe): Ésa es buena información, Vinod, pero es técnica. Concentrémonos en como
emplearía el usuario final esta capacidad, ¿está bien?
Vinod: No hay problema.
Persona de mercadotecnia: Decía que entraría a un sitio web y daría mi identificación de usuario y dos
niveles de clave.
Jamie: ¿Qué pasa si olvido mi clave?
Facilitador (interrumpe): Buena observación, Jamie, pero no entraremos a
ella por ahora y la llamaremos una excepción. Estoy seguro de que habrá otras.
Persona de mercadotecnia: Después de que introdujera las claves, aparecería una pantalla que
representaría todas las funciones CasaSegura. Seleccionaría la función de seguridad del hogar. El sistema
pediría que verificara quien soy, pidiendo mi dirección o número telefónico o algo así. Entonces
aparecería un dibujo del panel de control del sistema de seguridad y la lista de funciones que puede
realizar –activar el sistema, desactivar el sistema o desactivar uno o más sensores-. Supongo que
también me permitiría reconfigurar las zonas de seguridad y otras cosas como esa, pero no estoy
seguro.
(Mientras la persona de mercadotecnia habla, Doug toma muchas notas; esto forma la base
para el primer escenario informal de uso. Alternativamente hubiera podido pedirse a la
persona de mercadotecnia que escribiera el escenario, pero esto se hubiera hecho fuera de la
reunión.)

CasaSegura
Desarrollo de un diagrama de caso de uso de alto nivel

La escena: Una sala de juntas, donde continúa la reunión para recabar los requerimientos.
Participantes: Jaime Lazar, integrante del equipo de software; Vinod Roman, miembro del equipo de
software; Ed Robbins, miembro del equipo software; Doug Miller, gerente de ingeniería del software;
tres miembros de mercadotecnia; un representante de ingeniería del producto, y un facilitador.
La conversación:
Facilitador: Hemos pasado un buen tiempo hablando de la función de seguridad del hogar de
CasaSegura. Durante el receso hice un diagrama de caso de uso para resumir los escenarios importantes
que forman parte de esta función. Veámoslo.
(Todos los asistentes observan la figura 5.2)
Jamie: Estoy aprendiendo la notación UML. Veo que la función de seguridad del hogar del hogar está
representada por el rectángulo grande con óvalos en su interior, ¿verdad? ¿Y los óvalos representan los
casos de uso que hemos escrito?
Facilitador: Sí. Y las figuras pegadas representan a los actores –personas o cosas que interactúan con el
sistema según los describe el caso de uso… -; ¡ah! Usé el cuadrado para representar un actor que no es
persona.. en este caso, sensores.
Doug: ¿Es válido eso en UML?
Facilitador: La legalidad no es lo importante. El objetivo es comunicar información. Veo que usar una
figura humana para representar un equipo sería erróneo. Así que adopté las cosas un poco. No pienso
que genere problemas.
Vinod: Está bien, entonces tenemos narraciones de casos de uso para cada óvalo. ¿Necesitamos
desarrollarlas con base en los formatos obre los que he leído?
Facilitador: Es probable, pero eso puede esperar hasta que hayamos considerado otras funciones de
CasaSegura.
Persona de mercadotecnia: Esperen, he estado observando este diagrama y de pronto me doy cuenta
de que hemos olvidado algo.
Facilitador: ¿De verdad? Dime, ¿Qué hemos olvidado?
(La reunión continúa.)

21.8. Con sus palabras, describa la intención de la certificación en el contexto de la

ingeniería del software de cuarto limpio.

La intención la precisión, que las técnicas de control de calidad prevengan el defecto y

optimicen el software. La certificación asegura buenas prácticas aplicadas al desarrollo
del Software lógico, lo cual hace un proceso fiable y seguro.
Permite la mejora de proceso continua. Porque obliga a los equipos de diseño que
apliquen el desarrollo y las técnicas de revisión basados en métodos formales. Los
equipos de la prueba utilizan control de calidad estadístico para certificar la calidad del
sistema, en términos cliente significativos.

21.9. Al lector lo asignan a un equipo que desarrolla software para un fax módem. Su
labor es desarrollar la porción de “directorio” de la aplicación. La función directorio
permite el almacenamiento de hasta MaxNombres personas junto con los nombres de
compañía asociados, números de fax y otra información relacionada. Use lenguaje
natural para definir
a) La invariante de datos. MaxNombres
b) El estado. constante
c) Las probables operaciones. Iterador en aumento hasta que se cumpla MaxNombres

21.10. Al lector se le asigna a un equipo de software que desarrolla software, llamado

MemoriaDuplicador, que proporciona a una PC mayor memoria aparente que la
memoria física. Esto se logra al identificar, recopilar y reasignar bloques de memoria
que se asignaron a una aplicación existente, pero que no se utilizan. Los bloques no
utilizados se reasignan a aplicaciones que requieren memoria adicional. Realice las
suposiciones adecuadas y use lenguaje natural para definir
a) La invariante de datos. Capacidad máxima de memoria física
b) El estado. variable
c) Las probables operaciones. Aumenta y disminución de porciones de memoria
disponible.
21.11. Use la notación OCL o la Z que se presentó en las tabla 21.1 o 21.2, seleccione
alguna parte del sistema de seguridad CasaSegura descrito anteriormente en este libro
e intente especificarla con OCL o con Z.

21.12. Use una o más de las fuentes de información anotadas en las referencias o en
Lecturas adicionales y fuentes de información de este capítulo, para desarrollar una
presentación de media hora acerca de la sintaxis y la semántica básicas de un lenguaje
de especificación formal distinto a OCL o a Z.