Solier Ramos, Roger

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 39

UNIVERSIDAD NACIONAL DE SAN CRISTOBAL DE HUAMANGA

Facultad De Ingeniería De Minas, Geología Y Civil

Escuela De Formación Profesional

De Ingeniería De Sistemas

“construir los artefactos del software SIAC, para su mantenimiento, De la


Cooperativa De Ahorro Y Crédito De La Federación De Mercados
Ayacucho, 2012.”

Tipo de Investigación : Aplicada

Área de Investigación : Ingeniería Del Software

Estudiante : SOLIER RAMOS, Roger

Profesor : Msc.Ing. PORRAS FLORES, Efraín Elías

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

1.1. FUNDAMENTACION DEL PROBLEMA


Existen muchas empresas que no cuentan con un marco teórico
común que puedan ser usados por todas las personas que participan en el
desarrollo de los proyectos, muchas de estas empresas también priorizan la
fase de construcción (programación) y despliegue con la finalidad de
cumplir compromisos con el cliente, posponiendo y olvidando así el
registro y documentación de los nuevos requerimientos.

El mantenimiento de software es una de las actividades más comunes en


la Ingeniería de Software y es el proceso de mejora y optimización del
software desplegado, así como también corrección de los defectos.

"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.

El desarrollo de aplicaciones se ha convertido en una tarea compleja que


involucra un gran número de recursos tanto humanos como materiales;
resulta pues de vital importancia la adopción de métodos a fin de guiar la
construcción, mantenimiento y evolución de la aplicación a través de su
ciclo de vida. La fase de mayor duración y mayor costo de un programa o

5
aplicación, y durante la que se deben hacer toda clase de cambios,
alteraciones y mejoras, es la del mantenimiento.

La Cooperativa De Ahorro Y Crédito De La Federación De Mercados


Ayacucho (CACFMA), Cuenta con una área de sistemas, tiene personales
de administrador de bases de datos, programadores; Pero la cooperativa
adquiere software para automatizar los procesos críticos de terceros, esto
hace que el propietario de software de condiciones en la licencia para su
respectivo mantenimiento, generando así un gasto que puede sobrepasar
el precio del software.

En la actualidad la cooperativa CACFMA, cuenta con un software de


Sistema De Análisis De Crédito (SIAC), Pero con una serie de problemas que
hacen difícil la tarea de mantener sus sistemas, entre ellas podemos
mencionar: la falta de documentación, y la falta de un marco teórico y
técnico común que permita a los participantes del proyecto construir
aplicaciones legibles, flexibles y mantenibles. La importancia del
mantenimiento de software aun cuando son las últimas en el ciclo de vida
del software, las actividades de mantenimiento no son las menos
importantes, muy al contrario, el mantenimiento del software se ha
convertido en la principal actividad debido a su repercusión económica,
temporal y de recursos.

El software SIAC es un sistema variante ya que cada año va surgiendo


nuevos criterios y nuevas necesidades que se tienen que incorporar al
sistema para ello se tiene que recurrir a la empresa proveedora del
software para poder aumentar los módulos necesarios. Esto es un gasto
por no contar con una documentación.

El software que existe actualmente en CACFMA ha sido desarrollado


hace más de 10 años. Aunque estos programas fuesen creados utilizando

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.

Este programa ha sufrido una o varias migraciones a nuevas plataformas o


sistemas operativos Y han experimentado múltiples modificaciones para
mejorarlos y adaptarlos a las nuevas necesidades de los usuarios todos
estos cambios se realizaron sin tener en cuenta la arquitectura general del
sistema.

1.2. FORMULACIÓN DEL PROBLEMA


PROBLEMA PRINCIPAL

¿Cómo construir los artefactos del software, para realizar el


mantenimiento del software SIAC, de la Cooperativa De Ahorro Y Crédito
De Federación De Mercados Ayacucho, 2012?

PROBLEMAS SECUNDARIOS

a. ¿Cómo construir los artefactos del software de análisis y diseño a partir


de un software en funcionamiento?
b. ¿Cómo construir los artefactos del software a partir de código
ejecutable y estático?
c. ¿Cómo la funcionalidad del software, facilita el mantenimiento del
software?
1.3. OBJETIVOS DE LA INVESTIGACIÓN
OBJETIVO GENERAL

Seleccionar una metodología, para construir los artefactos del software


SIAC a partir del software en funcionamiento a través de la ingeniería
inversa, con el fin de reducir el costo en el mantenimiento del software, de
la Cooperativa De Ahorro Y Crédito De La Federación De Mercados
Ayacucho, 2012.
7
OBJETIVOS ESPECÍFICOS

a. Construir los artefactos del software de análisis y diseño desde un


software en funcionamiento a través de la ingeniería inversa con el fin
de elaborar la documentación.
b. Construir los artefactos del software a partir del código ejecutable y
estático a través de la ingeniería inversa con el fin de elaborar la
documentación.
c. Elaborar la descripción de la funcionalidad del software, con el fin de
facilitar el mantenimiento del software.

1.4. HIPÓTESIS DE LA INVESTIGACIÓN


Si seleccionamos una adecuada metodología para construir los
artefactos del software, entonces podremos reducir el costo del
mantenimiento del software SIAC, de la Cooperativa de Ahorro y Crédito
De Federación de Mercados De Ayacucho, 2012.

1.5. JUSTIFICACION Y DELIMITACIÓN DE LA INVESTIGACIÓN


1.5.1 JUSTIFICACION DE LA INVESTIGACIÓN
El presente investigación surgió como una necesidad percibida en la
Cooperativa De Ahorro Y Crédito De Federación De Mercados Ayacucho,
la cooperativa posee un software SIAC que no posee ninguna
documentación del mismo.

La investigación es importante metodológicamente porque se propone un


estudio de las diferentes metodologías relacionadas a la ingeniería inversa,
con el objetivo de crear una alternativa, plasmada en un modelo que se
sugiere que se siga los pasos para poder elaborar la documentación del
software SIAC de un código ya existente.

Como se ha mencionado anteriormente el mantenimiento del software es

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.

Con este estudio, se pretende seleccionar una metodología para obtener


los artefactos del software de análisis y diseño de un sistema ya construido.

1.5.2 DELIMITACION DE LA INVESTIGACIÓN


DELIMITACION ESPACIAL

El ámbito espacial de la investigación es la Cooperativa De Ahorro Y


Crédito De La Federación De Mercados Ayacucho, 2012.

DELIMITACION TEÓRICA

La investigación abarca los temas: ingeniería inversa, metodología XP,


documentación del software, construir artefactos del software,
mantenimiento del software y el análisis del código ejecutable y estático.

9
CAPITULO II

REVISIÓN DE LITERATURA

2.1.7.1 ANTECEDENTES DE LA INVESTIGACIÓN


La Ingeniería inversa de software aparece como un proceso que
ayuda al aseguramiento de la calidad y documentación de
aplicaciones con deficiencias en los modelos de análisis y diseño.
Además, ayuda en la disminución de costos y tiempos de
mantenimiento. En la actualidad existen herramientas CASE y algunas
propuestas de investigación que realizan el proceso de ingeniería
inversa a diagramas UML, en especial a los diagramas de clases y
secuencias. Algunas se encuentran en fases experimentales; otras se
enfocan mucho más en el diagrama de clases que en el de secuencias.
Un tercer grupo obtiene algunos elementos del diagrama de
secuencias, pero no posee muchos de los elementos que hacen parte
de la especificación de UML. En este artículo se propone un método
que automatiza la conversión de código JAVA en diagrama de
secuencias de UML, por medio de la aplicación de reglas de
transformación que convierten los elementos del código en elementos
del diagrama (Zapata, Ochoa, Vélez, 2008).
La necesidad de la ingeniería inversa emerge de problemas racionales
reales en el actual sistema como por ejemplo errores debido a la mala
calidad de software, al alto costo del mantenimiento debido a la
carencia de documentación y a nuevos requerimientos de los usuarios;
la ingeniería inversa puede extraer información de diseño del código
fuente pero el nivel de abstracción, la completitud de la
documentación, grado con el cual trabajan al mismo tiempo las
herramientas y el analista humano, y a direccionalidad del proceso son
sumamente variables (Acevedo,Puma, 2007).

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).

La ingeniería inversa puede extraer información de diseño del código


fuente, pero el nivel de abstracción, la completitud de la
documentación, el grado con el cual trabajan al mismo tiempo las
herramientas y el analista humano, y la direccionalidad del proceso son
sumamente variables (Cass, 1988).

2.2.7.1 MARCO TEÓRICO


2.2.7.1 ARTEFACTOS DEL SOFTWARE
Un artefacto es un producto tangible resultante del proceso de
desarrollo de software. Algunos artefactos como los casos de uso,
diagrama de clases u otros modelos UML ayudan a la descripción de la
función, la arquitectura o el diseño del software. Otros se enfocan en el
proceso de desarrollo en sí mismo, como planes de proyecto, casos de
negocios o enfoque de riesgos. El código fuente compilado para el
testeo se suele considerar un artefacto, ya que el ejecutable es
necesario para el plan de testeo (SEI, 2006).

La reestructuración se produce cuando la arquitectura básica de la


aplicación es sólida, aun cuando sus interioridades técnicas necesiten
un retoque. Comienza cuando existen partes considerables del software
que son útiles todavía, y solamente existe un subconjunto de todos los
módulos y datos que requieren una extensa modificación (Pressman,
2003).

Son métodos o procesos de un desarrollo especifico, un ejemplo de esto


es el Proceso unificado. Por otra parte podemos decir que un artefacto
es un producto tangible lo cual es el resultado de un proceso de
desarrollo de software. Se utilizan para describir funciones, arquitectura

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).

Los artefactos pueden variar en su necesidad de mantenimiento y


actualización. Los artefactos que detallan el diseño pretendido para el
producto suelen realizarse al principio del proyecto y no necesitan
mantenerse, mientras que otros se mantienen a lo largo del ciclo de
vida con información que se actualiza durante el desarrollo.

Un artefacto es un producto tangible resultante del proceso de


desarrollo de software. Algunos artefactos como los casos de uso,
diagrama de clases u otros modelos UML ayudan a la descripción de la
función, la arquitectura o el diseño del software. En ocasiones un
artefacto puede referirse a un producto terminado, como el código o el
ejecutable, pero más habitualmente se refiere a la documentación
generada a lo largo del desarrollo del producto en lugar del producto
en sí. Los artefactos pueden variar en su necesidad de mantenimiento y
actualización. Los artefactos que detallan el diseño pretendido para el
producto suelen realizarse al principio del proyecto y no necesitan
mantenerse, mientras que otros se mantienen a lo largo del ciclo de
vida con información que se actualiza durante el desarrollo (,2011).

Un factor determinante para el tratamiento de los artefactos de


persistencia es el nivel de abstracción de los modelos de datos (Ambler,
2005).

2.2.7.1 MANTENIMIENTO DEL SOFTWARE


El mantenimiento es la parte más costosa del ciclo de vida del
software. Estadísticamente está comprobado que el coste de
mantenimiento de un producto software a lo largo de toda su vida útil

12
supone más del doble que los costes de su desarrollo. La tendencia es
creciente con el paso del tiempo (Pressman, 1993).

Muchos proyectos de software eluden la aplicación de métodos de


desarrollo que faciliten el mantenimiento posterior de las aplicaciones
resultantes. Este tipo de aplicaciones carece de la documentación
necesaria para realizar su adecuado mantenimiento (Fitzgerald, Russo,
O’Kane, 2003).

2.2.7.1 CÓDIGO ESTÁTICO Y EJECUTABLE


El primero se basa en el código estático, es decir, cuando no se
utiliza información de tiempo de ejecución, y el segundo analiza el
código en ejecución. Esta diferencia es importante, en tanto establece
la dificultad dela inversión y sus alcances. Mientras que la inversión del
código estático se utiliza, ante todo, cuando se generan diagramas que
describen su estructura, como el diagrama de clases y el de paquetes,
la inversión que analiza el código en ejecución se utiliza,
primordialmente, cuando se requieren modelos que revelen las
características dinámicas del sistema, como el diagrama de objetos
(Fowler, 2004).

La reestructuración del software modifica el código fuente y/o los datos


en un intento de adecuarlo a futuros cambios. En general, la
reestructuración no modifica la arquitectura global del programa. Tiene
a centrarse en los detalles de diseño de módulos individuales y en
estructuras de datos locales definidas dentro de los con frecuencia, las
especificaciones escritas en fases centradas de la historia del programa
no llegan a actualizarse nunca. A medida que se hacen cambios, el
código deja de satisfacer esas especificaciones .módulos. Si el esfuerzo
de la reestructuración se extiende más allá de los límites delos módulos y
abarca la arquitectura del software, la reestructuración pasa a
seringeniería directa (Pressman, 2003).

2.2.7.1 ANÁLISIS Y DISEÑO

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).

En el diseño se construyen artefactos cercanos a la solución o a los


objetos del SGBD, tiene carácter imperativo, centrándose en el “cómo”
de la solución. Un esquema de datos se construye a partir de la
transformación del diagrama E‑R, teniendo en cuenta las siguientes
consideraciones: Tabla; Cada una de las entidades modeladas en el
análisis representa una tabla en el diseño. Por tratarse de la necesidad
de almacenamiento, su nombre suele ser el sustantivo que viene del
análisis pero en plural, pues en una tabla se almacenan muchos
registros. Se simbolizan con un rectángulo con los bordes rectos.
Columnas; Cada uno de los atributos del diagrama E‑R se transforma
en una columna del esquema de datos; la columna conserva las
características funcionales que tenía el atributo, salvo que algunas
veces se le adiciona el tipo de dato. Claves foráneas; Cada relación en
el diagrama E‑R genera una clave foránea en el esquema de datos y el
surgimiento de una o varias columnas. En la tabla del extremo de la
relación con multiplicidad de muchos. En el análisis se construyen
artefactos cercanos al dominio del problema; tienen carácter
declarativo, centrándose en “qué” se pretende hacer. Para la
construcción de un diagrama E‑R, se explora gramaticalmente la
narrativa del negocio, buscando elementos propios del modelo de la

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).

2.2.7.1 FUNCIONALIDAD DEL SOFTWARE


“La transformación desde una forma de representación a otra en el
mismo nivel de abstracción, preservando las características externas del
sistema (funcionalidad y semántica)” (Chifofsky, 1990).

La funcionalidad define el comportamiento interno del software:


cálculos, detalles técnicos, manipulación de datos y otras
funcionalidades específicas que muestran cómo los casos de uso serán
llevados a la práctica. Son complementados por los requisitos no
funcionales, que se enfocan en cambio en el diseño o la
implementación (Karl, 2003).

2.2.7.1 INGENIERIA INVERSA


La ingeniería inversa es el proceso para analizar componentes y
relaciones entre componentes, con el fin de construir descripciones de
un sistema en un nivel superior de abstracción. Elementos de la
Ingeniería Inversa Entre los elementos de la Ingeniería Inversa tenemos:

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.

Figura Nº 01: Fases de la ingeniería inversa

Ingeniería inversa para comprender el procesamiento: La primera


actividad real de la ingeniería inversa comienza con un intento de
comprender y extraer después abstracciones de procedimientos
representadas por el código fuente. Para comprender las abstracciones
de procedimientos, se analiza el código en distintos niveles de
abstracción: sistema, programa, componente, configuración y
sentencia. La funcionalidad general de todo el sistema de aplicaciones
deberá ser algo perfectamente comprendido antes de que tenga lugar
un trabajo de ingeniería inversa más detallado. Que establece un
contexto para un análisis posterior, y se proporcionan ideas generales
acerca de los problemas de interoperabilidad entre aplicaciones dentro
del sistema. Cada uno de los programas de que consta el sistema de

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.

Ingeniería inversa para comprender los datos: La ingeniería inversa de


datos suele producirse a diferentes niveles de abstracción6. En el nivel
de programa, es frecuente que sea preciso realizar una ingeniería
inversa de las estructuras de datos internas del programa, como parte
del esfuerzo general de la reingeniería. En el nivel del sistema, es
frecuente que se efectúe una reingeniería de las estructuras globales de
datos. La ingeniería inversa de las estructuras de datos globales actuales
establece el escenario para la introducción de una nueva base de
datos que abarque todo el sistema. Esta comprende:

a. Estructuras de datos internas: Las técnicas de ingeniería inversa para


datos de programa internos se centran en la definición de clases de
objetos. Esto se logra examinando el código del programa en un intento
de agrupar variables de programa que estén relacionadas. En muchos

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.

b. Estructuras de bases de datos: Independientemente de su


organización lógica y de su estructura física, las bases de datos permiten
definir objetos de datos, y apoyan los métodos de establecer relaciones
entre objetos. Por tanto, la reingeniería de un esquema de bases de
datos para formar otro exige comprender los objetos ya existentes y sus
relaciones. Para definir el modelo de datos existente como precursor
para una reingeniería que producirá un nuevo modelo de base de
datos se pueden emplear los pasos siguientes: Construcción de un
modelo de objetos inicial Las claves definidas como parte del modelo
se podrán conseguir mediante la revisión de registros de una base de
datos de archivos planos o de tablas de un esquema relacional.
Determinación de los candidatos a claves. Los atributos se examinan
para determinar si se van a utilizar o no para señalar a otro registro o
tabla. Refinamiento de las clases provisionales. Se determina si ciertas
clases similares pueden o no combinarse dentro de una Única clase.
Definición de las generalizaciones Para determinar si se debe o no
construir una jerarquía de clases con una clase de generalización como
precursor de todos sus descendentes se examinan las clases que
pueden tener muchos atributos similares.

Ingeniería inversa de interfaces de usuario: Las GUI sofisticadas se van

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.

¿Cómo puedo entender el funcionamiento de la interfaz de usuario


existente? Para comprender totalmente una interfaz de usuario ya
existente, es preciso especificar la estructura y comportamiento de la
interfaz. Se sugieren tres preguntas básicas a las cuales hay que
responder cuando comienza la ingeniería inversa de la IU: ¿Cuáles son
las acciones básicas que deberá procesar la interfaz?, ¿Cuál es la
descripción compacta de la respuesta de comportamiento del sistema
a estas acciones?, ¿Qué queremos decir con «sustitución», o más
exactamente, qué concepto de equivalencia de interfaces es
relevante en este caso? Es importante indicar que una GUI de
sustitución puede que no refleje la interfaz antigua de forma exacta (de
hecho, puede ser totalmente diferente). Con frecuencia, merece la
pena desarrollar metáforas de interacción nuevas (Chikofsky, Cross,
1990).

La ingeniería inversa permite subsanar esta deficiencia, al documentar


los productos de software a partir del código ejecutable, con el fin de
obtenerlos artefactos de análisis y diseño (Briand, Labiche,Miao, 2003).

La ingeniería inversa de software permite extraerlos detalles estructurales


y de comportamiento implícitos en el código de un producto de
software y expresarlos de forma estándar, generalmente en diagramas
UML (Tonella ,Potrich, 2005).

“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

20
información de diseño. El sistema en estudio no es alterado, sino que se
produce conocimiento adicional acerca del sistema” (SEI, 2004).

2.2.7.1 PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP)


Es una metodología ágil centrada en potenciar las relaciones
interpersonales como clave para el éxito en desarrollo de software,
promoviendo el trabajo en equipo, preocupándose por el aprendizaje
de los desarrolladores, y propiciando un buen clima de trabajo. XP se
basa en realimentación continua entre el cliente y el equipo de
desarrollo, comunicación fluida entre todos los participantes,
simplicidad en las soluciones implementadas y coraje para enfrentar los
cambios. XP se define como especialmente adecuada para proyectos
con requisitos imprecisos y muy cambiantes, y donde existe un alto
riesgo técnico. Los principios y prácticas son de sentido común pero
llevadas al extremo, de ahí proviene su nombre. Kent Beck, el padre de
XP, describe la filosofía de xp sin cubrir los detalles técnicos y de
implantación de las prácticas. Posteriormente, otras publicaciones de
experiencias se han encargado de dicha tarea. A continuación
presentaremos las características esenciales de XP organizadas en los
tres apartados siguientes: historias de usuario, roles, proceso y prácticas
(Beck, 2004).

La programación extrema (XP,Extreme programming) es un enfoque


para el desarrollo del software que utiliza buenas practicas para el
desarrollo y las lleva a los extremos. Se basa en principios y practicas
esenciales. Los cuatro valores son la comunicación, la simplicidad, la
retroalimentación y la valentía (Kendall, 2005).

“La Programación Extrema es una disciplina de desarrollo de software


con valores de sencillez, comunicación, retro alimentación y coraje. Nos
centramos en los papeles de cliente, administrador y programador y
acuerdo clave derechos y responsabilidades a las personas en esas
funciones” (Ron, Ann y Chet, 2000).

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).

“La Programación Extrema (XP) es un nuevo juego de reglas, para otros


esto es un juego humanista de valores, y esto a la vez es una
simplificación excesiva muy peligrosa” (Marchesi, Succi, Wells y Williams,
2002).

2.2.7.1 ¿CÓMO EMPIEZO CON XP?


La forma más obvia para iniciar la programación extrema (XP) es con un
nuevo proyecto. Comienza con recoger historias de usuario y conducir
soluciones para cosas que parecen de alto riesgo.

Programe una reunión de planificación para acordar la liberación. Invite


a los clientes, desarrolladores y administradores para crear un
calendario en el que todo el mundo esté de acuerdo. Comience su
desarrollo iterativo con una reunión de planificación. La mejor manera
de empezar XP es tomarse un buen tiempo buscando en la actual
metodología de software que usa y averiguar lo que se está llevando
hacia abajo.

22
Figura Nº 02: Proyecto de la Programación Extrema

Fuente: Extraído de la página http: // www.extremeprogramming.org/map/project.html.

ROLES DE LOS INTEGRANTES DE PROGRAMACIÓN EXTREMA

A. El papel del cliente


“El cliente elige lo que va a entregar, decide qué hacer primero y
qué aplazar, y define las pruebas para demostrar que el sistema hace lo
que necesita”( Ron, Ann y Chet,2000).

El equipo será más eficaz si el cliente permanece en el lugar y esté


presente con el equipo, a tiempo completo. El cliente, tiene la
responsabilidad fundamental de elegir las historias de elementos más
valiosos, de más alto valor comercial y él especifica las pruebas que
muestran si las historias se han aplicado correctamente. El cliente tiene
cinco trabajos importantes durante la iteración:
1. Responder a las preguntas
2. Escribir las pruebas de aceptación.
3. Ejecutar las pruebas de aceptación.
4. Dirigir la iteración y un trabajo (después de varias iteraciones),
cuando la entrega está lista.
5. Aceptar la entrega. (Wake, 2000).

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).

“El programador es el corazón de XP. En realidad, si los programadores


siempre pueden tomar decisiones que cuidadosamente equilibrados a
corto plazo y prioridades a largo plazo, no habría necesidad de ningún
otro personal técnico en el proyecto, además de los programadores.
Por supuesto, si el cliente no tienen una necesidad imperiosa de
software para mantener el negocio funcionando, no habría necesidad
de los programadores, por lo que no hacer, para obtener demasiado
grande encabezada por haber sido vital el programador” (Beck, Fowler
,2000).
C. El papel del Tester
“Dado que una gran cantidad de pruebas recae sobre la
responsabilidad de los programadores, el papel del probador en un
equipo de XP está realmente centrado en el cliente. Que es
responsable de ayudar a los clientes a escoger y escribir las pruebas de
funcionalidad. Si las pruebas funcionales no son parte de la integración,
que es responsable de ejecutar las pruebas funcionales y la publicación
periódica de los resultados en un lugar destacado” (Marchesi,
Succi,Wells y Williams,2000).
D. El papel del Manager.
“El manager hace que el cliente y los desarrolladores estén juntos
y les ayuda a combinar en el correcto funcionamiento del equipo”.
Cuando se trata del proceso de planificación, diseño, ensayo,
codificación, en la liberación, los jefes de proyectos no hacen ninguna
de estas cosas directamente. El jefe de proyecto promoverá estas cosas
por hacer, coordinar las tareas, e informará los resultados. Como jefe de
proyecto, promoverá una reunión. En una sesión stand-up un poco
24
antes de la liberación del tiempo planificación. Si hay un acuerdo
general, el gerente debe ir en la cabeza. Si hay conflictos en la
programación, ponerse de acuerdo con los miembros del equipo y
encontrar una fecha adecuada. Si es necesario, cambiar una cita en
conflicto (Jeffries, Ann Anderson y Chet, 2000).

“El jefe de proyecto tiene varios trabajos importantes: frente a terceros,


forma el equipo, obtiene los recursos, gestiona el equipo, y maneja los
problemas del equipo” (Wake, 2000).

FASES DE PROGRAMACION EXTREMA


Define 4 fases iterativas en los cuáles definen su proceso.
A. Planificación.
B. Diseño.
C. Código.
D. Prueba. (Extreme Programming.2008).
A. PLANIFICACIÓN.
Ésta es la planificación de historias que realizamos al inicio del
proyecto, tras estudiar el proyecto y mantener conversaciones con el
cliente. De esta redacción inicial de historias de usuario se realizó una
planificación inicial y posteriormente fue cambiada a lo largo del
proyecto. Algunas de estas historias fueron eliminadas o cambiadas, a
medida que cambiaban los requisitos del cliente, se tenía una
concepción más clara del proyecto (DSIIC, 2008).

Para poder guiarnos de una manera sencilla, construimos una tabla de


Actividades, Tareas, Artefacto, Técnica, Participantes, en el cual nos
indica específicamente que pasos uno debe realizar en el transcurso del
proyecto, en la fase de planificación.
B. DISEÑO
El diseño es la creación de una estructura que organiza la lógica
en el sistema, un buen diseño organiza la lógica de modo que un
25
cambio en una parte del sistema no siempre requiere un cambio en
otra parte del sistema, un buen diseño permite la extensión del sistema a
los cambios en un solo lugar. Cada proyecto de software en XP se rige
por una sola metáfora global, la metáfora sólo ayuda a todos a
comprender los elementos básicos y sus relaciones sobre el proyecto.
C. CODIFICACIÓN
Figura Nº 05: Desarrollo

Fuente: Extraído de la página http://www.WebSites\ExtremeProgramming\rules\squential.htm

En XP, la programación en pares es la práctica de tener dos


personas trabajando juntos en toda la producción del código. Ellos
hacen esto, como socios de pleno derecho, turnándose, escribiendo y
observando, para proporcionar el diseño constante y la revisión del
código.
Es conveniente elegir un estilo de programación para el par de
programadores para que posteriormente no ocurran problemas en la
integración de código y el desarrollo de las pruebas unitarias.
El programador implementa una tarea de ingeniería (la unidad más
pequeña de la programación) lo cual será integrado con el resto del
sistema mediante la refactorización.
D. PRUEBAS
“XP utiliza las pruebas de dos maneras: los clientes desarrollan
pruebas de aceptación que determinan el comportamiento general del

26
sistema, y los programadores crean pruebas unitarias en la
programación”.

Figura Nº 07: Pruebas

Fuente: Ron Jeffries, Ann Anderson, Chet Hendrickson, “Instalando la programación


Extrema” ,2000.

Hay muchas maneras diferentes para aplicar las pruebas de


aceptación en su proyecto, y los programadores pueden elegir uno. El
cliente crea pruebas de aceptación para cada historia que solicita. Las
pruebas de aceptación constituyen una prueba de existencia para la
comprobabilidad de las características solicitadas. Por último, el equipo
debe tratar de tener sus pruebas automatizadas. El usuario tiene una
interfaz familiar, y los programadores pueden escribir un pequeño
programa para leer la hoja de cálculo y ejecutar la prueba.
Para el proceso de pruebas, tenemos el siguiente cuadro en el cual
mencionamos cosas fundamentales en el desarrollo del proyecto (
Wake ,2000 ).
PRUEBAS UNITARIAS
La creación de las pruebas unitarias ayuda al desarrollador, para
considerar realmente lo que hay que hacer. Los requisitos se establecen
firmemente exactos por medio de ensayos. No puede haber ningún
malentendido, una especificación escrita en forma de código
ejecutable. También se tiene información inmediata mientras se trabaja.
A menudo no está claro cuando un desarrollador ha acabado la
funcionalidad necesaria. El ámbito de aplicación puede ocurrir como
ampliaciones y condiciones de error se consideran. Si vamos a crear

27
nuestras primeras pruebas unitarias entonces sabemos cuándo se
realizan, el plazo de todas las pruebas unitarias.

También hay un beneficio para el diseño del sistema. A menudo son


muy difíciles las pruebas unitarias de algunos sistemas de software. En
estos sistemas primeramente se construye el código y segundo las
pruebas, a menudo por un equipo totalmente diferente. Mediante la
creación de su primera pruebas su diseño se verá influido por un deseo
de poner a prueba todo lo de valor a su cliente. Su diseño reflejará este
por ser más fácil de probar. Puede crear una prueba para definir
algunos pequeños aspectos del problema en la mano. Luego de crear
el código más simple hay que hacer que pase la prueba. Luego de
crear una segunda prueba. Ahora se agrega el código que acaba de
ser creada para que esta nueva prueba pase, No hasta que haya una
tercera prueba. Usted continuará hasta que no quede nada para poner
a prueba. El código creado es simple y conciso, sólo la aplicación de las
características que quería. Otros desarrolladores pueden ver la forma de
utilizar este nuevo código de la navegación por las pruebas.

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.

Cada prueba de aceptación representa algunos de los resultados


esperados del sistema. Los clientes son los responsables de verificar la
exactitud de las pruebas de aceptación y la revisión de los resultados
de las pruebas para decidir cuales son de alta prioridad.

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.

El aseguramiento de la calidad (QA) es una parte esencial del proceso


de XP. En algunos proyectos de control de calidad es realizada por un
grupo aparte, mientras que en otros QA serán integrados en el
desarrollo de sí mismo. En cualquier caso XP requiere el desarrollo que
tiene relación mucho más estrecha con la garantía de la calidad.
Las pruebas de aceptación deben ser automatizadas por lo que se
puede ejecutar con frecuencia. Las pruebas de aceptación de
puntuación son publicadas en el equipo.

Tabla Nº 07: Formato de Pruebas de Aceptación


Caso de Prueba de Aceptación
Código: Historia de Usuario (Nro. y Nombre):
Nombre:
Descripción:
Condiciones de Ejecución:

Entrada / Pasos de ejecució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

3.1 TIPO DE INVESTIGACIÓN


Seleccionar una metodología para la construcción de los
artefactos del software SIAC, para Apoyar en el mantenimiento en la
cooperativa de ahorro crédito federación de mercado de Ayacucho,
2012”, usando el proceso ingeniería inversa y el proceso de xp. Desde el
punto de vista científico, describir es medir (Hernández et al., 2010), por
esta consideración el tipo de investigación es descriptiva.

3.2 DISEÑO DE LA INVESTIGACION


Según Hernández (2010), las investigaciones no experimentales
son “aquellas que se realizan sin manipular deliberadamente las
variables, es decir, no se varía intencionalmente la variable
independiente, simplemente lo que se hace es observar las funciones tal
y como se dan en su contexto natural para después analizarlo”. En la
presente investigación, usamos el proceso de ingeniería XP, para
construir el producto software, sin variar las variables de investigación.

3.3 POBLACION Y MUESTRA


POBLACIÓN.- La población está compuesta por los analistas,
programadores y administradores de bases de datos, de la cooperativa
de ahorro crédito federación de mercados de Ayacucho 2012.

MUESTRA.- La muestra esta compuesto de los analistas, programadores y


administradores de bases de datos, de la cooperativa de ahorro
crédito federación de mercados de Ayacucho 2012.

3.4 VARIABLES E INDICADORES


DEFINICIÓN CONCEPTUAL DE LAS VARIABLES

30
VARIABLE INDEPENDIENTE

Artefactos del software.- Los artefactos como los casos de uso,


diagrama de clases u otros modelos UML ayudan a la descripción de la
función, la arquitectura o el diseño del software.

INDICADORES DE LA VARIABLE INDEPENDIENTE

Código estático y ejecutable.- código estático se utiliza, ante todo,


cuando se generan diagramas que describen su estructura, como el
diagrama de clases y el de paquetes, código en ejecución se utiliza,
primordialmente, cuando se requieren modelos que revelen las
características dinámicas del sistema, como el diagrama de objetos.

Análisis y diseño.- En el diseño se construyen artefactos cercanos a la


solución o a los objetos del SGBD, tiene carácter imperativo,
centrándose en el “cómo” de la solución. Cada una de las entidades
modeladas en el análisis representa una tabla en el diseño. Por tratarse
de la necesidad de almacenamiento, su nombre suele ser el sustantivo
que viene del análisis pero en plural, pues en una tabla se almacenan
muchos registros.

VARIABLE DEPENDIENTE

Mantenimiento del software.- El mantenimiento de software es una de


las actividades más comunes en la Ingeniería de Software y es el
proceso de mejora y optimización del software desplegado, así como
también corrección de los defectos.

INDICADORES DE LA VARIABLE DEPENDIENTE

Funcionalidad del software.- define el comportamiento interno del


software: cálculos, detalles técnicos, manipulación de datos y otras
funcionalidades específicas que muestran cómo los casos de uso serán
llevados a la práctica.

31
DEFINICIÓN OPERACIONAL DE LAS VARIABLES

VARIABLE INDEPENDIENTE

X: Artefactos del software

INDICADORES DE LA VARIABLE INDEPENDIENTE

X1: Código estático y ejecutable

X2: Análisis y diseño

VARIABLE DEPENDIENTE

Y: Mantenimiento de software

INDICADORES DE LA VARIABLE DEPENDIENTE

Y1: Funcionalidad del software

3.5 TECNICA E INSTRUMENTOS


3.5.1 INSTRUMENTO PARA RECOLECTAR INFORMACIÓN
Se usará las técnicas de; entrevista, encuesta a los actores
directos e indirectos que interactúan con el software SIAC, para
recolectar datos, información y procesos, la información y los procesos
necesarios para comprender a profundidad, la necesidad de contar
con una documentación adecuada del software SIAC, para reducir los
costos en el mantenimiento de la Cooperativa De Ahorro Y Crédito
Federación De Mercados De Ayacucho.

Relaciones entre actores directos.- Instrumento para recolectar


información sobre la interacción con el software SIAC y los actores
directos. La información recolectada presenta la importancia en el
momento de la evaluación a los socios para un crédito de CACFMA.

Demanda y mercados.- Formato para recolectar información


entrevistando a un grupo de actores que realizan los análisis de créditos,
orientada al mercado local.

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.

3.5.2 TECNICA PARA APLICAR INGENIERIA INVERSA


Dragan Bojic y Duran Velasevic (2001), proponen una técnica basada
en el análisis dinámico de un sistema para seleccionados casos de
prueba que cubren casos de uso importantes. La teoría de análisis de
conceptos formales es aplicada para obtener clasificaciones de
elementos del modelo.

Ellos adoptan el enfoque de conducir ingeniería inversa guiado por


casos de uso por las siguientes razones:

A. Estudio del sistema existente.- Una técnica que ayudara al


entendimiento del sistema será: la entrevista.
B. Recuperación arquitectónica.- Para llevar acabo esta etapa se
utilizará el enfoque basado en 5 vistas, cada vista servirá para
recuperar cierta información de diseño. Entre las tareas de esta
fase tenemos:
a) Identificación de las tareas funcionales del sistema.
Diagrama de casos de uso.

b) Recuperación de la vista de diseño


Utilización de una herramienta CASE.
c) Representación de la interacción entre los objetos
Diagrama de Secuencia y Colaboración.

d) Identificación de componentes de software


Diagrama de componentes.
e) Identificación de componentes para el despliegue
Diagrama de despliegue.
C. Documentación de tareas y funciones del sistema.

33
3.5.3 TECNICA PARA APLICAR XP

34
CAPITULO IV

RESULTADOS DE LA INVESTIGACIÓN

35
BIBLIOGRAFÍA

Extreme Programming: A gentle introduction.


http://www.extremeprogramming.org/ [Consulta: 18 oct. 2008].

Ron Jeffries, Ann Anderson, Chet Hendricrickson, “Extreme Programming


Installed”, Editorial “Pearson Education, 1999”, Addison Wesley, 2000.

William C. Wake, “Extreme Programming Explored”, Editorial Pearson


Education, Addison Wesley, Copyright 2000, All Rights Reserved.

Michele Marchesi, Giancarlo Succi, Don Wells, Laurie Williams, “Extreme


programming Perpectives”, publisher, Adisson Wesley, Pags. 640, Agosto, 30
del 2002.

Kent Beck, Martin Fowler, “Planning Extreme Programming”, Pearson Education,


1999”, Addison Wesley, 2000.

Ejemplo de desarrollo software utilizando la metodología XP, “Desarrollo


de un sistema de gestión de una empresa de confecciones”, DSIIC,
Universidad Pontificia de Valencia,
http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemploxp[consulta:15
oct2008].

BOJIC Dragan y VELASEVIC Dusan ,Reverse Engineer of Use Case


Realizations in UML Tesis Doctoral, Facultad de Ingeniería Eléctrica,
Belgrado, 2001

36

También podría gustarte