Universidad Hispanoamericana

Licenciatura en Ingeniería Informática

Enfasis en Sistemas de Información
CUARTA GENERACIÓN V INFO-126

Profesora: Lic. Yusselin Murcia Céspedes

Practica de Examen
Tiempo disponible: 3 Horas.
Periodo: III Cuatrimestre 2019
Fecha: 21 de octubre de 2019

Nombre del estudiante: Jorge Campos Sánchez

Instrucciones generales

1. Esta práctica es para resolver en clase y de manera individual.

2. Contestar aquí mismo y subirlo a moodle.

3. Sea claro y ordenado al dar sus respuestas.

I Parte
RESPUESTA CORTA
Valor 53 puntos, cada pregunta tiene su propio puntaje y aplica un punto cada acierto.
INSTRUCCIÓN: Escriba la palabra o palabras que se requieran para completar cada ítem
que se indica a continuación.

1. ¿Qué es ingeniería inversa?

a. “El análisis de un sistema para identificar sus componentes actuales y las
dependencias que existen entre ellos, para extraer y crear abstracciones de
dicho sistema e información de su diseño”. (Chrfofsky, 1990).
b. “El proceso de analizar el código, documentación y comportamiento de un
sistema para identificar sus componentes actuales y sus dependencias para
extraer y crear una abstracción del sistema e información de diseño. El
sistema en estudio no es alterado, sino que se produce conocimiento
adicional acerca del sistema” (SEI, 2004).

1
2. Mencione 3 caracteristicas que deben de tener los sistemas para poderles aplicar
la ingeniería inversa
a. Documentación inexistencte o totalmente obsoleta
b. Programación en bloque de codigo muy grandes y/o sin estructurar
c. Inexistencia de documentación interna en los programas, o bien está es
incomprensible o está desfasada.
d. La aplicacioón cubre gran parte de los requisitos y del rendimiento
esperado.
e. La aplicacio está sujeta a cambios frecuentes, que puedan afectar a parte
del diseño.
f. Se prevé que la aplicación pueda tener aún larga vida.

3. ¿Qué es nivel de abstraccion en ingenieria inversa?

a. El nivel de abstracción de un proceso de ingeniería inversa y las
herramientas que se utilizan para realizar aluden a la sofiaticacion de a
información de diseño que se puede extraer del codigo fuente. El nivel de
abstracción ideal deberá ser lo más alto posible, el proceso de ingeniería
inversa debe ser capaz de deribar:
i. Sus representaciones de diseño de procedimiento
ii. La información de las estructuras de datos y de programas
iii. Modelos de flujos de datos y de control
iv. Modelos de entidades y de relaciones

4. ¿Qué es completitud?
a. La completitud de un proceso de ingenieria inversa alude al nivel de detalle
que se propociona en un determinado nivel de abstracción. En la mayoría
de los casos, la completitud decrece a medica que aumenta el nivel de
abstracción. Por ejemplo, dada un listado del codigo fuente, es
relativamente sencillo desarrollar una representación de diseño de
procedimientos completa.

5. ¿Que es interactividad?
a. La interactividad alude al grado con el cual el ser humano se “integra” con
las herramientas automatizadas para crear un proceso de ingeniería inversa
efectivo. En la mayoria de los casos, a medida que crece el nivel de
abastración, la interactividad deberá incrementarse, o si no la completitud
se vera reducida.

2
6. ¿Que es direccionalidad?
a. Si la direccionalidad del proceso de ingeniería inversa es monodireccional,
toda la información extraida del codigo fuente se proporcionará a la
ingenieria del software que podrá entonces utilizarla durante la actividad
de mantenimiento. Si la direccionalidad es bidireccional, entonces la
información se suministrará a una herramienta de reingeniería que
intentara reestructurar o regenerar el viejo programa.

7. ¿Que es proceso de ingeniería inversa?

a. El proceso de ingenieria inversa se representa de la siguiente forma. Antes
de poder comenzar poder comenzar las actividades de ingeniería, el código
fuente no estructurado (“sucio”) se reeestructura de modo que sólo
contenga las constructis de programación estructurados. Esto hace que el
codigo fuente sea más fácil de leer y que proporcione la base para todas las
actividades de ingenieria inversa posteriores.

8. Cite y defina el nombre de la norma para la documentación de software

a. Normas para la documentación de Software

b. El IEEE ha diseñado normas para la documentación de la industria del

software. Se le denomina IEEE 1063-2001, "Estándar para la
documentación de usuario de software", y detalla el contenido, la
arquitectura y la importancia de un manual de documentación del
software.

c. La Organización Internacional de Normalización y la Comisión

Electrotécnica Internacional (ISO e IEC, ídem) también han establecido
normas para la documentación del software. Sus estándares se llaman
ISO/IEC 18019-2004 e ISO/IEC TR 9294. Se ocupan de la documentación y la
gestión del software, respectivamente. Cada una de estas normas hace
hincapié en que la documentación es una parte integral del ciclo de vida del
software.

9. ¿Cual es el modelo de un proceso de reingenieria?

a. Análisis de inventario.
b. Reestructuración de documentos.
c. Ingeniería Inversa.
d. Reestructuración de código.

3
 e. Reestructuración de datos.
f. Ingeniería directa

10. ¿Que es reestructuración?

a. La reestructuración de software modifica el código fuente y/o los datos con
la intención de hacerlos sensibles a cambios futuros. En general, la
reestructuración no modifica la arquitectura global del programa. Tiende a
enfocarse sobre detalles de diseño de módulos individuales y sobre
estructuras de datos locales definidas dentro de módulos. Si el esfuerzo de
reestructuración se extiende más allá de las fronteras del módulo y abarca
la arquitectura del software, la reestructuración se convierte en ingeniería
hacia delante

11. ¿Que es reestructuración de código?

a. La reestructuración de código se realiza para producir un diseño que
produzca la misma función pero con mayor calidad que el programa
original. En general, las técnicas de reestructuración de código (por
ejemplo, las técnicas de simplificación lógica de Warnier [War74]) modelan
la lógica del programa usando álgebra booleana y luego aplican una serie
de reglas de transformación que producen lógica reestructurada. El
objetivo es tomar una “ensalada” de código y derivar un diseño
procedimental que se conforme con la filosofía de programación
estructurada.

12. ¿Que es reestructuración de datos?

a. Antes de que pueda omenzar la reestructuración de datos debe realizarse
una actividad de ingeniería inversa llamada análisis de código fuente. Se
evalúan todos los enunciados de lenguaje de programación que contienen
definiciones de datos, descripciones de archivo I/O y descripciones de
interfaz.
b. La intención es extraer ítems de datos y objetos, obtener información
acerca del flujo de datos y entender las estructuras de datos existentes que
se implementaron. Esta actividad en ocasiones se llama análisis de datos.
Una vez completado el análisis de datos, comienza el rediseño de datos. En
su forma más simple, un paso de estandarización de registro de datos
clarifica las definiciones de los datos para lograr consistencia entre
nombres de ítem de datos o formatos de registro físico dentro de una
estructura de datos existente o dentro de un formato de archivo.

13. ¿Que es análisis de inventarios?

a. El análisis de inventario es parte del proceso de reingeniería de procesos.

4
 b. Toda organización de software debe tener un inventario de todas las
aplicaciones. El inventario puede ser hojas de cálculo que contenga
información detallada de: tamaño, edad, importancia,
c. esfuerzo para aplicar estos cambios (horas/hombre)
- fecha último cambio
- sistema en que reside
- aplicaciones con las cuales tiene relación
- base de datos a las que accede
- errores presentados en los últimos 18 meses
- número de usuarios
- números de equipos en los que está instalado
- complejidad: arquitectura, código, documentación
- calidad de la documentación
- mantenibilidad general
- longevidad del proyecto
- costo anual de mantenimiento
- costo anual de funcionamiento
- valor anual de negocios
- importancia para el negocio
d. empresarial de cada aplicación activa. Al ordenar esta información de
acuerdo con importancia empresarial, longevidad, mantenibilidad actual,
soportabilidad y otros importantes criterios locales, aparecen los
candidatos para reingeniería. Entonces pueden asignarse recursos a esas
aplicaciones.
e. Es importante observar que el inventario debe revisarse con regularidad. El
estado de las
f. aplicaciones (por ejemplo, importancia empresarial) puede cambiar con el
tiempo y, como resultado, cambiarán las prioridades para aplicar la
reingeniería.

14. ¿Que es medida?

a. Proporciona una indicación cuantitativa de la cantidad de dimensiones o
tamaño de algunos atributos de un producto

15. ¿Que es medición?

a. Acto de determinar una medida

16. ¿Que es métrica?

a. Es una medida del grado en que un sistema, componente o proceso posee
un atributo dado.

17. Cite las 3 “C” del ¿medir para que?

a. Conocer

5
 b. Controlar
c. Comunicar

18. Cite y describa la clasificación de las métricas de software según los criterios
a. De complejidad: Métricas que definen la medición de la complejidad:
volumen, tamaño, anidaciones y configuración.
b. De calidad: Métricas que definen la calidad del software: Exactitud,
estructuración o modularidad, pruebas, mantenimiento.
c. De competencia: Métricas que intentan valorar o medir las actividades de
productividad de los programadores con respecto a su certeza, rapidez,
eficiencia y competencia.
d. De desempeño: Métricas que miden la conducta de módulos y sistemas de
un software, bajo la supervisión del SO o Hardware.
e. Estilizadas: Métricas de experimentación y de preferencia: estilo de código,
convenciones, limitaciones, etc.

19. ¿Que son métricas de proceso?

a. Se recopilan de todos los proyectos, y durante un largo período de tiempo.

20. ¿Que son métricas de proyecto?

a. Permiten evaluar el estado del proyecto y permiten seguir la pista de los
riesgos.

21. ¿Que son métricas de producto?

a. Se centran en las características del software y no en como fue producido.
Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad, y el
esfuerzo.

22. Cite y defina modelos para medir la calidad del software

a. MODELO MCCAL
i. Conocido como modelo de factores/criterios/métricas.
ii. Se focaliza en el producto de software.
iii. Identifica atributos (llamados factores de calidad) claves desde el
punto de vista del usuario.
b. MODELO DE DROMEY
i. Resalta el hecho de que la calidad del producto es altamente
determinada por los componentes del mismo (documentos, guías
de usuarios, diseño, código).
ii. Se sugiere el uso de tres categorías que son correctitud, internas,
contextuales y descriptivas.

6
 c. MODELO DE FRUPS
i. Basado en el modelo Mccal.
ii. Funcionalidad, usabilidad, confiabilidad, desempeño y capacidad de
soporte.
iii. Se utilizan para establecer métricas de la calidad para todas las
actividades de proceso de desarrollo de un software, inclusive de un
sistema de información.
d. MODELO PARADIGMA CQM (GOAL – QUESTION - METRIC)
i. Paradigma que permite evaluar la calidad del producto y del
proceso.
ii. Evalúa la calidad del software basado en la identificación de
objetivos a lograr.
e. MODELO CMM (CAPABILITY MADYRITY MODEL)
i. Evalúa los procesos de desarrollo.
ii. Orientado a la mejora de procesos de desarrollo de software.
iii. Describe prácticas que conducen a mejores productos de software.
iv. Ofrece un conjunto de prácticas importantes que deben de ser
implantadas por cualquier entidad de software.

23. ¿Que es la auditoría de la configuración?

a. Una auditoría es una verificación independiente de un trabajo o del
resultado de un trabajo o grupo de trabajos para evaluar su conformidad
respecto de especificaciones, estándares, acuerdos contractuales u otros
criterios. La auditoría de la Configuración es la forma de comprobar que
efectivamente el producto que se está construyendo es lo que pretende
ser.

24. ¿Cómo puede un equipo de software asegurarse de que el cambio se implementó

adecuadamente?
a. La respuesta es doble:
i. Revisiones técnicas.
ii. Auditoría a la configuración del software.

25. ¿Que son revisiones técnicas?

a. La revisión técnica se enfoca en la exactitud técnica del objeto de
configuración que se modificó. Los revisores valoran el ICS para determinar
la consistencia con otros ICS, así como omisiones o potenciales efectos
colaterales. Una revisión técnica debe realizarse para todos los cambios,
salvo los más triviales.

7
26. ¿Que es auditoría a la configuración del software?
a. Una auditoría de configuración del software complementa la revisión
técnica al valorar un objeto de configuración acerca de las características
que por lo general no se consideran durante la revisión.

27. Cite y defina actividades de la auditoría de la configuración

a. Revisiones de fase: Se realizan al finalizar cada fase del desarrollo y su
objetivo es examinar los productos de dicha fase.
i. El objetivo de esta revisión es descubrir problemas, no comprobar
que todo está bien.
ii. Hay que ser capaz de desenmascarar los problemas ocultos y sutiles,
no sólo los que son obvios.
b. Revisiones de cambios: Se realizan para comprobar que los cambios
aprobados sobre una línea base se han realizado correctamente.
c. Auditorías: Se realizan al final del proceso de desarrollo de software y su
objetivo es examinar el producto en su conjunto.

28. Cite y defina los tipos de auditorías de la configuración

a. Auditoría Funcional: Cuyo objetivo es comprobar que se han completado
todos los tests necesarios para el Elemento de Configuración auditado,
además según los resultados verificar si satisface los requisitos que se
impusieron sobre él.
b. Auditoría Física: Cuyo objetivo es verificar la adecuación, completitud y
precisión de la documentación que constituye las líneas base de diseño y de
producto.
c. Revisión Formal de Certificación: Cuyo objetivo es certificar que el
Elemento de Configuración del Software se comporta correctamente una
vez que éste se encuentra en su entorno operativo.

29. ¿Qué es control de versiones?

a. Se llama control de versiones a la gestión de los diversos cambios que se
realizan sobre los elementos de algún producto o una configuración del
mismo. Una versión, revisión o edición de un producto, es el estado en el
que se encuentra el mismo en un momento dado de su desarrollo o
modificación.

30. ¿Qué es sistema de control de versiones?, de un ejemplo

a. Es un sistema que registra los cambios realizados sobre un archivo o
conjunto de archivos a lo largo del tiempo de tal manera que sea posible
recuperar versiones especificas más adelante. Algunos ejemplos de ellos
son:

8
 i. Git
ii. Mercurial
iii. Plastic SCM.

31. Cite y defina los tipos de sistemas control de versiones

a. Tipo Local: Los sistemas de control de versiones locales en vez de mantener
las versiones como archivos independientes, los almacena en una base de
datos local o personal, llámese un disco duro externo.
b. Tipo Centralizado: En vez de almacenar los cambios y versiones en el disco
duro de los desarrolladores, estos se almacenaban en un servidor remoto.
c. Tipo Distribuido: Al no existir un repositorio central, cada desarrollador
puede trabajar a su propio ritmo, almacenar los cambios a nivel local y
mezclar los conflictos que se presenten solo cuando se requiera. Cómo
cada usuario tiene una copia completa del proyecto el riesgo por una caída
del servidor, un repositorio dañado o cualquier otro tipo de perdida de
datos es mucho menor que en cualquiera de sus predecesores.

32. ¿Qué es la gestión de cambios?

a. La gestión de cambios es esencial al momento de tener control sobre todos
los elementos generados por los integrantes del equipo de proyecto. Este
control ayuda a eliminar la posibilidad de confusiones que pueden resultar
de alto costo para el proyecto y asegurar que no existan inconsistencias en
el sistema desarrollado

33. Cite y defina las etapas del proceso de gestión de cambios

a. Identificación: se deben nombrar cada uno de los elementos que
intervienen mediante un enfoque orientado a objetos.
b. Control de la versión: combina procedimientos y herramientas para
gestionar diferentes versiones de objetos que se crean durante el proceso
del software
c. Control de cambio: se deben crear procesos para generar cambios al
sistema, donde se debe evaluar el impacto y otros aspectos.

34. ¿Cuales son los elementos de un sistema de gestión de cambios?

a. Elementos de componentes: herramienta que permite el acceso y gestión
de cada elemento de GC ejemplo: Base de datos
b. Elementos de proceso: serie de procedimientos y tareas que definen un
enfoque eficaz con el cual gestionar el cambio

9
 c. Elementos de construcción: Conjunto de herramientas que automatizan la
construcción del software al asegurar que se ha ensamblado un conjunto
de componentes validos de software
d. Elementos humano: que el equipo utilice las herramientas y procesos para
GC.

35. ¿Qué son métricas de calidad de software?

a. Antes de presentar una serie de métricas de producto que 1) auxilien en la
evaluación de los modelos de análisis y diseño, 2) proporcionen un indicio
de la complejidad de los diseños procedimentales y del código fuente y 3)
faciliten el diseño de pruebas más efectivas, es importante comprender los
principios de medición básicos

36. ¿Qué es formulación?

a. La derivación de medidas y métricas de software apropiadas para la
representación del software que se está construyendo

37. ¿Qué es recolección?

a. Mecanismo que se usa para acumular datos requeridos para derivar las
métricas formuladas

38. ¿Qué es análisis

a. El cálculo de métricas y la aplicación de herramientas matemáticas

39. ¿Qué es interpretación?

a. Evaluación de las métricas resultantes para comprender la calidad de la
representación

40. ¿Que es retroalimentación?

a. Recomendaciones derivadas de la interpretación de las métricas del
producto, transmitidas al equipo de software.

41. Cite y defina las métricas para el modelo de análisis.

a. Estas métricas atienden varios aspectos de la etapa de análisis en donde se
incluyen:
i. Funcionalidad entregada: Proporciona una medida indirecta de la
funcionalidad que se empaqueta con el software.
ii. Tamaño del sistema: Mide el tamaño general del sistema, definido
desde el punto de vista de la información disponible como parte del
modelo de análisis.

10
 iii. Calidad de la especificación: Proporciona un indicador específico o
el grado en que se ha completado la especificación de los requisitos.

42. Cite y defina métricas para el modelo de diseño.

a. Estas métricas cuantifican los atributos del diseño de manera tal que le
permiten al ingeniero de software evaluar la calidad del diseño, la métrica
incluye:
b. Métricas arquitectónicas: Proporcionan un indicio de la calidad del diseño
arquitectónico.
c. Métricas al nivel de componente: Mide la complejidad de los componentes
del software y otras características que impactan la calidad.
d. Métricas de diseño de la interfaz: Se concentran principalmente en la
facilidad de uso.
e. Métricas especializadas en diseño orientado a objetos: Miden
características de clases, además de las correspondientes a comunicación y
colaboración.

43. Cite y defina métricas para el código fuente.

a. Estas métricas miden el código fuente y se usan para evaluar su
complejidad, además de la facilidad con que se mantiene y prueba entre
otras características como:
i. Métricas de complejidad: Miden la complejidad lógica del código
fuente.
ii. Métricas de longitud: Proporcionan un indicio del tamaño del
software.
iii. Modelo de Medición de Calidad – Pasos Sugeridos:
1. Identificación de requisitos de calidad
2. Especificación de la evaluación
3. Diseño de la evaluación
4. Ejecución de la evaluación
5. Retroalimentación a la organización

44. Cite y defina métricas para pruebas.

a. Estas métricas ayudan a diseñar casos de prueba efectivos y evaluar la
eficacia de las pruebas en donde se incluyen:
i. Métricas de cobertura de instrucciones y ramas. Lleva al diseño de
casos de prueba que proporcionan cobertura del programa.
ii. Métricas relacionadas con los defectos. Se concentran en encontrar
defectos y no en las propias pruebas.
iii. Efectividad de la prueba. Proporciona un indicio en tiempo real de
la efectividad y de las pruebas aplicadas.
iv. Métricas en el proceso. Métricas relacionadas con el proceso de las
pruebas.

11
45. ¿Qué es proceso de la gestión de la configuración del software?
a. Conjunto de procesos destinados a asegurar la calidad de todo producto
obtenido durante cualquiera de las etapas del desarrollo de un Sistema de
Información (S.I.), a través del estricto control de los cambios realizados
sobre los mismos y de la disponibilidad constante de una versión estable de
cada elemento para toda persona involucrada en el citado desarrollo.

46. Cite las capas de la gestión de la configuración del software.

a. Identificación
b. Control del cambio
c. Control de la versión
d. Auditoría de la configuración
e. Reporte

47. ¿Cuál es el objetivo de la gestión de la configuración del software?

a. Identificar todos los elementos que definen la configuración del software.
Se trata de establecer estándares de documentación y un esquema de
identificación de documentos.
b. Gestionar los cambios a los elementos identificados. Consiste en la
evaluación y registro de todos los cambios que se hagan de la configuración
software.
c. Facilitar la construcción de versiones. - Sirven, junto con las revisiones
técnicas formales para garantizar que el cambio se ha implementado
correctamente.
d. Garantizar que la calidad del software se conserve durante la evolución.

48. ¿Qué son pruebas del software?

a. Son una serie de actividades que se realizan con el propósito de encontrar
los posibles fallos de implementación, calidad o usabilidad de un programa
u ordenador; probando el comportamiento del mismo.

49. ¿Cuáles son los objetivos de pruebas del software?

a. Detectar defectos en el software.
b. Verificar la integración adecuada de los componentes.
c. Verificar que todos los requisitos se han implementado correctamente.
d. Identificar y asegurar que los defectos encontrados se han corregido antes
de entregar el software al cliente.
e. Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes
clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

50. ¿Cuales son las etapas de la prueba del software?

12
 a. d Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su
objetivo, para qué exactamente se hace la prueba.
b. Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va
a utilizar para medir la calidad y qué clase de elementos de prueba se
deben usar.
c. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos
o situaciones de prueba que se utilizarán para ejecutar la unidad que se
prueba o para revelar algo sobre el atributo de calidad que se está
midiendo.
d. Determinar cuáles deberían ser los resultados esperados de los casos de
prueba y crear el documento que los contenga.
e. Ejecutar los casos de prueba.

51. Cite y defina los tipos de pruebas de software

a. Pruebas funcionales
i. Se entiende como las Funcionalidades del Sistema cómo “lo que el
sistema hace”.
ii. Las Funcionalidades pueden estar descritas en las especificaciones
de requerimientos, especificaciones funcionales, casos de uso e
inclusive no estar documentadas.
iii. Los casos de prueba se definen a partir de estas funciones o
características, así como su interoperabilidad entre sistemas.
iv. Consideran el comportamiento externo del sistema por lo que se
consideran pruebas de caja negra.
b. Pruebas no funcionales de software
i. Su objetivo es probar los requerimientos no funcionales, incluyendo
(sin limitarse a) pruebas de: Desempeño, Carga, Estrés, Usabilidad,
Mantenibilidad, Confiabilidad y Portabilidad.
ii. Los requerimientos no funcionales representan “cómo funciona el
sistema” (en contraposición con las funcionalidades que definen “lo
que el sistema hace”).
iii. Las características no funcionales del software, se pueden medir de
diversas maneras, por ejemplo por medio de tiempos de respuesta
en el caso de pruebas de desempeño.
iv. Pueden hacer referencias a modelos de calidad, como por ejemplo
ISO 9126.
v. Consideran el “comportamiento externo” del sistema, en la mayoría
de los casos son pruebas de caja negra.
c. Pruebas de la estructura o arquitectura del Software
i. Las Pruebas Estructurales es el término usado para las pruebas de
“Caja Blanca”.
ii. Se realizan aplicando técnicas de pruebas estructurales y técnicas
estáticas, en lugar de técnicas basadas en especificación.

13
 iii. Utiliza el concepto de “Cobertura” para definir la extensión con la
cual la estructura ha sido cubierta por el conjunto de pruebas,
expresado como un porcentaje del elemento probado.
iv. Si la cobertura no es del 100%, se pueden diseñar pruebas
adicionales.
v. Las pruebas estructurales se basan en la arquitectura del sistema,
por ejemplo arquitectura de “Jerarquía de llamadas”.

d. Pruebas de mantenimiento
i. Aplicadas sobre sistemas que están operativos en ambiente de
producción.
ii. Se ejecutan como resultado de modificaciones, migraciones o
desincorporación de software.
iii. Las Pruebas de Modificaciones incluyen mejoras planificadas,
correctivas o de emergencia, así como cambios en el entorno de
sistema operativo, bases de datos, actualizaciones o parches.
iv. Pueden ser difíciles de realizar si las especificaciones están
desactualizadas o no existen, o si no se cuenta con Testers con
conocimiento del sistema.

14