Análisis de calidad del software usando

Vector 5 (2010) 45 - 52
ISSN 1909 - 7891
Análisis de calidad del software usando optimización
por colonia de hormigas
Andrés Castaño Véleza*, Carlos Ruiz Villaa,b, Cristian Zuluagac
a
Departamento de Sistemas e Informática, Universidad de Caldas, Calle 65 No. 26-10, Manizales, Colombia
Departamento de Informática y Computación, Universidad Nacional de Colombia sede Manizales, Cra. 27 # 64-60, Manizales, Colombia
c
Programa de Ingeniería de Sistemas y Computación, Facultad de Ingeniería, Universidad de Caldas, Calle 65 No. 26-10, Manizales, Colombia
b
Recibido: 25 de mayo de 2011. Aprobado: 19 de diciembre de 2011
Resumen
Para clasificar un conjunto de clases de software posiblemente defectuosas, se comprobó una técnica de clasificación utilizando el algoritmo de optimización por colonia de hormigas (ACO), demostrando que mediante esta técnica es posible predecir errores en los módulos
de software. Para este efecto se probó en el aplicativo Myra-3.0.1 utilizando un repositorio público de datos, obteniendo un conjunto de
reglas que determinan si una clase es o no defectuosa con una precisión del 93,1%.
Palabras clave: Calidad de software, métrica, optimización por colonia de hormigas, minería de software, clasificación.
Software quality analysis using ant colony optimization
Abstract
To classify a set of possibly faulty software classes, a classification technique using the ant colony optimization (ACO) algorithm was
proved showing that using this technique it is possible to predict errors in software modules. To this effect it was tested in the Myra3.0.1 application using a public data repository, and obtaining a set of rules that determine whether a class is or is not defective with
93.1%. accuracy.
Key words: software Quality, metric, ant colony optimization, software mining, classification.
1. Introducción
Las primeras etapas del desarrollo de software son
cruciales en la consecución de productos de calidad
dentro de los límites de tiempo y costo establecidos
para un proyecto. Los errores introducidos en las
primeras etapas del desarrollo de software o durante
su evolución, son causa frecuente de dificultades en el
mantenimiento, baja reutilización y comportamiento
defectuoso de los programas. Además, las malas
estimaciones realizadas al comienzo del proyecto
tienen consecuencias desastrosas en cuanto a costos y
plazos de entrega (Garcia et al., 2001).
Las métricas de software son la clave para la gestión
de la calidad en el software. La gestión de la calidad
de software es una comparación de la calidad real de
un producto con la calidad esperada. En el ámbito
del desarrollo de software, significa, que las métricas
son recogidas en varios puntos del ciclo de desarrollo
y se utilizan para mejorar la calidad de un producto
de software (de Almeida et al., 1999). Las métricas se
* Autor de correspondencia.
E-mail: andres.castano@ucaldas.edu.co (A. Castaño)
utilizan para identificar los módulos en los sistemas
de software que son potencialmente propensos a
error, con el fin de que el desarrollo y el esfuerzo sean
dirigidos a estos módulos.
La gran cantidad de métricas existentes conjugadas
con las tecnologías actuales y diferentes aspectos del
software, han direccionado el desarrollo de una nueva
vía de investigación orientada hacia la propuesta de
modelos, arquitecturas y marcos de referencia que
permitan la organización de las medidas. En este
contexto, las técnicas de minería de datos surgen
como herramientas para realizar exploraciones más
profundas y extraer información nueva y útil que se
encuentra oculta en grandes volúmenes de datos.
El objetivo de este trabajo es mostrar cómo
mediante una técnica de clasificación bioinspirada es
posible predecir errores en los módulos de software
posiblemente defectuosos basados en una serie de
parámetros.
1.1. Métricas y calidad del software
El uso de los algoritmos de minería de datos
para las métricas de software ha sido ampliamente
Andrés Castaño Vélez et al. / Vector 5 (2010) 45-52
investigado. Las métricas del software han partido de
una combinación de técnicas de inteligencia artificial y
análisis estadístico. La técnica de inteligencia artificial
usada es un mecanismo para generar preguntas
basadas en los objetivos de los usuarios e identificar
métricas que pueden entregar una respuesta útil a
dichas preguntas, mientras que las herramientas
estadísticas empleadas son los análisis de correlación
y la búsqueda de valores anómalos en la base de
datos (Mendonca et al., 1998). Una validación de esta
aproximación se hace usando datos de encuestas a los
usuarios (Mendonca y Basili, 2000).
El uso de técnicas de minería de datos para ayudar
en la gestión de proyectos de software incluye el
análisis de regresión múltiple, análisis de componentes
principales, redes neuronales y árboles de clasificación
(Paul et al., 1999).
Para predecir la calidad del software desde las
métricas se ha buscado descubrir el conocimiento en
bases de datos (KDD). Si tomamos por ejemplo un
gran sistema de telecomunicaciones, la gestión de la
configuración asociada y el problema de reportes de
la base de datos, los módulos del sistema se pueden
dividir en 2 clases: los que han experimentado una
falla durante la operación del cliente y los que no.
Utilizando una herramienta de minería de datos
como el algoritmo de árbol de clasificación y regresión
(CART), con un experimento de validación en cruz, la
herramienta puede obtener un promedio de exactitud
de clasificación de alrededor del 75% (Khoshgoftaar
et al., 1999). Por otra parte, la minería de software
está enfocada a atacar los problemas de simulación y
modelado utilizando la extracción del conocimiento de
datos de proyectos anteriores que pueden aplicarse a
proyectos futuros o a fases de desarrollo (Vandecruys
et al., 2008). También puede utilizarse para optimizar
la precisión de los modelos predictivos de calidad del
software usados para clasificar nuevos datos partiendo
de modelos existentes (Azar y Vybihal, 2011).
1.2. Minería de software
La minería de software se refiere al uso de técnicas
de minería de datos para predecir errores en los
módulos de desarrollo del software, basándose en
datos de proyectos anteriores y que pueden aplicarse
a otros proyectos o a fases de desarrollo específicas.
Una categorización de 3 áreas comunes de interés
para la minería de software son la predicción de fallos,
detección de cambios incompletos y esfuerzos de
predicción (Vandecruys et al., 2008).
[ 46 ]
1.2.1. Fallos en proyectos de software
Las empresas hoy en día se centran en ofrecer
calidad a sus clientes, al ofrecerla están conduciendo
a la satisfacción del cliente, lo que a su vez conduce a
generar un vínculo más estrecho y obtener mayores
ingresos a largo plazo. Las empresas que ofrecen
software se rigen bajo este mismo hecho, uno de los
elementos clave que determinan la percepción del
usuario final respecto a la calidad del software es
el grado en el que el sistema se encuentra libre de
errores (Dick et al., 2004). Por esta razón, para los
administradores de sistemas de software, los productos
entregados libres de errores son una prioridad.
El Departamento de Defensa de los Estados Unidos
pierde cerca de cuatro mil millones de dólares de la
base anual debido a fallas del software. Un estudio
realizado en 2003 reveló que en 104 proyectos de
software desarrollados en diferentes continentes, el
reporte de usuario final entrega un promedio de 0,15
fallos por 1.000 líneas de código durante el primer año
en que el proyecto es entregado, que para 100.000 líneas
de código equivalen a 15 fallos que no pueden pasarse
por alto (Cusumano et al., 2003).
Una alta calidad en el software puede obtenerse
con la introducción de un proceso de desarrollo
estructurado de software y un intenso proceso de
pruebas. Sin embargo, en la mayoría de los casos, las
pruebas de software de forma exhaustiva no son una
opción viable, además el entorno de prueba puede
diferir fuertemente del entorno en el que el sistema se
desempeña regularmente, por lo tanto, los resultados
del proceso de pruebas no son siempre representativos
de la calidad de la experiencia del usuario final.
1.2.2. Cambios incompletos en proyectos de software
T í p i c a m e n t e u n p r o ye c t o d e s o f t wa r e e s
implementado por muchos programadores. Para el
caso específico de un software de código abierto, estos
programadores no están ubicados geográficamente
en la misma parte. En un caso de estudio sobre el
código abierto del servidor apache, el desarrollo de
su núcleo y nuevas funcionalidades fue realizado por
15 programadores, sin embargo, se tenían muchos
voluntarios que hicieron cambios completos al código
fuente como resultado de reportes de problemas. Un
programador que cambie un módulo posiblemente
no se percate del impacto que puede causar en otros
módulos que también son cambiados, y como tal se
realiza un cambio incompleto (Mockus et al., 2000).
Análisis de calidad del software usando optimización por colonia de hormigas
La estructura de un software de código abierto no es
la única causa de cambios incompletos al código fuente.
A menudo el código fuente de un proyecto está escrito
en diferentes lenguajes de programación haciendo que
sea bastante difícil descubrir las interdependencias
entre las partes escritas en diferentes lenguajes de
programación, lo cual, también incrementa el riesgo
de cambios incompletos en el código fuente (Ying et
al., 2004).
1.2.3. Estimaciones inexactas de proyectos de software
Al inicio de un proyecto de software, el administrador
decide la cantidad de tiempo, personas y dinero que
se requiere destinar para el desarrollo del proyecto. El
53% de los proyectos de software son entregados tarde,
demasiado caros o con menos de la funcionalidad
requerida, demostrando que es necesario en los
modelos estructurales incrementar la precisión de las
estimaciones como se muestra en el reporte CAOS del
grupo Standish (Standish Group, 2004).
Un ejemplo conocido, es el modelo de estimación
COCOMO II, una representación de costos que sirve
de base para planear y ejecutar proyectos de software,
que entrega el esfuerzo en persona/mes de acuerdo al
tamaño del proyecto (medido o convertido en miles de
líneas de código fuente), está bien estructurado, fácil
de utilizar y ofrece la posibilidad de adaptación para
las características específicas de la empresa (Boehm y
Harrowitz, 2000). Sin embargo, este modelo presenta
ciertos problemas en el proceso dado que los valores
de las constantes utilizadas en la fórmula A y B son
determinadas con ensayo y error, mientras que las
técnicas de regresión ofrecen una alternativa mejor.
Además, los valores de los factores de escala y los
esfuerzos multiplicadores se determinan en una forma
poco arbitraria. Para este fin, la lista de preguntas es
diligenciada por las personas responsables, por lo
tanto, la calidad del modelo resultante depende de
las respuestas subjetivas dadas por estas personas (De
Rore et al., 2006).
La minería de software puede ser una herramienta
muy útil si se usa como un instrumento para predecir
fallos, en este sentido, el usuario final de un sistema
de software asocia la calidad del software, entre otras
cosas, con un sistema de software libre de errores, sin
embargo, ya se había mencionado que los sistemas de
prueba de forma exhaustiva son poco viables. Por lo
tanto, esta herramienta puede ofrecer una solución
para el modelado de predicciones de calidad del
software o clasificaciones de calidad del software
(Khoshgoftaar y Seliya, 2003).
2. Métodos
La optimización por colonia de hormigas (ACO, Ant
Colony Optimization) es una técnica bioinspirada de
clasificación basada en el comportamiento externo de
una colonia de hormigas reales al momento de buscar
alimento (Dorigo et al., 2006). Una hormiga por sí sola
es un insecto con capacidades limitadas que se rige
por reglas de decisión sencillas, sin embargo, estas
reglas sencillas son suficientes para toda la colonia de
hormigas para encontrar caminos más cortos del nido
a la fuente de alimento. Cada hormiga deja caer una
sustancia química llamada feromona que atrae a otras
hormigas e indirectamente se comunica con las demás
hormigas compañeras de la colonia. Suponga que 2
hormigas inician desde el nido para buscar el camino
más corto a la fuente de comida, y existen 2 caminos
para llegar a la fuente de alimento, uno más corto que
el otro, inicialmente no hay feromonas presentes en
ninguno de los caminos, por lo que existe un 50% de
probabilidades de elegir cualquiera de los caminos.
Ahora, suponga que una hormiga escoge el camino
más corto, por lo tanto regresará más rápido al nido
dejando el doble de feromona en el camino más corto
a diferencia del camino más largo. Como resultado, la
probabilidad que la próxima hormiga elija el camino
más corto será 2 veces mayor, resultando en más
feromonas y por ende más hormigas elegirán este
camino, hasta que finalmente, por lo general, todas
las hormigas seguirán el camino más corto. Se debe
tener en cuenta que en el camino más largo el rastro
de feromonas irá desapareciendo por evaporación.
La optimización por colonia de hormigas emplea
hormigas artificiales que cooperan de manera similar
a las hormigas biológicas para encontrar las mejores
soluciones para los problemas de discretización (Dorigo
et al., 2006). El primer algoritmo de ACO (Dorigo
et al., 1996) consideró hormigas que iterativamente
construyen soluciones y adicionan feromonas a los
caminos correspondientes a estas soluciones. La
selección del camino es un proceso estocástico basado
no sólo en el valor histórico de la feromona sino en un
valor heurístico dependiente del problema. El valor
de la feromona entrega una indicación del número de
hormigas que ha escogido recientemente el camino,
mientras que el valor heurístico es una medida de
calidad dependiente del problema. En el momento
en que una hormiga llega a un punto de decisión, es
más probable que elija el sendero con mayor número
de feromonas y valores heurísticos. Una vez que la
hormiga llega a su destino, la solución que corresponde
al camino seguido por la hormiga es evaluada y el
valor de feromonas de ese camino es aumentado en
consecuencia. Además, la evaporación causa que el
[ 47 ]
Andrés Castaño Vélez et al. / Vector 5 (2010) 45-52
nivel de feromonas de todos los senderos disminuya
gradualmente, y los caminos que no son reforzados con
feromonas tienen menor probabilidad de ser elegidos
por las hormigas siguientes.
El desempeño de este algoritmo de ACO es pobre
en problemas de gran escala (Stutzle y Hoos, 1996).
En 1997 se diseña un algoritmo para superar este
problema (Dorigo y Gambardella, 1997). Lo realmente
importante para este documento es la aplicación que
este algoritmo tiene en la minería de datos, dado que
se conoce su aplicación en problemas de agrupamiento
(Abraham y Ramos, 2003; Handl et al., 2006) y en tareas
de clasificación (Parpinelli et al., 2002; Bo et al., 2003;
Xingliang y Jianzhang, 2006). Cuando se dio la primera
aplicación de este algoritmo en tareas de clasificación
fue llamado Ant-Miner; posteriormente aparecieron
las versiones mejoradas de Ant-Miner2, Ant-Miner3
y Ant-Miner+.
2.1. Algoritmo Ant-Miner+
Primero es necesario definir en qué ambiente operan
las hormigas. Cuando una hormiga se mueve en su
ambiente desde un punto de inicio hasta un punto
final, se puede construir de forma incremental una
solución al problema de clasificación (Vandecruys
et al., 2008). Para construir un conjunto de reglas de
clasificación, se establece un gráfico en el cual una vía
para cada hormiga implícitamente describe una regla
de clasificación. En un ACO las hormigas artificiales
construyen la solución usando un procedimiento
constructivo estocástico. Durante esta fase de
construcción las hormigas caminan aleatoriamente
por un grafo llamado ‘grafo de construcción’, donde
se tiene un conjunto de conexiones (arcos) entre
los componentes (nodos). En general, el grafo de
construcción es completo, es decir, está completamente
conectado, pero algunas de las restricciones del
problema pueden modelarse eliminando algunos
arcos del grafo completo. Cada arco tiene asociado un
rastro de feromona y puede tener asociado también
un valor heurístico. Ambos valores se usan para guiar
la fase de construcción estocástica que realizan las
hormigas, pero hay una diferencia importante entre
ellos: los rastros de feromona se modifican a lo largo
de la búsqueda mientras que los heurísticos son valores
fijos establecidos por fuentes externas al algoritmo
(el diseñador ). Los rastros de feromona pueden
asociarse también a los nodos del grafo de construcción
(componentes de la solución) en lugar de a los arcos
(conexiones entre componentes).
[ 48 ]
Un ejemplo de construcción gráfica de Ant-Miner+
para un conjunto de datos de minería de software con
sólo 3 variables (lenguaje de programación, líneas
de código-LOC y número de operadores), el camino
señalado en negrita describe la regla “Si Lenguaje
de programación=Java y LOC>=30 y número de
operadores>=15 entonces clase=defectuosa”. Para un
conjunto de datos con d clases, n variables, de las cuales
la primera y última variables son nominales y V2 es
ordinal (con los dos grupos vértices), los parámetros
de peso α y β determinan la importancia relativa de
la feromona y los valores heurísticos, como se indica
en (1):
(1)
donde:
= Nivel de feromona del arco
= Información heurística
α y β = Parámetros que determinan la importancia
relativa de la feromona en relación con la información
heurística.
Luego de que el ambiente está definido, se puede
examinar el funcionamiento de la técnica, todas las
hormigas empiezan en el nodo de inicio y caminan
a través de su ambiente hasta el nodo de fin,
construyendo gradualmente una regla. Sólo para la
hormiga que describa la mejor regla, su camino será
actualizado con feromona, como es propuesto por la
aproximación al sistema de colonia de hormigas minmax. La evaporación disminuye la feromona en todos
los caminos por la multiplicación con el factor ρ (un
número real en el rango [0,8-0,99]), mientras que los
niveles de feromonas se ven limitados dentro de los
límites de un intervalo dado [Tmin,Tmax]; estos límites se
imponen con el objetivo de evitar el estancamiento en
la búsqueda de soluciones. Cuando se da una iteración
con hormigas caminando desde el inicio hasta el
fin, ocurre la convergencia cuando todo el nivel de
feromonas de un camino es Tmax y los demás caminos
tienen un nivel de feromonas Tmin , el siguiente paso es
extraer la regla correspondiente a el camino con Tmax y
adicionada al conjunto de reglas. Finalmente, los datos
de entrenamiento que son cubiertos por esta regla se
remueven de todo el conjunto de datos, este proceso
es iterativo hasta que se detenga por el cumplimiento
de un criterio establecido.
Análisis de calidad del software usando optimización por colonia de hormigas
Figura 1. Ejemplo de un camino seguido por una hormiga para la construcción del gráfico de software definido por Ant-Miner+. La
regla correspondiente para seleccionar caminos es “Si lenguaje de programación=java and LOC ∈ [30, ∞) and número de operadores ∈
[15, ∞) entonces clase=defectuosa”.
La hormiga comienza en un nodo inicial y elige el
siguiente nodo de acuerdo con el rastro de feromona
y el heurístico asociado con cada arco (o nodo). La
hormiga añade el nuevo nodo al camino andado y
selecciona el siguiente nodo de la misma forma. Este
proceso se repite hasta que se construye una solución
candidata. Luego, se modifican los rastros de feromona
asociados con los arcos. Un rastro particular puede
aumentar si el arco correspondiente ha sido usado
por una hormiga para construir su solución y puede
disminuir debido a la evaporación (un mecanismo
que evita la convergencia prematura del algoritmo).
El aumento en los rastros de feromona normalmente
depende de la calidad de las soluciones candidatas
construidas por las hormigas que pasan por el arco.
Las ventajas de este algoritmo no sólo son su
exactitud y comprensión de los modelos generados
sino la posibilidad de obtener modelos de predicción
intuitivos, por ejemplo, cuando una regla de
clasificación se induce para predecir si un módulo de
software es defectuoso, la regla “Si LOC>1000 entonces
clase=no defectuoso”, es una regla no intuitiva, como se
espera que los módulos más grandes estén más sujetos
a fallos, al cambiar el signo del ejemplo por <, la regla
“Si LOC>1000 entonces clase=defectuoso”, es intuitiva
(Vandecruys et al., 2008).
3. Resultados
La aplicación en un caso real del algoritmo ACO
de clasificación se realizó sobre un conjunto de datos
dispuesto por el repositorio PROMISE (Sayyad
Shirabad y Menzies, 2005). Se tomó el conjunto de
datos KC1 creado por la NASA. El objetivo es realizar
la clasificación de módulos o clases de software
posiblemente defectuosos basados en una serie de
atributos conformados de acuerdo con las métricas
de complejidad del software (McCabe, 1976; Halstead,
1977) e identificar cuándo un módulo puede llegar a
tener un comportamiento adecuado o no. Este archivo
es del tipo ARFF (Attribute Relation File Format) y cuenta
con una serie de casos, los cuales a su vez contienen
atributos categóricos en donde se le asigna un valor
a cada uno para realizar el recorrido del algoritmo y
poder identificar un conjunto de reglas.
Tabla 1
Composición del conjunto de datos utilizado para el caso de estudio
Conjunto de datos
# Casos
#
Atributos categóricos
#
Atributos
continuos
#
Clases
Class-level data for KC1
144
0
94
2
(defectuoso, no defectuoso)
[ 49 ]
Andrés Castaño Vélez et al. / Vector 5 (2010) 45-52
La aplicación en la cual se ejecutó el algoritmo de
clasificación es Myra-3.0.1, un framework gratuito y de
código abierto escrito en lenguaje Java, proporciona
una capa especializada de minería de datos para
aplicaciones que utilizan optimización por colonia
de hormigas para problemas de clasificación. Myra3.0.1 incluye la implementación de los algoritmos
Ant-Miner, cAnt-Miner y cAnt-Miner2, permitiendo
seleccionar el algoritmo que más ventajas presente al
momento de obtener los datos con la mayor precisión.
El proceso de descubrimiento de las reglas se
determina en gran medida por el conjunto de
entrenamiento, descubriendo una regla a la vez.
Cada vez que se descubre una se añade a la lista
de reglas encontradas, luego elimina el conjunto de
patrones utilizados para descubrir dicha regla del
conjunto de entrenamiento y se hace la petición a
un nuevo proceso para repetir el ciclo, este proceso
es utilizado por ambos algoritmos. Pero, es preciso
tener presente que el algoritmo Ant-Miner realiza
una búsqueda estocástica de la información para la
identificación de reglas, mientras que cAnt-Miner
utiliza búsquedas deterministas para encontrar las
reglas, lo que diferencia ambos algoritmos, y entregan
una desviación estándar diferente. Con el ánimo de
comparar el desempeño de los algoritmos se hizo
necesario discretizar los atributos en una etapa de
preproceso para trabajar el mismo repositorio con
Ant-Miner y cAnt-Miner2. Se utilizó el método de
discretización C4.5-Disc (Kohavi y Sahami, 1996), el
cual consiste en usar el algoritmo de inducción por
árbol de decisión C4.5 para crear intervalos discretos
para cada atributo continuo de forma separada. Para
cada atributo continuo se aplica el algoritmo a un
conjunto reducido de datos que contiene el atributo
a discretizar y el atributo clase. De esta forma, de
las 145 instancias originales se obtuvieron 108 con la
discretización.
Condiciones iniciales para la clasificación del
conjunto de datos:
Algoritmo cAnt-Miner2
Parámetros utilizados en el conjunto de datos:
•
•
[ 50 ]
Number of ant in colony = 3000, determina el
conjunto de reglas construidas durante la iteración
de cada ciclo del algoritmo.
Maximum number of uncovered cases = 5,
determina el procedimiento de descubrimiento de
las reglas. Este proceso es iterativo en el conjunto
de datos de entrenamiento hasta que se supera
este umbral.
•
•
Minimum covered examples per rule value = 5,
determina el mínimo de cumplimientos de cada
regla para generar un grado de confiabilidad
dentro de los patrones descubiertos en el conjunto
de datos.
Maximum number of iterations = 1500, limita el
ciclo del algoritmo.
=== Run Information ===
Random seed: 1305733777287
Relation: kc1-class-level-defectiveornot
Instances: 145
Attributes: 94
Duplicates: yes
Classes: 2
Hierarchical: no
=== Discovered Rules ===
IF maxDIFICULTAD_PROGRAMA < 12.375
AND avgESENCIA_COMPLEJIDAD < 1.1833335
AND avgCOMPLEJIDAD_ALGORITMO_INDEP_
LENGUAJE < 22.6295 AND maxLINEAS_CODIGO <
38.5 THEN NO_DEFECTUOSO
IF sumNIVEL_ENTENDIMIENTO >= 3.09 AND
avgLINEAS_CODIGO_Y_COMENTARIO < 0.1785715
THEN DEFECTUOSO
IF VECES_INCLUIDA < 0.5 AND
maxCOMPLEJIDAD_ALGORITMO_INDEP_
LENGUAJE >= 46.935 AND sumNIVEL_
ENTENDIMIENTO < 4.21 THEN DEFECTUOSO
IF avgLINEAS_CODIGO < 37.9375 AND
maxCOMPLEJIDAD_ALGORITMO_INDEP_
LENGUAJE >= 35.335 AND maxLINEAS_
COMENTARIO < 19.5 THEN NO_DEFECTUOSO
IF sumNIVEL_ENTENDIMIENTO >= 1.19 AND
maxCOMPLEJIDAD_CICLOMATICA < 22.0 THEN
DEFECTUOSO
IF maxDIFICULTAD_PROGRAMA < 40.38 THEN
NO_DEFECTUOSO
IF <empty> THEN DEFECTUOSO
Measure (AccuracyMeasure): 0.9310344827586207
Elapsed time: 4 second(s)
Algoritmo Ant-Miner
Measure (AccuracyMeasure): 0.9028390572614326
Elapsed time: 4 second(s)
Análisis de calidad del software usando optimización por colonia de hormigas
Tabla 2
Exactitud predictiva de Ant-Miner y cAnt-Miner2 después de 10 veces del procedimiento de validación en cruz
Tamaño
Conjunto de datos
Class-level data for KC1
Original
144
4. Conclusiones
En este trabajo se ha demostrado cómo determinar
la predicción de errores en los módulos de software y
su aplicación a través de una técnica de clasificación en
un conjunto de datos con módulos o clases de software
posiblemente defectuosos utilizando el algoritmo de
Optimización por Colonia de hormigas (ACO).
El algoritmo cAnt-Miner2 posee una exactitud de
predicción levemente mayor que el algoritmo AntMiner, además encuentra la lista de reglas de una
manera más simple sin que se incremente el tiempo
de computo.
La utilización de ACO se ha extendido a problemáticas
de análisis de calidad de software. En este trabajo
tomamos información de un repositorio público. Los
resultados obtenidos ayudan al administrador del
proyecto de software a tomar acciones concretas y
mejorar el proceso de desarrollo.
El algoritmo cAnt-Miner2 evidencia la construcción
de un conjunto de reglas que no hace uso de la
reutilización de patrones encontrados para identificar
nuevas reglas, a partir de un conjunto de datos con
atributos continuos. Diferenciándose del algoritmo
C4.5 en donde el conjunto de reglas encontrado se
construye a partir de la reutilización de patrones para
ir de lo general a lo particular.
Referencias
Abraham A., Ramos V. (2003). Web usage mining using artificial
ant colony clustering and linear genetic programming. CEC ‘03.
The 2003 Congress on Evolutionary Computation, 1382: 1384-1391.
Azar D., Vybihal J. (2011). An ant colony optimization algorithm to
improve software quality prediction models: Case of class stability.
Information and Software Technology, 53(4): 388-393.
Bo L., Abbas H.A., McKay B. (2003). Classification rule discovery
with ant colony optimization. En: Intelligent Agent Technology, IAT
2003. IEEE/WIC. pp. 83-88.
Boehm B., Harrowitz E. (2000). Software Cost Estimation with Cocomo
II. Prentice Hall International.
Cusumano M., MacCormack A., Kemerer C., Crandall W. (2003).
Software development worldwide: the state of practice. IEEE
Software - IEEE Computer Society, 20(6): 28-34.
de Almeida M.A., Lounis H., Melo W.L. (1999). An investigation
on the use of machine learned models for estimating software
correctability. International Journal of Software Engineering and
Knowledge Engineering, 9(5): 565-594.
De Rore L., Snoeck M., Dedene G. (2006). COCOMO II applied in
a banking and insurance environment: experience report. En:
Discreto
108
Ant-Miner
90,28
Algoritmo
cAnt-Miner2
93,10
Software Measurement European Forum Edition 3. Roma. pp. 247-257.
Dick S., Meeks A., Last M., Bunke H., Kandel A. (2004). Data mining
in software metrics databases. Fuzzy Sets and Systems, 145(1):
81-110.
Dorigo M., Maniezzo V., Colorni A. (1996). The Ant System:
Optimization by a Colony of Cooperating Agents. IEEE
Transactions on Systems, Man, and Cybernetics-Part B, 26(1): 29-41.
Dorigo M., Gambardella L.M. (1997). Ant colony system: a
cooperative learning approach to the travelingsalesman problem.
IEEE Transactions on Evolutionary Computation, 1(1): 53-66.
Dorigo M., Birattari M., Stutzle T. (2006). Ant colony optimization.
Computational Intelligence Magazine, IEEE, 1(4): 28-39.
Garcia M.N.M., Quintales L.A.M., Penalvo F.J.G., Martin M.J.P.
(2001). Aplicación de técnicas de minería de datos en la
construcción y validación de modelos predictivos y asociativos
a partir de especificaciones de requisitos de software. En: ADIS.
pp. 1.
Halstead M.H. (1977). Elements of Software Science (Operating and
programming systems series). Elsevier Science Inc: New York.
Handl J., Knowles J., Dorigo M. (2006). Ant-Based Clustering and
Topographic Mapping. Artificial Life, 12(1): 35-61.
Khoshgoftaar T., Allen E., Jones W., Hudepohl J. (1999). Data Mining
for Predictors of Software Quality. International Journal of Software
Engineering and Knowledge Engineering, 9(5): 547-564.
Khoshgoftaar T.M., Seliya N. (2003). Analogy-Based Practical
Classification Rules for Software Quality Estimation. Empirical
Software Engineering 8(4): 325 - 350
Kohavi R., Sahami M. (1996). Error-based and entropy-based
discretization of continuous features. En: Proceedings of the second
international conference on knowledge discovery and data mining
California. pp. 114–119.
McCabe T.J. (1976). A complexity measure. IEEE Transactions on
Software Engineering, 2(4): 308–320.
Mendonca M., Basili V., Bhandari S., Dawson J. (1998). An approach
to improving existing measurement frameworks. IBM Systems
Journal, 37(4): 484-501.
Mendonca M., Basili V. (2000). Validation of an Approach for
Improving Existing Measurement Frameworks. IEEE Transactions
on Software Engineering, 26(6): 484-499.
Mockus A., Fielding R., Herbsleb J. (2000). A Case Study of Open
Source Software Development: The Apache Server. En: ICSE’2000.
ACM. pp. 263-272.
Parpinelli R.S., Lopes H.S., Freitas A.A. (2002). An ant colony algorithm
for classification rule discovery. En: Data Mining: A Heuristic Approach.
pp. 190-208.
Paul R.A., Kunii T.L., Shinagawa Y., Khan M.F. (1999). Software
metrics knowledge and databases for project management.
Knowledge and Data Engineering, IEEE Transactions on, 11(1): 255264.
Sayyad Shirabad J., Menzies T.J. (2005). The PROMISE Repository of
Software Engineering Databases. School of Information Technology
and Engineering, University of Ottawa, Canada,
Standish Group. (2004). Chaos report. The Standish Group.
Stutzle T., Hoos H. (1996). Improving the Ant-System: A detailed report
on the MAX --MIN Ant System.
Vandecruys O., Martens D., Baesens B., Mues C., De Backer M.,
Haesen R. (2008). Mining software repositories for comprehensible
[ 51 ]
Andrés Castaño Vélez et al. / Vector 5 (2010) 45-52
software fault prediction models. The Journal of Systems and
Software, 81(5): 823-839.
Xingliang Z., Jianzhang L. (2006). An Ant Colony System-based
Optimization Scheme of Data Mining. En: Sixth International
Conference on Intelligent Systems Design and Applications, ISDA
‘06. pp. 400-403.
Ying A.T.T., Murphy G.C., Ng R., Chu-Carroll M.C. (2004). Predicting
source code changes by mining change history. IEEE Transactions
on Software Engineering, 30(9): 574-586.
[ 52 ]