Solier Ramos, Roger
Solier Ramos, Roger
Solier Ramos, Roger
De Ingeniería De Sistemas
Ayacucho - Perú
2013
CONTENIDO
DEDICATORIA i
AGRADECIMIENTO ii
RESUMEN iii
INTRODUCCIÓN iv
CAPITULO I
PLANTEAMIENTO DE LA INVESTIGACIÓN
1.1 FUNDAMENTACION DEL PROBLEMA 1
1.2 FORMULACIÓN DEL PROBLEMA 3
1.3 OBJETIVOS DE LA INVESTIGACIÓN 3
1.4 HIPÓTESIS DE LA INVESTIGACIÓN 4
1.5 JUSTIFICACION Y DELIMITACIÓN DE LA INVESTIGACIÓN 4
1.5.1 JUSTIFICACION DE LA INVESTIGACIÓN 4
1.5.2 DELIMITACION DE LA INVESTIGACIÓN 5
CAPITULO II
REVISIÒN DE LITERATURA
2.1 ANTECEDENTES DE LA INVESTIGACIÓN 6
2.2 MARCO TEÓRICO 7
2.2.1 ARTEFACTOS DEL SOFTWARE 7
2.2.2 MANTENIMIENTO DEL SOFTWARE 9
2.2.3 CÓDIGO ESTÁTICO Y EJECUTABLE 9
2.2.4 ANÁLISIS Y DISEÑO 10
2.2.5 FUNCIONALIDAD DEL SOFTWARE 11
2.2.6 INGENIERIA INVERSA 12
2.2.7 PROGRAMACIÓN EXTREMA ( XP) 17
i
CAPITULO III
METODOLOGÍA DE LA INVESTIGACIÓN
3.1 TIPO DE INVESTIGACIÓN 30
3.2 DISEÑO DE LA INVESTIGACIÓN 30
3.3 POBLACIÓN Y MUESTRA 30
3.4 VARIABLES E INDICADORES 30
3.5 TÉCNICAS E INSTRUMENTOS 32
3.5.1 INSTRUMENTO PARA RECOLECTAR INFORMACIÓN 32
3.5.2 TÉCNICA PARA APLICAR INGENIERIA INVERSA 33
3.5.3 TÉCNICA PARA APLICAR XP 34
CAPITULO IV
RESULTADOS DE LA INVESTIGACIÓN
4.1 RESULTADOS
CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
5.1 RECOMENDACIONES
5.2 BIBLIOGRAFIA
5.3 ANEXO
i
i
ii
RESUMEN
iii
INTRODUCCIÓN
iv
CAPITULO I
PLANTEAMIENTO DE LA INVESTIGACIÓN
"El mantenimiento de software consume entre 60% y 80% de los costos totales del
ciclo de vida"(Gerardo, Aniello, 2000).
Como vemos el mantenimiento del software es una etapa crítica, sin una
adecuada documentación y sin la conciencia de la importancia de esto,
la mantenibilidad de un sistema podría determinar el éxito o fracaso del
sistema, y porque no decirlo también de la empresa.
5
aplicación, y durante la que se deben hacer toda clase de cambios,
alteraciones y mejoras, es la del mantenimiento.
6
las mejores técnicas de diseño y codificación existentes en su momento, se
construyeron con restricciones de tamaño y espacio de almacenamiento y
se desarrollaron con herramientas tecnológicamente desfasadas.
PROBLEMAS SECUNDARIOS
8
la etapa más prolongada y la que más costos genera, no es difícil imaginar
que estos costos serían mucho más grandes si no contamos con una
documentación adecuada del sistema.
DELIMITACION TEÓRICA
9
CAPITULO II
REVISIÓN DE LITERATURA
10
Debido a que no hay un documento que especifique como es
exactamente un proceso de ingeniería inversa, cada ingeniero de
software que desea realizar un proceso de este tipo propone su propia
metodología. El instituto de ingeniería de software propone un marco de
trabajo para llevar a cabo un proceso de ingeniería inversa (SEI, 2004).
11
o el diseño de un software los artefactos más comunes para realizar esta
tarea es el de Caso de Uso, Diagrama de Clase y algunos modelos de
UML. Otros modelos se enfocan en el proceso de desarrollo de sí mismo
como un plan de proyecto, entre ellos tenemos Caso de Negocio o
enfoque de riesgo. Existen ocasiones en el que los artefactos son
productos terminados, como el código o el ejecutable (Carpio, 2010).
12
supone más del doble que los costes de su desarrollo. La tendencia es
creciente con el paso del tiempo (Pressman, 1993).
13
Entre los usos más difundidos de la ingeniería inversa se
encuentran: la documentación de aplicaciones con deficientes fases
de análisis y diseño, con el fin de facilitar el mantenimiento y la
corrección de efectos que el software pueda presentar; la adquisición
de conocimiento de un producto de software, revelando los detalles
estructurales y de comportamiento que se encuentran dispersos u
ocultos, ofreciendo mayor independencia entre el producto de
software y sus constructores; finalmente, el apoyo al aseguramiento de
la calidad del software, al facilitar la comparación de los diagramas de
análisis y diseño contra los diagramas generados mediante el proceso
de ingeniería inversa. (Tonella,Potrich, 2005).
14
siguiente manera: Entidades; Se refieren a los conceptos, personas,
objetos o cosas de los cuales el sistema necesite guardar información.
Las forman los sustantivos más relevantes encontrados en la narrativa
del negocio. Por tratarse de un concepto o abstracción, suele utilizarse
un sustantivo en singular para nombrar la entidad. Se simbolizan usando
un rectángulo con los bordes redondeados. Atributos; Constituyen cada
una de las características asociadas a una entidad; gramaticalmente
los atributos se buscan en los adjetivos que califican a las entidades. Se
simbolizan colocando su nombre dentro del rectángulo de la respectiva
entidad. Relaciones: Muestran la forma en que dos entidades se
asocian; gramaticalmente las relaciones se pueden encontrar dentro
de la narrativa del negocio como verbos conjugados, preposiciones,
conjunciones u otros elementos que unen dos de los sustantivos que
representan entidades. Las relaciones se representan como líneas que
unen las dos entidades implicadas (Pressman, 2003).
15
a. El nivel de abstracción: El nivel de abstracción de un proceso de
ingeniería inversa y las herramientas que se utilizan para realizarlo aluden
a la sofisticación de la información de diseño que se puede extraer del
código fuente. El nivel de abstracción ideal deberá ser lo más alto
posible. Esto es, el proceso de ingeniería inversa deberá ser capaz de
derivar sus representaciones de diseño de procedimientos (con un bajo
nivel de abstracción); y la información de las estructuras de datos y de
programas (un nivel de abstracción ligeramente más elevado); modelos
de flujo de datos y de control (un nivel de abstracción relativamente
alto); y modelos de entidades y de relaciones (un elevado nivel de
abstracción). A medida que crece el nivel de abstracción se
proporciona al ingeniero del software información que le permitirá
comprender más fácilmente estos programas.
b. La completitud: La completitud de un proceso de ingeniería
inversa alude al nivel de detalle que se proporciona en un determinado
nivel de abstracción. En la mayoría de los casos, la completitud decrece
a medida que aumenta el nivel de abstracción. Por ejemplo, dado un
listado del código fuente, es relativamente sencillo desarrollar una
representación de diseño de procedimientos completa. También se
pueden derivar representaciones sencillas del flujo de datos, pero es
mucho más difícil desarrollar un conjunto completo de diagramas de
flujo de datos o un diagrama de transición de estados. La completitud
mejora en proporción directa a la cantidad de análisis efectuado por la
persona que está efectuando la ingeniería inversa.
c. La Interactividad: 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 mayoría de los casos, a
medida que crece el nivel de abstracción, la interactividad deberá
incrementarse, o sino la completitud se verá reducida.
d. La direccionalidad: Si la direccionalidad del proceso de ingeniería
inversa es monodireccional, toda la información extraída del código
fuente se proporcionará a la ingeniería del software que podrá
16
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 intentará reestructurar o
regenerar el viejo programa.
Fases de la Ingeniería Inversa: El núcleo de la ingeniería inversa es una
actividad denominada extracción de abstracción. El ingeniero tiene
que evaluar el viejo programa y a partir del código fuente (que no suele
estar documentado) tiene que extraer una especificación significativa
del procesamiento que se realiza, la interfaz de usuario que se aplica y
las estructuras de datos de programa o de base de datos que se utiliza.
17
aplicaciones representará una abstracción funcional con un elevado
nivel de detalle. También se creará un diagrama de bloques como
representación de la iteración entre estas abstracciones funcionales.
Cada uno de los componentes efectúa una subfunción, y representa
una abstracción definida de procedimientos. En cada componente se
crea una narrativa de procesamiento. En algunas situaciones ya existen
especificaciones de sistema, programa y componente. Cuando ocurre
tal cosa, se revisan las especificaciones para preciar si se ajustan al
código existente. Todo se complica cuando se considera el código que
reside en el interior del componente. El ingeniero busca las secciones de
código que representan las configuraciones genéricas de
procedimientos. En casi todos los componentes, existe una sección de
código que prepara los datos para su procesamiento (dentro del
componente), una sección diferente de código que efectúa el
procesamiento y otra sección de código que prepara los resultados del
procesamiento para exportarlos de ese componente. En el interior de
cada una de estas secciones, se encuentran configuraciones más
pequeñas.
18
casos, la organización de datos en el seno del código identifica los tipos
abstractos de datos. Por ejemplo, las estructuras de registros, los
archivos, las listas y otras estructuras de datos que suelen proporcionar
una indicación inicial de las clases. Para la ingeniería inversa de clases,
se podría sugerir el enfoque siguiente: Identificación de los indicadores y
estructuras de datos locales dentro del programa que registran
información importante acerca de las estructuras de datos globales,
Definición de la relación entre indicadores y estructuras de datos locales
y las estructuras de datos globales, Para toda variable (dentro de un
programa) que represente una matriz o archivo, la construcción de un
listado de todas las variables que tengan una relación lógica con ella.
19
volviendo de rigor para los productos basados en computadoras y para
los sistemas de todo tipo. Por tanto el nuevo desarrollo de interfaces de
usuario ha pasado a ser uno de los tipos más comunes de las
actividades de reingeniería. Ahora bien, antes de que se pueda
reconstruir una interfaz de usuario, deberá tener lugar una actividad de
ingeniería inversa.
20
información de diseño. El sistema en estudio no es alterado, sino que se
produce conocimiento adicional acerca del sistema” (SEI, 2004).
21
“La Programación Extrema (XP) es un nuevo enfoque de peso ligero
para el desarrollo del software, XP utiliza la información rápida y de gran
ancho de banda de la comunicación a fin de maximizar el valor
entregado, a través de una inspección sobre el cliente, un enfoque
particular de planificación, y probando constantemente” (Wake, 2000).
22
Figura Nº 02: Proyecto de la Programación Extrema
23
B. El papel del programador
“Los programadores analizan, diseñan, prueban el programa, e
integran el sistema. Los programadores estiman la dificultad de todas las
historias, y realizan el seguimiento del ritmo al que puede ofrecer las
historias para el cliente”( Ron, Ann y Chet,2000).
26
sistema, y los programadores crean pruebas unitarias en la
programación”.
27
nuestras primeras pruebas unitarias entonces sabemos cuándo se
realizan, el plazo de todas las pruebas unitarias.
PRUEBAS DE ACEPTACIÓN
Las pruebas de aceptación son creadas a partir de las historias de
usuario que son seleccionados en la reunión de planificación de
iteración y se traducirá en pruebas de aceptación. El cliente especifica
los escenarios para pruebas cuando una historia de usuario ha sido
aplicada correctamente. Una historia puede tener una o varias pruebas
de aceptación.
28
Una historia de usuario no se considerará completa hasta que ha
pasado pruebas de aceptación. Esto significa que las nuevas pruebas
de aceptación se deben crear en cada iteración.
Resultado Esperado:
Evaluación de la Prueba:
Fuente: Ejemplo de desarrollo software utilizando la metodología XP, LSI-PSW-LDS Departamento
Sistemas Informáticos y Computación (DSIIC) – Universidad Politécnica de Valencia, 2006.
29
CAPITULO III
METODOLOGÍA DE LA INVESTIGACIÓN
30
VARIABLE INDEPENDIENTE
VARIABLE DEPENDIENTE
31
DEFINICIÓN OPERACIONAL DE LAS VARIABLES
VARIABLE INDEPENDIENTE
VARIABLE DEPENDIENTE
Y: Mantenimiento de software
32
Matriz histórica de precios.- Formato para obtener la variación del
precio promedio del mantenimiento de software SIAC, de CACFMA, la
información obtenida entrevistando al área de contabilidad y finanzas.
33
3.5.3 TECNICA PARA APLICAR XP
34
CAPITULO IV
RESULTADOS DE LA INVESTIGACIÓN
35
BIBLIOGRAFÍA
36