Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
DEPARTAMENTO DE LENGUAJES Y SISTEMAS E INGENIERÍA SOFTWARE
Facultad de Informática Universidad Politécnica de Madrid
TESIS DOCTORAL
MODELO MATEMÁTICO PARAMETRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)
Autor Óscar Marbán Gallego
Licenciado en Informática
Directores Ernestina Menasalvas Ruíz
Doctora en Informática
Juan José Cuadrado Gallego Doctor en Informática
Año: 2003
UNIVERSIDAD POUTECNICA DE MADRID
(D-15)
Tribunal nombrado por el Magfco. y Excmo. Sr. Rector de la Universidad Politécnica de Madrid, el día. de de 200....
Presidente:
Vocal:
Vocal:
Vocal:
Secretario:.
Suplente:_
Suplente:_
Realizado el acto de defensa y lectura de la Tesis el día de de 200. en la E.T.S.I. /Facultad
EL PRESIDENTE LOS VOCALES
EL SECRETARIO
A todos aquellos que creyeron que la terminaría.... ... así como a aquellos que no lo hicieron. En especial a mis padres, Manuel y María, a mis abuelos y a la sonrisa de mi querida Susana
A todos debo la motivación para haber llegado hasta aquí.
Agradecimientos Para empezar quiero expresar mi más sincero agradecimiento a mis padres, Manuel y María, a mis
abuelos Miguel, María, Manolo y Antonia, y a mi tío Miguelito por haber hecho posible que me
dedicara a lo que me gusta. También quiero agradecer a Susana todo el apoyo que me ha dado
mientras realizaba este trabajo. Gracias a todos por soportarme durante todo este tiempo, bueno,
por soportarme siempre.
Quiero expresar mi agradecimiento a toda aquella gente que me ayudo a llegar hasta aquí, com
pañeros de carrera, profesores y compañeros. Entre ellos cabe mencionar a Juanfran, a José Marcos
y toda aquellas gente maravillosa que tanto tiempo pasó junto a mi en el laboratorio durante la ca
rrera y los cursos de doctorado. También algo parte de culpa de que yo haya llegado hasta aquí la
tiene Chema, gracias por tus enseñanzas magistrales.
Gracias a Antonio de Amescua por permitirme trabajar en su grupo de investigación en la Uni
versidad Carlos III durante este tiempo. Por otra parte quiere darle las gracias a Covadonga por la
confianza depositada en mi.
También merecen un agradecimiento especial Soco, Esther, Mike y Anita por darme la posibilidad
de realizar los experimentos de esta tesis con datos reales.
A mis directores de tesis Juanjo y Ernestina por haberme ayudado a conseguir este trabajo de tesis.
También debo darle las gracias a Coro por ayudarme con toda la burocracia que conlleva la reali
zación de un trabajo de tesis, sin su ayuda seguro que no me hubiera aclarado con tanto papel.
Mención especial merece la profesora y amiga Ernestina Menasalvas, por su gran ayuda a lo largo
del tiempo, a pesar de las broncas que de vez en cuando me he llevado por su parte, seguro que
me las merecía. Muchas gracias Ernes, sin tu ayuda no hubiera podido llevar a buen puerto este
trabajo.
Óscar Marbán Gallego
Madrid, 24 de Marzo de 2003
Resumen Data Mining surgió como línea de investigación en la década de los 80 para tratar de encontrar
una solución al problema de descubrimiento de conocimiento en bases de datos. El conocimiento
adquirido de las bases de datos se utiliza para dar soporte a los procesos de toma de decisiones
en las empresas. El desarrollo de técnicas de Data Mining sirvió como soporte para los proyectos
de CRM. Desde entonces son muchos los proyectos de CRM que se han desarrollado en todo tipo
de organizaciones. Sin embargo aún a día de hoy estos proyectos se realizan sin una estimación
clara de ningún tipo de recursos. Como consecuencia, si bien son muchos los proyectos que se han
terminado con éxito, son numerosas las referencias de fracasos de proyectos de Data Mining por
falta de estimación al comienzo de los mismos.
Si bien son muchas las referencias que aparecen en la bibliografía referente a algoritmos de des
cubrimiento, son escasas las que abordan el problema de aplicación de Data Mining en una em
presa desde la perspectiva de la Ingeniería del Software. De hecho la única aproximación es la
definición del modelo de proceso estándar CRISP-DM.
En los estándares de modelo de proceso para desarrollo de software, se encuentran procesos y ta
reas similares a los propuestos CRISP-DM para la generación del Presupuesto y del Plan de proyecto.
En el caso de desarrollo de software, se realiza la estimación de la duración y del esfuerzo que lle
vará la realización del proyecto para lo que se cuenta con múltiples métodos de estimación como
SLIM, SEER-SEM, PRICE-S o COCOMO entre otros. Si lo que se trata es de hacer la estimación para
un proyecto de Data Mining estos métodos no resultan apropiados, dado que su entrada principal
es el tamaño del software a desarrollar, y en los proyectos de Data Mining no se trata de desarrollar
software.
Aunque para ciertos tipos de problema de Data Mining hay métodos de estimación en fases avan
zadas del proyecto [Dom99, Dom98] no hay un método genérico de estimación de proyectos de
Data Mining, cuyos resultados, esfuerzo y tiempo, sirvan como punto de partida para realizar el
plan de proyecto y el presupuesto. Esta es la motivación central de este trabajo de tesis doctoral en
el que se propone establecer un método paramétrico de estimación para proyectos de Data Min
ing. Para ello se obtienen en esta tesis los principales drivers de coste para establecer, basándose en
proyectos reales, mediante regresión lineal la ecuación del modelo.
Abstract Data Mining is a research line that began in 1980 in order to find the knowledge that is hidden in the
data that organizations are storing in a daily basis. This knowledge supports the decisión making
processes in organizations. As a consequence companies of every kind have been developing data
mining projects since the term appeared. However, there is no way to estimate this kind of projects.
Although there are many references to Data Mining algorithms in the bibUography, not many au-
thors have dealt the problem frorn Software Engineering point of view.
CRISP-DM is a model process that appeared in 2000. CRISP-DM is the first standard of Data Mining
projects development.
In the standard of software development model process processes and tasks are proposed similar to
those in CRISP-DM model, nevertheless, in software development a lot of methods are described
to estimate the costs of project development (SLIM, SEER-SEM, PRICE-S and COCOMO). These
methods are not appropriate in the case of Data Mining projects because in Data Mining software
development is not the first goal.
Some methods have been proposed to estimate some phases of a Data Mining project [Dom99,
Dom98] but there is no method to estimate the global cost of a generic Data Mining project. The
lack od Data Mining project estimation processes is on the basis of many real life projects failure
due to the non realistic estimation at the beginning of the projects.
Consequently, we propose to design and valídate a parametric cost estimation model for Data Min
ing projects. The drivers of the model will be firstly proposed and later the equation of the model
will be obtained applying linear regression on data gathered of real Data Mining projects.
índice
Capítulo 1. Introducción 1
1.1. Objetivos del trabajo 4
1.2. Organización del trabajo 5
I ESTADO DE LA CUESTIÓN 6
Capítulo 2. Estado de la cuestión 7
2.1. Gestión de relaciones con los clientes (CRM) 8
2.2. Data Mining 10
2.2.1. Fase de preproceso 12
2.2.2. Vase de Data Mining 15
2.2.2.1. Tipos de problemas de DflíaM/«/«g 15
2.2.2.2. Operaciones y técnicas de Dflífl Mmmg 16
2.2.3. Fase de postproceso e implantación 18
2.2.4. Personal en los proyectos de Data Mining 18
2.2.5. Herramientas de Data Mining 20
2.3. Bases de datos analíticas: Data Warehouse 20
2.3.1. Aiquitectuia de un Data Warehouse 22
2.3.2. El modelo multidimensional 25
2.4. Modelo de proceso CRISP-DM 27
2.5. Estimación de proyectos software 30
2.5.1. Métodos de estimación software 31
2.5.2. Modelos matemáticos de estimación 35
2.5.2.1. Aspectos ftindamentales en el ftincionamiento de los modelos mate
máticos de estimación 35
2.5.3. Modelos matemáticos de estimación software 37
2.5.3.1. SLIM 38
2.5.3.2. PRICE-S 39
2.5.3.3. COCOMOII 41
2.6. Modelos de estimación en proyectos de Data Mining 48
2.6.1. Taxonomía de costes de problemas predictivos 48
2.6.2. Estimación en proyectos de marketing 49
2.6.3. Aplicación de NPV para la estimación del coste de aplicaciones "Machine
Learning" 50
2.7. Resumen contextual 51
II ESTUDIO Y RESOLUCIÓN DEL PROBLEMA 53
Capítulos. Planteamiento del problema 54
3.1. Planteamiento 54
3.2. Objetivos del trabajo 59
Capítulo 4. Solución 61
4.1. Introducción 61
4.2. Descripción del entorno 62
4.2.1. Descripción de la empresa 62
4.2.2. Descripción de un proyecto de Data Mining normal 63
4.3. Drivers de coste propuestos para proyectos de Dflífl Mwmg 64
4.3.1. Drivers de Datos 66
4.3.1.1. Volumen 66
4.3.1.2. Dispersión o número diferentes de valores de los atributos (DISP) . 69
4.3.1.3. Calidad de los datos 70
4.3.1.4. Disponibilidad de los modelos de datos (DMOD) 72
4.3.1.5. Privacidad de los datos (PRIV) 72
4.3.1.6. Necesidad de adquisición de datos externos (DEXT) 73
4.3.2. Drivers de Modelos 74
4.3.2.1. Número de modelos (NMOD) 74
4.3.2.2. Tipo de modelo (TMOD) 74
4.3.2.3. Características del modelo 75
4.3.2.4. Disponibilidad de técnicas para el tipo de problema a tratar (MTEC) 80
4.3.3. Drivers de Plataforma de desarrollo 81
4.3.3.1. Número y tipo de fuentes (NFUN) 82
4.3.3.2. Tipo de servidores donde residen los datos (NSER) 83
4.3.3.3. Distancia y forma de comunicación entre los orígenes de datos (SCOM) 83
4.3.4. Drivers de Técnicas y Herramientas 84
4.3.4.1. Disponibilidad de herramientas (TOOL) 84
4.3.4.2. Tipo de herramientas 85
4.3.4.3. Herramientas vs. Máquina vs. Modelo de datos (TOMM) 87
4.3.4.4. Nivel de transparencia de las herramientas (TRAN) 87
4.3.4.5. Nivel de formación de los usuarios que requieren las herramientas
(NFOR) 88
4.3.4.6. Amigabilidad de las herramientas (TFRI) 89
4.3.5. Drivers de Proyecto 90
4.3.5.1. Número de departamentos involucrados en el proyecto (NDEP) . . . 90
4.3.5.2. Documentación a entregar (DOCU) 90
4.3.5.3. Modelos para múltiples entornos (MSIM) 91
4.3.5.4. Desarrollo en múltiples localizaciones (SITE) 91
4.3.6. Drivers de Personal 92
4.3.6.1. Continuidad del personal (PCON) 92
4.3.6.2. Formación del personal en perfiles complementarios (PCOM) . . . . 93
4.3.6.3. Conocimiento de los datos que se van a utilizar (KDAT) 93
4.3.6.4. Actitud de la dirección frente al proyecto (ADIR) 94
4.3.6.5. Experiencia en proyectos similares (PEXP) 94
4.3.6.6. Familiaridad con el tipo de problema (MFAM) 95
4.3.6.7. Experiencia con técnicas y herramientas (TEXP) 96
4.3.6.8. Conocimiento del funcionamiento del negocio (BCON) 96
4.4. Planteamiento de la ecuación del modelo DMCOMO 96
4.4.1. Descripción de los datos de entrada 98
4.4.2. Obtención de la ecuación de regresión 100
4.4.2.1. Paso 1: Descripción estadística de los datos 100
4.4.2.2. Paso 2: Valores fuera de rango o "outliers" 102
4.4.2.3. Paso 3: Estudio de correlación 102
4.4.2.4. Paso 4: Ecuación del modelo mediante regresión lineal 105
4.4.2.5. Paso 5: Estudio de la significación de la ecuación 107
4.5. Validación de la ecuación del modelo DMCOMO 110
4.6. Resumen contextual 111
III CONCLUSIONES Y LÍNEAS FUTURAS 113
Capítulos. Conclusiones y Líneas futuras 114
5.1. Conclusiones 114
5.2. Líneas futuras 115
Bibliografía 117
Apéndice A. Método Delphi 129
A.I. Formularios Delphi utilizados para DMCOMO 130
Apéndices. Regresión múltiple 135
Apéndice C. Datos utilizados para DMCOMO 137
Apéndice D. Modelo DMCOMO 148
Capítulo 1
Introducción
"... Porque ¿quién hay entre vosotros que queriendo levantar una torre, no se sienta primero para calcular los gastos y ver si tiene para acabarla? No sea que, si pone el cimiento y no puede acabar, todos los que se enteren se burlen de él,..." [bib78, Lucas 14:28}
En 1999 un informe de GartnerGroup [DiLOO] predecía un gran crecimiento en el campo de Data
Mining. "En la próxima década, el número de proyectos de Data Mining crecerá drásticamente (más
de un 300 %) para mejorar las relaciones con los clientes y ayudar a las empresas a escuchar a sus
clientes".
El informe de Forrester Reseeirch [CTGN02] establecía que: "Después de la caída de más de 2.000
millones de dólares en el año 2002, el mercado de CRM crecerá más del 11% anual, alcanzando los
73.800 millones de dólares en el año 2007".
Teniendo en cuenta los resultados de los informes de GartnerGroup y de Forrester Research y la
cantidad de proyectos de CRM que se están desarrollando en las empresas, se puede determinar
que la industria de CRM tiene y tendrá un gran crecimiento en la década actual.
CRM [Customer Relationship Management, Gestión de las Relaciones con los Clientes) se puede
definir como la estructura que permite la obtención y el aumento del valor de los clientes así como
los medios para hacer que los clientes de más alto valor para la empresa permanezcan leales. El
• MODELO MATEMÁTICO PAKAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)
CAPÍTULO 1. INTRODUCCIÓN
típico concepto de "cliente" ya no existe. Hasta hace poco las organizaciones estaban preocupadas
por el qué en lugar de por el quién. En la actualidad, la mayoría de los clientes de las empresas
y comercios demandan servicios y tatro personalizado. La competencia entre empresas (márge
nes cada vez más reducidos, calidad máxima, reducción de costes, máxima adaptabilidad al cam
bio), las nuevas exigencias y los comportamientos mucho más dinámicos de los clientes unido a la
necesidad del trato personalizado y a la existencia de nuevos canales de negocio tales como Inter
net han dado lugar a la aparición del concepto CRM.
Consecuencia de todo lo visto, en los últimos años las empresas se han visto obligadas a desarrollar
sistemas de CRM. Estos sistemas se dividen en tres grandes áreas CRM Operacional, que es el con
junto de herramientas necesarias para mantener las operaciones de los distintos canales (medio
por el cual los productos y servicios son suministrados o prestados al cliente final) y la funciona
lidad soportada por los mismos; CRM Coloborativo, que mantiene el diálogo entre los distintos
canales y mantiene la coherencia y reutilización máxima de la información; y CRM Analítico, que
es el encargado de agrupar y gestionar la información con el fin de analizar estos datos y poder
optimizar la relación mantenida con el cliente. Para poder analizar los datos adquiridos día a día
por las organizaciones en búsqueda de información que ayude a dcir un trato personalizado a los
clientes surge en 1980 la investigación en Data Mining [PSF91, FPSSU96]. Data Mining es por tanto
la base para realizar CRM analítico en las organizaciones, lo que explica el gran número de proyec
tos de Data Mining que en las empresas se están realizando durante los últimos diez.
Para poder analizar el comportamiento de los clientes es necesario analizar las bases de datos
históricas obtenidas del día a día en cada empresa. Para solventar el problema del descubrimien
to de conocimiento en bases de datos surgió el área de investigación en KDD. Desde la aparición
del concepto de KDD en 1980 la investigación en este área de conocimiento ha dado como ñ"uto
numerosos algoritmos para resolver los distintos problemas de descubrimiento de conocimien
to que se pueden abordar. Estos algoritmos han servido de base para la implementación de nu
merosos sistemas comerciales de Data Mining (Clementine [ISL95, KS95, She96], IBM Intelligent
Miner [Tka98, IBM99], Weka rWitOO], DBMiner [The97]) que se utilizan hoyen día que en las orga
nizaciones involucradas en proyectos de Data Mining. Si bien las herramientas son de gran ayuda
en el desarrollo de los mencionados proyectos se requiere de una metodología para el desarrollo
de los mismos.
Para solventar los problemas que el desarrollo de proyectos de Data Mining estaba teniendo en
las organizaciones, un grupo de empresas (Teradata, SPSS (ISL), Daimler-Chrysler y OHRA) de
sarrollaron el modelo de proceso CRISP-DM [NSN+OO]. La aparición de CRISP-DM , supuso un
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ¡DMCOMO)
CAPÍTULO 1. INTRODUCCIÓN
modelo de proceso en el cual no solo se definen las fases, sino que también se definen los procesos
a realizar en cada una de ellas con las entradas y salidas correspondientes. El estándar CRISP-DM
propone un modelo de proceso para el desarrollo de sistemas de Data Mining, de forma similar
a los estándares ISO 12207 [IS095] e IEEE 1074 [IEE91] que proponen modelos de proceso para el
desarrollo de productos software.
Los modelos de proceso proponen una fase de gestión de proyectos dentro de la cual una subtarea
es siempre la estimación del esfuerzo y del tiempo que llevará el desarrollo del producto. Para rea
lizar dicha estimación se han desarrollado distintos modelos de estimación siendo los modelos
matemáticos paramétricos una de las primeras metodologías de estimación de costes desarro
lladas [ISP99]. Estos modelos, basados en un conjunto de variables de entrada significativas, o
parámetros, fueron desarrollados con el objetivo de realizar estimaciones de los costes de las nuevas
adquisiciones a realizar por el DoD [Department ofDefense, Departamento de Defensa de los Esta
dos Unidos de América).
El funcionamiento de los modelos matemáticos de estimación para proyectos software se funda
menta en la utilización de ecuaciones matemáticas mediante las cuales se obtiene el valor de un
conjunto de variables dependientes de salida (esfuerzo, tiempo de desarrollo, etc.) en función de
los valores numéricos dados a otro conjunto de variables independientes de entrada (tamaño de
la aplicación en líneas de código, ñabilidad requerida de la misma o complejidad, etc.). La mayor
parte de estos modelos suelen operar mediante un proceso de dos pasos, en el primero se realiza
una primera aproximación o estimación en función del valor de un conjunto reducido de variables
independientes, y en el segundo se precisa el resultado mediante la utilización de otro conjunto
de variables que permite refinar los cálculos. La obtención de buenos resultados haciendo uso de
este tipo de modelos se fundamenta en la correcta definición de las ecuaciones a utilizar, en la
continua revisión de las variables de entrada utilizadas, en el correcto calibrado de los parámetros
utilizados por el modelo y en la correcta selección del rango de las variables de entrada del modelo.
Como ejemplo de modelos matemáticos paramétricos de estimación para sistemas software desta
can COCOMOII [BARLOO], SLIM [SPJROO], PRICE-S [PS98b] entre otros. También existen modelos
de este tipo en otros campos como pueden ser para el desarrollo de hardware PRICE-H [PS98a] o
el propuesto en [Ham02a] para proyectos de lanzamientos espaciales en la NASA. Sin embargo, no
se han propuesto a fecha de hoy modelos para la estimación de proyectos de Data Mining.
Si bien, CRISP-DM, como modelo de proceso, también incluye una subtarea (desarrollo de un plém
de proyecto) que incluye la estimación del proyecto, no indica como estimar los proyectos de Data
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING IDMCOMOf
CAPÍTULO 1. INTRODUCCIÓN
Mining. Por tanto, se podría pensar en aplicar los modelos de estimación propuestos para el de
sarrollo de productos software (COCOMOII, SLIM, etc.).
No obstante, los modelos de estimación que se utilizan en proyectos de construcción de software
iCOCOMOII[BARLOO], SLIMfSPJROO], PRICE-S [PS98b], SEER-SEM[Ass96D no resultan útiles para
proyectos de Data Mining, puesto que todos ellos utilizan como principal entrada el tamaño (una
estimación del número de líneas de código) del software a construir. Por este motivo estos méto
dos de estimación no resultan válidos para proyectos de Data Mining, puesto que en este tipo de
proyectos no se trata, en principio, de construir una herramienta software, que se pueda medir en
líneas de código, sino que se trata de construir modelos que a partir de unos datos de entrada per
mitan la obtención de patrones en los datos, que es el objetivo básico del proceso de KDD.
Los métodos de estimación de proyectos de Data Mining que se han propuesto hasta el día de hoy
[MPS96, Dom98, KPR99] se pueden clasificar por un lado en aquellos que estiman el valor que ten
drá para la empresa la información obtenida [MPS96, KPR99] y por otro lado en aquellos modelos
que hacen una estimación de los beneficios que se obtendrán con el proyectos [Dom98] basándose
en NPV (Net Present Valué) para tomar la decisión de continuar o no con el proyecto. Este último
método tiene en cuenta factores tales como la experiencia del personal, si se utilizan herramientas,
etc.
Como consecuencia se puede afirmar que aunque han pasado veinte años desde la aparición del
término Data Mining no existe a día de hoy un método genérico para estimar los proyectos de Data
Mining. Consecuentemente se plantea en este trabajo de tesis doctoral un modelo paramétrico de
estimación para proyectos de Data Mining.
1.1. Objetivos del trabajo
Dada la importancia que está tomando en la actualidad el desarrollo de proyectos de Data Mining
y que no hay ningún método de estimación, que calcule la duración y el esfuerzo para este tipo de
proyectos, el principal objetivo de este trabajo de tesis doctoral es la construcción de un modelo
paramétrico de estimación para proyectos de Data Mining. Para ello el trabajo a realizar se puede
desglosar en los siguientes objetivos parciales:
Q Realizar un análisis de comportamiento para determinar que factores influyen en el esfuerzo
de los proyectos de Data Mining para establecer los drivers de coste.
• Recogida de datos acerca de los drivers planteados en proyectos reales de Data Mining.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOI"
CAPÍTULO 1. INTRODUCCIÓN
a Plantear un modelo inicial basado regresión lineal sobre el conjunto de datos recogidos.
• Validación del modelo, estimando el esfuerzo de un conjunto de proyectos reales y compa
rando el valor estimado con el valor real del esfuerzo.
El cumplimiento de estos objetivos, se traducirá en las siguientes aportaciones:
• Teóricas: La construcción de un modelo de estimación para proyectos de Data Mining. Co
mo consecuencia de la construcción del modelo, se conocerán los factores qué afectan al
esfuerzo de un proyecto de Data Mining y en qué medida lo hacen.
O Prácticas: Disponibilidad de una herramienta para poder realizar estimaciones del esfuerzo
de proyectos de Data Mining. También se aportará la forma de calibrado del mismo y la forma
de utilización.
1.2. Organización del trabajo
El contenido de este trabajo de Tesis se encuentra organizado de la forma que se detalla a conti
nuación.
Q En el Capítulo 2 se hace un repaso a los trabajos realizados hasta el momento en una serie
de campos, en la intersección de los cuales se encuadra tanto el problema planteado como
la solución propuesta. Estos trabajos son los realizados en el campo del descubrimiento de
información en grandes volúmenes de datos y los planteados en el campo de la estimación
de proyectos, en concreto, en la estimación de proyectos software.
a La segunda parte de este trabajo de Tesis presenta el problema tratado y la solución planteada
como respuesta al mismo.
• En el Capítulo 3 se plantea el problema a resolver.
• En el Capítulo 4 se propone la solución al problema planteado en el capítulo 3. Asimis
mo se realiza la validación de la solución propuesta.
• Finalmente, la última parte del trabajo recoge, en el Capítulo 5 las conclusiones extraídas de
esta investigación y en las líneas de investigación abiertas tras la realización del mismo.
•MODELO MATEMÁTICO PAÜAMÉTRICO DE ESTÍMACIÚNPAKA PROYECTOS DE DATA MINING (DMCOMOX
Parte I
ESTADO DE LA CUESTIÓN
•MODELO MATEMÁTICO PARAMÉrmCO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
Capítulo 2
Estado de la cuestión
índice General
2.1. Gestión de relaciones con los clientes (CRM) 8 2.2. Data Mining 10
2.2.1. Fase de preproceso 12 2.2.2. Fase de Data Mining 15 2.2.3. Fase de postproceso e implantación 18 2.2.4. Personal en los proyectos de Data Mining 18 2.2.5. Herramientas de £)aía Mm/ng 20
2.3. Bases de datos analíticas: Data Warehouse 20 2.3.1. Arquitectura de un Daífl Wflre/íOMse 22 2.3.2. El modelo multidimensional 25
2.4. Modelo de proceso CRISP-DM 27 2.5. Estimación de proyectos software 30
2.5.1. Métodos de estimación software 31 2.5.2. Modelos matemáticos de estimación 35 2.5.3. Modelos matemáticos de estimación software 37
2.6. Modelos de estimación en proyectos de Dato Mi'nzng 48 2.6.1. Taxonomía de costes de problemas predictivos 48 2.6.2. Estimación en proyectos de marketing 49 2.6.3. Aplicación de NPV para la estimación del coste de aplicaciones "Machine
Learning" 50 2.7. Resumen contextual 51
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOr
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
2.1. Gestión de relaciones con los clientes (CRM)
La aparición del concepto de CRM [Customer Relationship Management, Gestión de Relaciones con
los Clientes) se debe a la puesta en escena de nuevos parámetros en el entorno empresarial que han
hecho evolucionar las estrategias tradicionales de negocio. Entre estos parámetros destacan, por
un lado la competencia entre las organizaciones con márgenes cada vez más reducidos, reducción
de costes y máxima adaptabilidad al cambio. Por otro lado, se tienen clientes con nuevas exigencias
y comportamientos mucho más dinámicos, más exigentes, con mucha más información, criterio
propio y capacidad de decisión a la hora de la compra. Así, el más pequeño error en el trato provo
ca el rápido abandono de la compañía actual y el cambio a otra compañía que facilite el acceso y
la personalización en la relación. La fidelización de los clientes es por tanto un factor a tener en
cuenta cada vez con mayor cuidado. Por último la existencia de nuevas posibilidades técnicas con
infinidad de medios de interrelación con los sistemas de compra e información de las compañías,
facilitando la ubicuidad, sencillez y facilidad de acceso, como por ejemplo Internet, hacen que la
forma de hacer negocio tenga que adaptarse al cambio.
CRM ha sido definido como: "Conjunto global de procesos tecnológicos, humanos y funcionales des
tinados a proporcionar servicios integrales personalizados a la estructura de clientes de una Com
pañía o Corporación" [DycOl].
Durante muchos años los proyectos de Sistemas de Información de las organizaciones se han orien
tado hacia sistemas que capturan y tratan eficientemente las operaciones de la empresa. La mayo
ría de las veces estos sistemas son completamente independientes haciendo difícil una visión in
tegral de la información operacional de la empresa. En otros casos, los sistemas están organizados
por línea de producto, por línea de servicio o por segmentos de clientes. Así pues los Sistemas de
Información son aislados y carecen de una visión global y homogénea con una difícil integración
entre sus elementos. Una de las características más importantes de CRM es disponer de almacenes
de datos integrados, consolidados, fácilmente interpretables, manejables y de calidad.
Para abordar servicios CRM, muchas compañías han seleccionado un determinado producto de la
nueva generación de paquetes para aplicaciones de FrontOffice, por ejemplo orientadas a la rápida
implantación de procesos básicos de Atención al Cliente (Chordiant [Inc02], Clarify [fGE02], Reme-
dy [CRM02], etc.), de MiddleOffice, como son las soluciones de Bussines Inteligence para el análisis
de datos de negocio y de BackOffice, por ejemplo para facturación.
Sin embargo, durante el proceso de implantación de estos sistemas, se advierte la necesidad de
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PAJU PROYECTOS DE DATA MINING (DMCOMOJ
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
tener una visión coordinada de los datos, de los procesos de la organización y del cliente con el
fin de conseguir un verdadero beneficio y valor diferencial en la gestión del servicio proporciona
do. Las necesidades de estas organizaciones pasan a ser necesidades tecnológicas de integración
de nuevas aplicaciones con paquetes previamente adquiridos y sistemas ya montados {legacy sys-
tems). Para poder unir las herramientas anteriores (FrontOffice, MiddleOffice y BackOffice) en un
sistema de CRM integrado se han de construir una serie de subsistemas que se comunican entre si.
Así los sistemas de CRM, según Gartner Group [GroOl], están divididos en tres grandes áreas, una
operacional, una analítica y una colaborativa (ver figura 2.1).
CRM Operacional CRM Analítico
Back Office
Front Office
Mobile Office
Interacción con
el cliente
ERP SMC
Customer Service
Legacy Systems
Automatización - de -.
Marl<eting
Automatización >• d e
ventas
Sistema Móvil de ventas
Atención de campo
• Data Warefiouse
Voz Web Correo electrónico
Fax Cartas
Interacción directa
CRM Colaborativo
Figura 2.1: Descripción de CRM
Por CRM Operacional se entiende al conjunto de herramientas necesarias para mantener las ope
raciones de los distintos canales, y la funcionalidad soportada por los mismos, entendiendo por
canal el medio a través del cual los productos y servicios son suministrados o prestados al usuario
o cliente final. Está formado por un BackOffice o MiddleOffice constituido por los sistemas ERP
{Enterprise Resource Planning], SCM {Supply Change Management) y el resto de los sistemas cor
porativos {Legacy Systems), por un FrontOffice {Customer Service, Automatización de Marketingy
Ventas) y por un MobileOffice {Sistema Móvil de Ventas y Atención de Campo). En algunos casos
también se denomina a este subsistema como CRM transaccional puesto que se ocupa de ges
tionar todas las transacciones de información entre los distintos elementos.
El CRM Colaborativo mantiene el diálogo entre los distintos canales y las herramientas de BackOf
fice manteniendo la coherencia y fomentando la reutilización máxima de la información.
Por último el subsistema de CRM Analítico es el encargado de agrupar y gestionar la información
• MODELO MATEMÁ TICO PARAMÉTRICO DE ESTIUACIÓN PARA PBOYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 10
con el fin de analizar estos datos, utilizando Data Warehouse y Data Marts, para poder optimizar
la relación mantenida con el cliente, potenciando los productos y servicios de mayor aceptación,
potenciando los canales de mayor llegada, desplegando una red de canales diferentes, centrándose
en aquellos clientes de mayor valor potencial o mayor rentabilidad pasada, etc. Es aquí donde se
aplican las técnicas de descubrimiento de información en bases de datos, entre ellas Data Mining.
2.2. Data Mining
La evolución de los dispositivos de almacenamiento masivo (en relación precio - capacidad de al
macenamiento) tales como los discos duros que pueden almacenar gigabytes de información a un
precio reducido, dio lugar a que las organizaciones almacenaran todo tipo de información.
Con el tiempo, la cantidad de datos que se fue almacenando empezó a crecer y, si bien, el soporte
de las herramientas para realizar la gestión de los datos era el adecuado, los datos empezaron a
sobrepasar las capacidades humanas para el análisis. Al mismo tiempo, los sistemas de bases de
datos habían comenzado a descentralizarse con lo que las decisiones tenían falta de credibilidad,
ineficiencia y falta de productividad. Como respuesta a esto surgieron por un lado la investigación
en KDD [Knowledge Discovery in Databases) [PSF91, FPSSU96] o Data Mining para dar respuesta a
los problemas de análisis de datos y por otro lado surge la investigación en Data Warehouse como
base de datos de soporte al proceso de KDD.
El proceso de descubrimiento de información oculta en bases de datos se conoce con el nombre de
proceso de KDD {Knowledge Discovery in Data Bases). El proceso de KDD fue definido en [PSF91] y
en [FPSS96] como: "El proceso no trivial de identificación de patrones válidos, novedosos potencial-
mente útiles y comprensibles en los datos".
En la definición anterior se entiende por datos un conjunto de hechos y patrones que se expre
san en algún lenguaje. Por lo general, el formato de representación de estos datos son tupias de
una base de datos. Si bien se dice que es una base de datos, en la mayoría de los casos estos datos
no están en una única base de datos, sino que se hallan dispersos entre las bases de datos opera-
cionales de la organización. El término patrones designa los modelos extraídos en base a los datos
y que representan una descripción de alto nivel de los datos de los que provienen. Estos patrones
serán los que servirán para representar el conocimiento que se extraerá de la base de datos y que
será utilizado en los procesos de CRM. Los patrones extraídos pueden representarse como reglas,
árboles, grafos o cualquier otra forma de representar información de alto nivel.
' MODELO MATEMÁ TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO}'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 11
Por otra parte se dice que es Data Mining es un proceso porque descubrir conocimiento de bases
de datos, implica una serie de pasos entre los que destacan la selección de los datos, discretización
de valores, refinamiento de los datos, búsqueda de los patrones, evaluación del conocimiento ex
traído y posiblemente iteraciones sobre todas las fases para el posterior refinado. Este proceso
además no es un proceso trivial porque si bien existen herramientas de Data Mining, estas he
rramientas ayudarán en las distintas fases pero se requerirá de la experiencia de expertos en cada
una de las fases del proceso para conseguir con éxito los patrones buscados. Por otra parte, los
patrones que se descubran deberán ser válidos con algún grado de certeza y novedosos al menos
para el sistema que los descubre y preferiblemente para el usuario que los requiere. En este punto
es importante recordar que el usuario que requiere la información no es un experto en Data Mining
sino que es un experto en temas de negocio. Debido a esto, para que se pueda asegurar que el pro
ceso termina con éxito el conocimiento extraído deberá proporcionar algún beneficio al usuario o
tarea que requiere de ese conocimiento y por supuesto debe ser comprensible bien directamente
o bien después de algún procesamiento por parte del usuario final. Ya se ha dicho, que uno de los
usos fundamentales de Data Mining es como componente básico del CRM analítico, por ello es
fundamental que el conocimiento extraído sea interpretable por los expertos de negocio.
Si bien el término KDD es como surgió el área de investigación referida al descubrimiento de
conocimiento en bases de datos, este término fue pronto sustituido por el de Data Mining. Da
ta Mining en la definición original de BGDD figuraba como el nombre de una de las fases en las que
se descomponía el proceso (ver figura 2.2).
Figura 2.2: Fases de Data Mining
Si bien distintos autores [CHS+97, PSF91, Man97] han dado distintos nombres a las distintas fases
del proceso de KDD, se observan dos partes claramente diferenciadas, la parte que desarrolla los
modelos y la parte en la cual se implantan los modelos adquiridos. Todas las diferentes propuestas
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PAHAPUOYECTOSDB DATA MINING (DMCOMO)'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 12
de proceso de KDD se han unificado en un estándar conocido como CRISP-DM [NSN+00].
Así, en las descomposiciones del proceso de KDD [CHS+97, PSF91, Man97] se pueden diferenciar
claramente tres fases:
• Preproceso
• Data Mining
• Postproceso
Es obvio que previo a cualquiera de estas fases se requiere una fase de establecimiento del pro
blema en la cual quede claro cuál es la meta que se pretende conseguir. El dejar claro el objetivo
será la única manera de poder establecer al final del proyecto de Data Mining si este concluyó con
éxito. Además la meta a conseguir será la que marcará las tareas a realizar en cada una de las fases
que analizarán a continuación. El disponer de esta información permitiría, caso de que existiera
un modelo de estimación de costes, el poder calcular el coste del proyecto antes de comenzarlo.
2.2.1. Fase de preproceso
Uno de los problemas fundamentales con los que se enfrentan los proyectos de Data Mining es la
recolección de los datos que se van a utilizar para descubrir el potencial conocimiento oculto en
ellos. Estos datos proceden en su mayoría de las bases de datos operacionales de la organización,
y como tal, ocurre que han sido diseñadas en distintos momentos, se encuentran almacenados en
sistemas de gestión de bases de datos de distintos fabricantes, habiéndose utilizado distintos crite
rios para el nombrado, tipado, y almacenamiento de los mismos. Por otra parte, no todos los datos
se van a encontrar en bases de datos bien diseñadas, sino que se dispone de gran parte de datos en
ficheros, papel, hojas de cálculo, datos provenientes de Internet o adquiridos de fuentes externas.
Como consecuencia el primer paso, antes de poder aplicar algún algoritmo de descubrimiento de
conocimiento, es la recolección, selección, limpieza e integración de los datos objetivo, que se co
rresponde con la subtarea de selección de los datos.
El objetivo de la subtarea de selección de los datos es la identificación de las fuentes de datos
disponibles y la extracción de los datos necesarios para un análisis preliminar de manera que al
final de la fase se tengan los datos que se prepararán para posteriormente aplicar sobre ellos técni
cas de Data Mining. Es obvio que la selección de los datos depende del tipo de problema a resolver
y de la meta perseguida. Una vez que se tienen recogidos los datos hay que comprobar la canti
dad y calidad de los mismos. Para construir modelos robustos es necesaria una buena cantidad de
'MODELO MATEMÁTICO PARAMÉFRICO DE ESTIMACIÓN PAEA PROYECTOS DE DATA MINING fDMCOMO)'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 13
datos, pero además de tener grandes cantidades de datos, se tendrá que estudiar cada campo, los
tipos de datos, los valores máximo y mínimos etc. para que los datos que se vayan a utilizar sean de
calidad. Además a la hora de seleccionar datos hay que tener en consideración el tiempo de vida
de la variable, o lo que es lo mismo, habrá que establecer el periodo de tiempo a partir del cual la
variable habrá dejado de ser significativa.
Las subtareas anteriormente vistas habrá que realizarlas siempre y cuando los datos no se hallen
previamente integrados en un Data Warehouse. Aun cuando los datos se encuentren en un Data
Warehouse y en cualquier otro caso, siempre será necesaria una transformación de los datos previo
a las tareas de descubrimiento para convertirlos en entrada adecuada del algoritmo de Data Mining
que se vaya a utilizar. En este paso, son tareas que se tendrán que realizar siempre la eliminación
de nulos en caso de que existan, tratamiento de valores fuera de rango, discretización de valores en
el caso de que el formato de entrada requiera valores discretos, entre otros, que se corresponden
con las subtareas de preproceso de los datos y de transformación de los datos. Así pues, la meta de
la subtarea de preproceso de los datos es asegurar la calidad de los datos que se han seleccionado,
es decir, que los datos estén limpios y libres de inconsistencias, puesto que es un requisito previo
para que un proyecto de Data Mining tenga éxito.
Por otra parte, cuanto más y mejor se conozcan los datos será más fácil saber que datos utilizar en
la fase de Data Mining. Esta subtarea es más problemática porque los datos que van a ser analiza
dos no fueron recogidos con el objetivo de ser analizados. Por este motivo la primera tarea que se
debe realizar es la supervisión de la estructura de los datos para obtener una primera medida de la
calidad de los mismos. Para la realización de esta tarea cobran especial importancia las herramien
tas de visualización (histogramas, representaciones gráficas de los datos, etc.), que pueden ayudar
a visualizar la distribución de cada variable identificando valores nulos y valores fuera de rango, y
los métodos estadísticos (análisis descriptivo). Una vez que se han analizado los datos habrá que,
para cada variable a considerar, eliminar los valores con ruido, tratar los valores nulos y detectar
inconsistencias. El ruido es un error aleatorio o varianza en una variable. Como consecuencia, las
variables afectadas por el ruido tendrán valores que caen fuera de los valores esperados para las
mismas. Los "outliers" o valores fuera de rango pueden representar un objetivo a buscar o datos
incorrectos. Para tratar los "outliers", puesto que pueden ser de distintos tipos, se utilizan técnicas
diferentes para su tratamiento. Alguna de las técnicas para el tratamiento de valores fuera de ran
go son: binning o método de los cubos, clustering y regresión. Cuando se están analizando datos,
muchas veces ocurre que alguno de los valores de los atributos para algunas de las tupias no existe.
Si ocurre esto, hay que decidir que se hace con la tupia o como se rellena el valor que no existe. Para
eliminar estos valores inexistentes, o valores nulos, se pueden utilizar varias técnicas, pero hay que
•MODEW MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 14
tener en cuenta que la eliminación de nulos puede conllevar la introducción de ruido. Algunas de
las posibles técnicas para la eliminación de ruido son: eliminar o ignorar la tupia, rellenar la tu
pia manualmente, utilizar una constante global para rellenar el valor nulo, por ejemplo, se puede
utilizar un valor como "desconocido", utilizar el valor de la media de los valores del atributo para
rellenar el valor, utilizar la media de los objetos que pertenecen a la misma clase o utUizar alguna
técnica de Data Mining para inferir el valor más probable. También puede ocurrir que los datos al
macenados presenten inconsistencias. Algunas de ellas se pueden corregir manualmente utilizan
do referencias externas. Estas técnicas manuales se pueden combinar con rutinas automáticas que
controlcín si se han violado restricciones sobre los datos. Una de las mayores fuentes de inconsis
tencias proviene de la integración de los datos donde a menudo ocurre que el mismo atributo tiene
distintos nombres, distintos valores e incluso está medido en distintas unidades.
Por otro lado, el objetivo de la subtarea de transformación de los datos preprocesados es la trans
formación de los mismos a un modelo analítico. Este es un modelo representa una vista integrada,
consolidada y dependiente del tiempo de los datos seleccionados y preprocesados provenientes de
las múltiples fuentes de datos. Esta subtarea es una subtarea importante, puesto que el éxito y la
exactitud de los modelos que se obtendrán en la fase de Data Mining depende de como el analista
de datos decida estructurar y presentar la entrada a la siguiente fase. Por otra parte, es en esta fase
cuando se tienen que codificar los datos para que sean una entrada adecuada para los algoritmos
de Data Mining que se vaya a utilizar. Otra transformación frecuente que se realiza es lo que se de
nomina reducción de variables, donde en lugar de eliminar variables redundantes o no necesarias
lo que se hace es una consolidación de varias variables en una con mayor semántica. Algunas de la
operaciones que se realizan en esta fase son: agregación, discretización, generalización, reducción,
compresión, normalización y construcción de atributos.
Cuando se habla de esta fase, es importante resaltar que el perfil de los usuarios participantes es
un perfil mixto, puesto que se requieren usuarios con profundos conocimientos de estadística para
poder realizar todas las fases relativas a la calidad de los datos y usuarios con conocimientos del
negocio que indiquen si las variables y datos seleccionados serán apropiados para el tipo de meta
que se persigue.
Más en concreto, es esta fase tienen que participar analistas del negocio (business analyst) con
conocimientos en el dominio del problema para ayudar a fijar el objetivo del proyecto, analistas
de datos (data analyst) que se encargará de transformar los objetivos del negocio en objetivos de
Data Mining, seleccionará los algoritmos de Data Mining que mejor se adecúen para resolver el
problema planteado y deberá hacer el preproceso y la transformación de los datos. Además hace
•MODELO MATEMÁTICO PARAMÍTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING IDMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 15
falta personal con el perfil de especialista en la gestión de los datos (data management specialist)
durante la subtarea de selección de los datos, puesto que será el encargado de la recolección e
integración de los datos que se van a utilizar.
2.2.2. Fase de Data Mining
Una vez los datos han sido seleccionados y preprocesados de manera que se tiene un conjunto de
datos integrados sin inconsistencias y de calidad adecuada llega el momento de aplicar algorit
mos de Data Mining para descubrir el conocimiento que se pretendía al comienzo del proyecto.
Nuevamente, este paso no es obvio y se componen de toda una serie de pasos cuya realización es
obligatoria si se quiere concluir con éxito el proyecto. De esta manera lo primero que habrá que
establecer es el tipo de problema de Data Mining que se quiere resolver. Esto pasa por una traduc
ción del objetivo establecido en términos de negocio al objetivo expresado en términos de Data
Mining. En este particular es importante destacar que si bien el número de problemas de negocio
que se pueden enfrentar son infinitos todos pueden ser expresables dentro de una gama finita de
problemas de Data Mining. En concreto los problemas de Data Mining se pueden clasificar en
predictivos y descriptivos. Si bien a continuación, se describirán en detalle los distintos tipos de
problemas, es importante en este punto destacar que establecer adecuadamente el tipo de proble
ma ayudará a establecer el esfuerzo del proyecto. De esta manera, los proyectos descriptivos, en
general, son de menor complejidad que los proyectos de índole descriptiva. Habiendo establecido
el tipo de problema la siguiente dificultad a resolver es encontrar la técnica más adecuada para
resolver el problema. Nuevamente esto no es un paso obvio puesto que para cada tipo de proble
ma, y dependiendo del tipo de datos habrá que seleccionar la técnica y el algoritmo más adecuado.
Este es otro de los puntos que marcará la complejidad del proyecto puesto que esta directamente
relacionado con la naturaleza de los datos (discretos, continuos).
En esta fase todo el personal participante tendrá el perfil de analista de datos (data analyst) para
la ejecución de los algoritmos de Data Mining sobre los datos correspondiente, y adicionalmente
debería participar un especialista en la gestión de los datos (data management specialist) por si
hubiera algún problema con la estructura, contenido o significado de los datos.
2.2.2.1. Tipos de problemas de Data Mining
A pesar de existir multitud de problemas que se pueden intentar resolver mediante técnicas de Da
ta Mining todos ellos se pueden clasificar en dos grandes grupos, problemas descriptivos o proble
mas de aprendizaje no supervisado y problemas predictivos o problemas de aprendizaje supervisa
do.
•MODELO MATEMÁTICO PARAMÉTRICO DB ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 16
Bajo el epígrafe de problemas descriptivos se encuadran aquellos problemas cuya meta es sim
plemente encontrar una descripción de los datos que se están analizando. Este tipo de problemas
se puede descomponer en problemas de análisis de segmentación y en problemas de análisis de
asociaciones. El problema de análisis de segmentación trata de encontrar grupos homogéneos en
los datos origen que están siendo analizados (por ejemplo, obtener una segmentación de tipos de
clientes), mientras que el problema de análisis de asociaciones persigue obtener relaciones entre
los valores de atributos de una base de datos (por ejemplo el de análisis de la cesta de la compra).
En cuanto a los problemas predictivos, su meta es obtener un modelo que pueda ser aplicado para
predecir comportamientos futuros. Es importante destacar aquí que el proceso de Data Mining es
siempre un proceso inductivo en el que no se realiza ninguna predicción, pero este tipo de pro
blemas se conoce como problemas predictivos porque el resultado se utiliza para predecir algún
valor, si bien los resultados se obtienen a través de técnicas inductivas. Los problemas predictivos
se pueden dividir en problemas de clasificación si la variable a predecir es de tipo categórico y en
problemas de predicción de valores si la variable a predecir es de tipo numérico.
Esta clasificación en tipos de problemas de Data Mining es importante puesto que en fianción
del tipo de problema que se afronte, se aplicará una u otra operación de Data Mining para solu
cionarlo.
2.2.2.2. Operaciones y técnicas de Data Mining
Para resolver los problemas de Data Mining se pueden utilizar múltiples operaciones provenientes
de diferentes enfoques (estadístico, machine learning, orientado a bases de datos, matemático,
etc.). En la tabla 2.1 se puede observar un resumen de las principales operaciones de Data Mining
y las posibles técnicas de Data Mining que se pueden utilizar para resolver las operaciones de Data
Mining.
Operaciones Modelos predictivos
Segmentación de bases de datos
Análisis de relaciones
Detección de desviaciones
Técnicas - Clasificación - Predicción de valores - Clustering demográfico - Clustering neuronal - Descubrimiento de asociaciones - Descubrimiento de patrones secuenciales - Descubrimiento de patrones en series temporales - Técnicas de visualización - Métodos estadísticos
Tabla 2.1: Ejemplos de operaciones y técnicas de Data Mining
'MODEtO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 17
Los modelos predictivos se basan en la experiencia del aprendizaje humano, donde se utiliza la
observación para construir un modelo esencial de algo, sin necesidad de memorizar todos y cada
uno de los casos que se tengan clasificar, para utilizarlo posteriormente para clasificar algo similar.
En el caso de Data Mining se utilizan los datos para formar un modelo con las características es
enciales de los mismos.
Estos modelos se crean en dos fases, una fase de entrenamiento, para crear el modelo a partir de
datos históricos, y otra fase de prueba, en la que se utilizan datos reales para comprobar que mode
lo creado en la fase anterior es correcto. Al final estos modelos se reducen a reglas del tipo IF-THEN.
Las técnicas de Data Mining asociadas a los modelos predictivos son la clasificación (árboles de de
cisión, árboles de inducción y redes neuronales) y la predicción o estimación de valores (regresión
lineal o no lineal, funciones RBF).
Las operaciones de segmentación de la bases de datos tratan de particionar la base de datos en
conjuntos de objetos con características similares o en conjuntos homogéneos. Este tipo de ope
ración se utiliza para descubrir subpoblaciones dentro de una base de datos y poder crear perfiles
que caractericen a esas subpoblaciones. Para segmentar una base de datos se pueden emplear dos
técnicas diferente, por un lado el clustering demográfico que compara cada registro de la base de
datos con todos los clusters y se asocia al más cercano utilizando una función de distancia, y por
otro lado el clustering neuronal basado en redes neuronales basadas (mapas de Kohonen).
Por otro lado, mediante el análisis de relaciones se trata de buscar relaciones entre diferentes regis
tros de la base de datos. Estas relaciones suelen llamarse asociaciones. Dentro de esta operación de
Data Mining se distinguen tres técnicas. La primera de ellas es el descubrimiento de asociaciones,
que se utiliza principalmente para observar registros que ocurren simultáneamente. El objetivo de
esta técnica de Data Mining es encontrar elementos que implican la presencia de otros elementos
dentro de una misma transacción. El resultado de esta técnica son reglas del tipo "if X then Y". Uno
de los algoritmos de asociación más utilizados es Apriori [AFS93, AS94b, AS94a]. Otra técnica es
el descubrimiento de patrones secuenciales, que trata de descubrir patrones entre transacciones
en las que un conjunto de elementos va seguido de otro conjunto de elementos distanciados un
periodo de tiempo determinado. La ultima de las técnicas es el descubrimiento de patrones en
series temporales. Con esta técnica se pretenden descubrir ocurrencias o secuencias similares a
una dada en una base de datos que almacene información que represente una serie temporal.
Todas estas operaciones y técnicas de Data Mining se pueden encontrar implementadas en alguna
herramienta de Data Mining comercial o no comercial (ver sección 2.2.5).
•MODELO MATEMÁTICO PARAMÉTRICO DEESTIMACIÚN PARA PROYECTOS DE DATA MINING ÍDMCOMOr
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 18
2.2.3. Fase de postproceso e implantación
Una vez obtenidos los modelos en la fase de Data Mining hay que analizar los resultados que pro
porcionan y ver si son interesantes, válidos y si con ellos se puede tomar decisiones. Esto es, hay
que analizar con medidas objetivas el conocimiento que proporcionan para aplicarlo posterior
mente en la organización. Si no se puede aplicar el conocimiento obtenido, habrá que volver a
fases anteriores del proceso para analizar de nuevo los datos hasta llegar a obtener conocimiento
que resulte aplicable en la orgemización.
Los resultados que se obtienen con los modelos tienen diversas formas, reglas, árboles, redes neu-
ronales, etc. que no son fácilmente interpretables por los usuarios finales debido a que sue perfil
(ejecutivos, alta dirección, etc.) no es técnico. Por tanto se hace neceseiria la transformación de
resultados proporcionados por los modelos de Data Mining en resultados comprensibles por los
usuarios finales.
Los participantes en esta fase del proceso son analistas de datos (data analyst) que se encargarán
de la transformación de los resultados, analistas de negocio (business analyst) que ayudan con la
interpretación correcta de los resultados y los usuarios finales que son los que tomarán las deci
siones convenientes en función de los resultados obtenidos.
Por último, una vez que los resultados son aceptados por los usuarios finales, hay mostrar los resul
tados desde la perspectiva del negocio y hay que plantear la forma en la que explotcir el conocimien
to obtenido. Para llevar a cabo esto puede ser necesario la integración del nuevo conocimiento en
sistemas previamente construidos o el desarrollo de nuevos sistemas que lo incorporen (construc
ción o mantenimiento de software).
2 .2 .4 . Personal en los proyectos de Data Mining
Tal y como se he venido exponiendo, los proyectos de Data Mining se caracterizan por ser multi
disciplinares, consecuencia de lo cual se pueden distinguir varios roles entre los participante en el
mismo.
Los diferentes roles que se diferencian en un proyecto de Data Mining son: el sponsor, formado por
la dirección de la empresa y/o la dirección del departamento para el cual se desarrolla el proyecto
de Data Mining, el equipo de Data Mining formado por analistas de datos [data analyst) y espe
cialistas en gestión de datos {data management specialist), los expertos en el negocio (business an-
• MODELO MATEMÁTICO PAMMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING IDMCOMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 19
alyst) y los usuarios finales de la información extraída (user group). Por último y como en cualquier
otro proyecto que se desarrolle habrá un jefe de proyecto iproject manager] que se encargará de
todas las tareas relacionadas con la gestión del proyecto.
La dirección de la empresa es la parte patrocinadora del proyecto, es decir, es la parte que pone el
dinero para que se pueda llevar a cabo el proyecto, sin su participación y apoyo sería muy difícil el
llevar a cabo el proyecto. Este rol es similar al de cualquier otro tipo de proyecto.
En el siguiente nivel se encuentra la dirección del departamento, también en parte responsable de
la financiación del proyecto. La dirección del departamento es la que decidirá que datos son los
que se pueden analizar sin violar la intimidad de los individuos cuya información se encuentra
almacenada en los datos analizados. Asimismo, la dirección del departamento también es respon
sable de la implantación de los resultados obtenidos del proyecto. Sin el apoyo de la dirección del
departamento es imposible el desarrollo de un proyecto de Data Mining.
El equipo de Data Mining será el responsable del análisis de los datos para extraer el conocimiento
oculto en los mismo. La composición de este equipo suele ser multidisciplinar, matemáticos, es
tadísticos, informáticos, expertos en los datos, gente de marketing, etc. Por lo general, el personal
del equipo de Data Mining debería tener al menos conocimiento de los problemas, operaciones y
técnicas de Data Mining, aunque lo ideal sería que, las personas que lo integran, hubiesen traba
jado anteriormente en otros proyectos de Data Mining.
Por otro lado sería conveniente la participación en el proyecto de expertos en el negocio que ayu
den al equipo de Data Mining a tomar las decisiones correctas sobre que datos se deben utilizar o
para analizar la validez de los modelos creados mediante técnicas de Data Mining. Estos expertos
al conocer el negocio sabrán valorar las decisiones que se toman por el equipo de Data Mining
siendo de gran ayuda en momentos críticos del proyecto.
Por último, los usuarios del conocimiento extraído de la información son participantes indirectos
en un proyecto de Data Mining. Normalmente suelen ser directivos de la empresa que no tienen
porque tener conocimientos de informática y que solo saben analizar resultados concretos. Por lo
tanto, el equipo de Data Mining debe plantear la visualización del conocimiento extraído de forma
interpretable por los usuarios finales.
'MODELO MATEMÁTICO PABAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOt
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 20
2.2.5. Herramientas de Data Mining
A lo largo del tiempo desde que surgió la investigación en Data Mining, han ido surgiendo toda
una serie de herramientas comerciales y no comerciales (Clementine [ISL95, KS95, She96], IBM
Intelligent Miner [Tka98, IBM99], Weka [WitOO], DBMiner [The97], DAMISYS [FPM+99, FMP+00])
para ayudar a realizar las tareas de Data Mining, desde el preproceso de los datos, pasando por la
aplicación de técnicas de Data Mining al conjunto de datos seleccionado, hasta la visualización de
los resultados obtenidos.
La mayoría de las herramientas de Data Mining implementan un conjunto de técnicas, no sólo, de
Data Mining (Apriori, redes neuronales, algoritmos de clasificación, etc.) sino de todo el proceso de
KDD como pueden ser técnicas de visualización de resultados o técnicas de preproceso con el ob
jetivo de facilitar el trabajo de Data Mining a los usuarios de las mismas. Estas herramientas suelen
tener un interfaz de usuario gráfico amigable y fácil de utilizar, lo que hace que si hay que repetir
una serie de acciones múltiples veces, por lo general, no resulten muy adecuadas. Por otro lado, las
herramientas de Data Mining pueden tratar datos que se encuentran en diferentes tipos de fuentes
de datos (ficheros de texto, Sistemas Gestores de Base de Datos, etc.), permiten pueden exportar
los resultados a diferentes herramientas ofimáticas (procesadores de texto, hojas de cálculo, etc.),
incluso llegan a exportar los modelos creado a código implementado en algún lenguaje de pro
gramación. Algunas herramientas permiten añadir pequeños programa o "plug-ins" para realizar
alguna tarea, ya sea de preproceso, de Data Mining o de postproceso. Otras permiten utilizar en
otros programas las técnicas de Data Mining que tienen implementadas a través de una API (.Ap
plication Program Interface). Por lo tanto, las herramientas de Data Mining, en principio, tratan
de facilitar el trabajo a los miembros participantes en un proyecto de Data Mining, pero esto no
siempre es así. Dependiendo del tipo de tareas a realizar, de las técnicas soportadas por las herra
mientas, de la facilidad de uso y nivel de integración de la herramienta o herramientas utilizadas
para el desarrollo del proyecto, resultarán más o menos útiles para la realización del mismo.
Otro de los elementos que facilita la realización de un proyecto de Data Mining, es el Data Ware-
house, entendiendo como Data Warehouse la base de datos de soporte al proceso de KDD.
2.3. Bases de datos analíticas: Data Warehouse
Si bien Data Mining surgió como respuesta a los problemas de análisis de datos para ayudar a la
toma de decisiones en las organizaciones, tenía el problema de que los datos no se almacenabém
de la forma adecuada para ser tratados posteriormente con técnicas de Data Mining, por lo que
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 21
Data Warehouse surge como base de datos de soporte a los procesos de toma de decisiones, entre
ellos Data Mining.
Un Data Warehouse se define como [Inm02]: "Un Data Warehouse es una colección de datos que
sirve de apoyo a la toma de decisiones, organizados por temas, integrados, no volátiles y en los que el
concepto de tiempo varía respecto a los sistemas tradicionales". Si bien ha habido múltiples defini
ciones de Data Warehouse [Inm97, RKT98] de todas ellas se concluye que el concepto de inte
gración es el más destacable entre las características de un Data Warehouse
Por lo tanto, los Data Warehouse son soportes de datos "ad hoc" para realizar tareas de Data Min
ing, aunque no siempre son necesarios para ello.
Tal y como indica la definición, los datos en un Data Warehouse no se organizan acorde con las
aplicaciones que los usan, sino que lo hacen acorde con su semántica, independientemente de
qué aplicación los utilice. Esto hace que los métodos de diseño de un Data Warehouse varíen con
respecto a los métodos de las bases de datos operacionales, en concreto con respecto al modelo
Entidad-Relación [Ana97].
Otra de las características que se citan en la definición anterior, y que se considera la más impor
tante de un Data Warehouse, es la de integración. Un Data Warehouse se construye a partir de los
datos de las diversas fuentes de datos de una organización, lo que hace necesario un esfuerzo para
"poner en común" los datos de las diferentes fuentes. Cada una de las fuentes de datos de la orga
nización tendrá sus propios modelos de datos, sus propias políticas de asignación de nombres a
campos, de codificación de valores, y un largo etcétera de diferencias que hacen que el hecho de
recolectar los datos de las diversas fuentes de datos para unirlos en un esquema común supon
ga un gran esfuerzo, tanto computacional como humano. El esfuerzo computacional proviene del
hecho que hay que recorrer todos los datos a integrar, y realizar una transformación para que en
caje con el esquema centralizado que se adopte para el Data Warehouse. El esfuerzo humano es
debido a la necesidad de estudiar los modelos conceptuales, realizar uno común, unificar todas las
políticas de asignaciones, y, en definitiva, toda tarea no automatizable que genere el proceso de la
recolección e integración de los datos. Consecuentemente, si se utiliza un Data Warehouse en un
proyecto de Data Mining se reduce considerablemente el esfuerzo en la fase de preproceso.
Otra característica importante es la de la no volatilidad. Existen varias razones por las que los datos
de un Data Warehouse no son volátiles. La más importante es que un Data Warehouse se construye
para dar soporte a la toma de decisiones, y este tipo de tareas pueden requerir el análisis de datos
•MODEljO MATEMÁTICO PARAMÍTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 22
de diferentes momentos del tiempo, para realizar análisis comparativos. Por tanto, los datos de un
Data Warehouse no sufren actualizaciones. En él, se mantienen diferentes versiones temporales
de dichos datos, por tanto, el proceso que se realiza es la inserción de los nuevos datos en lugar
de una actualización de los mismos, añadiendo una marca temporal que los distingue de las dife
rentes versiones temporales ya existentes de dichos datos (tiempo). Una consecuencia directa de
tener que almacenar datos históricos es que el tamaño de la base de datos de soporte va a aumen
tar, pudiendo ocurrir que el tamaño de almacenamiento se duplique cada seis meses [Inm96]. Por
último es importante resaltar que el Data Warehouse sirve de apoyo a la toma de decisiones. Esto
hace referencia a que es necesario un modelo de almacenamiento de información que satisfaga
las necesidades de las aplicaciones de análisis, toda vez que los sistemas imperantes han sido op
timizados para el campo operacional. Y es precisamente para este propósito por lo que surgió el
Data Warehouse.
Así pues, queda claro que un Data Warehouse no es un producto que se pueda comprar, ni una base
de datos que se diseña, sino que es un conjunto de procesos y datos que ayudan a la extracción
de conocimiento de las bases de datos. Por lo tanto, la existencia de un Data Warehouse facilita
enormemente las tareas de desarrollo asociadas a la fase de preproceso en los proyectos de Data
Mining, si bien no es un requisito peira la realización de proyectos de Data Mining. A continuación,
se va a describir la arquitectura de un Data Warehouse. Esto dejará claro cuales son los procesos
implicados y de que manera el Data Warehouse ayuda en los procesos de Data Mining.
2.3.1. Arquitectura de un Data Warehouse
En un Data Warehouse se pueden distinguir claramente tres módulos (ver ñgura 2.3)
Q Módulo de adquisición: recopila todos los procesos enceirgados de la extracción de datos des
de las base de datos operacionales a la base de datos de soporte al Data Warehouse. Asimis
mo, este módulo está encargado de las labores de transformación e integración de los datos.
a Módulo de almacenamiento: este módulo es el encargado de mantener los datos. En estos
datos podemos distinguir datos con el máximo nivel de detalle provenientes directamente de
las fuentes, datos derivados y otros datos con un nivel de granularidad inferior que permitirán
resolver consultas con distintos grados de generalización.
Q Módulo de extracción: se encarga de dar soporte a todas las herramientas de extracción de
conocimiento. Estas herramientas pueden ser desde simples herramientas de "Query & Re-
porting" hasta las más soñsticadas herramientas de Data Mining.
Es importante resaltar que si bien un Data Warehouse da soporte a los procesos de toma de de
cisión los datos se van a encontrar integrados y este es el aspecto fundamental, pero no necesaria-
• MODELO MATEMÁTICO PAKAMÍTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 23
mente preparados para ser objeto de cualquier consulta de Data Mining. Si bien, seguiría siendo
necesario la aplicación de algoritmos de preparación de datos antes de realizar cualquier proceso
de Data Mining, es importante resaltar el hecho de que una vez se tiene un Data Warehouse las
tareas de integración se minimizan enormemente.
Otras fuentes
Bases de Datos operacionales
Adquisición de datos
Almacenamiento de datos
Extracción de Información
Herramientas
Usuarios
Análisis Query
Informes Ipata IVIlning
Figura 2.3: Arquitectura de un Data Warehouse
A continuación se presenta un análisis más detallado de cada módulo del Data Warehouse.
Módulo de adquisición
La tarea principal de este módulo es la de recoger los datos desde las fuentes de datos, ya sean bases
de datos o ficheros y hacerlos disponibles para el sistema de almacenamiento. Tiene que tratar el
problema de ETL {Extracción, Transformación y Carga). Desde un punto de vista global, esta tarea
parece simple, identificar los datos que se quieren cargar en el Data Warehouse y cargarlos. Pero
cuando se intenta realizar las tareas de ETL no son tan simples, ya que surgen múltiples proble
mas cuando se trata de integrar datos de múltiples fuentes. Desde el momento en que se decide
qué datos formarán parte del Data warehouse, empieza la tarea de integración. Una vez estableci
dos qué datos se almacenarán en el Data Warehouse, se procederá a la integración de los mismos.
El primer problema que se plantea al realizar esta tarea es la heterogeneidad de las fuentes, que
dificultará la tarea de encontrar los datos. Esta dificultad es debida a que un mismo dato en dis
tintas bases de datos puede tener diferente nombre, diferente tipo, diferente asignación de valores,
diferente representación interna. El segundo problema, que puede denominarse problema de asig-
• MODELO MATEMÁTICO PARAMÉTRKO DE ESTIMAOÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 24
nación de nombres, se refiere al hecho de que, en las diversas fuentes de datos, las tablas, atributos
y demás elementos no tienen porque estar identificados de manera unívoca por su nombre. El tipo
utilizado para representar un dato tampoco tiene porqué ayudar a la tarea de encontrar atributos
iguales. Dos datos equivalentes no tienen por qué estar almacenados con el mismo tipo. Por últi
mo, la misma información puede estar representada con diferentes valores de atributos, sean del
mismo tipo o no, por ejemplo, el atributo género podría tomar en una base datos los valores MyV
y en otra base de datos los valores O y 1.
Otra de las funciones del modulo de adquisición es la de limpieza de los datos, es decir, eliminar
aquellos datos que son inconsistentes, no están presentes, no pueden leerse o simplemente son
erróneos, por ejemplo valores fuera de rango. Una vez que los datos están integrados y limpios hay
que transformarlos para que se amolden al formato con el que se almacenaran en el Data Ware-
house. Una vez realizado el proceso de ETL los datos ya están listo para su almacenamiento en el
Data Warehouse.
Módulo de almacenamiento
Este módulo es el que gestiona el Data Warehouse, entendiendo por Data Warehouse la base de
datos que contiene los datos. Normalmente un Data Warehouse se implementa sobre un sistema
gestor de bases de datos relacional que debe soportar una serie de características especiales de
los Data Warehouses. Entre éstas características destaca el elevado número de tablas que se al
macenará, puesto que en el Data Warehouse se crean tablas agrupando datos por ciertos campos
para dar respuesta de forma óptima a las posibles consultas (diferente nivel de granularidad en las
tablas). Asimismo, en un Data Warehouse hay gran cantidad de datos almacenados en las tablas ya
que albergan datos provenientes de toda la organización, y además los datos que hay en el Data
Warehouse no se actualizan, sino que se van añadiendo nuevas tupias.
Además de los datos en un Data Warehouse también se almacenan metadatos o información sobre
los datos almacenados. Tal y como se ha comentado con anterioridad un Data Warehouse se con
cibe para dar soporte a la toma de decisión. Esto trae como consecuencia que las consultas que se
van a realizar contra esta base de datos van a ser accesos de solo lectura que tratan de analizar un
hecho (generalmente de negocio) por varios factores que influyen en el mismo. Este tipo de consul
tas incide directamente en el diseño de la base de datos de soporte. La consecuencia más inmediata
es que los métodos tradicionales de diseño de bases de datos no son adecuados para diseñar este
tipo de bases de datos. Por consiguiente, se han analizado distintos métodos de diseño llegándose
a la conclusión [RKT98] de que el modelo multidimensional es el mejor método de diseño para
Data Warehouses.
•MODELO MATEMÁTICO PARAMÉTBICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 25
Módulo de extracción
Este módulo proporciona acceso a la información almacenada en el Data Warehouse. Debe ser
capaz de entender las peticiones que realizan los usuarios. Asimismo, proporciona una interfaz
sencilla que permite a los usuarios hacer uso de los datos almacenados en el Data Warehouse.
Por lo tanto, este módulo se comunica con el módulo de almacenamiento para dar respuesta a
las peticiones de los usucirios. Además este módulo tiene que atender no solo las peticiones real
izadas por los usuarios, sino que debe atender también las peticiones realizadas por diversas apli
caciones (herramientas de análisis OLAP, herramientas de Data Mining, generadores de informes,
etc.). Para la implantación del Data Warehouse se han propuesto diversas metodologías, entre ellas
destacan la metodología top-down que propone la construcción de Data Warehouse monolíticos,
la metodología bottom-up que proponen la construcción de DataMart separados para cada depar
tamento que se integrarán con el tiempo para construir un Data Warehouse integrado. El primer
enfoque tiene la ventaja de conseguir un Data Warehouse integrado y la desventaja de requerir
altos costes de personal y tiempo para su construcción. El segundo enfoque requiere menos es
fuerzo, pero no se tiene una visión integrada de la empresa. Consiguientemente, se ha propuesto
una tercera metodología denominada de Bus común de Data Warehouse [RKT98] que pretende au
nar las ventajas de las metodologías anteriores, comenzando el diseño con la idea de construir un
Data Warehouse global para terminar implantando Data Marts integrados que formarán el Data
Warehouse global. En esta metodología se propone el modelo multidimensional como modelo de
diseño de la base de datos de soporte al Data Warehouse.
2 .3 .2 . El modelo mult idimensional
Una vez que se han recogido los requisitos de la organización y se han estudiado los datos que van
a formar parte del Data Warehouse, se está en disposición de comenzar el diseño lógico y físico
del Data Warehouse. Cabe pensar que como los Data Warehouse son al final bases de datos se po
drían utilizar las técnicas de diseño de bases de datos (Modelo Entidad/Relación (E/R) o el Modelo
relacional) pero estos modelos no son adecuados para el diseño de la base de datos de un Data
Warehouse.
Los modelos E/R son muy útiles cuando se realizan diseños transaccionales y se pueden utilizar en
las fases de administración del Data Warehouse o en la zona temporal de carga y transformación
de datos, pero no deberían utilizarse para el modelo final del Data Warehouse. Esto se debe a que
la técnica de E/R busca eliminar la redundancia en los datos y esto la hace apropiada psira modelar
transacciones puesto que las hace simples y deterministas. Sin embargo, debido a la eficiencia en
las transacciones se pierde eficiencia en las consultas que requieran más de una tabla.
•MODEIO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MININO (DMCOMO!
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 26
Si se observa la base de datos de un Data Warehouse, se llega a la conclusión de que no es una
base de datos donde la consistencia sea un problema puesto que los procesos fundamentales que
se realizan en un Data Warehouse son de consulta por usuarios y/o aplicaciones finales. Por tanto,
se tiene que pensar en una manera de diseñar la base de datos para que la información llegue al
usuario ñnal de forma eficiente.
La técnica de modelado multidimensional es una técnica de diseño lógico que busca presentar los
datos en un marco estándar que sea intuitivo y que permita accesos de alto rendimiento. La idea
subyacente a este método de diseño es que las consultas típicas en un Data Warehouse analizarán
distintos factores acerca de un mismo hecho de negocio. Para modelar esta idea en el modelo di
mensional se tiene el concepto de tabla de hechos que servirá para almacenar cada transacción
relativa a un determinado hecho y el concepto de tabla de dimensión que permitirá almacenar la
información relativa a cada factor por el que se analizan los hechos.
En la figura 2.4 se muestra un ejemplo del aspecto que tienen los diagramas resultantes del mode
lado multidimensional denominados diseños en "Estrella" o diseños "STAR".
Tabla de Dimensión
Tabla de Dimensión
Tabla de
HECHOS
Tabla de Dimensión
Tabla de Dimensión
Figura 2.4: Arquitectura de un Data Warehouse
En un modelo dimensional se hace la distinción entre hechos y atributos. Los atributos suelen
ser campos que describen características de las entidades u objetos, generalmente se utilizan para
designar a las propiedades de las dimensiones. Un hecho es generalmente algo que no se conoce
de antemano, es una observación del mundo real.
La tabla de hechos es la que contiene las observaciones sobre el hecho que se analiza a lo largo del
tiempo. Toda tabla de hechos tiene la siguiente estructura:
a Una clave primaria compuesta, donde cada uno de sus componentes es clave ajena respecto
a la clave primaria de una dimensión.
•MODELO MATEMÁTICO PARAMÉTmCO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 27
O Una serie de atributos (generalmente numéricos) que se denominan hechos.
En cuanto al tamaño de las tablas de hechos y de dimensiones cabe destacar que es con respecto a
las primeras con las que hay que tomar decisiones de diseño para su particionamiento. Dado que
estas tablas son las que contienen información de los hechos de la organización crecerán conti
nuamente con la operativa del día a día de la organización. No obstante, las tablas de dimensión
si bien pueden cambiar no suelen ser tablas cuyo tamaño crezca de manera alarmante. En cuanto
al diseño global del Data Warehouse es importante resaltar que el diseño de cada Data Mart es
tará compuesto por entre 10 y 15 diagramas en estrella cada uno de los cuales tendrá de 10 a 15
tablas de dimensión. No obstante las tablas de dimensión comunes a todas las estrellas formarán
parte del bus común del Data Warehouse, por lo que sólo se almacenará una vez.
2.4. Modelo de proceso CRISP-DM
A partir del análisis de los problemas que surgen del desarrollo de proyectos de Data Mining, una
serie de empresas punteras en proyectos de CRM (Teradata, SPSS (ISL), Daimler-Chryslery OHRA)
propusieron una guía de referencia para el desarrollo sistemático de proyectos de Data Mining,
conocida como CRISP-DM {CRoss Industry Standard Processfor Data Mining) [NSN+00]. Una de
las grandes ventajas de este estándar es que no está ligado a ningún producto comercial ni a ningún
tipo específico de aplicaciones o problemas.
El modelo de proceso CRISP-DM se define como un modelo de proceso jerárquico dividido en cua
tro niveles de abstracción, siendo el primero el más general y el último el más específico. Dentro
del primer nivel, el proceso de Data Mining se organiza en un cierto número de fases, constituidas
por varias tareas genéricas de segundo nivel que se pretende cubran todas las posibles situaciones
que se puedan presentar. El tercer nivel describe cómo se llevarán a cabo las acciones de dichas
tareas genéricas en situaciones específicas. En el cuarto nivel se tiene un registro de las acciones,
decisiones y resultados del caso de Data Mining abordado.
Por otro lado, la metodología CRISP-DM distingue entre el modelo de referencia y la guía de usuario.
El primero presenta una vista general de las fases, tareas y salidas, describiendo qué debe hacerse
en un proyecto de Data Mining mientras que la guía de usuario proporciona una información mas
detallada, consejos y recomendaciones para cada fase, pero en ningún caso indica como realizar
las tareas propuestas.
En el modelo CRISP-DM se distinguen cuatro dimensiones de contextos de Data Mining, el do
minio de aplicación que es el área específica en la que se desarrolla el proyecto de Data Mining,
• MODELO MATEMÁ TICO PARAMÉTRICO DE ESTIMAOÓN PARA PROYECTOS DE DATA MINING (DMCOMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 28
el tipo de problema de Data Mining que describe los objetivos específicos del proyecto, el aspecto
técnico que cubre asuntos específicos en Data Mining que describen diferentes retos que suelen
tener lugar dureinte el proyecto y la dimensión de herramientas y técnicas que especifica el tipo de
herramientas y/o técnicas de Data Mining que se deben aplicar durante el proyecto.
La aparición de CRISP-DM, supuso al menos un modelo de proceso en el cual no solo se definen
las fases, sino que también se definen los procesos a realizar en cada una de ellas con las entradas
y salidas correspondientes, aunque no propone como realizar las tareas propuestas para cada pro
ceso.
El modelo de de proceso CRISP-DM divide el proceso de KDD en las seis fases que se muestran en
la figura 2.5 y se describen brevemente a continuación.
Figura 2.5: Modelo de proceso CRISP-DM [NSN+00]
Q Comprensión del problema
Esta fase se centra en comprender los objetivos y los requisitos del proyecto desde el punto de
vista del negocio, para posteriormente definir el problema en términos de problema de Data
Mining. Una de las tareas que se propone en esta fase es la de definir un plan de proyecto
inicial para lograr los objetivos del proyecto. El plan de proyecto incluye la estimación del
proyecto, no obstante, no se dice nada de como se ha de realizar dicha estimación.
O Comprensión de los datos
El objetivo de esta fase es la localización de las fuentes de datos y la familiarización con el sig-
' MODELO MATEMÁTICO PARAMÉTR/CO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO/
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 29
nificado de los datos que se van a utilizar durante el proyecto. Asimismo, hay que comprobar
la calidad de los datos y los problemas que podría generar durante el desarrollo del proyecto.
ü Preparación de los datos
La fase de preparación de los datos consiste en la construcción del conjunto final de datos,
obteniendo datos derivados a partir de otros o eliminando aquellos datos que no resultan
útiles para el proyecto.
ü Modelado
La fase de modelado es la que corresponde con Data Mining. Durante la misma se aplican
diferentes técnicas y algoritmos sobre los datos con objeto de descubrir la información oculta
que hay en los mismos.
• Evaluación
En esta fase se evalúa la calidad de los modelos obtenidos y los resultados que se derivan de
los mismos, y si cumplen con los objetivos de negocio. Durante esta fase se debe tomar la de
cisión de si se continua a la fase siguiente {desarrollo) y si se utilizan los resultados obtenidos
en la fase anterior.
• Desarrollo
Implantación y documentación del conocimiento obtenido en las fases previas para que pue
da ser utilizado.
En la tabla 2.2 se muestran las tareas que propone CRISP-DM que hay que realizar en cada una de
las fases en las que se divide el proceso de KDD según el estándar CRISP-DM.
Comprensión del problema Determinar los objetivos de negocio Valoración de la situación
Determinar los objetivos de Data Mining Producción del plan de proyecto
Comprensión de los datos Recogida de los datos iniciales Descripción de los datos
Exploración de los datos
Verificar la calidad de los datos
Preparación de los datos Selección de los datos Limpieza de datos
Construcción de datos
Integración de datos Formatear los datos
Modelado
Selección de técnicas Generación de un diseño de prueba
Construcción del modelo
Evaluación de los modelos
Evaluación
Evaluación de los resultados Revisión del proceso
Decidir acciones siguientes
Desarrollo
Plan de despliegue
Plan de seguimiento y mantenimiento Creación del informe final
Revisión del proyecto
Tabla 2.2: Fases y tareas de CRISP-DM
CRISP-DM propone en la fase de compresión del problema tareas de estimación del coste del
proyecto. En concreto las tareas de determinar el plan del proyecto y valoración de la situación
tienen como salida el presupuesto y la valoración inicial de personal.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOr
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 30
u G Máximo -
u u
En la tarea de Valoración del proyecto una de sus salidas es presupuesto del proyecto donde se in
dica que hay que estimar el coste del conjunto de datos, el coste del desarrollo e implementación
de la solución, los costes de operación, así como identificar los beneficios producidos por una de
terminada solución, y todo ellos necesita ser estimado. En cuanto a la tarea de Determinar el plan
de proyecto, la estimación se encuentra involucrada en la salida plan de proyecto, donde se pro
pone estimar el esfuerzo y los recursos necesarios para lograr el desarrollo de una solución, para
poder planificcir los recursos y las tareas del proyecto. Sin embargo, no se establece como se ha de
realizar esta estimación. De forma experimental en [CMS"*" 97] se postula que el esfuerzo necesario
para realizar cada una de las fases de un proyecto de KDD es la que muestra en la figura 2.6.
80% 70% 60%
g 50% I 40% iS 30%
20% 10%
0% Establecer Preparación Data Mining Análisis de
objetivo de los datos resultados
Fases de KDD
Figura 2.6: Esfuerzo de las fases de KDD
A continuación se van a analizar las técnicas más usuales de estimación de proyectos software y se
analizarán las propuestas que se han realizado para la estimación de coste en proyectos de Data
Mining.
2.5. Estimación de proyectos software
Desde que en los años 70 comenzara a tomarse en consideración la crisis del software, multitud
de organismos de todo el mundo han trabajado para que la construcción de software sea conside
rada una ingeniería, intentando conseguir que se construya software de calidad. Desde entonces,
se han propuesto múltiples estándares de modelos de proceso que tratan de describir de la forma
más precisa posible cómo abordar la construcción de un producto software [Moo98].
Los modelos de proceso más representativos en cuanto a procesos de desarrollo software son el
estándar ISO 12207 (ISO,1995) (Information technology -Software Ufe cycle processes) y el estándar
IEEE 1074 (IEEE, 1991) (Software life-cycle processes). Estos estándares agrupan las actividades
•MODELO MATEMÁTICO PAPAMÉTIIICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 31
que se pueden realizar durante el ciclo de vida de un producto software en procesos. Los procesos
se dividen en actividades que a su vez se dividen en tareas.
En ambos estándares se contemplan procesos de gestión de proyectos dentro de los cuales se pro
pone una actividad de "estimación" del esfuerzo y tiempo que llevará el desarrollo del proyecto.
De forma análoga, en el modelo de proceso para el desarrollo de proyectos de Data Mining, CRISP-
DM, se propone una tarea de estimación pero no se indica como realizarla. Los estándares IEEE
1074 e ISO 12207, tampoco describen como hay que llevar a cabo está tarea de estimación.
A diferencia con los proyectos de Data Mining, para los proyectos de desarrollo de softw^are si que
se han definido multitud de métodos de estimación, de los cuales los más utilizados son los méto
dos matemáticos paramétricos.
2.5.1. Métodos de estimación software
Desde los años sesenta hasta hoy en día se ha pubhcado un gran número de modelos de estimación
que han ido reflejando en sus fundamentos el progreso experimentado en los métodos de produc
ción de software y en el propio software. Algunos de estos modelos se ha dejado de utilizar porque
se han quedado obsoletos y otros han ido evolucionando en distintas versiones hasta llegar a ser
el fundamento de las eficaces herramientas de estimación existentes hoy en día. A lo largo de es
tos años se han propuesto clasificaciones de dichos modelos sobre la base de distintos criterios,
clasificaciones que también han sufrido una evolución según ha ido desarrollándose la disciplina
de estimación en ingeniería del software.
Una de las primeras clasificaciones de los modelos en metodologías se propuso en [BoeSl]. A través
de la misma, se pretendió ordenar el conjunto de modelos existentes hasta la fecha en que fue
propuesta. Estos métodos de estimación tenían fundamentos muy dispares por lo que el objeti
vo fundamental de la clasificación era diferenciar los distintos caminos o métodos que se habían
propuesto en la estimación del software. Esta clasificación propuso la existencia de siete métodos
de estimación que se describen brevemente a continuación.
Q Modelos algorítmicos
Este tipo de modelos agrupa los modelos que proporcionan uno o más algoritmos que per
miten realizar las estimaciones de costes de un producto software a partir de un conjunto de
variables denominadas "drivers" de coste. Hay cinco tipos diferentes de algoritmos que dan
lugar a cinco tipos de modelos. Los métodos lineales que utilizan ecuaciones lineales, los
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PFOYECmS DE DATA MINING (DMmMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 32
métodos multiplicativos que hacen uso ecuaciones multiplicativas, los métodos analíticos
que cuyo algoritmo está formado por una ecuación matemática de cualquier tipo, los méto
dos tabulares que se fundamentan en la utilización de un conjunto de tablas para determinar
el valor de los valores de entrada de las variables independientes, y los métodos compuestos
que incorporan una combinación de funciones lineales, multiplicativas, analíticas y tabu
lares.
Q Estimación basada en la experiencia de expertos
Este método implica la consulta a uno o más expertos para realizar las estimaciones. La con
sulta se realiza a través de la aplicación de algún método de extracción de conocimiento de
expertos {Método Delphi [Far70, Hel66], sistemas basados en reglas [Mad97] o Work Break-
down Structure (WBS) [BoeSl]).
a Analogía
Este método realiza las estimaciones comparando el proyecto actual con los datos reales de
otros proyectos de las mismas Cciracterísticas realizados con anterioridad.
a "Parkinson"
Este método se basa en el principio de que el coste será el máximo de los recursos disponibles.
Q "Pricetowin"
Este método se basa en el principio de que el coste debe ser aquel que de más ventajas a la
comercialización del producto.
Q Estimación de arriba abajo
Las estimaciones se realizan para el proyecto total y después se fraccionan para saber las
asociadas con cada parte del mismo.
Q Estimación de abajo a arriba
Se divide el proyecto en partes y se realizan estimaciones para cada una de ellas. Las estima
ciones para el proyecto total son la suma de las partes.
Con esta clasificación, cualquier modelo se incluiría dentro de uno de los tipos disponibles.
Otra clasificación es la propuesta en [CDS86] donde los métodos de estimación se dividen en cua
tro tipos que se describen brevemente a continuación.
D Modelos históricos o experimentales
Se refiere a aquellos modelos basados en un conjunto de ecuaciones propuestas por un ex
perto
'MODEW MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 33
ü Modelos estadísticos
Agrupa a los modelos que utilizan un análisis de regresión para establecer la relación entre el
esfuerzo y los "drivers" de coste. Se pueden diferenciar dos tipos en función de las ecuaciones
utilizadas. Si las ecuaciones utilizadas son lineales, los modelos son modelos estadísticos li
neales, pero si las ecuaciones son no lineales los modelos son estadísticos no lineales.
Q Modelos teóricos
Están basados en teorías sobre como los seres humanos se comunican entre si, sobre como
funciona la mente humana durante el proceso de programación o sobre las leyes matemáticas
que sigue el proceso de construcción de un producto software.
Q Modelos compuestos
Incorporar una combinación de ecuaciones analíticas, ajuste estadístico de los datos e ideas
de expertos.
Otra clasificación de los métodos de estimación de proyectos software aparece en [Jon98] donde se
proponen seis metodologías agrupadas en dos grandes conjuntos, métodos manuales, los cuales
no tienen herramientas que automaticen los cálculos, y métodos automáticos, que si las tienen.
Para cada uno de estos dos conjuntos se distinguen tres metodologías, Al nivel de proyecto, Al ni
vel de fases basada en proporciones y porcentajes y Al nivel de actividades o tareas utilizando Work
Breakdown Structure (WBS)].
En [CBS99] y en [BAB+00] se propone otra clasiñcación de los modelos de estimación en seis méto
dos (Modelos estáticos. Experiencia de expertos. Orientada al aprendizaje. Modelos dinámicos,
Modelos estadísticos y Modelos compuestos)
Todas las clasificaciones anteriores se han resumido en [GalOl, CMOl]. El resumen de las clasifica
ciones anteriores se describe a continuación.
a Metodología de Estimación basada en Modelos Operacionales (Operational Models, OM)
En este tipo de modelos se incluyen aquellos modelos muy desarrollados y experimentados
para los cuales se han construido herrcimientas software muy sofisticadas. Son modelos que
están siendo continuamente investigados y mejorados, están en continua evolución y son
empleados en la industria con unos resultados muy buenos. Incluirá tanto a modelos públi
cos como patentados sin importar cuales son sus fundamentos de funcionamiento.
ü Metodología de Estimación basada en Modelos Experimentales (Experimental Models, EM)
Los modelos de este tipo tienen tienen versiones que se están aún desarrollando y estudiando
pero no tienen aún la consistencia de un modelo operacional, o bien han dejado de estudiarse
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULOS ESTADO DE LA CUESTIÓN 34
por no haber proporcionado buenos resultados. Estos modelos tienen unas versiones básicas
de herramientas asociadas que pueden estar siendo aphcadas en la industria sobre criterios
de costes o sencillez de uso de la herramienta.
Dentro de esta clasificación se pueden subclasiñcar cada uno de ellos (ver figura 2.7) tomando
como criterio los fundamentos conceptuales de cada modelo, estableciéndose las siguientes cate
gorías.
a Modelos Matemáticos. Fundamentados en la utilización de ecuaciones matemáticas tanto
lineales como no lineales.
O Modelos basados en técnicas de Inteligencia Artificial. Su funcionamiento se basa en el uso
de técnicas de inteligencia artificial como Redes Neuronales o Sistemas Expertos [LCHB99,
DYNOOO].
• Modelos Comparativos. Se basan en la comparación con los resultados reales obtenidos en
proyectos ya terminados y son aplicados por expertos cuya experiencia en este caso es fun
damental. Son muy útiles cuando no se dispone de datos empíricos. Están basados en los
conocimientos adquiridos en la realización de proyectos anteriores en los que los expertos
hayan participado. El problema de estos modelos es que se fundamentan en una opinión y
aunque sea la de un experto es siempre un sistema subjetivo (años de experiencia no tienen
porque estar necesariamente relacionados con altos niveles de competencia [GMS99]). Los
resultados no se puede probar de forma científica y normalmente no hay forma de corregir
los si son erróneos.
• Modelos Dinámicos. Se fundamentan en el hecho de que los factores que afectan a los costes
y la duración de un proyecto software cambiarán a lo largo del tiempo de ejecución del mis
mo. Teniendo esto presente realizan estimaciones continuas para tener en cuenta esas varia
ciones [AHM91, Mad94].
Modelos de estimación
Modelos operacionales
Modelos experimentales
Modelos matemáticos
Modelos técnicas I. A.
Modelos Comparativos
Modelos Dinámicos
Figura 2.7: Clasificación de los métodos de estimación software
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN RWAPROrBCTOS DE DATA MINING (DMCOMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 35
2.5.2. Modelos matemáticos de estimación
Los modelos matemáticos paramétricos de estimación de costes fueron la primera metodología
de estimación de costes que se desarrollo [ISP99]. Basados en un conjunto de variables de entrada
significativas, o parámetros, fueron desarrollados con el objetivo de realizar estimaciones de los
costes de las nuevas adquisiciones a realizar por el ejército.
Rand Corporation construyó el primer modelo matemático paramétrico de estimación que de de
nominó Relaciones de Estimación de Costes {Cost Estimating Relationship, CER) [ISP99], para pre
decir el coste de producción de los aviones en función de ciertas variables. En Rand descubrieron
que se podían desarrollar relaciones significativas entre el coste de un avión de guerra y variables
o parámetros relacionados con propiedades del mismo, tales como la velocidad, el alcance y la al
titud, aunque en un principio las relaciones entre éstos y el coste final no fueran tan obvias.
Paralelamente al desarrollo de modelos de matemáticos de estimación surgieron herramientas
software que automatizaban el proceso de estimación. Las primeras herramientas de estimación
que implementaban modelos matemáticos paramétricos fueron: PRICE-H [PS98a], que se utiliza
ba para realizar estimaciones en el desarrollo y producción de elementos hardware, y PRICE-S
[PS98b] que servía para realizar estimaciones en el desarrollo de proyectos de software.
Desde la creación de los primeros modelos de estimación paramétricos se han desarrollado múlti
ples modelos, especialmente en el área de estimación de costes de proyectos software (ver sección
2.5.3), así como en otra áreas como puede ser para el desarrollo de hardware (PRICE-H [PS98a]),
para proyectos de lanzamientos espaciales en la NASA [Ham02a] o para el desarrollo de barcos
[Ham02b].
Todos estos modelos tienen en común su forma de funcionamiento. A partir de un conjunto de
variables de entrada o "drivers" de coste son capaces de estimar el valor de alguna o algunas vari
ables, como puede ser el tiempo o el esfuerzo que será necesario para desarrollar un determinado
proyecto, relacionadas mediante una ecuación matemática, ya sea lineal o no lineal.
2.5.2.1. Aspectos fundamentales en el funcionamiento de los modelos matemáticos
de estimación
El funcionamiento de los modelos matemáticos de estimación se fundamenta en la utilización
de ecuaciones matemáticas mediante las cuales se obtiene el valor de un conjimto de variables
dependientes de salida, como pueden ser, por ejemplo, el esfuerzo y el tiempo de desarrollo, en
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOr
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 36
función de los valores numéricos dados a otro conjunto de variables independientes de entrada,
tales como, el tamaño de la aplicación en líneas de código, la fiabilidad requerida de la misma o su
complejidad.
La mayor parte de estos modelos suelen operar mediante un proceso de dos pasos:
1. Realizar una primera aproximación o estimación en función del valor de un conjunto reduci
do de variables independientes cuyo peso en el resultado final de los cálculos se considera
mayor que el del resto y que normalmente no están relacionadas con el entorno específi
co de construcción de la aplicación. En muchos modelos se utiliza una única variable que
suele ser el tamaño de la aplicación, normalmente estimado en líneas de código fuente. Para
calcular las líneas de código de la aplicación se utiliza alguna versión de puntos de función
[NES97, Ass98, Gro99, Abr99], o mediante otros métodos como son los basados en interfaces
gráficas de usuario, componentes, módulos, ballpark, etc.
2. Precisar el resultado mediante la utilización de otro conjunto de variables que permite refinar
los cálculos, introduciendo en ellos las características propias de la aplicación y del entorno
de desarrollo. Generalmente los valores numéricos del conjunto de variables independientes
que permiten realizar los cálculos a los distintos modelos de estimación no suelen tener
un sistema de estimación preciso. Estos deben ser previamente calculados o seleccionados
por los encargados de realizar la planificación del proyecto, en función de las características
propias del mismo. De tal forma que dicho valor cuantitativo de entrada de cada variable
independiente o factor de ajuste tiene un origen cualitativo en función de una serie de carac
terísticas del proyecto que afectan a dicho factor y que harán escoger para el mismo un valor
real dentro de un rango de posibles valores.
La obtención de buenos resultados mediante la utilización de este tipo de modelos se fundamenta
básicamente en cuatro puntos:
1. Una correcta definición de las ecuaciones que van a ser utilizadas. Así, por ejemplo, las ecua
ciones no lineales han sustituido a las lineales en todos los modelos matemáticos paramétri-
cos más utilizados. Son ecuaciones más complejas y en consecuencia más difíciles de mane
jar, sin embargo los resultados que proporcionan han sido mejores.
2. Una continua revisión de las variables de entrada utilizadas. Esta revisión no sólo implica
añadir o eliminar variables para reflejar los cambios producidos en la tecnología o en los
métodos de producir software, sino también profundizar en el conocimiento de las elegidas.
Por ejemplo, en el modelo COCOMOII [BAB+00] se han eliminado algunos "drivers" de coste
que se utilizaban en el modelo COCOMO 81 [BoeBl], como la restricción en el tiempo de eje-
•MODELO MATEMÁTICO PARAMÉTRICODEESTIMACIÓN PARA PROYECTOS DE DATAMININGÍDMCOMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 37
cución (TIME), y se han introducido otros "drivers", por ejemplo, la documentación utilizada
durante el ciclo de vida del software (DOCU).
3. Un correcto calibrado, para el entorno de desarrollo en el que se va a aplicar, de los paráme
tros utilizados por el modelo. Para ello se han utilizado nuevos conjuntos de datos, revisados
y ampliados [CCB97, CCBS98, Shr97, Fis97].
4. Una correcta selección del rango para las variables de entrada que el modelo necesita para
realizar las estimaciones del proyecto que se está estudiando.
La mayoría de los modelos matemáticos planteados son para estimar el tiempo y el esftierzo que
llevará el desarrollo de un producto software. A continuación se describirán los modelos de esti
mación más utilizados en la actualidad para el desarrollo de productos software.
2.5.3. Modelos matemáticos de estimación software
Los modelos matemáticos de estimación de software, relacionan una serie de factores de entrada,
normalmente el tamaño del software a construir y las características del proyecto y del equipo de
desarrollo, con un serie de variables de salida, habitualmente el esftierzo requerido para la cons
trucción del software y el tiempo que llevará el desarrollo de ese software. Desde el principio de la
investigación en modelos matemáticos de estimación para proyectos de software se han desarro
llado una gran variedad de modelos, tanto públicos como propietarios. De los modelos púbUcos
se conocen sus factores de entrada, sus factores de salidas, las ecuaciones que los relacionan y la
forma de funcionamiento, mientras que de los modelos propietarios sólo se conocen los factores
de entrada, los factores de salida y de forma empírica se conocen la ecuaciones de estos modelos.
Modelos Públicos Aerospace [Jr.77] Aron [Aro69a] Bailey-Basili [BB81] COCOMO 81 [Boe81] COCOMOII [BCH+95] COPMO [TS84] Doty [HPRS77] ESD [Com75] Farr-Zargosky [FZ65]
Function Points [Alb79] GRC [TD74] Navair [Buc71] SDC-Nelson [Nel66] Sech-Square-Parr [ParSO] SLICE [Kus77] SPQR-x [Jon77] IBM-FSD-Walston-Felix [WF77] TRW-Wolverton [Wol74]
Modelos Propietarios Boeing [BCG77] Checkpoint [Jon97] Estimacs [Rub83] Price-S [PS98b] SEER-SEM-Jensen [Jen83] Select [Too98] SLIM [Put78] Softcost [Tau81] TECOLOTE [Fre74]
Tabla 2.3: Métodos matemáticos de estimación
A continuación se describirán los métodos matemáticos de estimación más importantes y más
utilizados en la actualidad. Como modelo público se comentará COCOMO II pues es el método
sobre el que más se investiga y se proponen más modiñcaciones para adaptarlo a otros entornos, y
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 38
como métodos propietarios se describirán SLIM y PRICE-S por ser los más utilizados actualmente
en las organizaciones [CMOl].
2.5.3.1. SLIM
La denominación SLIM [PM92] procede de "Software Llfecycle Management" (Gestión del Ciclo de
Vida del Software).
Este modelo se fundamenta en el análisis de L. Putnam [Put78] del ciclo de vida del software. Put-
nam establece, basándose en los trabajos de T. Norden [Nor63] y de J. Aron [Aro69b], que la dis
tribución del tamaño del equipo de desarrollo de un producto software frente al tiempo sigue una
distribución de Rayleigh.
Desde que el modelo fue patentado, las ecuaciones del mismo no han sido editadas para el dominio
público, aunque los algoritmos de funcionamiento del mismo pueden deducirse a partir de las
publicaciones que se han realizado del modelo [PF79, PM92, SPJROO], y son las que se muestran a
continuación.
• Tamaño
La ecuación deducida para el calculo del tamaño con SLIM es la que aparece en la ecuación
(2.1).
s = cxKÍ{t^)i (2.1)
donde s es el tcimaño en SLOC [SourceLines OfCode, líneas de código fuente), K es el esfuer
zo total necesario para completar el proyecto, seleccionado de una base de datos de proyec
tos anteriores, c es una constante del proyecto denominada Factor Tecnológico, que refleja el
efecto de numerosos "drivers" de costes como las restricciones de hardware, la complejidad
del programa, los niveles de experiencia del personal y el entorno de programación y tm es el
tiempo de desarrollo total del proyecto.
• Esfuerzo
La ecuación deducida para el calculo del esfuerzo mediante SLIM es la que aparece en la
ecuación (2.2).
e(í) = i f ( l -e"* ' ) (2.2)
donde e{t) es el esfuerzo que se ha consumido en hombres - mes (Man - Month, MM) para de
sarrollar el proyecto durante t meses, a es una constante del proyecto que determina la pen
diente de la curva, se obtiene también de proyectos anteriores, y se calcula como se muestra
en la ecuación (2.3).
A = ¿ - (2.3)
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROVECTOS DE DATA MINING (OMCOMOr
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 39
Para realizar las estimaciones SLIM clasifica inicialmente los datos de entrada que necesita para
realizar las estimaciones en dos tipos:
• Características del Proyecto
Representan el primer nivel de entrada o la información mínima necesaria para realizar esti
maciones sobre un nuevo proyecto. Las características son:
• Fases de las que se compondrá el proyecto en función de la metodología utilizada. Para
cada fase se debe seleccionar el perfil del tamaño del equipo de desarrollo más adecua
do, pudiéndose elegir, por ejemplo, entre una curva de Raileigh, una exponencial, etc.
También se seleccionará el tiempo de desarrollo que se prevé dedicar a las primeras fa
ses.
• Tamaño. El tamaño estimado se introduce indicando tres valores (bajo, valor más pro
bable y alto) en la unidad elegida.
• Tipo de Aplicación. Esta característica se refiere al tipo de producto a desarrollar. SLIM
soporta nueve subcategorías de aplicación. Microcódigo, Sistemas, Tiempo real, Avióni-
ca, Comando y Control, Telecomunicaciones, Científico, Procesos y Negocios.
• índice de Productividad (PI). Junto con la información de tamaño, el índice de produc
tividad es muy importante para los algoritmos de estimación del modelo. El índice de
productividad básico se determina mediante el calibrado con los datos históricos pro
pios de la organización o a partir de la base de conocimiento proporcionada por SLIM.
A continuación se ajusta el PI para el entorno de desarrollo de la organización a través
de la determinación de cuatro categorías: Herramientas y Métodos, Dificultades Técni
cas, Perfil del Equipo de Desarrollo y Tamaño del Software Reutilizado. Cada categoría
estará compuesta de diferentes aspectos, para cada uno de ellos habrá que asignar para
su aplicación en la organización un valor entre O, cuando no se aplique, hasta 10 cuando
su aplicación sea máxima.
Con esta información y el tipo de aplicación, SLIM ajusta el PI a partir de los datos de los
proyectos recogidos en la base de datos del modelo.
• Restricciones del Proyecto
Las restricciones permiten especificar los valores que el proyecto debe cumplir para: Tiempo
de desarrollo. Coste, Equipo de desarrollo y Calidad.
2.5.3.2. PRICE-S
La denominación PRICE - S [PS98b] procede de "Programming Review of Information Costingand
Evaluation - Software" (Revisión Programada del Coste y Evaluación de la Información - Software).
' MODELO MATEMÁ TICO PARAMÍTRICO DE ESTIMACIÓN PMtA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 40
El modelo PRICE - S consiste en tres submodelos:
• Submodelo de Adquisición (PRICE - S Adquisition)
Este submodelo predice el coste y el calendario del proyecto. Cubre todos los tipos de apli
caciones software, incluyendo los sistemas de gestión, comunicaciones, control, aviónica, y
sistemas espaciales. También tiene en cuenta los más modernos aspectos de la ingeniería del
software como son la reingeniería, la generación automática de código, el desarrollo en espi
ral, el desarrollo rápido, el prototipado rápido, el desarrollo orientado a objetos y la medición
de la productividad del software [KinOO]. Las principales entradas de este submodelo pueden
ser agrupadas en siete categorías que son:
• Tamaño del producto
• Carácter del producto. Tipo de aplicación que se va a realizar
• Reutilización. Los nuevos proyectos software puede que no requieran de un diseño to
talmente nuevo. Algunas de las subrutinas requeridas, algoritmos, procedimientos e ins
trucciones de control de periféricos pueden ser utilizadas de otros proyectos. La esti
mación de costes de software debe reflejar esta disponibilidad, y PRICE - S Adquisition
refleja esta cuestión de la reutilización para permitir al analista especificar la cantidad
de diseño y código nuevos que son requeridos.
• Productividad. La variable llamada Factor de Productividad en PRICE ha sido diseñada
para reflejar el peso de todos los factores que inciden en la productividad del equipo de
desarrollo.
• Restricciones del Hardware. Capacidad del procesador y velocidad y capacidad de la
memoria.
• Utilización del producto. Especificaciones del cliente y Requisitos de seguridad. El valor
llamado Plataforma en PRICE resume las operaciones requeridas en términos de especi
ficaciones y seguridad.
• Factores de Riesgo. La variable de entrada denominada Complejidad es utilizada para
proporcionar una descripción cuantitativa del impacto relativo de los factores compli
cados que no han sido directamente tratados por otras variables de PRICE. En general,
las complicaciones tienen un tiempo para ser resueltas. Por lo tanto, la variable Com
plejidad describe los efectos de los factores adicionales sobre el desarrollo que están
directamente relacionados con el programa o el tiempo.
Cada una de estas entradas puede ser calculada de forma sepeuada en componentes indivi
duales o para el software en conjunto.
•MODEUD MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOr
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 41
• Submodelo de Estimación del Tcimaño "PRICE SizingModel"
Este submodelo predice el tamaño del software que va a ser desarrollado. El tamaño puede
ser obtenido en SLOC (líneas de código) [Par92], Puntos de Función y/o Object Points (Puntos
Objeto) [BKK92]. La estimación realizada por este submodelo se utiliza como entrada del
submodelo PRICE
• Submodelo de Coste del Ciclo de Vida (PRICE Life Cycle CostModel)
Este submodelo se utiliza para calcular de forma rápida el coste de la fase de mantenimiento
del software. Se usa de forma conjunta con el submodelo PRICE - S Adquisition.
2.5.3.3. COCOMO H
La denominación COCOMO [BAB+00] procede de "COnstructive COst Model (Modelo de cons
trucción de costes), II indica que es la segunda versión del modelo COCOMO y aparece cuando
se publica para diferenciarla de la anterior, COCOMO 81, ya que aunque ambos tienen la denomi
nación COCOMO. Entre estas dos versiones existió una versión de COCOMO 81 denominada Aíia
COCOMO [BR89] que permitía realizar estimaciones para sistemas de tiempo real, la cual presenta
ba algunas diferencias sobre el modelo original pero sus fundamentos teóricos eran semejantes.
Las ecuaciones matemáticas no lineales en que se fundamenta COCOMO II son:
• Esfuerzo:
e = a X (s)''+=^'=iy' ><(flx¡\ (2.4)
donde e es el esfuerzo medido en hombre - mes {Man - Month, MM], s el tamaño en miles de
líneas de código fuente (SourceLines OfCode, SLOQ, a,byc son constantes, y Xj el valor del
factor de ajuste / n toma el valor 7 en el submodelo diseño preliminar y el valor 17 en post
arquitectura y yi es el factor de escala i.
• Tiempo de desarrollo: t = 3(e)0,33+o,2(í,-i,oi) ^ í^£^%\ (2.5)
donde t representa el tiempo en meses, e representa el esfuerzo medido en MM, b es una cons
tante y SCED es el multiplicador de esfuerzo tiempo necesario para el desarrollo, estimado
en porcentaje.
El modelo COCOMO II está compuesto por tres submodelos:
• Composición de aplicaciones
Este submodelo es usado para estimar el esfuerzo y el tiempo de desarrollo en proyectos
•MODELO MATEMÁTICO PARAMÉFRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOS
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 42
cuya ejecución se realiza en un entorno totalmente automatizado mediante ICASE "Integrat-
ed Computer Aided Software Engineering" (Ingeniería del Software Asistida por Ordenador en
un entorno Integrado) péira desarrollo rápido de aplicaciones. Estos productos aunque son
muy diversos, son lo suficientemente simples como para ser construidos rápidamente a par
tir de componentes interoperables. Componentes típicos son los constructores del Interfaz
Gráfico de Usuario {Graphical User Interface, GUI), gestores de bases de datos o de objetos, o
procesos de transacción, etc. así como componentes de dominios específicos como paquetes
de control médico o industrial.
• Post - Arquitectura
Este submodelo puede ser utilizado cuando se ha completado el diseño de alto nivel y se
dispone de información detallada sobre el modelo y, como su nombre sugiere, la arquitec
tura del software está bien definida y establecida. Este modelo es parecido en estructura y
formulación al modelo intermedio de COCOMO 81.
Utiliza un conjunto de cinco factores de escala a cada uno de los cuales se les asigna un valor
que será un número real correspondiente al rango en el que se sitúe el factor para el proyecto
que se está desarrollando. Hay seis rangos: Muy Bajo, Bajo, Nominal, Alto, Muy Alto y Extra
Alto.
Utiliza también diecisiete multiplicadores de esfuerzo o factores de ajuste, cada uno con un
rango de seis niveles. Dichos factores de ajuste se agrupan en cuatro categorías: Producto,
Personal, Proyecto y Plataforma.
• Diseño inicial
Este submodelo es utilizado en los primeros pasos del desarrollo de un proyecto software,
cuando se sabe muy poco sobre el tamaño del producto que está siendo desarrollado, las ca
racterísticas de las plataformas de destino de la aplicación, la naturaleza del personal que va
a estar involucrado en la ejecución del proyecto o las características específicas detalladas del
proceso en el que va a ser utilizado.
Utiliza un conjunto de cinco factores de escala, iguales en su fundamento conceptual a los
del submodelo post-arquitectura. Además este submodelo utiliza 7 multiplicadores de esfuer
zo a los que se les asigna un número real teniendo en cuenta el rango de seis niveles en que
se encuentre el multiplicador para el proyecto estudiado. El rango para cada uno de los mul
tiplicadores de esfuerzo para el submodelo diseño inicial en un proyecto específico se ob
tiene a partir de los rangos que tendrían los multiplicadores de esfuerzo del submodelo post-
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOy
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 43
arquitectura que compongan el multiplicador del submodelo Diseño Inicial estudiado.
Los factores de escala son los siguientes:
a Precedentes (PREC): Tiene en cuenta la experiencia de la organización en el desarrollo de ese
tipo de aplicaciones.
Q Flexibilidad en el desarrollo (FLEX): Tiene en cuenta la rigidez de los requisitos y de las res
tricciones.
O Arquitectura / Solución de riesgos (RESL): Tiene en cuenta las medidas tomadas para la elimi
nación de riesgos
Q Cohesión del equipo (TEAM): Refleja las diñcultades de cohesión y sincronización de los im
plicados en el proyecto, debido a su diversa procedencia y objetivos. Éstos son: usuarios,
clientes, desarrolladores, equipo de mantenimiento, etc.
Q Madurez de procesos (PMAT): Este factor tiene en cuenta el nivel de madurez de procesos
de la organización, para lo cual utiliza la escala de cinco niveles de CMM {CapabiUty Matu-
rityModel} [PGCB93, PWCC95] desarrollado por el SEI (Software Engineering Institute) de la
Universidad de Carnegie Mellon.
Los multiplicadores de esfuerzo para el caso de COCOMOII post-arquitectura son 17 y se dividen
en cuatro categorías:
a Producto
• Fiabilidad requerida del softv rare (RELY)
• Tamaño de la base de datos (DATA)
• Complejidad del producto (CPLX)
• Reutilización requerida (RUSE)
• Documentación desarrollada (DOCU)
a Plataforma
• Restricciones en el tiempo de ejecución (TIME)
• Restricciones en el almacén principal (STOR)
• Volatilidad de la plataforma (PVOL)
• Personal
• Aptitud de los analistas (ACAP)
•MODELO MATEMÁTICO PARAMÉTmCO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 44
• Aptitud de los programadores (PCAP)
• Experiencia en el desarrollo de aplicaciones similares (AEXP)
• Experiencia con la plataforma de desarrollo (PEXP)
• Experiencia con el lenguaje y la herramienta (LEXP)
• Continuidad del personal (PCON)
ü Proyecto
• Utilización de herramientas software (TOOL)
• Desarrollo en múltiples localizaciones (SITE)
• Tiempo necesario para el desarrollo (SCED)
En el caso de COCOMO11 diseño inicial los drivers de coste son los 7 que se enumeran a continua
ción:
O Fiabilidad y complejidad del producto (RCPX). Agrupa los drivers de post-arquitectura RELY,
DATA,CPLXyDATA.
ü Reutilización requerida (RUSE). Equivale al driver de coste de post-arquitectura RUSE.
• Dificultad de la plataforma (PDIF). Es equivalente a los drivers TIME, STOR y PVOL de CO
COMO II post-arquitectura.
Q Aptitud del personal (PERS). ACAP PCAP y PCON son los drivers equivalentes de post-arqui
tectura de COCOMO II.
a Experiencia del personal (PREX). Combina los driver APEX, PLEX y LTEX del modelo COCO
MO II post-arquitectura.
ü Facilidades (FCIL). Es la unión de los drivers de coste TOOL y SITE de COCOMO II post
arquitectura.
Q Tiempo necesario para el desarrollo (SCED). Equivale a SCED del modelo COCOMO II post
arquitectura.
Las descripciones de los factores de escala y de los drivers de coste que se proponen para COCOMO
II se pueden observar en la tabla 2.5 y los valores asociados a cada rango se pueden ver en la tabla
2.4.
Drivers XL VL L N H VH XH Factores de escala
PREC FLEX
6,20 5,07
4,96 4,05
3,72 3,04
2,48 2,03
1,24 1,01
0,00 0,00
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOt
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 45
Drivers RESL TEAM PMAT
XL VL 7,07 5,48 7,80
L 5,65 4,38 6,24
N 4,24
3,29 4,68
H 2,83
2,19 3,12
VH 1,41 1,10 1,56
XH 0,00
0,00 0,00
Multiplicadores de esfuerzo (Post-arquitectura) RELY
DATA
CPLX
RUSE
DOCU
TIME STRO
PVOL
ACAP PCAP
PCON
APEX
PLEX LTEX
TOOL
SITE SCED
Muí RCPX RUSE
PDIF
PERS PREX FCIL SCED
Ta
0,82
0,73
0,81
1,42 1,34
1,29
1,22
1,19 1,20
1,17
1,22 1,43
tiplícadores c 0,49
2,12
1,59 1,43
3la2.4:
0,60
1,62
1,33 1,30
1,43 Driver
0,92
0,90
0,87
0,95
0,91
0,87
1,19 1,15
1,12
1,10
1,09 1,09
1,09
1,09
1,14 eesñi 0,83 0,95
1,00 1,26
1,12 1,10
1,14 s d e c o
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00
1,00 1,00
1,00
1,00
1,00 1,00
1,00
1,00 1,00
erzo (I 1,00 1,00
1,00 1,00
1,00 1,00 1,00
ste de (
1,10
1,14
1,17 1,07
1,11
1,11 1,05
1,15
0,85 0,88
0,90
0,88
0,91 0,91
0,90
0,93 1,00
tiseño 1,33 1,07
1,00 0,83
0,87 0,87 1,00
COCOÍ
1,26 1,28
1,34
1,15
1,23
1,29 1,17
1,30
0,71 0,76
0,81
0,81
0,85 0,84
0,78
0,86 1,00
inicial^ 1,91
1,15
0,63
0,74 0,73 1,00
4 0 I I
1,74
1,24
1,63 1,46
0,80
2,72 1,24
0,50 0,62
0,62
Cost Drivers RELY
DATA
CPLX RUSE
DOCU
TIME
Muy bajo
Ligera inconveniencia
Bajo
Pérdidas bajas fácilmente recuperables
DB bytes / Pgm SLOC < 10
Nominal
Pérdidas moderadas fácilmente recuperables 10 < D/P < 100
Verta
Muciías necesidades del ciclo de vida no cubiertas
Ninguna
Algunas necesidades del ciclo de vida no cubiertas
En el programa
Correctamente dimensiona-da para el ciclo de vida
< 50 % uso del tiempo disponible
Alto
Pérdidas elevadas
100 < D/P < 1000
Muy alto
Riesgos para la vida humana
D/P > 1000
Extra alto
bla 2.6 En el proyecto
Excesiva
70 % uso
En la línea de producto
Muy excesiva
85 % uso
Múltiples líneas de producto
95 % uso
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 46
Cost Drivers STOR
PVOL
ACAP PCAP PCON APEX PLEX LTEX TOOL
SITE: Ubicación
SITE: Comunicaciones
SCED
PREC
FLEX
RESL
TEAM
PMAT
Muy bajo
Percentil 15 Percentil 15 48 % año < 2 meses < 2 meses < 2 meses Edición, codificación, debug
Internacional
Teléfono, correo postal
%75 del nominal Profundamente desconocido Riguroso
Poco (20 %)
Interacciones muy difícües
Nivel 1 Bajo CCM
Tabla 2.5
Bajo
Cambios importantes cada 12 meses; cambios menores cada mes Percentil 35 Percentil 35 24 % año 6 meses 6 meses 6 meses CASE, poca integración
Multiciudad y multicom-pañia Teléfono individual, fax
85%
En gran parte desconocido Relajación ocasional Alguna (40%)
Algunas interacciones difíciles Nivel 1 Alto CCM
Descripción d
Nominal
< 50 % uso del almacenamiento disponible Importantes: 6 meses; menores: 2 semanas
Percentil 55 Percentil 55 12 % año 1 año 1 año 1 año Herramientas básicas para el ciclo de vida, integración moderada
Multiciudad 0 multicom-pañia E-maü de banda estrecha
100%
Algo desconocido Alguna relajación A menudo (60 %) Interacciones básicamente cooperativas Nivel 2 CCM
e los drivers a
Alto
70% uso
Importantes: 2 meses; menores: 1 semana
Percentil 75 Percentil 75 6 % año 3 años 3 años 3 años Herramientas maduras para el ciclo de vida, integración moderada
Misma ciudad
E-mail de banda ancha
130%
Generalmente desconocido Conformidad general Generalmente (75%) En gran parte cooperativas
Nivel 3 CCM
e coste de CO(
Muy alto
85 % uso
Importantes: 2 semanas; menores: 1 día
Percentil 90 Percentil 90 3% año 6 años 6 años 6 años Herramientas maduras proactivas para el ciclo de vida, bien integradas con procesos y métodos Mismo edificio
Comimicación electrónica de banda ancha, video conferencia ocasional 160%
En gran parte conocido Alguna conformidad En su mayor parte (90 %) Altamente cooperativas
Nivel 4 CCM
:oMO II
Extra alto
95 % uso
Misma situación
Multimedia interactiva
Profundamente conocido Metas generales Totalmente (100%) Interacciones sin fisuras
Nivel 5 CCM
Operaciones de control
Operaciones com-putacionales
Operaciones dependientes del dispositivo
Operaciones de gestión de datos
Operaciones de gestión del in-terfaz de usuario
Muy bajo Líneas de código sencillas con pocas estructuras de anidamiento. Composición de módulos de simple vía llamada a procedimientos o scripts simples
Evaluación de expresiones simples A=B+C*(D+E)
Lectura simple, sentencias de escritura con formatos sencillos
Arrays sencillos en memoria principal. Actuaciones y consultas COTS-DB sencillas
Generadores de informes y formularios de entrada sencillos
• MODELO MATEMÁTICO PARAMÉmiCO DE ESTIMAUÚN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 47
Operaciones control
de Operaciones com-putacionales
Operaciones dependientes del dispositivo
Operaciones de gestión de datos
Operaciones de gestión del in-terfaz de usuario
Bajo Utilización sencilla de estructuras de programación anidadas. Principalmente predicados simples
Evaluación de expresiones de nivel moderado D=SQRT(B*'2-4*A*Q
No se necesita conocimientos de ningún procesador en particular, ni dispositivo deI/0
Estructura de ficheros sencilla, sin cambios en la estructura, sin ediciones ni ficheros intermedios. Actuaciones y consultas COTS-DB moderadamente complejas
Utilización de constructores sencUlos de in-terfaz de usuario (GUI)
Nominal Mayormente anidamiento sencillo. Algún control in-termódulos. Tablas de decisión. Vuelta atrás sencillas o paso de mensajes, incluyendo soporte middleware para proceso distribuido
Uso de rutinas matemáticas y estadísticas estándar. Operaciones básicas de vectores y matrices
El procesamiento I/O incluye selección de dispositivo, tes-teo de estado y procesamiento de errores
de Múltiples ficheros entrada y un único fichero de salida. Cambios estructurales sencillos, ediciones simples. Actualizaciones y consultas COTS-DB complejas
Alto Amplia utilización de operadores de estructuras anidadas con predicados compuestos. Control de pila y cola. Procesamiento distribuido homogéneo. Control de tiempo real sencillo sobre un procesador
Análisis numérico básico, interpolación multiva-riada, ecuaciones diferenciales ordinarias. Operaciones de truncado y redondeo
Operaciones a nivel físico de I/O (traducciones de direcciones físicas de almacenamiento, búsquedas, lecturas, etc.). Optimización de losoverlapdel/O
Disparo de eventos sencillo activados por los contenidos de las corrientes de datos. Reestructuración de datos compleja
Muy alto Codificación reentrante y recursiva. Manejo de interrupciones por prioridades fijas. Sincronización de tareas, vuelta atrás complejas, procesamiento distribuido homogéneo. Control de tiempo real complejo sobre un procesador
Complejo análisis numérico estructurado: ecuaciones diferenciales parciales, resolución de ecuaciones matriciales. Para-lelización sencilla
Rutinas para la diagnosis de interrupciones, servicios de enmascaramiento. Manejo de líneas de comunicaciones. Rendimiento intensivo de sistemas empotrados
Coordinación distribuida de la base de datos. Desencadenamientos complejos. Búsqueda de la optimización
Gráficos dinámicos 2D/3D moderadamente complejos, multimedia
Extra alto
Múltiples fuentes de programación con cambios dinámicos de prioridad. Control a nivel de microcódigo. Control distribuido complejo de tiempo real
Análisis numérico difícil y sin estructurar: análisis de ruido altamente preciso, datos estocásticos. Paralelización compleja
Codificación por dispositivos dependientes del tiempo, operaciones micro-programadas. Rendimiento crítico de sistemas empotrados
Objetos y estructuras dinámicas altamente acopladas. Gestión de datos en lenguaje natural
Multimedia compleja y realidad virtual
Tabla 2.6: Descripción del driver de coste "Complejidad" (CPLX)
' MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO/
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 48
2.6. Modelos de estimación en proyectos de Data Mining
No se ha descrito en la literatura ningún método de estimación del coste de un proyecto completo
de Data Mining. No obstante si existen propuestas para estimar diferentes tipos de problemas de
Data Mining que se explican a continuación.
2.6.1. Taxonomía de costes de problemas predictivos
En [TurOO] se presenta una taxonomía de los diferentes tipos de costes que pueden surgir durante
el desarrollo de un proceso de aprendizaje inductivo. De acuerdo a los autores esta taxonomía
ayudaría a poder estimar y valoreír los resultados de un proceso de índole predictiva. Los costes
identificados en ese trabajo son los que se analizan a continuación.
a Costes por errores en la clasificación
Este tipo de coste en los procesos de "aprendizaje inductivo" surge debido a que los modelos
que se crean no son exactos, es decir, no clasifican adecuadamente todos los casos de entra
da que se le presentan, dicho de otra forma, puede que un elemento pertenezca a la clase
í y el modelo creado lo clasifique en la clase j siendo esto un error en la clasificación. Los
costes para este tipo de errores pueden ser constantes, es decir, todos los errores tienen el
mismo coste, o bien el coste puede ser variable en función del tipo de error cometido en la
clasificación.
Q Costes de las pruebas
Cada prueba realizada para obtener casos de prueba conlleva un coste asociado. Únicamente
se debe pagar una prueba si el coste de una mala clasificación es mucho mayor que el coste
de las pruebas. Este tipo de coste puede ser constante si el coste de cada prueba tiene el mis
mo valor, y puede ser variable en función de las condiciones que influyen en la prueba, por
ejemplo, la duración de la prueba, si la prueba tiene efectos colaterales, si se puede realizar
un conjunto de pruebas simultáneamente sin aumentar el coste, etc.
• Costes del instructor
Disponer de un instructor para entrenar al clasificador supone un coste adicional. El instruc
tor está disponible para el aprendiz, pero cada petición que realiza de clasificación que rea
liza el aprendiz al instructor lleva un coste asociado. Este coste puede ser constante si todas
las peticiones tienen el mismo coste, y variable si cada pregunta al instructor tiene un coste
diferente, por ejemplo, en función de la complejidad de la petición.
Q Costes de intervención
Estos costes van asociados con el coste de manipulación o modificación del valor de alguna
• MODELO MATEMÁTiCOPARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO/
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 49
de las variables o factores que participan en la clasificación. El coste representa el esfuerzo
requerido para modificar el valor del factor durante el proceso de recogida de la informa
ción. Estos coste pueden ser constantes, si todas las modificaciones son igual de costosas y
variables, si cada modificación implica un coste diferente.
• Costes de objetivos conseguidos y no deseados
Asociado con el tipo de coste anterior (coste por intervención) se encuentra el tipo de coste
por objetivos conseguido y no deseados. Estos objetivos conseguidos y no deseados se deben
a la modificación de alguno de los valores de los factores de la clasificación, con lo que se
obtienen errores en la clasificación con el coste asociado.
Q Costes de computación
Los recursos de computación son limitados por lo que hay que tener en consideración el
coste de este tipo de recursos. Los costes de computación se pueden dividir en función de la
complejidad en estáticos y en dinámicos y también se pueden dividir en función de si tienen
relación con la fase de entrenamiento o de prueba.
• Costes de Interacción Hombre - Máquina (HCI)
Tiene que ver con los costes del personal que utiliza el software de aprendizaje inductivo.
Este coste incluye el coste de encontrar los atributos a utilizar, los parámetros para optimizar
los resultados de los algoritmos, la conversión de los datos al formato adecuado requeri
do por el algoritmo, el análisis de los modelos construidos y la incorporación al modelo de
conocimiento sobre el dominio en el cual se analiza el problema.
Si bien este trabajo presenta la relación de costes asociados a los procesos de aprendizaje no se
presentan métodos para estimar estos costes. A continuación se presentan modelos de estimación
de costes en los procesos de aprendizaje en los que se propone una función de coste que se intenta
minimizar durante la construcción del modelo de aprendizaje propuesto.
2.6.2. Estimación en proyectos de marketing
En [KPR99] se propone un entorno y una manera de evaluar el valor del conocimiento obtenido
después de la fase de Data Mining en los proyectos de CRM. En este trabajo se propone un marco
de estimación desde el punto de vista microeconómico. Así, un patrón en los datos solo es intere
sante si es utilizable en el proceso de toma de decisión de la empresa, es decir, un patrón solo es
útil si se puede transformar en información, esta en acción y la acción en valor. Así pues, en este
trabajo se transforma el problema de estimación en un problema de optimización que se puede
formular como
máx/(a;) (2.6)
XED
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROVECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 50
donde D es el dominio de todas las posibles decisiones (planes de producción, estrategias de mar-
keting, etc.) y f{x) es la utilidad o valor de la decisión x e D.El objetivo de este trabajo es realizar
un estudio de Data Mining desde el punto de vista económico de los problemas de optimización
cuando se trabaja con un gran volumen de datos no agregados. El marco y los modelos desarro
llados en este trabajo hacen uso de optimización combinatoria, programación lineal y teoría de
juegos. El objetivo final es proponer la utilidad de las operaciones de Data Mining de forma cuan
titativa.
En esta misma línea de estimación de proyectos de marketing se encuentra el trabajo presentado
en [MPS96] donde se propone que hay que tener en cuenta el valor de los clientes para determinar
el beneficio de los modelos predictivos de Data Mining. En este trabajo se propone un modelo de
estimación basado en el modelo de negocio que se muestra a continuación:
P = {rxp)-c (2.7)
donde P es el beneficio obtenido de un cliente, c el coste de captar al cliente, r los ingresos que
se obtienen del cliente por parte de la organización y p la probabilidad de que el cliente responda
positivamente a una oferta.
Este modelo se utiliza para evaluar diferentes modelos predictivos peira tratar de obtener el modelo
que deje un mayor beneficio P a la organización.
2.6.3. Aplicación de NPV para la estimación del coste de aplicaciones "Machine Learning"
El NetPresent Valúes (NPV) [BM96] de una investigación se define como la suma del flujo de caja
{cashflow) generado menos el retorno de la inversión {Retum On Investment, ROÍ). Matemática
mente el NPV se define como aparece en la ecuación (2.8).
^ ( 1 + r)*
donde Co es el flujo inicial de caja, normalmente negativo, y representa la inversión inicial.
En [Dom98] se aplica este modelo a proyectos de "Machine Learning", en concreto a modelos de
clasificación. En este caso, la ecuación 2.8 se interpreta de la siguiente manera: NPV representa el
coste del desarrollo del sistema, incluyendo coste de hardware, de software, de formación del per
sonal, etc, t es el periodo de tiempo, Ct es el flujo de caja durante el periodo í, y r es el retorno de
inversión esperado. El flujo de caja en un momento de tiempo í > 1 es el resultado de las decisiones
tomadas por el sistema, y tiene dos componentes, el coste de tomar una decisión y el flujo de caja
•MODELO MATEMÁTICO PABAMÍTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOJ
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 51
resultante de la decisión tomada. El coste de tomar una decisión incluye el coste de mantener el
sistema ejecutando, el coste de la recopilación de la información necesaria para tomar la decisión,
el entrenamiento continuo del sistema si es necesario, etc., y el flujo de caja resultante de la de
cisión depende del efecto que produzca la decisión tomada sobre el dominio para el cual se toma
la decisión. Para el calculo del flujo de caja se utilizan dos matrices de dos dimensiones, la matriz
de flujo de caja iQ), donde Q{i,j) representa el flujo de caja resultante de clasificar el elemento i
como perteneciente a la clase j , y la matriz de confusión {P), donde P{i,j) es la probabilidad de
que el elemento i se clasifique como perteneciente a la clase j . Así el flujo de caja C asociado con
una decisión se define como: m m
^ = ' + EE^(^'^M^'^) (2.9) ¿ = 1 3 = 1
donde D < O es el flujo de caja de tomar una decisión. Si se desarrolla el sistema desde cero, no hay
ni siquiera un procedimiento manual o de expertos para realizar la clasificación, la ecuación (2.8)
se puede reescribir como: nC
NPV = Co + (2.10) r
siendo n el número medio de decisiones que se tomarán durante el periodo t. Como normalmente
este tipo de sistemas no se desarrolla partiendo de cero (hay algún procedimiento que lo realiza
actualmente) el NPV se puede calcular como:
NPV^NPVM-MPVL=ICO + ' ^ \ - ' ^ (2.11)
siendo los términos de subíndice M los valores asociados con el sistema de "Machine Learning" y
los de subíndice L los términos de la solución actual.
Es importante resaltar que este método tiene en cuenta factores tales como la experiencia del per
sonal participante en el proyecto, si se utilizan herramientas para la construcción del modelo, etc.,
para realizar la estimación como hacen los modelos de estimación para el desarrollo de proyectos
de software. Sin embargo con este método de estimación solo se puede tomar la decisión de si se
continua con el proyecto {NPV > 0) o no se continua con el proyecto {NPV < 0) en un determi
nado momento de tiempo, pero no se puede utilizeir para estimar el esfuerzo del proyecto.
2.7. Resumen contextual
Se ha analizado en este capítulo el proceso de descubrimiento de conocimiento en detalle por ser
la base que sustenta los proyectos de CRM en las empresas. Asimismo, en este capítulo se han
analizado los diferentes métodos de estimación paramétricos de estimación de proyectos de desa
rrollo de software. Es obvio que estos métodos de estimación no pueden ser utilizados para estimar
•MODELO MATEMÁTICO PABAMÍTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 2. ESTADO DE LA CUESTIÓN 52
proyectos de Data Mining dadas las características especiales que caracterizan a los mismos. Sin
embargo, son pocas la referencias que existen en la literatura para la estimación de este tipo de
proyectos. Tal y como se acaba de ver, los trabajos de estimación de costes en Data Mining han
están más orientados hasta el momento en cuestiones relativas al coste que para la empresa tiene
que el conocimiento obtenido no sea de la calidad requerida que en el esfuerzo que conlleva el
desarrollo del mismo.
Consecuentemente, después de más de veinte años de realizar proyectos Data Mining, no existe a
día de hoy un método genérico para estimar el esfuerzo necesario para su desarrollo.
• MODELO MATEMA TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOt
Parte II
ESTUDIO Y RESOLUCIÓN DEL PROBLEMA
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
Capítulo 3
Planteamiento del problema
índice General
3.1. Planteamiento 54 3.2. Objetivos del trabajo 59
3.1. Planteamiento
En el año 1999 un informe de GartnerGroup [DiLOO] predecía un gran crecimiento en el campo de
Data Mining, más de un 300 % para mejorar las relaciones con los clientes. Informes más recientes
[CTGN02] aseguran que: "Después de la caída de más de 2.000 millones de dólares en el año 2002,
el mercado de CRM crecerá más del 11% anual, alcanzando los 73.800 millones de dólares en el año
2007".
CRM se puede definir como: "darle al cliente lo que este quiere, cuando, como y donde lo quiere"
[DycOl]. La idea que subyace detrás de los proyectos de CRM es la de recuperar la relación 1 a 1
(one-to-one) que se ha perdido como consecuencia del entorno competitivo en el que se mueven
las organizaciones. Esto explica la cita que se acaba de exponer [CTGN02], dado que las empre
sas desde hace aproximadamente diez años se han visto obligadas a desarrollar sistemas de CRM
para fidelizar y mantener a sus clientes. En los sistemas de CRM se pueden distinguir tres áreas:
CRM Operacional, CRM Coloborativo y CRM T^alítico, siendo este último el encargado de analizar
los datos operacionales para poder optimizar la relación mantenida con el cliente. Debido al gran
•MODELO MATEMÁTICO PABAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MININO (DMCOMO)'
CAPÍTULOS. PLANTEAMIENTO DEL PROBLEMA 55
volumen de datos que se han de analizar, la única manera de poder extraer conocimiento de los
mismos es mediante la aplicación de técnicas de Data Mining.
De alguna manera, se puede afirmar que el gran impulso que la investigación en Data Mining ha
tenido en los últimos años ha sido motivada por la necesidad de las empresas de analizar sus datos
en búsqueda de conocimiento que les permitiera mantenerse en el entorno competitivo en el que
se están moviendo. La consecuencia directa de este hecho, es que las organizaciones de todo tipo
están dedicando cada día más recursos para la elaboración de proyectos de Data Mining,
Según datos recogidos [KdN02] (ver figura 3.1) el 83% de las empresas consultadas aseguraron el
crecimiento del sector de Data Mining y sólo un 15 % de empresas consultadas (334) consideraron
que la industria de Data Mining permanecería o tendría un ligero ascenso.
Crecimiento esperado en la industria de Data Mining en el 2001
Descenso significativo 4%
Ligero descenso / /—Ns/nc2% 4%
Permanencia 5%
Crecimiento c r e c i m i e n t o ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ significativo 53% 32%
Figura 3.1: Crecimiento de Data Mining
Los datos de la encuesta anterior se reafirman con datos de otra encuesta conducida en año 2002
[KdN02] cuyos resultados se muestran en la figura 3.2, en la cual más del 60% de empresas (179
empresas consultadas) aseguraron que el trabajo dedicado a proyectos de Data Mining en cada
empresa era superior al 20 % del trabajo total.
Todos estos datos permiten establecer que los desarrollos de CRM seguirán teniendo un gran auge
en la década actual.
Sin embargo, no todos los datos son tan alentadores. Si bien es verdad que se han desarrolla
do muchos proyectos de CRM, también se ha demostrado que ni todos ellos están en utilización
[EKT03a, EKT+03b] y que muchos de ellos no se llegan a concluir por una falta de estimación de
los costes al comienzo de los mismos [EE97, StrOO].
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PAJIA PROVECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 3. PLANTEAMIENTO DEL PROBLEMA 56
Porcentaje del trabajo dedicado a proyectos de Data Mining (2002)
Figura 3.2: Porcentaje de trabajo en Data Mining
La necesidad de métodos eficientes de búsqueda de conocimiento en grandes volúmenes de datos
provocó un gran auge en la investigación en Data Mining consecuencia de lo cual se desarrolla
ron numerosos algoritmos y herramientas de Data Mining. En un primer momento todo el énfa
sis estuvo centrado en la obtención de algoritmos eficientes para poder dotar a las empresas de
herramientas con las que poder obtener el conocimiento que necesitaban. Sin embargo, no se
pensó que, dada la complejidad de los procesos de Data Mining, para el éxito de los mismos no sólo
se necesitaban técnicas eficientes sino metodologías que ayudaran a su realización sistemática.
Esto explica la tardía aparición del primer estándar de modelo de proceso para proyectos de Data
Mining (CRISP-DM) [NSN+00].
La aparición de CRISP-DM como modelo de proceso supuso un gran avance, dado que por primera
vez se disponía de una metodología para poder realizar proyectos de Data Mining y suponía una
estandarización en cuanto a salidas de cada fase y nomenclatura utilizada. Esto hizo que este
estándar fuera seguido por gran número de empresas según se pone de manifiesto en la figura
3.3.
Tal y como se ha visto en la sección 2.4 el estándar propone las fases a seguir en un proyecto de
Data Mining y establece las entradas y salidas de las mismas. Es importante resaltar en este punto,
que si bien en el estándar se propone el establecimiento de un presupuesto y de una valoración de
los costes en tiempo y en personal del proyecto, en ningún momento aparece referencia alguna a
como realizar esta estimación.
•MODEIJO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 3. PLANTEAMIENTO DEL PROBLEMA 57
Metodología de Data Mining utilizada (Agosto 2002)
Figura 3.3: Utilización de metodologías de Data Mining [KdN02]
La estimación de proyectos ha sido desde siempre un aspecto clave a resaltar por parte de los direc
tivos de las empresas. En concreto, para estimar el coste de un proyecto de desarrollo de software
se han propuesto distintos modelos de estimación, siendo los modelos matemáticos paramétricos
de estimación de costes de los primeros que se desarrollaron [ISP99].
No obstante, los modelos de estimación que se utilizan en proyectos de construcción de software,
tales como COCOMOII [BAB+00], SLIM [SPJROO], PRICE-S [PS98b], SEER-SEM [Ass96] no resultan
útiles para proyectos de Data Mining, puesto que todos ellos utilizan como principal entrada el
tamaño del software a construir.
La salida principal de un proyecto de Data Mining no son líneas de código sino conocimiento
expresado como una serie de patrones de distinto tipo. Para poder valorar el éxito o fracaso de
un proyecto de Data Mining se tendría que disponer de un método que ñiera capaz de estimar
la bondad del conocimiento obtenido, el tiempo empleado en descubrirlo, los costes asociados a
personal y recursos empleados entre otros.
Pero no es sólo necesario estimar de manera objetiva la bondad del conocimiento obtenido sino
que es necesario estimar el coste que para la organización supone la obtención de dicho conoci
miento. De nada servirá el poder asegurar que los patrones obtenidos serán valiosos si los costes
para la obtención de los mismos se escapan de los presupuestos de la organización.
Con respecto a la primera parte se han desarrollado propuestas tal y como se ha visto en la sec
ción 2.6 que permiten valorar el conocimiento obtenido. De esta manera en [KPR99] se propone
un entorno y una manera de evaluar el valor del conocimiento obtenido después de la fase de Da-
• MODELO MATEMÁTICO PARAMÉTIIICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING IDMCOMO)'
CAPÍTULOS. PLANTEAMIENTO DEL PROBLEMA 58
ta Mining en los proyectos de CRM, intentando maximizar el valor del mismo. Por otro lado, en
[MPS96] se propone tomar en cuenta el valor de los clientes para determinar el beneficio de los
modelos predictivos de Data Mining.
En cuanto a la estimación del coste del proyecto de Data Mining, en [Dom98] se propone un mode
lo de estimación del coste de un proyecto de Data Mining en un momento determinado del tiempo
haciendo uso de NPV {NetPresent Valué) que es la diferencia entre el dinero invertido en proyecto
y el dinero recuperado de esa inversión. En este trabajo se hace uso de esta estimación del NPV
presente en un momento durante el ciclo de desarrollo del proyecto de Data Mining para tomar
la decisión de si se continua o no con el proyecto. Sólo se continuará con el proyecto si el valor de
NPV es positivo en el momento calculado.
Por su parte en [TurOO] se propone una clasificación de los coste presentes en un proyecto de Data
Mining pero no se proporcionan métodos para estimarlos.
Todos estos métodos propuestos tal y como se ha visto en la sección 2.6 no permitan establecer
al principio del proyecto el esfuerzo que requiere. Las únicas herramientas disponibles por el mo
mento para estimar proyectos de Data Mining son los métodos de estimación de proyectos soft
ware.
Los métodos de estimación de proyectos software tienen en cuenta factores como experiencia del
equipo de desarrollo, disponibilidad de herramientas, plataforma de desarrollo entre otros. Estos
factores se tienen que tener en cuenta también para estimar un proyecto de Data Mining. No obs
tante, dadas las características de los proyectos de Data Mining, para poder estimar los costes de
realización será necesario también tener en cuenta factores como el origen de los datos objetivo,
nivel de integración de los mismos, tipo de problema de Data Mining que se tiene que resolver
y número de modelos que se tienen que construir. Ninguno de estos factores está presente en un
proyecto de desarrollo de software clásico.
Por este motivo los métodos de estimación de software no resultan válidos para proyectos de Data
Mining.
Como consecuencia, se puede afirmar que a día de hoy no se dispone de un método genérico para
estimar los proyectos de Data Mining, aunque se llevan desarrollando proyectos de Data Mining
desde hace más de veinte años. Consecuentemente se plantea en este trabajo de tesis doctoral un
modelo matemático paramétrico de estimación del esfuerzo necesario para el desarrollo de para
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMAUÓN PARA PROYECTOS DE DATA MINING (DMCOMOX
CAPÍTULOS. PLANTEAMIENTO DEL PROBLEMA 59
proyectos de Data Mining. El modelo se denominará DMCOMO {Data Mining COstMOdel] y es
tará basado en los modelos matemáticos de estimación paramétricos existentes para la estimación
de proyectos.
El objetivo del modelo que se quiere construir es estimar el esfuerzo expresado en hombres x mes
(MM) que requiere el desarrollo de un proyecto de Data Mining desde su concepción (Compren
sión del problema) hasta la obtención del conocimiento. Quedarán fiiera de la estimación las ta
reas que se deriven de la implantación de los datos, tales como la construcción de herramientas de
predicción basadas en el conocimiento obtenido, personalización del modelo en entornos simila
res, etc. Se considera que esta fase está fuera del ciclo de un proyecto de Data Mining y por lo tanto
fuera del ámbito de aplicación de esta tesis.
El modelo de estimación que se planteará toma como base las ideas de los modelos de estimación
paramétricos. Por lo tanto, para la definición del modelo se tendrá en primer lugcir que establecer
los factores que influyen en los costes del proyecto y que constituirán los factores de entrada o va
riables independientes. Una vez establecidos se tendrán que establecer los rangos, las descripcio
nes y valores que pueden tomar cada uno de los niveles de estos factores. Asimismo, se tendrá que
establecer los factores de salida (esfuerzo). Con todo ello se estará en disposición de plantear la
ecuación que relacionará los factores de entrada y los de salida.
Para finalizar se validará la ecuación obtenida con proyectos que no se utilizarán para la construc
ción del modelo y se compararán los resultados obtenidos con los resultados reales.
3.2. Objetivos del trabajo
El principal objetivo de este trabajo de tesis doctoral es el planteamiento de método matemático
paramétrico de estimación para proyectos de Data Mining, que se denominará DMCOMO (Data
Mining COst MOdel). Este objetivo principal se puede desglosar en los siguientes objetivos par
ciales:
a Realizar un análisis de comportamiento para determinar que factores influyen en el esfuerzo
de los proyectos de Data Mining. Esto permitirá plemtear los drivers de coste para proyectos
de Data Mining.
Q Recogida de datos de proyectos reales de Data Mining. Se analizarán proyectos reales y se
establecerá el valor real de los drivers planteados.
a Plantear un modelo inicial basado en regresión lineal. Una vez se tiene el valor del esfuerzo
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULOS. PLANTEAMIENTO DEL PROBLEMA 60
en proyectos reales así como el valor de los drivers de coste de los mismos se tiene que aplicar
un modelo de predicción para obtener el modelo de estimación del esfuerzo. En este trabajo
se plantea hacer uso de una regresión lineal.
Q Validación de la ecuación. Una vez obtenida la ecuación del modelo mediante la regresión
lineal, habrá que validarla con proyectos que no se utilizaron para la obtención del modelo.
La consecución de los objetivos propuestos se traducirá por un lado en aportaciones teóricas como
es el planteamiento de un modelo de estimación para proyectos de Data Mining, y por otro lado en
aportaciones prácticas puesto que se dotará de una herramienta para poder estimar el esfuerzo de
los proyectos de Data Mining y además se proporciona la forma de utilización del modelo de es
timación propuesto. Como consecuencia de la aportaciones de este trabajo de tesis, se conocerán
qué factores influyen en el esfuerzo necesario para llevar a cabo un proyecto de Data Mining, con
lo que se proporciona una primera solución al problema de estimación en proyectos de Data Min
ing y se favorece el desarrollo de los mismos.
•MODEW MATEMÁTICO PARAMÉTEICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOt
Capítulo 4
Solución
índice General
4.1. Introducción 61 4.2. Descripción del entorno 62
4.2.1. Descripción de la empresa 62 4.2.2. Descripción de un proyecto de Data Mining normal 63
4.3. Drivers de coste propuestos para proyectos de Data Mining 64 4.3.1. Drivers de Datos 66 4.3.2. Drivers de Modelos 74 4.3.3. Drivers de Plataforma de desarrollo 81 4.3.4. Drivers de Técnicas y Herramientas 84 4.3.5. Drivers de Proyecto 90 4.3.6. Drivers de Personal 92
4.4. Planteamiento de la ecuación del modelo DMCOMO 96 4.4.1. Descripción de los datos de entrada 98 4.4.2. Obtención de la ecuación de regresión 100
4.5. Validación de ia ecuación del modelo DMCOMO 110 4.6. Resumen contextual 111
4.1. Introducción
En este capítulo se propone el modelo de estimación paramétrico para proyectos de Data Min
ing denominado DMCOMO {Data Mining COstMOdel). Puesto que es un modelo de estimación
paramétrico es necesario establecer los factores que influirán en el esfuerzo total del proyecto.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4. SOLUCIÓN 62
Para cada posible factor o driver de coste del modelo se van a establecer sus posibles valores tal y
como se hace en cualquier modelo de estimación paramétrico. De esta manera se establecerá para
cada factor la descripción del esfuerzo considerado "nominal", y a partir de ahí se establecerá lo
que se considera menor esfuerzo y mayor esfuerzo. Para ayudar a establecer los valores nominales
de cada factor se han analizado las características de diferentes empresas (alguna de las cuales han
aportado datos de sus proyectos para crear la ecuación) en las que se desarrollan proyectos de Data
Mining. Los resultados de este análisis se presenta a continuación.
4.2. Descripción del entorno
En este apartado se presentará la situación que se ha considerado para el establecimiento de las
descripciones "nominales" de los drivers de coste de DMCOMO (ver sección 4.3). Por un lado se
planteará la descripción de una empresa típica a la cual se le va a desarrollar un proyecto de Data
Mining y por otro lado se plantearán las características normales de un proyecto de Data Mining.
Para ello se utilizaron los valores obtenidos mediante la ejecución de un Método Delphi [Far70] de
2 rondas sobre un grupo de expertos en Data Mining (ver apéndice A, sección A.1).
4.2.1. Descripción de la empresa
Cuando se va a desarrollar un proyecto de Data Mining lo primero que hay que tener en conside
ración es el volumen de datos. Por ello, el dato fundamental que hay que analizar es el número y el
tipo de las bases de datos que se utilizarán.
Si bien la empresa se compone de varios departamentos, lo habitual es que el proyecto de Data
Mining se desarrolle sólo involucrando a uno de ellos.
En cuanto al tipo de base de datos, lo normal hoy en día es que el soporte de datos sea un sistema
gestor de base de datos relacional y que muchas empresas dispongan de Data Marts departamen
tales donde el tamaño normal es de 5 estrellas y alrededor de 15 dimensiones por estrella, por lo
que se tendrán unas 80 tablas de datos para el desarrollo del proyecto de Data Mining.
El número de tupias de las tablas de dimensión es aproximadamente de unas 10.000 tupias al año
y el número de tupias de las tablas de hecho rondará los 30.000.000 tupias al año. El número de
tupias se considera anual puesto que normalmente en los proyectos de Data Mining el periodo de
estudio de los datos suele ser anual.
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING IDMCOMO)'
CAPÍTULO 4. SOLUCIÓN 63
En cuanto al número de atributos de cada tabla, las tablas de hecho contiene alrededor de 20 o 25
atributos, entre 10 o 15 atributos que forman la clave y otros 10 que son los hechos propiamente
dichos, mientras que el número de atributos de las tablas de dimensión está en torno a los 25.
En los datos que manejan este tipo de empresas el volumen normal de información desconocida
oscila entre un 15 % y un 20 %. Asimismo, estas empresas tienen documentados la mayoría de los
modelos de datos que se utilizarán en el desarrollo del proyecto de Data Mining; los datos suelen
residir en varios lugares (orígenes o fuentes de datos); se suelen manejar entre 3 y 5 fuentes de
datos en este tipo de empresas.
Las características anteriores son las que se han tomado como referencia a la hora de establecer los
valores nominales en las descripciones de los drivers de coste del modelo DMCOMO.
4.2.2. Descripción de un proyecto de Data Mining normal
En cuanto a los proyectos de Data Mining, es conveniente analizar una serie de características muy
dispares como las características de los modelos que hay que generar, las características de las he
rramientas a utilizar para el desarrollo del proyecto o las características de los participantes en el
proyecto de Data Mining.
En todo proyecto de Data Mining la primera fase que se lleva a cabo es la fase de preproceso,
donde se integran y se limpian los datos que se van a utilizar en el proyecto (ver sección 2.2). En
esta fase se elimina gran cantidad de datos de los disponibles para el proyecto por inconsistencias
en los mismos o porque no van a resultar útiles para el proyecto, con lo que se eliminan tupias y
atributos, al menos en un orden de magnitud respecto a los datos disponibles. A su vez también
se generan nuevos atributos con información derivada del contenido de otros atributos, normal
mente se derivan entre 10 y 15 atributos.
En cuanto a las fuentes u orígenes de datos, suelen ser de diversos tipos, desde ficheros de texto
pasando por Sistemas Gestores de Bases de Datos (SGBD) hasta Data Warehouses. El soporte de al
macenamiento físico de las fuentes de datos, en caso de ser SGBD o Data Warehouse, suele ser de
diversos fabricantes o si son del mismo fabricante pueden ser diferentes versiones que no tienen
porque ser compatibles entre ellas. Además, las diferentes fuentes de datos no tienen porque en
contrarse todas en el mismo lugar, pueden estar en el mismo edificio, en la misma cuidad, en el
mismo país, etc. Lo normal es que los orígenes de datos se encuentren en fuentes heterogéneas (de
2 a 3 fuentes) de distintos fabricantes localizadas en el mismo edificio y comunicadas por una Red
de Área Local {Local Área Network, LAN).
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO}'
CAPÍTULO 4. SOLUCIÓN 64
En la fase de modelado o fase de Data Mining, lo normal es que haya que construir entre 5 y 7
modelos, documentados, pudiendo ser generados utilizando más de una técnica mediante el uso
de herramientas de Data Mining. Para el desarrollo de un proyecto de Data Mining, lo normal es
utilizcir varias herramientas que requieren un ligero conocimiento de las técnicas de Data Mining
y tienen un interfaz de usuario gráfico y amigable. Los modelos que se generan son, normalmente,
para el hecho, producto o departamento central de la organización.
En cuanto al personal participante en el proyecto de Data Mining se distinguen varios perfiles
diferenciados, uno la dirección de la organización y/o del departamento, los expertos en Data Min
ing y los expertos en los datos y/o negocio para el cual se desarroUcín los modelos. Lo normal para
el personal es que los miembros del equipo de Data Mining hayan trabajado en otros proyectos
de Data Mining, y al menos hay un experto en el equipo para cada área del proyecto. El equipo
de Data Mining no tienen porque estar familiarizado con los datos que se van a utilizar pero hay
una descripción de los mismos o hay un experto a disposición del equipo de Data Mining, pero
si estará familiarizado con las herramientas de Data Mining que se van a utilizar. También hay
una descripción del modelo de negocio puesto que lo normal es que el equipo de Data Mining no
este familiarizado con los procesos de negocio de la organización para la cual van a desarrollar el
proyecto. Es también importante mencionar en este aspecto que siempre hay que tener en cuenta
el apoyo con el que cuenta el proyecto. A este respecto convienen destacar que lo normal es que
la dirección de la empresa no se oponga al proyecto y que la dirección del departamento lo apoye
desde el principio.
4.3. Drivers de coste propuestos para proyectos de Data Mining
Una vez analizados los proyectos "normales" de Data Mining y las empresas típicas a las que se
le desarrollan proyectos de Data Mining se tienen que establecer los factores que influyen en los
proyectos de Data Mining, es decir, hay que proponer los drivers de coste del modelo DMCOMO.
Se ha optado por dividir los drivers en 6 categorías, de la misma forma que agrupa el modelo CO-
COMOII los drivers de coste para los proyectos de software. En el caso de COCOMO II los drivers
de coste se agrupan en cuatro grupos. Producto, Plataforma, Proyecto y Personal de acuerdo a las
características que engloban y según a la parte del desarrollo de software afectan.
Para el caso de DMCOMO se ha intentado seguir la misma clasificación, pero dado que la natu
raleza de los proyectos de Data Mining varia de la de los proyectos de desarrollo de software, la
clasificación queda como se muestra a continuación:
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PnOYECTOS DE DATA MINING (DMCOMOy
CAPÍTULO 4. SOLUCIÓN 65
ü Datos
Agrupa aquellos drivers de coste que tienen que ver con la cantidad y la calidad de los datos
a tratar en el proyecto de Data Mining, también se agrupan bajo esta clasificación todos los
drivers relativos a modelos de datos y a sistemas gestores de bases de datos en los que se
pueden encontrcir los datos objetivo del análisis.
Q Modelos
En este grupo se encuadran todas aquellas características o drivers de coste que tienen que
ver con los modelos que hay generar. Estos drivers tienen en cuenta el volumen de datos que
se va a utilizar píira genereír los modelos, la disponibilidad de técnicas de Data Mining que se
pueden utilizar para la generación de los modelos y la dificultad del mismo.
• Plataforma
Los drivers de coste aquí agrupados tienen que ver con las características de los almacenes
de datos y su localización.
Q Técnicas y Herramientas
Aquí se agrupan las características de las técnicas y herramientas de Data Mining que se
van a utilizar en el proyecto. Estas características se centran principalmente en el nivel de
formación que requieren, la amigabilidad de las mismas y el número de técnicas de Data
Mining que soportan.
Q Proyecto
Este grupo agrupa aquellas características relativas a los departamentos y a las localizaciones
para las que se desarrolla el proyecto de Data Mining. También incluye características acerca
de la documentación que es necesario generar durante la realización del proyecto.
Q Personal
Bajo el nombre de personal se encuentran todos aquellos factores relacionados con las per
sonas que participan en el proyecto de Data Mining (dirección, equipo de Data Mining y
expertos). Los drivers evaluarán el conocimiento y la capacidad requerida para llevar a cabo
cada una de las tareas del proyecto.
Se describirán a continuación en detalle cada uno de los factores de cada grupo presentado para
cada driver de coste su descripción, sus niveles y las descripciones asociadas, y la forma de calcu
larlo en caso de no ser trivial. Para el establecimiento de los niveles y de las descripciones asociadas
de de cada driver, se hizo uso del Método Delphi [LT75] (ver apéndice A).
'MODELO MATEMÁTICO PABAMÉTRICO DE ESTIMACIÓN PAKA PROYECTOS DE DATA MINING ÍDMCOMO)'
CAPÍTULO 4. SOLUCIÓN 66
4 . 3 . 1 . Drívers de Datos
Los drivers que se agrupan en este apartado hacen referencia al esfuerzo requerido para el desarro
llo de un proyecto de Data Mining a causa de factores relacionados con los datos manejados en el
mismo. De esta manera, no requiere el mismo esfuerzo un proyecto en cual se trabaja sobre un
número pequeño de tablas con pocos atributos y con una dispersión baja, que si el proyecto utiliza
un número elevado de tablas, con un número alto de atributos y una dispersión elevada. Asimismo,
el grado de limpieza de los atributos también influye en el esfuerzo requerido para llevar a cabo el
proyecto. Del mismo modo, el nivel de integración de los datos y la localización de los mismos son
factores influyentes en el esfuerzo.
Los drivers de datos se han agrupado en factores relativos al volumen de datos disponible al comien
zo del proyecto, factores que tienen que ver con la dispersión y la calidad de los datos que se van a
manejar, disponibilidad de los modelos de datos y posibles medidas de privacidad.
4.3.1.1. Volumen
Para los drivers de coste que se refieren al volumen de datos, siempre se tendrá en cuenta el vo
lumen de datos inicial, antes de la fase de preproceso, puesto que, la fase de preproceso es la fase
que por lo general requiere un mayor esfuerzo. Bajo el nombre de volumen se agrupan los drivers
de coste referentes al Número de tablas (NTAB), Número de tupias (NTUP) y Número de atributos
(NATR) que se describen a continuación.
O Número de tablas (NTAB)
Este factor hace referencia al número inicial de tablas que se tendrán en consideración al
comienzo del proyecto, o lo que es lo mismo, hace referencia al número de tablas que alber
gan las fuentes u orígenes de datos (ficheros, bases de datos, etc.).
Rango Extra bajo Muy bajo Bajo Nominal Alto Muy alto Extra alto
Descripción Hasta 20 tablas Desde 20 hasta 50 tablas Desde 50 hasta 80 tablas Desde 80 hasta 100 tablas Desde 100 hasta 200 tablas Desde 200 hasta 300 tablas Más de 300 tablas
Valor 0 1 2 3 4 5 6
Tabla 4.1: Factor NTAB
En la tabla 4.1 se describen los valores para cada uno de los rangos que puede tomar el factor
NTAB. Para calcular el número de tablas que se van a utilizar basta simplemente con acceder
•MODELO MATEMÁTICO PAKAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOf
CAPÍTULO 4. SOLUCIÓN 67
a la base de datos que las alberga y contarlas, si es que las fuentes de datos son bases de datos,
sino habrá que contar el número de tablas en función del tipo de fuente.
Por lo tanto, considerando el Data Warehouse de un departamento que contiene 5 diagramas
en estrella con alrededor de 15 dimensiones, se obtienen 75 tablas a las que hay que sumar
5 tablas más correspondientes a las tabla de hechos con lo que se obtiene un total de 80 tablas.
a Número de tupias (NTUP)
El factor NTUP considera el número inicial de tupias que contienen las tablas que se van a
tener en cuenta a la hora de comenzar el proyecto. La forma de calcular el número total de
tupias aparece en la ecuación (4.1).
ntab
NTUP = Y^ ntupi (4.1) í= i
donde ntab es el número de tablas a considerar y ntupi es el número de tupias de la tabla i-
ésima.
Si los datos residen en un Sistema Gestor de Bases de Datos, la forma de calcular el número
de tupias se puede realizar mediante consultas SQL sobre las tablas de la base de datos. Una
vez calculadas las tupias del proyecto, para obtener el valor de este driver de coste se utiliza
la tabla 4.2.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Menos de 5 * 10''' tupias Entre 5 * 10'' y 10 * 10^ tupias Entre 10 * 10 y 20 * 10 tupias Entre 20 * 10' y 50 * 10' tupias Más de 50 * 10 tupias
Valor 1 2 3 4 5
Tabla 4.2: Factor NTUP
Para obtener los valores de la descripción de la tabla 4.2 se ha supuesto que para el valor nomi
nal el número de tupias a considerar es de aproximadamente de 10.000 tupias/año para las
tablas de dimensión y de 100.000 tuplas/dia (3.000.000 tupias/mes, 36.000.000 tupias/año)
para las tablas de hechos (ver sección 4.2.1). Teniendo estos datos en cuenta y que el número
de tablas de hechos que se supone normal es 5, y el número de tablas de dimensión es 10 (ver
sección 4.2.1), se obtienen alrededor de 180.000.000 tupias. Por lo tanto este será el valor con
siderado como nominal para NTUP. El volumen de tupias se ha considerado en tupias/año.
• MODELO MATEMÁ TICO PAHAMÉTDICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4. SOLUCIÓN 68
En caso de que no se disponga del volumen de tupias en un año habrá que extrapolar los
datos que se tengan para que sean en tupias/año.
a Número de atributos (NATR)
Este driver de coste tiene en cuenta el esfuerzo introducido en la realización de un proyecto
de Data Mining debido al número inicial de atributos que contienen las tablas candidatas a
ser consideradas en el proyecto. NATR es uno de los factores que tiene una mayor influen
cia sobre el esfuerzo a la hora de llevar a cabo un proyecto de Data Mining, puesto que un
mayor número de atributos implica un mayor preproceso de los datos, por lo tanto un mayor
esfuerzo. En la ecuación (4.2) se puede ver la forma de calcular el número de atributos.
ntab
NATR = Y^ ^o-tri (4.2)
donde ntab es el número de tablas y natri es el número de atributos de la tabla i-ésima.
Para obtener los valores que se deben utilizar en las ecuaciones del modelo, se utiliza la tabla
4.3.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descrípción Menos de 500 atributos Entre 500 y 1000 atributos Entre 1000 y 1500 atributos Entre 1500 y 2000 atributos Más de 2000 atributos
Valor 1 2 3 4 5
Tabla 4.3: Factor NATR
Para establecer el valor nominal del driver de coste NATR, se han tomado como punto de
partida los valores considerados por los expertos como "normales" para el número de atri
butos que se tienen cuando se comienza un proyecto de Data Mining. Los valores conside
rados son 20 atributos para las tablas de hechos (10 atributos de clave +10 hechos) y para
las tablas de dimensión entre 20 y 30 atributos (ver sección 4.2.1). Con lo que si se tienen 5
estrellas con una tabla de dimensión cada estrella se obtienen 100 atributos para los hechos.
Las dimensiones son alrededor de 10 por estrella, y como tenemos 5 estrellas, se obtienen
entre 1000 y 1500 atributos para las dimensiones. Por lo tanto, los valores considerados para
el valor "nominal" son entre 1000 y 1500 atributos (los 100 atributos de los hechos se pueden
despreciar frente al número de atributos de las dimensiones).
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMAUÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4. SOLUCIÓN 69
4.3.1.2. Dispersión o número diferentes de valores de los atributos (DISP)
Debido al número de valores diferentes que pueden tomar los atributos (dispersión) en un proyec
to de Data Mining se introduce u esfuerzo adicional.
Como medidas de dispersión de los datos, se pueden utilizar medidas estadísticas, tales como la
varianza o la desviación típica, si los datos son cuantitativos, y si los datos son cualitativos se puede
emplear la entropía de la información definida por Shannon [SW49] u otras medidas tales como
asignar valores a las categorías, si tienen un orden, teniendo en cuenta que la diferencia entre cada
categoría es la misma y luego aplicar la varianza estadística sobre las categorías en forma numéri
ca. En caso de las proyectos de Data Mining los valores de los variables que se están utilizando
pueden ser tanto cuantitativos como cualitativos, así que para solucionar el problema se ha optado
por utilizar una combinación de la varianza (CT ), para los atributos cuantitativos, y de la entropía
propuesta por Shannon para los atributos cualitativos. La varianza se define como
k
X; {xi - xfrii a^ = ^^^^ (4.3)
donde k es el número de observaciones de la variable, x es la media de los los valores de la variable
analizada, Xi es el valor ¿-ésimo que toma la variable, n» es número de veces que la variable toma
el valor XÍY N es el número total de observaciones o valores que toma la variable analizada.
La entropía se define como
H = -J2Pi^og^Pi (4.4) i=l
donde H representa la entropía del sistema, Pi es la probabilidad del elemento ¿, y M es el número
de elementos que aparecen en el sistema.
Así pues, para calcular el valor del driver de coste DISR se calcula la varianza de cada uno de los
atributos cuantitativos y la entropía de cada uno de los atributos cualitativos. Posteriormente se
aplica la ecuación (4.5) para el calculo final del valor del driver de coste DISP.
^ISP=¡,(JE<^í-,EH,yM^ (4.5)
siendo i el número de atributos cuantitativos, j el número de atributos cuantitativos, V la varianza
y M la media de todos los valores de las varianzas y las entropías de los atributo. La resta de M y la
división por V se hace para normalizar los valores de la dispersión de los atributos en el intervalo
[O, 1]. Para el atributo DISP la experiencia demuestra que a mayor número de valores que puedan
tomar los atributos, o lo que es lo mismo, a mayor entropía, mayor resulta el esfuerzo porque es
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOy
CAPÍTULO 4. SOLUCIÓN 70
más costoso crear e interpretar los modelos.
En la tabla 4.4 se muestran los rangos, las descripciones y los valores del atributo DISP. En esta tabla,
una vez calculada la dispersión de los atributo se obtendrá el valor a introducir en la ecuación del
esfuerzo que se planteará en la sección 4.4.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descrípción 0 < H < 0,2 0,2 < H < 0,4 0,4 < H < 0,6 0,6 < H < 0,8 0,8 < H < 1
Valor 1 2 3 4 5
Tabla 4.4: Factor DISP
4.3.1.3. Calidad de los datos
En los factores aquí agrupados se encuentran aquellos que hacen referencia a la bondad de los
datos disponibles al principio del proyecto, antes de las fases de preproceso y transformación.
a Porcentaje de nulos (PNUL)
El porcentaje de valores nulos o indefinidos en los atributos de las tablas influirá en el esfuer
zo para el desarrollo de un proyecto de Data Mining, puesto que hay que decidir que se hace
con esos valores nulos. Algunas de las posibles acciones a tomar son:
• Eliminar las tupias con nulos.
• Eliminar únicamente los atributos con muchos nulos.
• Asignar a los valores nulos un valor utilizando un modelo predictivo.
Del correcto tratamiento de los valores nulos, junto con la correcta definición del problema a
resolver, dependerá el éxito de un proyecto de Data Mining.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Hasta un 10 % de valores nulos Desde un 10 % hasta un 15 % de valores nulos Desde un 15 % hasta un 20 % de valores nulos Desde un 20 % hasta un 25 % de valores nulos Más de 25 % de valores nulos
Valor 1 2 3 4 5
Tabla 4.5: PNULp. Factor PNUL para cada atributo
• MODELO MATEMA TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 4. SOLUCIÓN 71
Así pues este factor se refiere al esfuerzo que se realiza para el tratamiento de los valores nulos
que aparecen en los valores iniciales de los datos. A mayor porcentaje de nulos, parece que
debe realizarse un mayor esfuerzo puesto que habrá que tomar un mayor número de deci
siones. En la tabla 4.5 se tiene el rango de valores junto con su descripción y el valor concreto
para cada nivel del rango.
El valor PNUL por lo tanto se obtiene redondeando la suma de los valores PNULp de cada
atributo dividido entre el número total de atributos tal y como se muestra en la ecuación
PNUL = BOUND(^'-^^1""-^'^) (4.6)
siendo n el número total de atributos a tratar. El redondeo y la división entre el número total
de atributos se hace para dejar con un valor entero y normalizado entre 1 y 5 para que el valor
total se corresponda con alguno de los valores de los rangos del driver de coste que se mues
tran en la tabla 4.6, siendo el valor PNUL el utilizado como valor del nivel correspondiente
para este driver de coste.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.6: Factor PNUL
• Criterios para la codificación de valores (CCOD)
Hay veces que los datos de origen no son válidos como entrada de los algoritmos de Data
Mining que se vayan a utilizar (ver sección 2.2.1). Así pues el factor CCOD tiene en cuenta
si los criterios de discretización o de transformación del tipo de valores son dados por un
usuario experto en la utilización de los datos o si por el contrario el criterio de codificación
o transformación lo tiene que proponer el encargado de esa parte en el proyecto de Data
Mining. Si el criterio es establecido por el usuario experto en la utilización de los datos, el
esfuerzo en el proyecto es menor que si tiene que proponer los valores el encargado de esa
parte en el proyecto de Data Mining.
Para el calculo del valor de este driver de coste se tendrá únicamente en cuenta aquellos
atributos que sean susceptible de transformación. En la tablas 4.7 se muestran los rangos, las
descripciones y los valores para el atributo CCOD.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 72
Rango Muy bajo Bajo Nominal Alto Muy alto Extra alto
Descripción Se facilitan todos los valores de transformación 80 % de transformaciones dadas por el usuario 65 % de transformaciones dadas por el usuario 50 % de transformaciones dadas por el usuario 30 % de transformaciones dadas por el usuario Menos del 30 % de transformaciones dadas por el usuario
Valor 1 2 3 4 5 6
Tabla 4.7: Factor CCOD
4.3.1.4. Disponibilidad de los modelos de datos (DMOD)
Cuando se crean las bases de datos operacionales, normalmente se documentan los modelos crea
dos. En esta documentación, además del modelo utilizado para el diseño de la base de datos, se
tiene información sobre las tablas y los atributos de dichas tablas, así como del significado de los
valores que pueden almacenar los atributos. Muchas veces esta documentación no está disponible,
bien porque no se creo en el momento del diseño de la base de datos o porque es inaccesible para
el personal del proyecto de Data Mining.
Así, si se cuenta con la documentación de los modelos de datos resultará mucho más fácil la com
prensión de los datos a manejar y en algunos casos ayudará a entender el problema que se tiene
que resolver. Por lo tanto hay que tener en cuenta que si los modelos de datos están disponibles
para el proyecto de Data Mining, puesto que si se dispone de los modelos de datos el compren
der lo que significa toda la información es más fácil que si no se dispone de los mismos, lo cual
requiere un menor esfuerzo en el proyecto de Data Mining. El rango, la descripción de cada rango
y los valores correspondientes que se utilizcirán en el calculo del esfuerzo para el factor DMOD se
pueden observar en la tabla 4.8.
Rango Extrabajo Muy bajo Bajo Nominal Alto Muy alto
Descripción Todos los modelos documentados El 90 % de los modelos disponibles Entre el 80 % y el 90 % de los modelos disponibles Entre el 70 % y el 80 % de los modelos disponibles Entre el 60 % y el 70 % de los modelos disponibles Menos del 60 % de los modelos disponibles
Valor 0 1 2 3 4 5
Tabla 4.8: Factor DMOD
4.3.1.5. Privacidad de los datos (PRIV)
Este factor toma en consideración que por motivos de privacidad debido a la Ley Orgánica 15/1999
de Protección de Datos de Carácter Personal (LOPD) [B.099] haya datos inaccesibles que pueden ser
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4. SOLUCIÓN 73
personales y la empresa para la cual se desarrolla el proyecto de Data Mining no pueda aportarlos
para la realización del proyecto.
Muchos de estos datos puede que sean necesarios para terminar el proyecto. Puede ocurrir que
si los datos no se puedan inferir y son vitales para el proyecto, este nose puede realizar, o si los
datos no son de gran importancia para el proyecto este se pueda realizar. En otros casos, los datos
se pueden inferir a partir de otros datos (internos o externos a la organización). En el caso de que
los datos se puedan inferir, esto supone un esfuerzo adicional en el proyecto. Por ejemplo, puede
que los datos demográficos, excepto el código postal, acerca de clientes de una determinada orga
nización sean privados. Si se obtiene una base de datos demográfica externa a lo organización se
pueden inferir datos como la renta a partir de los valores de la base de datos demográfica adquiri
da, pero esto lleva el esfuerzo adicional de la consecución de la base de datos demográfica y la
integración con los datos que se tenían originalmente. Los valores correspondientes a PRIV se en
cuentran en la tabla 4.9.
Rango Muy bajo Bajo
Nominal
Alto
Descripción Todos los datos son accesibles por el equipo de proyecto Entre el 20 y el 30 % de los datos son privados pero se pueden inferir Entre el 20 y el 30 % de los datos son privados y son difíciles o imposibles de inferir Entre el 30 y el 50 % de los datos son privados pero se pueden inferir ellO % de ellos
Valor 1 2
3
4
Tabla 4.9: Factor PRIV
4.3.1.6. Necesidad de adquisición de datos externos (DEXT)
Si existe la necesidad de utilizar datos externos a la organización para la cual se realiza el proyecto
de Data Mining, por ejemplo, datos geográficos del estilo de las bases de datos MOSAIC [Inc03]
(valores socio-demográficos, sociológicos, etc.) el esfuerzo del proyecto aumentará, puesto que
hay que comprender los modelos de datos externos y posteriormente integrar los datos externos
con los datos propios del proyecto. Los valores a utilizar para el calculo del esfuerzo y la forma de
seleccionarlos se describe en la tabla 4.10, entendiendo por "fuente" cualquier conjunto de datos
sea cual sea su soporte de almacenamiento (papel, fichero electrónico, base de datos, etc.).
Rango Bajo Nominal Alto Muy alto
Descripción Entre 1 y 3 fuentes de datos externas Entre 3 y 5 fuentes de datos externas Entre 5 y 7 fuentes de datos externas Más de 7 fuentes de datos externas
Valor 2 3 4 5
Tabla 4.10: Factor DEXT
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOj'
CAPÍTULO 4. SOLUCIÓN 74
4.3.2. Drívers de Modelos
En el esfuerzo dedicado a un proyecto de Data Mining los modelos de Data Mining a generar
tienen gran influencia, puesto que no es lo mismo desarrollar un modelo que varios. Además, hay
que tener en cuenta el tipo de modelos a desarrollar. También hay que tener en cuenta el número
de tupias y atributos que se utilizarán en cada modelo, puesto que a mayor cantidad de datos,
mayor esfuerzo para construir el modelo. Los datos derivados que son necesarios para cada mod
elo también hay que tenerlos en consideración a la hora de calcular el esfuerzo.
Adicionalmente, hay que considerar el número de técnicas de Data Mining disponibles para la
creación del modelo y si se dispone de herramientas para la generación de dichos modelos o hay
que implementarlas.
4.3.2.1. Número de modelos (NMOD)
El número de modelos a generar en un proyecto de Data Mining es un factor muy importante a la
hora de hacer la estimación del esfuerzo, puesto que a mayor número de modelos, mayor trabajo
habrá que realizar para adaptar los datos a los algoritmos que se utilicen, y mayor esfuerzo hay que
realizar para obtener un mayor número de modelos que produzcan unos resultados aceptables.
Así pues el factor NMOD tiene en cuenta el número de modelos que hay que generar como resulta
do del proceso de Data Mining. Está claro que cuantos más modelos se tengan que generar mayor
será el esfuerzo que que hay que realizar. En la tabla 4.11 se presenta la forma de seleccionar los
valores para este factor de coste.
Rango Bajo Nominal Alto Muy alto
Descripción De 1 a 3 modelos De 3 a 5 modelos De 5 a 7 modelos Más de 7 modelos
Valor 2 3 4 5
Tabla 4.11: Factor NMOD
4.3.2.2. Tipo de modelo (TMOD)
El tipo o tipos de modelos que hay que obtener hay que tenerlo en cuenta puesto que no requiere
el mismo esfuerzo obtener un modelo predictivo que un modelo descriptivo.
Dentro de los modelos predictivos y descriptivos hay diferentes tipos de técnicas que se pueden
aplicar, así no es lo mismo generar e interpretar un modelo basado en redes neuronales, que un
modelo basados en árboles de decisión. En la figura 4.1 se muestra la clasificación de los modelos
' MODEÍJO MATEMA TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 4. SOLUCIÓN 75
de Data Mining utilizada para la generación de los valores de la tabla 4.12 en función del tipo de
operación de Data Mining.
Modelos de Data Mining
Modelos Descriptivos Modelos Predictivos
Asociación Clustering Patrones secuenciales Clasificación Predicción Estimación Series temporales
Figura 4.1: Modelos de Data Mining
En la tabla 4.12 se presenta la forma de seleccionar los valores a utilizar en el calculo del esfuer
zo para el factor TMODp, es decir, la influencia que tendrá cada modelo en el esfuerzo final del
proyecto. Así pues, para calcular el valor del driver de coste TMOD, primero hay que hacer uso de
la tabla 4.12 para calcular el valor asociado con cada modelo.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Modelo descriptivo: Asociación Modelo descriptivo: Clustering Modelo descriptivo: Patrones secuenciales Modelo predictivo: Clasificación Modelo predictivo: Predicción o Estimación o Series temporales
Valor 1 2 3 4 5
Tabla 4.12: TMODp. Factor TMOD para cada modelo
El valor TMOD por lo tanto se obtiene redondeando la suma de los valores TMODp de cada modelo
dividido entre el número total de modelos tal y como se muestra en la ecuación (4.7).
TMOD^ROUNDÍ^^^^:^^^^^ (4.7)
siendo n el niimero total de modelos a generar. Con este valor y la tabla 4.13 se obtiene el nivel
correspondiente para este driver de coste.
4.3.2.3. Características del modelo
A continuación se proponen los factores propios de los modelos que afectan al esfuerzo total del
proyecto de Data Mining. Estos factores tienen relación con el volumen de datos requerido por
cada modelo así como con la necesidad de generación de datos derivados píua conseguir alcanzar
con éxito los objetivos propuestos al comienzo del proyecto de Data Mining.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECmS DE DATA MINING ÍDMCOMOy
CAPÍTULO 4. SOLUCIÓN 76
a Volumen de datos requerido para cada modelo
Los drivers de coste que se analizan a continuación (MTUP, MATR y MDIS) se refieren al
número de tupias, número de atributos y dispersión de los atributos respectivamente, des
pués de la fase de preproceso. Es decir, hacen referencia únicamente a la cantidad de tupias,
cantidad de atributos que se utilizarán realmente para la construcción de los modelos.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.13: Factor TMOD
Q Número de tupias (MTUP)
Este driver de coste representa el número de tupias que utilizará cada modelo y sólo es
representativo de cara al tiempo de computación del modelo, puesto a que cuantas más
tupias haya que procesar para construir el modelo más tiempo se requerirá para obtener
el modelo.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Menos de 5 * 10* Entre 5 * 10'' y 10 * W Entre 10 *10' y 20* 10** Entre 20* 10** y 50* 10' Más de 50 * 10**
Valor 1 2 3 4 5
Tabla 4.14: MTUPp. Factor MTUP para cada modelo
La reducción en un orden de magnitud del número de tupias para los modelos (MTUP)
frente al número de tupias totales que se utilizarán para el proyecto tiene que ver con
que los datos ya se encuentran preprocesados y se habrán eliminado aquellas tupias
que no son necesarias para la construcción de los modelos.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.15: Factor MTUP
• MODELO MATEMÁTICO PARAMÉnUCO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 77
El valor MTUP se obtendrá como se muestra en la ecuación (4.8).
MTUP = ROUND(^^^^^^:^^^^^) (4.8)
siendo n el número total de modelos a generar. Una vez obtenido el valor MTIIR se cal
culará su nivel haciendo uso de la tabla 4.15.
Q Número y tipo de atributos (MATR)
El número de atributos utilizados para cada modelo, al igual que MTUP, solo es nece
sario de cara al tiempo de construcción del modelo. Por lo general a mayor número de
atributos, se tardará más en construir el modelo.
En cuanto al tipo de los atributos, pueden ser cuantitativos y cualitativos. Por lo general,
el tratamiento de valores cualitativos es más complejo que el tratamiento de los valores
cuantitativos, por lo que requerirá un mayor esfuerzo trabajar con valores cuantitativos.
El número de atributos a tratar para generar el modelo es bastante inferior al número de
atributos que se tienen al comenzar el proyecto (NATR), puesto que en las fases de pre-
proceso y transformación hay muchos atributos que se eliminan, o que se fusionan con
otros atributos. Además hay muchos atributos que no son necesarios para los modelos
a generar.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Menos de 10 atributos Entre 10 y 20 atributos Entre 30 y 50 atributos Entre 50 y 70 atributos Más de 70 atributos
Valor 1 2 3 4 5
Tabla 4.16: MATRnp. Factor MATRn para cada modelo
Por lo tanto hay que tener en cuenta el número y el tipo de los atributos que se van a
utilizar para cada modelo. Para obtener los valores de los MATRn (número de atributos)
y MATRt (tipo de atributos) se hará uso de las ecuaciones (4.9) y de las tablas 4.16 y 4.17
respectivamente.
MATRn = ROUND{ ÍEti MATRnpÜ)
MATRt = ROUND(^^^^^^f^^) (4.9)
siendo n el número total de modelos a generar. Para el calculo del valor del driver de
coste MATR se combinan los valores MATRn y MATRp obtenidos con la ecuación 4.9. La
•MODELO MATEMÁTICO PAKAMÉTRICO DE ESTIMAOÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOT
CAPÍTULO 4. SOLUCIÓN 78
Rango Muy bajo Bajo
Nominal Alto
Muy alto
Descripción Todos los atributos no numéricos Mayor número de atributos no numéricos que de atributos numéricos 50 % de atributos numéricos y 50 % de atributos no numéricos Mayor niimero de atributos numéricos que de atributos no numéricos Todos los atributos numéricos
Valor 1 2
3 4
5
Tabla 4.17: MATRtp. Factor MATRt para cada modelo
ecuación para la obtención del valor MATR es la que se muestra en la la ecuación (4.10).
MATR = TRUNC ÍMATRn + MATRt\
(4.10) V 2 y
donde TRUNC es la función que devuelve solo la parte entera del número que se le pasa
como parámetro.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.18: Factor MATR
• Dispersión de los atributos (MDIS)
Aunque en la sección 4.3.1.2 ya se trató la entropía de los atributos, el driver DISP trata el es
fuerzo introducido por el conjunto de datos originales que se tienen al principio del proyecto,
sin embargo el driver MDIS trata el esfuerzo adicional que introduce el número diferente de
valores de los atributos cuando se van a crear los modelos. Al igual que para MTUP y MATR
solo influye en el tiempo de construcción del modelo, con lo cual a mayor dispersión mayor
esfuerzo.
Las ecuación a utilizar para el calculo de MDIS es la misma que se utiliza para el cálculo de
DISP, lo único que hay que calcular la dispersión de los atributos que se utilizan para cada
modelo. Lo que cambia en relación al driver DISP es la descripción de los rangos del driver,
pues no tiene porque aportar el mismo esfuerzo un valor de entropía x en DISP que en MDIS.
Para calcular el valor del driver de coste MDISp, se calcula la varianza de cada uno de los atri
butos cuantitativos y la entropía de cada uno de los atributos cualitativos, para cada modelo.
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4. SOLUCIÓN 79
Posteriormente se aplica la ecuación (4.12) para el cálculo final del valor del driver de coste
MDISp, y haciendo uso de la tabla 4.19 se obtienen los valores de MDISP para cada modelo
que se utilizarán para el calculo de MDIP.
MDISPp=^{ij:a^ + j:H, M (4.11)
siendo i el número de atributos cuantitativos, j el número de atributos cuantitativos, V la
varianza y M la media de todos los valores de las varianzas y las entropías de los atributo.
Rango Bajo Nominal Alto Muy alto Extra alto
Descripción 0 < H < 0,2 0,2 < H < 0,4 0,4 < H < 0,6 0,6 < H < 0,8 0,8 < H < 1
Valor 2 3 4 5 6
Tabla 4.19: MDISPp. Factor MDIS para cada modelo
Para obtener el valor MDIS de todos los modelos que es realmente el que se utiliza en la
ecuación de DMCOMO, se hace uso de la ecuación (4.12).
MDISP = R0UND(^^^^^^^IM1 (4.12)
siendo n el número total de modelos a generar. En la tabla 4.20 se presentan los niveles co
rrespondientes al driver de coste MDIS así como sus descripciones asociadas y los valores
correspondientes.
Rango Bajo Nominal Alto Muy alto Extra alto
Descripción 0 < H < 0,2 0,2 < H < 0,4 0,4 < H < 0,6 0,6 < H < 0,8 0,8 < H < 1
Valor 2 3 4 5 6
Tabla 4.20: Factor MDIS
Q Datos derivados requeridos (MDER)
Este driver trata de reflejar el esfuerzo necesario en obtener datos derivados a partir de los
que ya se tiene en los datos limpios para ser utilizados en un modelo concreto. Parece claro
que a mayor número de atributos derivados que haya que utilizar, mayor será el esfuerzo
requerido. En el caso de de los atributos derivados el número de ellos por modelo suele ser
bastante alto, puesto que se obtiene más semántica en el modelo al tener un mayor número
' MODELO MATEMÁ TICO PARAMÉTRICO DB ESTIMACIÓN PARA PBOYECTOS DE DATA MINING (DMCOMO/
CAPÍTULO 4. SOLUCIÓN 80
de atributos. A priori, el número de atributos a derivar es desconocido, pero se puede hacer
una estimación en función de los atributos disponibles para la creación de un determinado
modelo. En la tabla 4.21 se encuentran los rangos, las descripciones de cada rango y los valo
res del esfuerzo para este factor para cada modelo (MDERp).
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Menos de 5 atributos derivados Entre 5 y 10 atributos derivados Entre 10 y 15 atributos derivados Entre 15 y 20 atributos derivados Más de 20 atributos derivados
Valor 1 2 3 5 5
Tabla 4.21: MDERp. Factor MDER para cada modelo
Como los datos derivados son para cada modelo la forma de calcular el valor total del atributo
MDER es la que aparece en al ecuación (4.13).
MDER = ROUND(^:¡^^^^^^^ (4.13)
siendo n el número total de modelos a generar. Los rangos de este driver de coste se muestran
en la tabla 4.22.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.22: Factor MDER
4.3.2.4. Disponibilidad de técnicas para el tipo de problema a tratar (MTEC)
Para generar los distintos modelos se pueden aplicar diferentes técnica, pero no todas las técnicas
se pueden aplicar sobre todos los modelos (ver sección 2.2.2.2).
Normalmente a mayor número de técnicas disponibles, se requerirá un menor esfuerzo puesto
que se puede obtener un modelo bueno por diferentes técnicas. Es preferible y requiere menos
esfuerzo el probar con varias técnicas que tener que hacer "tuning" de un modelo para obtener un
modelo suficientemente bueno. En la tabla 4.23 se describen el rango y los valores de de este driver
de coste.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROTECTOS DE DATA MINING (DMCOMOt
CAPÍTULO 4. SOLUCIÓN 81
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Extra alto
Modelos Descriptivos Descripción Existen más de cuatro técnicas para el modelo a generar Existen 3 técnicas para el modelo a generar
Existen 2 técnicas para el modelo a generar Existen 1 técnicas para el modelo a generar ~
"
Valor 1
2
3
4
~
~
Modelos Predictlvos Descripción
Existen más de cuatro técnicas para el modelo a generar Existen 4 técnicas para el modelo a generar Existen 3 técnicas para el modelo a generar Existen 2 técnicas para el modelo a generar Solo existe 1 técnica para el modelo a generar
Valor
2
3
4
5
6
Tabla 4.23: MTECp. Factor MTEC para cada modelo
Tal y como se observa en la tabla 4.23 el análisis de las técnicas disponibles se tiene que realizar
teniendo en cuenta el tipo de modelo que se va a generar (predictivo, descriptivo). Para el calculo
del valor de MTEC primero hay que calcular el valor correspondiente de MTECp haciendo uso de la
tabla 4.23, para posteriormente combinar todos los valores de MTECp haciendo uso de la ecuación
(4.14). obteniendo un único valor para este driver de coste.
(4.14)
siendo n el número total de modelos a generar. Para utilizar este valor en la ecuación de DMCOMO
hay que obtener el valor asociado al nivel correspondiente haciendo uso de la tabla 4.24.
Rango Muy bajo Bajo Nominal Alto Muy alto Extra alto
Descripción 1 2 3 4 5 6
Valor 1 2 3 4 5 6
Tabla 4.24: Factor MTEC
4.3.3. Drivers de Plataforma de desarrollo
Bajo este epígrafe se agrupan los factores que tienen que ver con la plataforma de desarrollo y
que influyen en el esfuerzo del proyecto de Data Mining. Se tienen en cuenta el tipo y el número
de fuentes de datos, entendiendo por fuente de datos al conjunto de datos que puede tener en
' MODELO MATEMÁTICO PAMMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 82
cualquier formato (papel, electrónico, base de datos, etc). También se tiene en cuenta el número
de servidores, entendiendo como servidor el soporte de almacenamiento de los datos, y la forma
de comunicación entre los diferentes servidores.
4.3.3.1. Número y tipo de fuentes (NFUN)
Se áeñne fuente de datos al conjunto de datos almacenado en un soporte de almacenamiento, pa
pel, formato electrónico, base de datos. Data Warehouse, etc.
El driver de coste NFUN tiene en cuenta tanto el número de fuentes u orígenes de datos, como
el tipo de fuente donde residen los datos. A mayor número de fuentes mayor será el esfuerzo que
hay que realizar para integrar todos los datos que se deben utilizar en el proyecto de Data Mining.
Se tendrá que tener también en cuenta la integración de fuentes externas a la organización. Si los
datos se encuentran almacenados en un Data Warehouse la influencia de este factor será muy baja
en esfuerzo, puesto que los datos ya se encuentran integrados de antemano, es decir, se integran y
se limpian durante la carga del Data Warehouse.
Por otro lado, en cuanto al tipo de fuente, no requiere el mismo esfuerzo trabajar con ficheros
planos, con bases de datos relaciónales o con bases de datos jerárquicas. Por ejemplo, cierto tipo
de operaciones como puede ser el "pin" de dos tablas, no se realiza igual de fácil si las dos tablas
se encuentran almacenadas en dos ficheros en papel o en dos tablas dentro de un SGBD.
Una fuente de datos es homogénea si está en el del mismo tipo de almacenamiento (fichero plano,
base de datos. Data Warehouse) y además el soporte de almacenamiento es del mismo fabricante,
del mismo producto (o productos compatibles entre ello sin necesidad de software externo al del
producto de almacenamiento) y de la misma versión (o versiones totalmente compatibles entre si).
En cualquier otro caso las fuentes de datos son heterogéneas. Los valores, rangos y descripciones
de NFUN se presentan en la tabla 4.25.
Rango Muy bajo
Bajo Nominal Alto Muy alto
Descripción Una sola fuente de datos (fichero electrónico, base de datos operacional) o un único Data Warehouse Varias fuentes (2-3) homogéneas 2-3 fuentes heterogéneas Más de 3 fuentes heterogéneas sin ficheros en papel Más de 3 fuentes heterogéneas con algún fichero en papel
Valor 1
2 3 4 5
Tabla 4.25: Factor NFUN
•MODEW MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROVECTOS DE DATA MINING (OMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 83
4.3.3.2. Tipo de servidores donde residen los datos (NSER)
Se considerará como servidor un soporte de almacenamiento de datos, ya sea papel, ficheros elec
trónicos de cualquier tipo (de procesador de textos, de hoja de cálculo, etc.), sistemas gestores de
bases de datos, etc. Así pues, NSER tiene en cuenta el tipo de servidores de distintos fabricantes
que almacenan los datos del proyecto. Este factor hay que tenerlo en cuenta puesto que no to
dos los servidores se pueden integrar con la misma facilidad. Hay que ver si el fabricante de los
diferentes servidores ofrece herramientas para la interconexión de sus servidores con servidores
de otros fabricantes. La descripción, el rango y los valores del factor NSER se muestran en la tabla
4.26.
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción Todos los servidores son SGBDs del mismo fabricante y del mismo tipo (marca y versión) Todos los servidores del mismo fabricante pero de diferente tipo (marca y/o versión) Servidores de fabricantes diferentes con herramientas de conexión entre ellos Servidores de fabricantes diferentes pero solo hay herramientas de conexión entre algunos de ellos, pero no para todos Servidores de fabricantes diferentes sin herramientas de interconexión entre ellos
Valor 1
2
3
4
5
Tabla 4.26: Factor NSER
4.3.3.3. Distancia y forma de comunicación entre los orígenes de datos (SCOM)
Como los orígenes de datos no tienen porque encontrarse todos en la misma localización, hay
que tener en cuenta la forma de comunicación entre los distintos orígenes de datos, así como la
localización de los mismos en el calculo del esfuerzo. Para el driver de coste SCOM su rango, su
descripción y los valores se muestran en la tabla 4.27.
Rango Muy bajo Bajo Nominal
Alto
Muy alto
Descripción Datos en la misma máquina donde se van a analizar Datos en la misma base de datos Todos los orígenes de datos datos en el mismo edificio, comunicación a través de LAN Todos los orígenes de datos en un lugar diferente a donde se van a analizar pero existe comunicación entre ellos Todos los orígenes de datos en un lugar diferente a donde se van a analizar y no existe comunicación entre ellos
Valor 1 2 3
4
5
Tabla 4.27: Factor SCOM
• MODELO MATEMÁ TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 84
4.3.4. Drivers de Técnicas y Herramientas
La utilización de herramientas para la generación de modelos puede facilitar mucho el trabajo por
ello conviene tener en cuenta las herramientas disponibles y las técnicas implementadas en las
mismas, así como la integración con otras herramientas que se vayan a utilizar dureinte el proyecto,
de cara a computar el esfuerzo total del proyecto. De esta manera se ha de calcular el número de
herramientas, tipo y compatibilidad de las mismas.
4.3.4.1. Disponibilidad de herramientas (TOOL)
La utilización de herramientas para un proyecto de Data Mining puede facilitar la realización del
proyecto, con lo cuál si tenemos herramientas de Data Mining (ver sección 2.2.5) que implementan
algoritmos de Data Mining se puede reducir el esfuerzo necesario peira llevar a cabo el proyecto.
Hay que tener en cuenta que no todas las herramientas implementan todas las técnicas de Data
Mining por lo tanto si disponemos de un mayor número de herramientas para la realización del
proyecto, hay una probabilidad más alta de que la técnica que sea necesaria utilizar esté implemen-
tada en alguna de las herramientas, por lo tanto a un mayor número de herramientas el esfuerzo
será menor.
También hay que tener en cuenta que algunas herramientas no son adecuadas para trabajcir con
grandes volúmenes de datos, con lo cual si el proyecto que hay que desarrollar maneja gran can
tidad de datos la herramienta en lugar de facilitar el trabajo, lo entorpece, con lo cual el esfuerzo
aumenta en lugar de reducirse por el uso de herramientas. En la tabla 4.28 está el rango con la
descripción para cada nivel de rango y el valor del driver de coste asociado al nivel de rango corres
pondiente para el factor TOOL.
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción Se utilizarán herramientas para el desarrollo de todos los modelos Más del 70 % de los modelos se desarrollaran utilizando una herramienta, pero no todos los modelos se desarrollem con una herramienta Entre el 50 % y el 70 % de los modelos se desarrollaran utilizando una herramienta Hasta el 50 % de los modelos se desarrollaran utilizando una herramienta No se utilizarán herramientas en el desarrollo de ninguno de los modelos
Valor 1
2
3
4
5
Tabla 4.28: Factor TOOL
• MODELO MATEMÁ TICO PARAMÉTRICO DE ESTIMACIÓN PAIIA PROVECIVS DE DATA MINING (DMCOMOf
CAPÍTULO 4. SOLUCIÓN 85
4.3.4.2. Tipo de herramientas
Este factor analiza aquellos factores relativos a las herramientas que tienen que ver con la com
patibilidad de las herramientas de Data Mining con cualquier software ofimático o con otras he
rramientas de Data Mining disponibles en la organización. También se contempla el número de
técnicas de Data Mining que tiene implementadas las herramientas que se está utilizando.
Q Número de técnicas soportadas (NTEC)
Este driver refleja el número de técnicas que han de ser utilizadas en el proyecto y son so
portadas por las herramientas disponibles. A mayor número de técnicas ya implementadas
que se puedan utilizar menor será el esfuerzo que hay que realizar para obtener un modelo
óptimo. En la tabla 4.29 se muestran los valores de este driver de coste para cada herramienta
que se encuentre disponible para ser utilizada en el proyecto.
Rango Muy bajo
Bajo
Nomined
Alto
Descripción Las herramientas disponibles soportan hasta el entre el 80 % y el 100 % de las técnicas a utilizar Las herramientas disponibles soportan entre el 70 % y el 80 % de las técnicas a utilizar Las herramientas disponibles soportan entre el 50 % y el 70 % de las técnicas a utilizar Las herramientas disponibles soportan hasta el 50% de las técnicas a utilizar
Valor 1
2
3
4
Tabla 4.29: NTECp. Factor NTEC para cada herramienta
Para calcular el valor del driver de coste NTEC se utiliza la ecuación 4.15.
NTEC = ROUND í íEtiNTECpji)
n (4.15)
siendo n el número de herramientas disponibles para el proyecto. Los niveles, descripciones
y valores del driver de coste se muestran en la tabla 4.30.
Rango Muy bajo Bajo Nominal Alto
Descripción 1 2 3 4
Valor 1 2 3 4
Tabla 4.30: Factor NTEC
Q Compatibilidad (COMP)
Este factor tiene en cuenta el grado de compatibilidad de las herramientas que se vayan a
utilizar en el proyecto con el resto de software disponible para la realización del proyecto. De
•MODELO MATEMÁTICO PARAMÉrmCO DE ESTIMACIÓN PARA PROYECmS DE DATA MINING (DMCOMO!
CAPÍTULO 4. SOLUCIÓN 86
esta manera, comprende el nivel de compatibilidad de las herramientas de Data Mining, el
nivel de compatibilidad con los diferentes sistemas gestores de bases de datos que albergan
los datos que se utilizarán para el proyecto, incluso se tiene en cuenta el nivel de compatibi
lidad con otras herramientas como pueden ser hojas de cálculo, procesadores de texto, etc.
El nivel de compatibiUdad de las herramientas hay que tenerlo en cuenta puesto que cuan
to más compatibles sean las herramientas con el resto de software disponible menor es el
esfuerzo que hay realizar si hay que utilizar otro software adicional para el tratamiento de
los datos y de los resultados. La descripción del rango y los valores de este factor para cada
herramienta de Data Mining se encuentran en la tabla 4.31.
Rango Extrabajo
Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción Compatibilidad nula con el resto de herramientas disponibles en la organización CompatibiUdad con editores de texto disponibles en la organización Compatibilidad con editores de texto y hojas de cálculo disponibles en la organización Compatibilidad con editores de texto, hojas de cálculo y SGBD disponibles en la organización Compatibilidad con editores de texto, hojas de cálculo, SGBD y herramientas de Data Mining disponibles en la organización Compatibilidad e integración total con el resto de herramientas disponibles en la organización
Valor 0
1
2
3
4
5
Tabla 4.31: COMPp. Factor COMP para cada herramienta
Para calcular el valor final COMP hay que sumar los valores de COMPp de cada herramienta y
dividirlo entre el número de herramientas de Data Mining disponibles. En la ecuación (4.16)
se muestra la forma de calcular el valor final de COME
COMP = ROUND{^:¡^I^^^) (4.16)
siendo n el número de herramientas disponibles. En la tabla 4.32 se tienen los niveles corres
pondientes a este driver de coste.
• Compatibilidad entre herramientas de Data Mining (TCOM)
Aquí se refleja el tipo de compatibilidad que hay entre las diferentes herramientas de Data
Mining utilizadas en el proyecto. Se consideran dos tipos de compatibilidad: intercambia-
bilidad y compatiblilidad. Dos herramientas son compatibles si los modelos generados por
una de las herramientas se pueden convertir, mediante algún proceso, a un modelo que se
pueda utilizar en la otra herramienta, y son intercambiables si los modelos generados por
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PASA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4. SOLUCIÓN 87
Rango Extra bajo Muy bajo Bajo Nominal Alto Muy alto
Descripción 0 1 2 3 4 5
Valor 0 1 2 3 4 5
Tabla 4.32: Factor COMP
una herramienta se pueden utilizar directamente en la otra herramienta. Los descriptores,
rangos y valores de TCOM se encuentran en la tabla 4.33.
Rango Bajo Nominal Alto
Descripción Herramientas intercambiables Herramientas compatibles Herramientas no compatibles
Valor 2 3 4
Tabla 4.33: Factor TCOM
4.3.4.3. Herramientas vs. Máquina vs. Modelo de datos (TOMM)
Como no todos los modelos que se van a generar en el proyecto son soportados por todas las herra
mientas ni, todas las técnicas son soportadas de igual manera por las diferentes herramientas, hay
que tener en cuenta el esfuerzo añadido por los tener que generar determinados tipos de modelos
con determinadas herramientas en determinado tipo de máquina. En la tabla 4.34 se encuentra la
forma de seleccionar el rango y los valores de este driver de coste.
Rango Bajo
Nominal
Alto
Descripción Todas las herramientas pueden generar todos los modelos, y todas las herramientas se pueden ejecutar en todas las máquinas Hay máquinas y herramientas para todas los modelos pero no necesariamente todas las herramientas se pueden ejecutar con todos los modelos en todas la máquinas Sólo algunas máquinas pueden ejecutar las herramientas de Data Mining
Valor 2
3
4
Tabla 4.34: Factor TOMM
4.3.4.4. Nivel de transparencia de las herramientas (TRAN)
Este factor tiene en cuenta la posibilidad de modificación de las herramientas pudiendo hacer
modificaciones sobre el código de los algoritmos o añadiendo "plug-ins" sobre las mismas. Si se
requiere y se puede modificar el código de los algoritmos utilizados se requerirá más esfuerzo en
•MODELO MATEMÁTICO PAMMÉTRICO DE ESTIMACIÓN PARA PROYECTOS OEDATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 88
cuanto a programación de la nueva parte del algoritmo, pero, por otra parte se reducirá el esfuerzo
puesto que tendrán mejor rendimiento que los algoritmos originales puesto que han sido modifi
cados "ad hoc" para resolver el problema. En la tabla 4.35 se encuentran el rango, la descripción y
los valores para cada nivel del rango para el atributo TRAN para cada herramienta.
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción Se dispone del código fuente y de la documentación de los algoritmos que implementan una determinada técnica Se dispone del código fuente algoritmos que implementan una determinada técnica Se dispone de una API y de su documentación para hacer modificaciones a los algoritmos para poder adaptarlos a las necesidades del proyecto Se puede construir un "plug-in" para la herramienta y se dispone de la API de interconexión con la misma Solo se pueden utilizar los resultados producidos por la herramienta
Valor 1
2
3
4
5
Tabla 4.35: TRANp. Factor TRAN para cada herramienta
En la ecuación (4.17) se plantea la forma de calcular el valor de TRAN
TRAN = ROUND(^^I^:^^M (4.17)
Una vez obtenido el valor de TRAN se hace uso de la tabla 4.36 para obtener el nivel asociado.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.36: Factor TRAN
4.3.4.5. Nivel de formación de los usuarios que requieren las herramientas (NFOR)
El nivel de formación que requiere una determinada herramienta tiene que ver con el esfuerzo que
hay que realizar para desarrollar el proyecto, puesto que si se tiene que formar al equipo que la
va utilizar esto requiere un esfuerzo adicional. Por lo tanto requerirá un mayor esfuerzo, desde el
punto de vista de la formación, utilizar una herramienta que sólo pueda ser utilizada por expertos
que una herramienta que funcione a través de asistentes y agentes inteligentes que guíen al usuario
a través del proceso de generación de modelos. En la tabla 4.37 se describen los niveles del rango y
los valores asociados a cada nivel para el factor NFOR.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4. SOLUCIÓN 89
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción La herramienta utiliza asistentes y agentes inteligentes que guían al usuario a través del proceso de Data Mining. El usuario únicamente necesita un leve conocimiento de las técnicas de Data Mining Conocimiento de las técnicas de Data Mining. La herramienta funciona a través de asistentes Conocimiento ligero de las técnicas de Data Mining y de la herramienta Conocimiento de la técnicas de Data Mining y experto en la herramienta Experto tanto en técnicas de Data Mining como en la herramienta
Valor 1
2
3
4
5
Tabla 4.37: NFORp. Factor NFOR para cada herramienta
Donde el valor de NFOR se calcula aplicando la ecuación (4.18).
(4.18)
donde n es el número de herramientas. El valor a utilizar en la ecuación del esfuerzo se obtiene a
través de la tabla 4.38.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.38: Factor NFOR
4.3.4.6. Amigabilidad de las herramientas (TFRI)
Si la herramienta o herramientas que se van a utUizar para el proyecto tienen una buena interfaz de
usuario y se comunican bien con las bases de datos hace mas fácil el trabajo, con lo cual se reduce el
esfuerzo. Si la herramienta es complicada de usar y no es especialmente buena relacionándose con
las bases de datos, el trabajo se vuelve complicado, con lo que el esfuerzo aumenta. Para calcular el
valor de TFRI, primero hay que calcular el valor de TFRI para cada herramienta. Para ello se utiliza
la tabla 4.39.
Para calcular el valor de TFRI se hace uso de la ecuación (4.19) y de la tabla 4.40 para obtener el
valor correspondiente.
TFRI = TFRI [^^lIl^Ml^ (4.19)
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMAOÓN PAKA PROYECTOS DE DATA MINING ÍDMCOMOy
CAPÍTULO 4. SOLUCIÓN 90
Rango Bajo Nominal Alto Muy alto
Descrípción Compleja de usar Fácil de utilizar con un interfaz en modo línea de comandos Fácil de usar con un interfaz gráfico amigable Fácil e intuitiva, con un interfaz gráfico amigable que facilita las tareas de Data Mining
Valor 2 3 4 5
Tabla 4.39: TFRIp. Factor TFRI para cada herramienta
donde n es el número de herramientas. El valor obtenido de TFRI se utiliza junto con la tabla 4.40
para la obtención del nivel del driver TFRI.
Rango Bajo Nominal Alto Muy alto
Descrípción 2 3 4 5
Valor 2 3 4 5
Tabla 4.40: Factor TFRI
4.3.5. Drívers de Proyecto
Bajo este apartado se agrupan todos los factores relacionados con el número de departamentos
involucrados en el desarrollo del proyecto. De está manera se tiene que tener en cuenta que si
hay que generar los modelos para varios lugares o si hay varios departamentos involucrados en el
proyecto, implica un esfuerzo adicional, de la misma manera que influye en el esfuerzo el número
y el tipo de documentos a generar como parte de la documentación a entregar.
4.3.5.1. Número de departamentos involucrados en el proyecto (NDEP)
El factor NDEP tiene influencia en el esfuerzo total del proyecto porque cada departamento tiene
sus propios modelos de datos, sus propias políticas de nombrado, puede ser reacio a participeír en
un proyecto de Data Mining con lo cual hay que realizar un mayor esfuerzo. Por lo tanto parece
claro que a mayor número de departamentos involucrados en el proyecto de Data Mining, se re
quiere mayor esfuerzo. En la tabla 4.41 se presentan los rangos, los descriptores y los valores de
NDEP
4.3.5.2. Documentación a entregar (DOCU)
Este factor de escala refleja el esfuerzo empleado en producir la documentación que hay que de
sarrollar durante el proyecto de acuerdo a las exigencias del cliente y de la organización. Es obvio,
que desarrollar mucha documentación requiere un mayor esfuerzo, pero el esfuerzo en la docu-
• MODELO MATEMÁTICO PARÁMÉTKICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 4. SOLUCIÓN 91
Rango Bajo Nominal Alto Muy alto
Descripción Solo participa 1 departamento en el proyecto En el proyecto participan 2 departcimentos En el proyecto participan entre 3 y 5 departamentos Participan en el proyecto más de 5 departamentos
Valor 2 3 4 5
Tabla 4.41: Factor NDEP
mentación no solo tiene que ver con el volumen de documentación sino que también está influido
por la complejidad de la documentación a desarrollar. En la tabla 4.42 se encuentra el rango con la
descripción y el valor de cada nivel para el factor de coste DOCU..
Rango Bajo
Nominal Alto
Muy alto
Descripción Sólo se genera documentación para el modelo que se implanta finalmente Se genera documentación para todos los modelos generados Se genera documentación para todos los modelos y además se crea documentación para las fases centrales de Data Mining Se genera documentación para todos los modelos y además se crea documentación para cubrir todas las fases de Data Mining
Valor 2
3 4
5
Tabla 4.42: Factor DOCU
4.3.5.3. Modelos para múltiples entornos (MSIM)
Este factor tiene en cuenta si durante el desarrollo hay que desarroUcir modelos para múltiples en
tornos, como por ejemplo, modelos de clientes para varias ciudades. El desarrollo de modelos para
varios entornos implica hacer un mayor esfuerzo, puesto que hay que comprender la información
local y desarrollar el modelo para cada entorno. El rango, la descripción y el valor de cada nivel del
rango para MSIM se encuentran en la tabla 4.43.
Rango Bajo Nominíd
Alto
Descripción Desarrollo para 1 entorno local Desarrollo para 1 entorno involucrando el producto, hecho o departamento central de la empresa Desarrollo para varios entornos locales
Valor 2 3
4
Tabla 4.43: Factor MSIM
4.3.5.4. Desarrollo en múltiples localizaciones (SITE)
Puesto que un proyecto no tiene porque desarrollarse en el mismo lugar (edificio, ciudad, país,
etc.) hay que tener en cuenta el esfuerzo adicional que supone tener que comunicar diferentes
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MININCIDMCOMO)'
CAPÍTULO 4. SOLUCIÓN 92
equipos de desarrollo en diferentes localizaciones. También hay que tener en cuenta el tipo de
soporte de comunicaciones que se proporciona para la comunicación de las diferentes localiza
ciones (teléfono, RDSI, LAN, WAN,...), puesto que también influirá en el esfiíerzo requerido para
el proyecto. En la tabla 4.44 aparece la descripción y el valor para cada nivel del rango del factor
SITE.
Rango
Muy bajo
Bajo
Nominal
Alto
Muy alto
Extra alto
Descripción Ubicación En el mismo lugar
Mismo edificio o complejo
Misma ciudad o área metropolitana Varias ciudades y varias compañías Varias ciudades y varias compañías Internacional
Comunicaciones Comunicación multimedia interactiva Banda ancha de comunicaciones y ocasionalmente videoconferencia Banda ancha de comunicaciones Banda estrecha de comunicaciones, e-mail Teléfono, FAX
Teléfono, correo
Valor
1
2
3
4
5
6
Tabla 4.44: Factor SITE
4.3.6. Drivers de Personal
En el cálculo del esfuerzo hay que tener en cuenta el nivel de formación y cohesión de los in
tegrantes del equipo participante en el proyecto. Los perfiles de personal que participan en un
proyecto de Data Mining se pueden revisar en la sección 2.2.4.
4.3.6.1. Continuidad del personal (PCON)
Con este factor se quiere representar el esfuerzo de trabajar con personas diferentes en cada proyec
to. Si las personas que vein a participar en el proyecto se conocen y han trabajado previamente jun
tas en otros proyectos debería ser mucho más fácil la comunicación entre ellos porque ya conocen
la forma de de trabajo de cada uno, con lo cual el esfuerzo en este aspecto se reducirá. Por el con
trario si no se conoce la forma de trabajo de las personas participantes en el proyecto, hay que
añadir un esfuerzo adicional debido a esto. Este factor se mide en porcentaje de gente que per
manece durante un año en el equipo de la empresa. La descripción y los valores de los niveles de
este factor de coste se muestran en la tabla 4.45. La descripción de este driver de coste está extraída
del driver de coste PCON de COCOMO [BAB+00].
Las descripciones de la tabla anterior se leen como que el a; % de personal de la empresa y que
participa en proyectos de Data Mining se mantiene dureinte el año.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ¡DMCOMOf
CAPÍTULO 4. SOLUCIÓN 93
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 48%/año 24%/año 12%/año 6%/año 3%/año
Valor 1 2 3 4 5
Tabla 4.45: Factor PCON
4.3.6.2. Formación del personal en perfiles complementarios (PCOM)
Este driver tiene en cuenta cuantos participantes en el proyecto que desempeñan un determinado
rol tienen conocimientos suficientes para desempeñar un rol diferente en el mismo proyecto. En la
tabla 4.46 se tiene el rango de PCOM junto con la descripción y el valor de esfiíerzo para cada nivel
del rango.
Rango Bajo
Nominal Alto
Descripción Expertos con conocimientos complementarios. Estadísticos con formación en marketing y el personal no técnico tiene formación en técnicas de Data Mining Hay al menos un experto en cada área Gente reciclada de otras áreas. No han trabajado nunca con técnicas de Data Mining ni en proceso decisional
Valor 2
3 4
Tabla 4.46: Factor PCOM
4.3.6.3. Conocimiento de los datos que se van a utilizar (KDAT)
KDAT tiene en cuenta si los participantes en el proyecto conocen los datos que van a utilizar para el
proyecto y los han manejado con anterioridad. Si los datos son conocidos y han sido utilizados con
anterioridad el esfuerzo será menor que si se van a utilizar por primera vez y sin un conocimien
to previo de los datos. El rango de KDAT, la descripción y el valor de influencia en el esfuerzo se
encuentran en la tabla 4.47.
Rango Muy bajo
Bajo
Nominal
Alto
Descripción Hay colaboración de personal experto en los datos para ayudar al entendimiento de los mismos y colaboración de un experto en el negocio Hay colaboración de personal experto en los datos para ayudar al entendimiento de los mismos El equipo no está familiarizado con los datos y se suministra una descripción de los mismos que no tiene porque ser real No hay ni descripción de los datos ni modelo de datos
Valor 1
2
3
4
Tabla 4.47: Factor KDAT
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 4, SOLUCIÓN 94
4.3.6.4. Actitud de la dirección frente al proyecto (ADIR)
Uno de los principales problemas en los proyectos de Data Mining tiene que ver con la participa
ción y el apoyo de la dirección de la empresa o del departamento (perfil de "sponsor").
Así pues, este factor tiene en cuenta la facilidad que da la dirección de la empresa a los participantes
en el proyecto de Data Mining para utilizar datos, para moverse entre los diferentes sistemas de la
organización, etc. Si la organización facilita este trabajo, es decir, tiene una actitud buena de cara
al proyecto, el esfuerzo disminuirá, por el contrario si la dirección no tiene una buena actitud de
cara al proyecto, el esfuerzo aumentará. En la tabla 4.48 se plantean los niveles del rango de ADIR
así como la descripción y el valor de cada uno de los niveles de ADIR.
Rango Muy bajo
Bajo
Nominal
Alto
Descrípción La dirección del departamento y de la empresa apoyan positivamente el proyecto de Data Mining La dirección del departamento apoya el proyecto pero la de la no El director del departamento involucrado apoya el proyecto y la dirección no se opone al proyecto La dirección del departamento no apoya o está en contra de los procesos de Data Mining y la dirección de la empresa no apoya el proyecto
Valor I
2
3
4
Tabla 4.48: Factor ADIR
4.3.6.5. Experiencia en proyectos similares (PEXP)
La experiencia del personal en proyectos similares, reduce notablemente el esfuerzo total del proyec
to, puesto que ya se tiene conocimiento de la situación. En la tabla 4.49 se muestra el rango, la
descripción y los valores de este factor de coste.
Rango Muy bajo Bajo
Nominal
Alto
Descrípción Equipo consolidado de Data Mining (más de 4 proyectos) Los participantes han trabajado en más de 2 proyectos de Data Mining Los participantes han trabajado en varios proyecto de Data Mining (hasta 2) Nunca han trabajado en proyectos de Data Mining
Valor 1 2
3
4
Tabla 4.49: Factor PEXP
A pesar del tiempo que lleva Data Mining como línea de investigación y de la cantidad de proyectos
de CRM que se han desarrollado, sin embargo la experiencia demuestra que no se tienen equipos
consolidados de Data Mining.
' MODELO MATEMÁ TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 95
4.3.6.6. Familiaridad con el tipo de problema (MFAM)
El esfuerzo requerido para resolver un determinado problema está en relación con el nivel de
conocimiento que posee el personal que tiene que resolver en dicho problema. Si se trata de re
solver un problema con el que los participantes en el proyecto de Data Mining no están familia
rizados, su resolución implica un mayor esfuerzo que si los participantes se encuentran familiari
zados con el problema. El problema que se tiene que resolver con el proyecto de Data Mining se
puede descomponer en subproblemas y el personal participantes puede estar familiarizado con
un tipo de subproblemas, con todos o con ninguno. Así pues, el valor MFAM se calcula como com
binación del nivel de familiaridad con cada uno de los subproblemas que tengan los participantes
en el proyecto. En la tabla 4.50 se describen los rangos y los valores para el driver de coste MFAM
para cada subproblema.
Rango Muy bajo
Bajo
Nomined
Alto
Muy alto
Descripción Los participantes en el proyecto siempre trabajan con el tipo de problemas de Data Mining del proyecto actual y con datos similares Los participantes en el proyecto han trabajado en problemas de Data Mining como el actual y con datos similares Los participantes en el proyecto han trabajado en problemas de Data Mining pero no con los datos del proyecto real Los participantes en el proyecto han trabajado en problemas de Data Mining pero nunca en el entorno del proyecto actual Los participantes en el proyecto no han trabajado nunca con problemas de Data Mining
Valor 1
2
3
4
5
Tabla 4.50: MFAMp. Factor MFAM para cada modelo
La forma de calcular el valor de MFAM es la que aparece en la ecuación (4.20).
(4.20)
v ^ siendo n el número de subproblema en los que se descompone el problema global. Para calcular el
nivel correspondiente se hace uso de la tabla 4.51.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción 1 2 3 4 5
Valor 1 2 3 4 5
Tabla 4.51: Factor MFAM
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROTECTOS DE DATA MINING (DMCOMOX
CAPÍTULO 4. SOLUCIÓN 96
4.3.6.7. Experiencia con técnicas y herramientas (TEXP)
Si el personal participante en el proyecto ha trabajado con las técnicas y/o herramientas que se
van a utilizar, el esfuerzo será menor que si no lo ha hecho, puesto que en este caso debería con
sumir una parte del esfuerzo total del proyecto en conocer las técnicas y herramientas que se van
a utilizar. En la tabla 4.52 se muestra el rango, la descripción y los valores de este factor de coste.
Rango Bajo
Nominal
Alto
Descripción La mayoría de los miembros del equipo de desarrollo conocen la mayoría de las herramientas de Data Mining que se van a utilizar en el proyecto El equipo de desarrollo ha trabajado alguna vez con alguna herramienta de Data Mining La mayoría de los miembros del equipo de desarrollo no ha trabajado nunca con las herramientas de Data Mining
Valor 2
3
4
Tabla 4.52: Factor TEXP
4.3.6.8. Conocimiento del funcionamiento del negocio (BCON)
Hay que tener en cuenta que si los participantes en el proyecto son conocedores de la lógica del
negocio requerirá un menor esfuerzo poner en marcha el proyecto y comprender algunas de las
acciones que hay que tomar. En la tabla 4.53 se muestra el rango, la descripción y los valores de
este factor de coste.
Rango Bajo
Nominal
Alto
Descripción Hay personas con conocimiento del negocio involucradas en el proyecto o los analistas conocen el negocio No hay gente que tenga conocimiento del negocio o alguien tiene una leve idea del negocio, pero hay documentación sobre el funcionamiento del negocio o hay expertos en el negocio dispuestos a colaborar No hay no conocimiento del negocio por parte de ninguno de los miembros del equipo de desarrollo, ni documentación sobre el negocio, ni hay un experto disponible o que quiera colaborar en el proyecto
Valor 2
3
4
Tabla 4.53: Factor BCON
4.4. Planteamiento de la ecuación del modelo DMCOMO
El siguiente paso a realizar una vez que se tienen los drivers es plantear la ecuación. Para ello se
ha de recabar información de proyectos reales para poder establecer una predicción. El análisis de
•MODELO MATEMÁTICO PARAMÉTÜICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMO)'
CAPÍTULO 4. SOLUCIÓN 97
los datos de los proyectos reales se encuentra en al sección 4.4.1. Para la obtención de la ecuación
de estimación del esfuerzo para el modelo DMCOMO se utilizará un método de regresión lineal
multivariante [GHJ93, Wei85], puesto que ésta es la forma más usual de obtener la ecuación del
esfuerzo en los métodos estimación paramétricos [BoeSl, Ham02b, Ham02a].
Así pues, si se utilizan las técnicas de regresión lineal se obtendrá una ecuación lineal, cuya forma
genérica es: n
2/ = ao + ^ aiXi + e (4.21)
donde y es la variable dependiente, Xi es la variable independiente i-ésima, n es el número de varia
bles independientes, Oi son constantes y e¿ es el error cometido en la estimación í-ésima (también
llamado residuo).
En el apéndice B se explican en detalle los métodos de regresión lineal, y se plantean las condi
ciones para que el modelo obtenido como resultado de la regresión sea útil. Estas restricciones
son:
• El conjunto de datos es lo suficientemente grande.
• No hay valores "nulos".
• No hay valores extraños {"outliers").
Q Las variables predictoras no tienen correlación entre ellas (factor de correlación menor a 0,5).
Cuando se trabaja en el campo de la estimación de proyectos software, las restricciones anteriores
sobre las regresiones se suelen relajar tal y como se establece en [BBT92]. Por lo tanto para la cons
trucción de las ecuaciones de los métodos de estimación paramétricos, mediante regresión, no es
necesario que se cumplan todas las restricciones anteriores. La restricción más difícil de cumplir
es la obtención de un gran número de datos, puesto que se trata de un proceso continuo. Dentro
de este proceso, primero se recoge un conjunto pequeño de datos sobre unos drivers de coste y
sobre una veiriable dependiente (suele ser el esfuerzo), se construye la ecuación con ese conjunto
de datos mediante regresión lineal y se siguen recogiendo datos para ir refinando la ecuación con
el nuevo conjunto de datos, y así sucesivamente.
Para calcular el número de datos (proyectos) necesario se aplica la regla del pulgar [DC99] que dice
que para cada parámetro a calibrar se debería tener al menos datos de 5 proyectos. En el caso de
COCOMO II el número de proyectos necesario aplicando la regla anterior sería de 115 ya que se
tienen 23 parámetros de entrada (drivers y factores de escala). No obstante, es importante resaltar
que para el establecimiento de la ecuación sólo se utilizeiron 83 proyectos después de 16 años de
•MODELO MATEMÁTICO PAfíAMÍTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO/
CAPÍTULO 4. SOLUCIÓN 98
Utilización, desde la aparición de su predecesor COCOMO. En el caso del presente trabajo de tesis
se dispone de datos de 40 proyectos. En las secciones 4.4.2.1,4.4.2.2,4.4.2.3 se analizan estas condi
ciones sobre los datos disponibles en este trabajo para el planteamiento de la ecuación.
Cuando se ha comprobado que los datos cumplen las condiciones necesarias se está en disposi
ción de calcular la ecuación.
Pcira llegar a obtener la ecuación de una regresión lineal hay que seguir una serie de pasos [Wei85]:
Paso 1: Estudio descriptivo de los datos de entrada. Se calcularan el número de observaciones, la
media, los valores máximo y mínimo y la desviación típica de cada una de las variables
con el objetivo de ver si las variables no tienen valores nulos y el rango de las variables es
el correcto. En el caso de encontrar valores se puede eliminar la observación o rellenar el
valor nulo con alguno de los métodos vistos en la sección 2.2.1.
Paso 2: Estudio de valores fuera de rango o "outliers" presentes en los datos. Se construirán diagra
mas de tallo y hoja (stem-and-leaf) o los histogramas para observar si hay valores extraños
en alguna de las variables. En caso de encontrar valores extraños hay que tomar una de
cisión, eliminar la observación o convertir el valor a un valor dentro de los valores normales
de las variables.
Paso 3: Estudio de correlación de las vciriables de entrada. Se construirá la matriz de correlación
(mayor que 0,5), para ver el grado de correlación que tiene cada variable con el resto de
variables presentes. Si hay variables con un alto grado de correlación respecto a otras va
riables, estás variables no se deberían utilizar para construir la ecuación de la regresión.
Paso 4: Aplicar la regresión lineal para obtener la ecuación. Se construirá las regresión lineal uti
lizando las variables que no se encuentren correladas.
Paso 5: Estudiar estadísticamente si la regresión obtenida es significativa. Para ello es posible ha
cer uso del análisis de varianzas (ANOVA) y de las gráficas de los residuos u errores cometi
dos por la regresión para comprobar que siguen una distribución normal.
Para la realización de los pasos anteriores se utilizará la herramienta estadística SPSS de SPPS Inc.®
4.4.1. Descripción de los datos de entrada
Los datos que se han utilizado en este trabajo provienen de proyectos de Data Mining realizados
por el grupo de Bases de Datos de la Facultad de Informática de la Universidad Politécnica (Madrid,
España), por la Universidad del Valle (Cali, Colombia), por la Universidad de Stony Brook (Nueva
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 99
York, U.S.A.) y por el Naval Research Laboratory (Monterrey, U.S.A.) en colaboración con diferentes
empresas involucradas en el desarrollo de proyectos de Data Mining.
Para la recogida de los datos se hizo uso de un formulario como el de la tabla 4.54 para conocer el
valor que cada jefe de proyecto daba a los drivers propuestos. Este formulario junto con la descrip
ción de los drivers de coste propuestos en la sección 4.3 se distribuyeron entre los jefes de proyecto
de los diferentes proyecto.
Driver NTAB NTUP NATR DISP PNUL CCOD DMOD PRIV DEXT NMOD Duración (meses) Personas
Valor Driver TMOD MTUP MATR MDIS MDER MTEC NFUN NSER SCOM TOOL
Valor Driver NTEC COMPJ TCOM TOMM TRAN NFOR TFRI NDEP DOCU MSIM
Valor Driver SITE PCON KDAT ADIR PEXP MFAM TEXP BCON
Valor
Tabla 4.54: Formulario de recogida de datos
Observando la descripción de los drivers cada jefe de proyecto rellenéirá un formulcirio por proyec
to indicando para cada driver su valor: Extra bajo (XB), Muy Bajo (MB), Bajo (B), Nominal (N), Alto
(A), Muy Alto (MA) o Extra alto (XA). Así mismo como se trata de proyectos ya terminados el jefe de
proyecto indicará la duración del proyecto y el número de personas que estuvo involucrado en el
desarrollo del mismo.
Como el resultado que se quiere obtener es el esfuerzo y este no se recoge directamente con los for
mularios hay que calcularlo como el producto de la duración en meses por el número de personas
participantes.
Esfuerzo{MM) = Duracion{meses) x Personas (4.22)
Toda esta información se recogió para 40 proyectos (la información detallada aparece en el apéndice
C en la figura C.l). Posteriormente, y de cara a trabajar con valores cuantitativos, los valores de
los rangos (XB, MB, B, N, A, MA, XA) se sustituyeron por los valores numéricos correspondientes
preservando el orden intrínseco a los mismos.
Los valores que se asociaron a cada valor de los rangos de los drivers de coste se muestran en la
tabla 4.55. Estos valores se podrían sustituir por otros sin que ello afectara a la forma de hacer el
estudio de los datos, ni a la forma de plantear la ecuación de la regresión lineal. El cambio de va-
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PABA PROYECTOS DE DATA MININCÍDMCOMOy
CAPITULO 4. SOLUCIÓN 100
Nivel del rango Extrabajo Muy bajo Bajo Nominal Alto Muy alto Extra alto
Etiqueta asociada XB MB B N A
MA XA
Valor 0 1 2 3 4 5 6
Tabla 4.55: Niveles y valores de los drivers
lores tampoco afectará al cálculo del esfuerzo si se utilizan los mismos valores para el cálculo de la
ecuación y posteriormente en el cálculo del esfuerzo para un nuevo proyecto. El único efecto que
tienen el cambiar los valores asociados a los rangos es en los coeficientes (a¿) de la regresión que
serán diferentes porque se están utilizando diferentes puntos para crear la ecuación de regresión.
Una vez recogidos los datos hay que analizarlos para ver si los valores de cada driver están es su
rango correspondiente, si no hay valores nulos en alguno de los drivers y su distribución es ade
cuada.
4.4.2. Obtención de la ecuación de regresión
A continuación se muestra el proceso seguido para llegar a obtener la primera ecuación de regre
sión.
4.4.2.1. Paso 1: Descripción estadística de los datos
El primer paso a realizar antes de establecer la ecuación de regresión es la descripción estadísti
ca de los datos que se utilizarán para la creación de la ecuación de la regresión lineal. El resulta
do de este estudio incluye el número de observaciones, la media, el valor máximo y mínimo y la
desviación típica de cada una de las variables con el objetivo de ver si las variables no tienen val
ores nulos y si los rangos de las variables son los correcto.
En la ñgura 4.2 se puede ver que todas las variables tienen 40 observaciones, una observación por
proyecto. En cuanto a los valores máximo y mínimo sirven para comprobar si todos los valores
están dentro de los rangos asociados al driver de coste y si toman todos los posibles valores del
rango. Se puede comprobar observando las tablas de los drivers de coste que se muestran en la
sección 4.3 que todos los drivers toman valores en sus rangos, pero hay drivers que no toman todos
los valores posibles, por ejemplo el driver DMOD está definido entre O y 5 y solo toma valores entre
1 y 5. Esto se debe a que en los proyectos recogidos la característica DMOD no toma nimca el valor
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 4. SOLUCIÓN 101
Extra Bajo (XB). Esto mismo ocurre para las variables PRIV, MDIS, MTEC, NFUN, NSER, SCOM,
TFRI, NDEIÍ PCON, KDAT y ADIR.
Estadísticos descriptivos
NTAB NTUP NATR DISP PNUL CCOD DMOD PRIV DEXT NMOD TMOD MTUP MATR MDIS MDER MTEC NFUN NSER SCOM TOOL NTEC COMP TCOM TOMM TRAN NFOR TFRI NDEP DOCU MSIM SITE PCON PCOM KDAT ADIR PEXP MFAM TEXP BCON MM N válido (según lista)
N 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40
40
Mínimo 0 1 1 1 1 1 1 2 2 2 1 1 1 2 1 1 1 1 1 1 1 1 2 2 1 1 2 2 2 2 1 2 2 1 1 1 1 2 2
90
Máximo 6 5 5 5 5 6 5 4 5 5 5 5 5 5 5 5 4 4 4 5 4 5 4 4 5 5 5 4 5 4 6 5 4 3 3 4 5 4 4
184
Media 3,08 3,13 2,85 2,65 3,43 3,00 2,90 3,15 3,55 2,75 3.10 2,88 2,63 2,98 2,63 3,45 2,53 2,53 2,40 3,08 2,33 3,30 3,08 3,08 3,08 2,90 3,03 2,78 3,35 3,10 3,40 3,05 3,10 2,22 1,85 3,02 3,28 2,90 2,95
121,48
1
Desv tlD. 1,992 1,539 1,312 1,511 1,517 1,502 1,464 ,921
1,339 ,927
1,257 1,436 1,334 1,187 1,334 1,484 1,037 1,012 1,033 1,492 ,829
1,454 ,917 ,917
1,385 1,336 1,187 ,832
1,167 ,928
1,630 ,904 ,928 ,800 ,736 ,920
1,502 ,928 ,815
21,147
Figura 4.2: Descripción estadística de los datos
También se muestran en la figura 4.2 los valores correspondientes a la media y a la desviación
típica de los drivers de coste propuestos. Cabe destacar que si no se realizará la regresión el error
•MODELO MATEMÁTICO PARAMtrRICODBESTIMACIÓN PARA PROYECTOS DE DATA MININO (DMCOMOr
CAPÍTULO 4. SOLUCIÓN 102
cometido en el esfuerzo, si para un nuevo proyecto se toma el valor de la media de MM (121,48),
sería de ±21,147 hombres x mes.
4.4.2.2. Paso 2: Valores fuera de rango o "outliers"
Para la realización del estudio "outliers" presentes en los datos se utilizan los histogrcunas de cada
uno de los drivers de coste propuestos (ver anexo C). En esos histogramas se puede ver la distribu
ción de cada driver de coste para cada valor de los mismos.
Para la detección de outliers existen numerosos métodos [Pyl99]. No obstante en este trabajo se
considera por outlier un valor cuya frecuencia de apeirición es muy baja con respecto al resto de
valores. Esto ocurre por ejemplo en el histograma correspondiente a NMOD donde el valor cinco
solo ocurre una vez. Por lo tanto este valor, el 5, se podría consideran como un outlier. Lo mismo
ocurre para los drivers de coste NTEC, PCON y PEXP
Para no provocar errores en la ecuación final, los outliers deberían ser eliminados, eliminando la
observación completa para esos casos o cambiado por el valor más cercano a ellos que no sea un
outlier. En el caso del presente trabajo, como los valores provienen de datos recogidos para el ex
perimento y el número de observaciones es pequeño (40) se ha decidido dejar estos valores.
Por otra parte, es importante recordar que algunos de los drivers propuestos se han definido no
toman todos los posibles valores definidos para los niveles (Extra Bajo, Muy Bajo, Bajo, Nominal,
Alto, Muy Alto, Extra Alto). Este es el caso de los drivers PRiy TCOM, TOMM, NDEP, MSIM, PCOM,
KDAT, ADIR, TEXP, BCON. Como consecuencia, al establecer los histogramas (ver apéndice C) exis
ten drivers (los mencionados con anterioridad) para los cuales hay valores que no aparecen en los
rangos (1,5; 2,5; 3,5). Estos valores no tienen ninguna ocurrencia, y no hay que tenerlos en con
sideración pues se deben a que los histogramas se encuentran definidos sobre un mínimo de 5
clases.
4.4.2.3. Paso 3: Estudio de correlación
El siguiente paso en la construcción de la ecuación del esfuerzo es realizar el estudio de correlación
entre los drivers planteados y acerca de los cuales se tienen datos.
En el apéndice C (figura C.2) se muestra la matriz de correlación para los drivers de coste pro
puestos en función de los valores que toman para los 40 proyectos que se están utilizando para
el cálculo de la ecuación del esfuerzo. En esta matriz de correlación aparecen marcados aquellos
valores mayores a 0,5 en valor absoluto, puesto que se considera que dos variables de entrada o
drivers tienen correlación si el factor de correlación entre ellas es superior a 0,5. Esta matriz es una
matriz simétrica puesto que la correlación entre variables es recíproca, si la variable xl tiene un
• MODELO MATEMA TICO PARAMÉTBICO DE ESTIMACIÓN PAHA PROYECTOS DE DATA MINING (DMCOMOÍ'
CAPÍTULO 4. SOLUCIÓN 103
factor de correlación z con la variable x2, la variable x2 tendrá un factor de correlación z con la
variable xl, y la diagonal de la matriz es igual a 1, puesto que una variable está siempre correlada
consigo misma con el factor 1. En la tabla 4.56 se resume la matriz de correlación del apéndice C
(figura C.2) mostrando sólo aquellos drivers que tienen correlación con otros drivers, así como el
valor del factor de correlación.
Atributo CCOD PRIV MDIS MDER NSER NTEC TCOM TOMM TRAN TFRI MSIM PCON PCOM PEXP TEXP BCON
Correlado con DMOD DEXT DISP MATR NFUN TOOL TOOL*, TOMM, TRAN TOOL*, TCOM, TRAN TOOL*, TCOM, TOMM NFOR PCOM, PEXP MFAM*, TEXP BCON MSIM, PEXP, MFAM*, TEXP MSIM, PCOM, MFAM*, TEXP MSIM, PCOM, PEXP MFAM*, BCON PCON*, TEXP
Valor 0,968 0,971 0,967 0,553 0,805 0,628 0,952* 0,952* 0,978* 0,972 0,955* 0,838 0,955* 0,886* 0,738* 0,838
* Factor de correlación respecto al driver marcado con +
Tabla 4.56: Resumen de la correlación de atributos
Una vez realizado el estudio de correlación se eliminarán de cada par de atributos con una corre
lación alta (mayor a 0,5) uno de ellos, eliminando siempre el que menos importancia tenga en el
estudio que se está realizando.
Para eliminar uno de los atributos hay dos posibilidades, la eliminación directa de uno de los atri
butos o la integración de ambos atributos en uno solo. En el caso del presente trabajo se optó por la
eliminación de aquellos atributos correlados de menor importancia o que pudieran estar incluidos
dentro de otros. En concreto no se tuvieron en consideración los siguientes drivers de coste:
• CCOD (Criterios de codificación de valores) se encuentra correlado con DMOD (Disponibili
dad modelos de datos). Esta correlación puede ser debida en parte a que en los modelos de
datos se pueda encontrar criterios de codificación para los atributos. Se decide la eliminación
de CCOD puesto que se puede suponer integrado en DMOD.
• PRIV (Privacidad de los datos) se encuentra correlado con DEXT (Necesidad de datos exter
nos). Se debe a los valores que toman los datos para los 40 proyectos utilizados. Se elimina
PRIV puesto que es menos importante que DEXT. La adquisición de datos externos lleva con-
• MODELO \aTEMA TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOX
CAPÍTULO 4. SOLUCIÓN 104
sigo un proceso de integración de los datos externos con los datos propios de la organización.
• MDIS (Dispersión de los atributos para cada modelo) está correlado con DISP (Dispersión).
Ambos drivers hacen referencia al número de valores distintos que pueden tomar los atribu
tos, y como el número de valores que toman los atributos no cambia parece que la correlación
tiene sentido. Se decide eliminar la variable MDIS puesto que se refiere únicamente a mode
los mientras que DISP se refiere a la dispersión de todo el conjunto de atributos.
• MDER (Datos derivados) correlado con MATR (Número y tipo de atributos para cada mode
lo). Esta correlación se debe a los valores que toman los drivers para los proyectos utilizados.
Se decide eliminar MDER por ser menos importante que MATR.
• NSER (Número de servidores) y NFUN (Número y tipo de fuentes). Estos dos factores se en
cuentran correlados puesto que normalmente el número de servidores se corresponde con el
número de fuentes. El factor eliminado es NSER puesto que es más importante el número de
fuentes que el número de servidores.
• NTEC (Número de técnicas soportadas), TCOM (Compatibilidad entre herramientas), TOMM
(Herramientas vs. Máquina vs. Modelo) yTRAN (Nivel de transparencia) están correlados con
TOOL (Disponibilidad de herramientas). Está correlación se debe en parte a que los valores
asociados a los drivers de coste NTEC, TCOM, TOMM y TRAN toman valores que dependen
de la utilización de herramientas de Data Mining para el desarrollo del proyecto. Por esto el
driver TOOL se considera el más importante eliminando el resto.
• TFRI (Amigabilidad de la herramienta) con NFOR (Nivel de formación de los usuarios). Esta
correlación se debe a los valores de los datos. Como el nivel de formación de los usuarios es
más importante en cuanto al calculo del esfuerzo que la amigabilidad de la herramienta.
• MSIM (Modelos para múltiples localizaciones), PCOM (Formación del personal en perfiles
complementarios), PEXP (Experiencia en proyectos similares) y TEXP (Experiencia con técni
cas y herramientas) se encuentran correlados con MFAM (Familiaridad con el tipo de proble
ma). La correlación de MSIM es debida a los valores de los datos de los proyectos. El resto de
drivers PCOM, PEXP y TEXP tienen relación con la familiaridad del equipo de Data Mining
con lo problemas y herramientas de Data Mining que se traten en el proyecto. Se considera el
driver MFAM como el más importante puesto que el resto se pueden obtener de este driver,
elimiando el resto de drivers.
• PCON (Continuidad del personal) se córrela con BCON (Conocimiento del negocio). Como
PCON se ha eliminado este driver se elimina por tener correlación con un factor eliminado.
•MODEin MATEMÁTICO PARAMÉimCO DE ESTIMACIÓN PARA PROYECmS DE DATA MtmNGÍDMCOMOf
CAPÍTULO 4. SOLUCIÓN 105
• BCON (Conocimiento del negocio) correlado con TEXP (Experiencia con técnicas y herra
mientas). Como TEXP se ha eliminado este factor se elimina por tener correlación con un
driver eliminado.
El resultado del estudio de correlación fue que se eliminaron del conjunto de drivers 16 drivers, con
lo que para la construcción de la ecuación del esfuerzo para DMCOMO se utilizaron únicamente
los 23 drivers de coste que se muestran en la tabla 4.57.
Nombre Número de tablas Número de tupias Número de atributos Dispersión Porcentaje de nulos Disponibilidad modelos de datos Necesidad de datos externos Número de modelos Tipo de modelo Número de tupias para cada modelo Número y tipo de atributos para cada modelo Disponibilidad de técnicas Número y tipo de fuentes Distancia y forma de comunicación Disponibilidad de herramientas Compatibihdad Nivel de formación de los usuarios Número de departamentos involucrados Documentación a desarrollar Desarrollo en múltiples localizaciones Conocimiento de los datos Actitud de la dirección Familiaridad con el tipo de problema
Abrev. NTAB NTUP NATR DISP PNUL DMOD DEXT
NMOD TMOD MTUP MATR MTEC NFUN SCOM TOOL COMP NFOR NDEP DOCU SITE KDAT ADIR MFAM
Tabla 4.57: Drivers finales de coste del modelo
En este momento ya se puede aplicar regresión lineal sobre los drivers de coste puesto que si se
utilizan lo que aparecen en la tabla 4.57 no hay ninguno correlado. En el siguiente apartado se
plantea la regresión lineal.
4.4.2.4. Paso 4: Ecuación del modelo mediante regresión lineal
Una vez analizados los datos y eliminada la correlación del conjunto de variables de entrada se
está en disposición de aplicar la regresión para el cálculo de la ecuación del esfuerzo del modelo
DMCOMO.
La única restricción que se viola para la obtención de una regresión significativa es la cantidad de
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PAItA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULO 4. SOLUCIÓN 106
datos a partir de los cuales se crea la regresión. Según la regla del pulgar [DC99] que dice que para
cada parámetro a calibrar se debería tener al menos 5 datos, el número de proyectos necesarios
sería de 23 x 5 = 115 proyectos y sólo se dispone de 40, pero según se demuestra en [BBT92] se
puede aplicar la regresión con garantías aun cuando el numero de proyectos no es el suficiente.
Personalizando la ecuación de la regresión lineal para el caso del modelo que se pretende construir
n
2/ = ao + ^ üiXi + e¿ (4.23)
la variable independiente (y) se corresponde con el valor a estimar, es decir con el esfuerzo total del
proyecto medido en hombres x mes (MM), las variables independientes (Xi) se corresponden con
los diferentes drivers de la tabla 4.57, las constantes a^ son los valores desconocidos que hay que
determinar mediante la regresión lineal, y n se corresponde con el número de drivers, en el caso de
DMCOMO son serían 23, los que aparecen en la tabla 4.57.
Coeficientes
Modelo 1 (Constante)
NTAB NTUP NATR DISP PNUL DMOD DEXT NMOD TMOD MTUP MATR MTEC NFUN SCOM TOOL COMP NFOR NDEP DOCU SITE KDAT ADIR MFAM
Coeficientes no estandarizados
B 78,752 2,802 1,953 2,115 6,426 ,345
-2,656 2,586 -,456 6,032 4,312 4,966
-2,591 3,943 ,896
-4,615 -1,831 -4,698 2,931 -,892 2,135 -,214
-3,756 -4,543
Error típ.
37,415 1,654 2,108 2,558 2,096 2,204 2,613 2,853 3,654 2,727 2,312 2,930 2,063 3,723 3,521 2,479 3,100 2,186 4,230 2,783 2,112 4,258 5,110 2,562
Coeficientes estandarizados
Beta
,264 ,142 ,131 ,459 ,025
-,184 ,164
-,020 ,358 ,293 ,313
-,182 ,193 ,044
-,326 -,126 -,297 ,115
-,049 ,165
-,008 -,131 -,323
t 2,105 1,695 ,927 ,827
3,065 ,157
-1,017 ,906
-,125 2,212 1,865 1,695
-1,256 1,059 ,254
-1,861 -,591
-2,149 ,693
-.321 1,011 -,050 -,735
-1,773
Sig. ,051 ,109 ,368 ,421 ,007 ,877 ,324 ,378 ,902 ,042 ,081 ,109 ,227 ,305 ,802 ,081 ,563 ,047 ,498 ,753 ,327 ,961 ,473 ,095
Figura 4.3: Resultados de la regresión lineal
Para el cálculo de la ecuación de regresión el conjunto de datos es el que se muestra en la ñgura
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING IDMCOMOX
CAPÍTULO 4. SOLUCIÓN 107
C.3 donde ya se han eliminado aquellos drivers con un alto nivel de correlación, se han sustituido
las etiquetas por sus valores correspondientes (XB=0, MB=l, B=2, N=3, A=4, MA=5, XA=6). Como
resultado de la regresión lineal se obtienen los valores de las constantes Oj que se muestran en la
figura 4.3.
Cada valor de la columna B de la figura 4.3 se corresponde con un a¿ de la ecuación, siendo el va
lor nombrado como constant el correspondiente a la constante OQ y el resto de valores identificados
con los nombres de los drivers de coste, son los correspondientes a los valores a¿ asociados al driver.
Por lo tanto, la ecuación del esfuerzo {E{p)) del modelo DMCOMO, construida a partir de de un
conjunto de proyectos (figura C.3) es la que se muestra en la ecuación (4.24).
E(p)= 78,752 + 2,802 x NTAB + 1,953 x NTUP + 2,115 x NATR + 6,426 x DISP-I-
+0,345 X PNUL + (-2,656) x DMOD + 2,586 x DEXT + (-0,456) x NMOD+
+6,032 X TMOD + 4,312 x MTUP + 4,966 x MATR + (-2,591) x MTEC-h
+3,943 X NFUN + 0,896 x SCOM + (-4,615) x TOOL + (-1,831) x COMP+
+(-4,689) X NFOR + 2,931 x NDEP + (-0,892) x DOCU + 2,135 x SITE+
+(-0,214) X KDAT + (-3,756) x ADIR + (-4,543) x MFAM (4.24)
A continuación se debe realizar un estudio de la significación que tiene la ecuación desde el punto
de vista estadístico.
4.4.2.5. Paso 5: Estudio de la significación de la ecuación
Después de obtener la ecuación del modelo hay que ver si esta es significativa desde el punto de
vista estadístico. Para ello se utiliza el análisis de varianza (ANOVA) y el análisis de residuos de la
regresión lineal.
Resumen del modelo
Modelo 1
R ,893
R cuadrado ,798
R cuadrado corregida
,507
Error típ. de la estimación
14,846
Figura 4.4: Resumen del modelo de la figura 4.3
En la 4.4 se muestra un resumen de las características de la regresión donde se puede ver que la
regresión creada es capaz de predecir el 80 % (columna Rcuadrado] de los valores de entrada del
conjunto de prueba. El error típico de la estimación es de 14,846 (columna Error típ. de la esti-
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECmS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 108
moción) siendo menor que el obtenido para el esfuerzo (variable MM) en la descripción de los
datos (figura 4.2) que es de 21,147. Por lo tanto, el error cometido con la regresión es menor que si
se utiliza la media de los esfuerzos (figura 4.2) como valor del esfuerzo para nuevos proyectos.
Los resultados del Análisis de Varianza (ANOVA) se muestran en la figura 4.5.
Modelo 1 Regresión
Residual Total
Suma de cuadrados
13913,477 3526,498
17439,975
ANOVA
gi 23 16 39
Media cuadrática
604,934 220,406
F 2,745
Sig. ,02la
Figura 4.5: Análisis de varianza (ANOVA) del modelo de la figura 4.3
Del resultado de ANOVA se concluye que, como el estadístico p - valué es menor que 0,05, hay
relación estadística significativa entre los drivers de coste y la variable a estimar (el esfuerzo) con
un nivel de confianza del 95 %, por lo tanto la regresión se puede considerar aceptable desde el
punto de vista estadístico.
Adicionalmente, hay que tener en cuenta la importancia relativa de cada driver de coste en la
ecuación, para ello se utiliza la columna sig de la figura 4.3. El análisis de este estadístico indica
que hay algunos drivers que no son significativos en la ecuación, aquellos con un valor alto del
estadístico sig. Estos drivers son:
• PNUL
• NMOD
• SCOM
- DOCU
• KDAT
y por lo tanto no tendrán grein influencia en la estimación del esfuerzo. Esto puede ser debido al
reducido número de datos de proyectos de los que se dispone.
Por último, hay que analizar si los residuos o errores cometidos por la regresión lineal siguen una
distribución normal [Wei85]. En el histograma se observa también la curva normal observando
que la distribución de los residuos sigue una distribución normal, y los puntos representados en el
gráfico P-P deben estar próximos a la diagonal.
' MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ¡DMCOMOf
CAPÍTULO 4. SOLUCIÓN 109
Tal y como se observa en la figura 4.6 los residuos siguen una distribución normal con lo que se
puede afirmar que la regresión es aceptable.
Histograma
Variable dependiente: iVIH/l
Gráfico P-P normal de regresión Residuo tipificado
Variable dependiente: MM
Li- O
Std. Dev = ,64
Mean = 0,00
N =40,00
' > ' % ~-" Vj> ' cs- "ís- V ^ - í ^ - r , -TJ
Regresión Residuo tipificado
0,0 ,3 ,5
Prob acum observada
Figura 4.6: Análisis de los residuos
Todo el análisis realizado permite establecer que la ecuación presentada se puede utilizar con un
error aceptable para la estimación del esfuerzo de un proyecto de Data Mining.
Id. NTAB NTUP NATR DISP PNUL DMOD DEXT NMOD TMOD MTUP MATR MTEC NFUN SCOM TOOL COMP NFOR NDEP DOCU SITE KDAT ADIR MFAM MM
1 3 2 5 5 1 1 1 4 2 5 4 5 1 6 4 4 4 1 2 3 2 2 1
117
2 1 1 3 5 1 6 3 2 2 2 2 2 2 3 3 5 2 1 1 2 2 1 4
93
3 5 1 1 5 4 2 2 1 5 1 4 6 1 4 1 5 5 4 1 3 3 3 3
162
4 3 2 2 4 2 3 3 3 1 3 5 3 3 4 1 1 3 4 3 3 3 3 4
167
5
0 2 2 4
3 5 1 2 5 2 2 4 1 0 5 5 3 1 1
6 1 3 2
105
6 2 5 1 4 1 1 4 3 3 1 4 2 1 3 2 5 1 4 2 2 2 2 2
168
7
0 1 3 3 3 1 4 3 3 3 2 4 2 5 5 6 3 3 2 9
1 5
108
8 5 3 2 3 3 3 3 4 1 3 5 3 3 3 3 6 3 3 3 4 1 3 4
131
9 5 3 5 2 1 6 1 2 4 5 5 2 2 3 3 3 5 2 2 1 3 1 3
123
10 1 3 4 2 5 4 4 4 4 5 3 3 3 6 1 6 3 3 3 5 2 1 5
121
11
0 4 1 2 4
3 1
3 5 3 2 5 3 1 1 2 5 1 3 2 3 3 4
87
12 5 4 1 2 3 4 2 3 4 2 2 3 1 4 4 3 3 4 3 2 3 2 4
127
13
1 2 i
2 3 3 1 2 2 1 1 6 4 4 2 4 3
3 2 5 2 2 4
113
14
5 1 2 1 1
3 1 3 2 5 2 6 3 0
1 6 4 2 3 5 1 2 3
118
15 2 2 2 1 4 1 3 3 4 3 4 2 4 6 1 5 4 1 1 6 1 1 5
154
Figura 4.7: Conjunto de proyectos de prueba
•MODELO MATEMÁTICO PAMMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
CAPÍTULO 4. SOLUCIÓN 110
4.5. Validación de la ecuación del modelo DMCOMO
Una vez establecido el modelo DMCOMO (ver apéndice D) es necesario comprobar como se com
porta ante nuevos proyectos, no utilizados para crear la regresión lineal. Para ello se han recogi
do datos a cerca de 15 proyectos, utilizando el procedimiento explicado en la sección 4.4.1 y se
aplicó la ecuación obtenida mediante la regresión lineal (ecuación 4.24) para calcular el esfuer
zo de esos proyectos. La figura 4.7 muestra los datos suministrados por los responsables de los 15
proyectos para los drivers de coste finalmente establecidos.
Aplicando la ecuación propuesta sobre los nuevos datos se obtuvieron los resultados de la ñgura
4.8. En estos datos Id. representa el identificador del proyecto, MM es el valor real del esfuerzo y
%E - MM es el valor del esfuerzo estimado mediante la ecuación propuesta.
Id. MM $E-MM
1 117
132,56
2 93
100,80
3 162
130,50
4 167
136,38
5 105
92,27
6 168
146,43
7 108
93,09
8 131
117,75
9 123
129,40
10 121
138,56
11 87
91,63
12 127
101,14
13 113
87,59
14 118
96,92
15 154
132,53
Figura 4.8: Valores del esfuerzo estimados
Comparando los valores reales [MM) con los valores estimados [%E - MM) se pueden obtener los
resultados de la tabla 4.58 y las gráfica de las figuras 4.9,4.10 que se muestran a continuación.
Error mínimo Error máximo Error medio Error medio absoluto Desviación típica Ocurrencias
-17,559 31,498 11,097 18,025 16.908
15
Tabla 4.58: Resultados de la estimación sobre el conjunto de prueba
En la tabla 4.58 se observan los errores máximo, mínimo y medio cometidos por el modelo en
relación a los valores reales, así como la desviación típica. La desviación típica indica que el error
a considerar en una estiamción es de ±16,908 hombres x mes. En la figura 4.9 se representan los
valores reales y estimados del esfuerzo para cada proyecto.
En la gráfica 4.10 se muestra el error relativo cometido en cada proyecto calculado de la siguiente
manera: ^ , valor estimado — valor observado , „ , Error relativo = ; ; ; (4.25)
valor observado calculado para cada proyecto.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PHOYECrOS DE DATA MINING (DMCOMOr
CAPÍTULO 4. SOLUCIÓN 111
o E 150
o C § 110
< 4 -10 lil
-MM -$E-MM
1 2 3 4 5 6 7 10 11 12 13 14 15
Figura 4.9: Resultados de la estimación sobre el conjunto de prueba
En la figura 4.10 se muestra el error relativo de las estimaciones sobre los valores observados. Cabe
destacar que el 33 % de las estimaciones tienen un error inferior al 15 % y tan solo el 13 % de las
estimaciones tienen un error superior al 20 % no siendo superior en ningún caso al 25 %.
1 2 3 4 5 7 B 9 10 11 12 13 14 15 16
Id. proyecto
Figura 4.10: Error relativo de la estimación
4.6. Resumen contextual
En este trabajo se ha planteado un primer modelo de estimación para modelos de Data Mining.
Para ello se han propuesto los drivers de coste o factores que influyen en el esfuerzo de los proyec-
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMAOÓN PARA PROYECTOS DE DATA MINING (DMCOMOY
CAPÍTULO 4. SOLUCIÓN 112
tos de Data Mining y la ecuación correspondiente que relaciona el esfuerzo con los drivers de
coste. El modelo propuesto puede ser refinado para obtener una mayor precisión en las estima
ciones. No obstante, se dispone de un primer modelo que puede ser utilizado como técnica para
estimar el esfuerzo de los proyectos de Data Mining.
' MODELO MATEMÁTICO PAKAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
Parte
CONCLUSIONES Y LINEAS FUTURAS
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
Capítulo 5
Conclusiones y Líneas futuras
índice General 114 115
5.1. Conclusiones
En el presente trabajo de tesis se ha propuesto un método matemático paramétrico para la esti
mación del esfuerzo en proyectos de Data Mining.
Para ello se ha realizado un estudio en detalle de los factores que influyen en la realización de los
mismos.
Dada la complejidad del proceso de Data Mining de cara a establecer los factores que influyen en
el esfuerzo del mismo ha sido necesario identiñcar las fases del proceso, para lo cual se he utilizado
el estándar de modelo de procedo de Data Mining CRISP-DM.
De esta manera en el establecimiento de los drivers del modelo se ha tenido en cuenta el tipo y
diseño de base de datos que posee la organización y ha quedado claro que es uno de los factores
más influyentes en el coste del proyecto. De la misma manera, se ha tenido en cuenta el tipo de
patrones que la organización quiere obtener, naturaleza de los datos objetivo y requisitos de pri-
• MODELO MATEMÁ TICO PAHAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
CAPÍTULOS. CONCLUSIONES Y LÍNEAS FUTURAS 115
vacidad subyacentes en los datos objetivo. Todo ellos ha permitido constatar los aspectos diferen-
ciadores de un proyecto de Data Mining con respecto a un proyecto de desarrollo de software, con
lo que ha quedado patente la necesidad de establecer un nuevo método de estimación péira este
tipo de proyectos.
Los drivers establecidos de principio han sido sometidos a análisis estadísticos para comprobar su
validez. De este modo, se ha eliminado todos aquellos drivers que o bien su distribución no era la
adecuada o bien presentaban altos índices de correlación con respecto al resto. Posteriormente y
con la ayuda de datos obtenidos de proyectos reales de Data Mining, provenientes de diferentes
sectores empresariales, se ha establecido la ecuación de regresión que mejor se ajusta a los datos.
La ecuación ha sido validada con datos de proyectos que no habían sido utilizados con anteriori
dad.
De esta manera, se ha suministrado un conjunto de drivers, con sus niveles, descripciones y valores
asociados a los diferentes niveles, así como una ecuación que permite estimar el esfuerzo expresa
do en hombres x mes (MM).
Si bien el modelo propuesto se tendrá que refinar con datos de más proyectos a lo largo del tiempo,
de la misma manera que todos los modelos de estimación se han ido refinando con el tiempo, se
puede afirmar que se dispone de un primer modelo de estimación de proyectos de Data Mining.
5.2. Líneas futuras
En esta tesis se ha propuesto un modelo de estimación para proyectos de Data Mining. Si bien
el modelo ha sido validado, el desarrollo del modelo ha dejado abiertas futuras líneas de investi
gación.
En primer lugar el modelo planteado permite establecer el esfuerzo expresado en hombres x mes
{MM) pero no se ha dado un modelo para estimar el tiempo. Sería muy interesante el disponer de
una ecuación no solo para medir el esfuerzo sino también para medir el tiempo. De la misma for
ma, a partir de este primer modelo planteado sería interesante encontrar relaciones matemáticas
para valorar el beneficio que se obtendrá con el proyecto ROÍ [Return On Investment), el flujo de
caja NPV (Net Present Valué], ya sea a partir del esfuerzo obtenido con DMCOMO o a partir de los
valores de los drivers de coste de los proyectos.
Por otra parte, es necesario continuar con el estudio de las variables de entrada del modelo uti-
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
CAPÍTULO 5. CONCLUSIONES Y LÍNEAS FUTURAS 116
lizadas en DMCOMO con el objetivo de definir con la mayor precisión posible cuáles son las ca
racterísticas que afectan a los proyectos de Data Mining y continuar con la recogida de datos de
proyectos, no solo con los drivers planteados como finales, sino con todos los drivers propuestos.
Esto se debe a la necesidad de ir corrigiendo los factores de la ecuación del esfuerzo que afectan a
los drivers de coste en función de más datos.
Pcira el establecimiento de la ecuación del esfuerzo en esta tesis se ha utilizado la técnica de regre
sión lineal. Sería muy interesante aplicar otras técnicas para lograr obtener el valor del esfuerzo.
Estas técnicas pueden ir ser técnicas de regresión no lineal, técnicas de Inteligencia Artificial co
mo redes neuronales o algoritmos genéticos hasta técnicas de Data Mining. Esto permitiría poder
contrastar los resultados de cara a obtener la mejor ecuación.
Para finalizar, se podrían introducir variables de segundo nivel [GalOl] para los drivers de coste
propuesto en este trabajo. Con estas variables de segundo nivel se podría reducir el error cometido
en la estimación debido a una mala selección del nivel correspondiente a los drivers.
•MODELO MATEMÁTICO PADAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
Bibliografía
[Abr991 A. Abran. FFP reléase 2.0: An implementation of COSMIC functional size measurement
concepts. In FESMA 99, Amsterdam, 1999.
[AFS93] R. Agrawal, C. Faloutsos, and A. Swami. Efíicient similarity search in sequence databas-
es. In Foundations of Data Organizations and Algorithms (PODO) Conference, 1993.
[AgoOO] L. Agosta. The Essential Guide to Data Warehousing. Prentice Hall, 2000.
[AHM91] T. Abdel-Hamid and S. Madnick. Software Project Dynamics. Prentice-Hall, 1991.
[Alb79] A. Albrecht. Measuring application development productivity. In The Joint
SHARE/GUIDE/IBM Application Development Symposium, pages 83-92,1979.
[Ana97] S. Anahory. Data Warehousing in the Real World. Addison-Wesley, 1997.
[Aro69a] J. Aron. Estimating resources for large systems. In J.N. Bnxton and B. Randell, editors,
NATO Conference Report on Software Engineering Techniques, Roma (Italia), 1969.
[Aro69b] J. Aron. NATO Conference Report on Software Engineering Techniques, chapter Esti
mating Resources for Large Systems. J.N. Bnxton and B. Randell, 1969.
[AS94a] R. Agrawal and R. Strikant. Mining sequential patterns. In Proc. 1995 Int. Conf. Very
Large Databases, pages 487^99,1994.
[AS94b] Rakesh Agrawal and Ramakrishnan Srikant. Fast algorithms for mining association
rules. In Jorge B. Bocea, Matthias Jarke, and Cario Zaniolo, editors, Proc. 20th Int. Conf.
Very Large Data Bases, VLDB, pages 487-499. Morgan Kaufmann, 12-15 September
1994.
[Ass96] Galorath Associates. SEER-SEM User's Manual Versión 4.5. Galorath Associates Tech
nologies, 1996.
[Ass98] UK Software Metrics Association. UKSMA, Mk II Function Point Analysis Counting
Practices Manual Versión 1.3.1. UK Software Metrics Association, 1998.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PAHA PROYECTOS DE DATA MINING ÍDMCOMOf
BIBLIOGRAFÍA 118
[BAB+00] B. W. Boehm, C. Abts, A. W. Brown, S. Chulani, B. K. Clark, E. Horowitz, R. Madachy,
D. Reifer, and B. Steece. Software Cost Estimation with COCOMO II. Prentice Hall,
2000.
[Bar97] B. Barquín. Planning and Designing the Data Warehouse. Prentice-Hall, 1997.
[BB81] J. Baylei and V. Basili. A meta-model for software development resource expenditures.
In Proceedings of the Fifth International Conference on Software Engineering., 1981.
[BBT92] Lionel C. Briand, Víctor R. Basílí, and WíUíam M. Thomas. A pattern recognítion ap-
proach for software engineering data analysis. IEEE Transactions on Software Engi
neering, 18(11), November 1992.
[BCG77] R. Black, R. Curnow, R. Katz , and M. Gray. BCS software production data. Technical
Report Final Technical Report RADC-TR-77-116, Boeing Inc., 1977.
[BCH+95] B. Boehm, B. Clark, E. Horowitz, C. Westland, R. Madachy, and R. Selby. Cost models
for future software Ufe cycle processes: COCOMO 2.0. Annals of Software Engineering,
1:57-94,1995. Software Process eind Product Measurement.
[BFOS84] L. Breiman, J. Friedman, R. Olshen, and C. Stone. Classification and Regression Traes.
Wadsworth, California, 1984.
[bib78] iVew International Versión of the Holy Bible. Grand Rapids, MI, Zondervan, 1978.
[BKK92] R. Banker, Robert J. Kauffman, and Rachna Kumar. An Empirical Test of Objectbased
Measurement Metrics in a Computer Aided Software Engineering (CASE) Environ-
ment. Morgan Kauffman, 1992.
[BM96] R.A. Brealey and S.C. Myers. Principies of Corporate Finance. McGraw-Hill, New York,
NY, 5th edition, 1996.
[B.099] B.O.E. LEY ORGÁNICA 15/1999, de 13 de diciembre, de protección de datos de carácter
personal. Diciembre 1999.
[BoeSl] B. Boehm. Software Engineering Economics. Prentice Hall, 1981.
[BR89] B. Boehm and W. Royce. Ada COCOMO and the ADA process model. In 5th COCOMO
Users' Group Meeting. Software Engineering Institute, 1989.
[Buc71] E Buck. A cost-by-function model for avionics computer system. iVADC-SD-7088, 1,
1971.
•MODELO MATEMÁTICO PARAMÉTRICO DEESTIMAOÓN PAJU PROYECTOS DE DATA MINING (DMCOMOÍ
BIBUOGRAFÍA 119
[CBS99] Sunita Chulani, Barry Boehm, and Bert Steece. Bayesian analysis of empirical software
engineering cost models. iEEE Transactions on Software Engineering, 25(4):573-583,
July/August 1999. Special Section: Empirical Software Engineering.
[CCB97] S. Chulani, B. Clcirk, and B. Boehm. Calibration approach and results of COCO-
MOII.1997. In 22nd Software Engineering Workshop, Goddard, 1997. NASA.
[CCBS98] S. Chulani, B. Clark, B. Boehm, and B. Steece. Calibration approach and results of the
COCOMOII post-architecture model. In 20th Annual Conference If the International
Society of Parametric Analysts (ISPA) and the 8th Annual Conference of the Society of
Cost Estimating and Analysis (SCEA), 1998.
[CDS86] S. Conté, H. Dunsmore, and V. Shen. Software Engineering Metrics and Models. Ben
jamín Cummins Publishing company, 1986.
[CGJ96] D. A. Cohn, Z. Ghahramani, and M. I. Jordán. Active learning with statistical models.
/ournal of Artificial Intelligence Research, 4:129-145,1996.
[CHS+97] P. Cabena, P. Hadjinian, R. Stadler, J. Verhees, and A. Zcinasi. Discovery Data Mining.
From Concept to Implementation. Prentice Hall, 1997.
[CMOl] J.J Cuadrado and O. Marbán. Revisión and classification of current software cost esti-
mation models. In 6th World Multiconference on Systemicsm Cybernetics and Infor-
matics (SCI 2002), volume 1, pages 339-34, Orlando, FL, U.S.A., July 2001.
[Com75] Air Forces System Command. Goverment/Industry software. In Workshop Summary
Notes. Electronic System División, 1975.
[CRM02] Remedy CRM. www.windthrope.com/crm.htm, 2002.
[CTGN02] Bob Chatham, Bruce D. Temkin, Katharine M. Gardiner, and Taichi Nakashima. CRM's
future: Humble growth through 2007, july 2002.
[DAGJ95] Cohn D. A, Z. Ghahramani, and M. I. Jordán. Active learning with statistical models.
Advances in Neural Information Processing Systems, 7:705-712, 1995.
[DC99] Sunita Devnani-Chulani. Bayesian Analysis of Software Cost and Quality Models. PhD
thesis, Faculty of the Gradúate School. University of Southern California, May 1999.
[Dev97] B. Devlin. Data Warehouse: From Architecture to Implementation. Prentice-Hall, 1997.
[DiLOO] L. DiLauro. What's next in monitoring technology? data mining finds a Ccdling in cali
centers, may 2000.
' MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMO)'
BIBLIOGRAFÍA 120
[dMOO] D. de Marco. Building and Managing the Meta Data Repository. John Willey and Sons,
2000.
[Dom98] Pedro Domingos. How to get a free lunch: A simple cost model for machine learning
applications. In Proceedings of AAAI-98/ICML-98 Workshop on the Methodology of
Applying Machine Learning, 1998.
[Dom99] Pedro Domingos. MetaCost: A general method for making classifiers cost-sensitive. In
Surajit Chaudhuri and David Madigan, editors, Proceedings of the Fifth ACM SIGKDD
International Conference on Knowledge Discovery and Data Mining, pages 155-164,
N.Y., August 15-18 1999. ACM Press.
[DycOl] Jill Dyché. The CRM Handbook: A Business Cuide to Customer Relationship Manage
ment. Addison-Wesley Pub Co., 1 edition, 2001.
[DYNOOO] T. Dohi, Y. Yatsunami, Y.Ñishio, and S. Osaki. The effective smoothing technique
to estímate the optimal software reléase schedule based on artificial neural network.
Transctions on Fundamentáis of Electronics, Comunications and Computer Sciences,
E83-A(5):796-803,2000.
[EE97] H. A. Edelstein and H. C. Edelstein. Building, Using, and Managing the Data Ware-
house. Data Warehousing Institute. Prentice Hall PTR, Ist edition, 1997.
[EKTOSa] B. Eisenfeld, E. Kolsky, and T. Topolinski. 42 percent of CRM software goes unused.
www.gartner.com. Febrero 2003.
[EKT+03b] B. Eisenfeld, E. Kolsky, T. Topolinski, D. Hagemeyer, and J. Grigg. Unused CRM software
increases TCO and decreases ROL www.gartner.com. Febrero 2003.
[Eng99] L. English. Data Warehouse Quality. McGraw-Hill, 1999.
[Far70] J. A. Farquhar. A preliminary inquiry into the software estimation process. Technical
Report RM-6271-PR, The Rand Corporation, 1970.
[Faw93] T. Fawcett. Feature Discovery for Problem SoMng Systems. PhD thesis, Department of
Computer Science, University of Massachusetts, 1993.
[fGE02] Amdocs Clarify CRM for Global Enterprises. wv«v.amdocs.com, 2002.
[Fis97] L. Fischman. Calibrating a software evaluation model. In ARMS Conference, 1997.
[FMP+00] Covadonga Fernández, Ernestina Menasalvas, José M. Peña, Juan F. Martínez, Óscar
Delgado, and J. Ignacio López. Rough sets as a foundation of data mining queries in
DAMISYS. In Proceedings of IPMU'2000,2000.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PAHA PROYECTOS DE DATA MINING (DMCOMOf
BIBLIOGRAFÍA 121
[FP96] T. Fawcett and F. J. Provost. Combining data mining and machine learning for effective
user profiling. In Proceedings of the Second International Conference on Knowledge
Discovery and Data Mining, KDD-96, pages 8-13,1996.
[FP97] T. Fawcett and F. J. Provost. Adaptive fraud detection. Data Mining and Knowledge
Discovery, 1(3), 1997.
[FP99] T. Fawcett and F. J. Provost. Activity monitoring: Noticing interesting changes in behav-
ior. In Proceedings of the Fifth International Conference on Knowledge Discovery and
Data Mining, KDD-99., 1999.
[FPM+99] Covadonga Fernández, José M. Peña, Juan F. Martínez, Óscar Delgado, J. Ignacio López,
M. Ángeles Luna, and J.F. Borja Pardo. DAMISYS: An overview. In Proceedings of
DAWAK'99, Florencia, Italy, pages 224-230, August 1999.
[FPSS96] Usama M. Fayyad, Gregory Piatetsky-Shapiro, and Padhraic Smyth. From data mining
to knowledge discovery: An overview. In Advances in Knowledge Discovery and Data
Mining, pages 1-34.1996.
[FPSSU96] U. Fayyad, G. Piatetsky-Shapiro, P. Smith, and R. Uthurusamy. Advances un Knowledge
Discovey and Data Mining. AAAI/MIT Press, MA, 1996.
[Fre74] B. C. Frederic. A provisional model for estimating computer program development
costs. TechnicalReportTM-7/REV-l, TECOLOTE Research Inc., 1974.
[FZ65] L. Farr and H. Zagorski. Quantitative analysis of programming cost factors: A progress
report. In A. Frielink, editor, ICC Symposium Proceedings Economics of Automatic
Data Processing, Amsterdam: North-HoUand Holland, 1965.
[GalOl] Juan J. Cuadrado Gcdlego. Método Matemático de Selección Del Rango de Las Vari
ables de Entrada En Los Modelos Paramétricos de Estimación Software. PhD thesis.
Departamento de Informática, Universidad Carlos III de Madrid, 2001.
[GHJ93] W.E. Griffiths, R.C. Hill, and G.G. Judge. Learning and Practicing Econometrics. John
Wiley & Sons, Inc., New York, 1993.
[GMS99] A. Gray, S. MacDonell, and M. Shepperd. Factors systematically associated with errors
in subjetive estimates of software development effort: The estability of expert judge-
ment. In 6th International Software Metrics Symposium, pages 216-227, EE.UU., 1999.
IEEE Computer Society.
' MODELO MATEMA TICO PAMMÉTRICO DE ESTIMACIÓN PARA PROVECTOS DE DATA MINING (DMCOMOy
BIBUOGRAFÍA 122
[Gri96] Udo Grimmer. Clementine: Data mining software. In Hans-Joachim Mucha and
Hans-Hermann Bock, editors, Classification and Multivariate Graphics: Models, Soft
ware and Applications, number 10 in Weierstrass-Institut für Angewandte Analysis und
Stochastik, pages 25-31. Berlin, Germany, 1996.
[Gro99] International Function Point Users Group. IFPUG, Funtion Point Counting Practices
Manual Reléase 4.1. International function point users group, 1999.
[GroOl] Gartner Group. B2B CRM: PRM trends and evolution, 2001.
[Ham02a] loe Hamaker. Rules of thumb: Space project cost trends over time holding technical
performance constant. Parametric World, pages 5-7, Winter 2001-2002.
[Ham02b] Joe Hamaker. Using the mínimum squared error regression aproach. Parametric
World, 21(3): 11-13, Winter 2002.
[Hel66] O. Helmer. Social Technology. Basic Books, NY (E.E.U.U.), 1966.
[HHdB74] J. Hermans, J. D. F. Habbema, and A. T. Van der Burght. Cases of doubt in allocation
problems, k populations. BuUetin of the International Statistics Institute, 45:523-529,
1974.
[HM72] William W. Hiñes and Douglas C. Montgomery. Probabüity and Statistics In Engineer-
ing and Management Science. Wiley Series, 1972.
[HPRS77] J. Herd, J. Postak, W. Russell, and K. Stewart. Software cost estimation study - study
results. Technical Report Final Technical Report, RADC-TR-77-220, Doty Associates,
Inc., 1977.
[HR98] M. Hasenjager and H. Ritter. Active learning with local models. Afeural Processing
Letters,7(2):107-117,1998.
[IBM99] IBM. Application programming interface and utility reference. IBM DB2 Intelligent
Miner for Data. IBM, September 1999.
[IEE91] IEEE. Standard for Developing Software Life CycleProcesses. IEEE Std. 1074-1991. IEEE
Computer Society, Nueva York (EE.UU.), 1991.
[Inc02] Chordiant Software Inc. www.chordiant.com, 2002.
[Inc03] Mosaic Inc. www.mosaic.com, 2003.
[Inm96] W. H. Inmon. 5uilding the DataWarehouse. John Willey and Sons Inc, 1996.
[Inm97] W. H. Inmon. Managing the DataWarehouse. John Willey and Sons Inc, 1997.
•MODELO MATEMÁTICO PAHAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMO)'
BIBLIOGRAFÍA 123
[Inm98] W. H. Inmon. Data Warehouse Performance. John Willey and Sons Inc, 1998.
[Inm02] W. H. Inmon. Building the Data Warehouse. John Wiley and Sons, 3rd edition, 2002.
[ISL95] ISL. Clementine User Guide, volume Versión 5. ISL, Integral Solutions Limited, July
1995.
[IS095] ISO. ISO/IEC Standard 12207:1995. Software Life Cycle Processes. International Orga-
nization for Standarization, Ginebra (Suiza), 1995.
[ISP99] International Society of Parametric Analysts ISPA. Parametric Cost Estimating Hand-
book. International Society of Parametric Analysts (ISPA), 2nd edition, 1999.
[Jen83] R. Jensen. An improved macrolevel softwcire development resource estimation model.
In Proceedings 5 Th ISPA Conference, 1983.
[Jon77] C. Jones. Programing quality and programer productivity. Technical Report TR-02-764,
IBM, 1977.
[ Jon97] C. Jones. Applied Software Measurement. McGraw Hill, 1997.
[Jon98] Capers Jones. Estimating Software Cost. Mc-Graw Hill, 1998.
[Jr.77] T. James Jr. Software cost estimating methodology. In Proceedings of National
Aerospace Electronic Conference, pages 22-28,1977.
[ Jud85] Gerge G. Judge. The Theory and Practice of Econometrics. John Wiley and Sons, 2nd
edition, 1985.
[KacOO] R. Kachur. Data Warehouse Management Handbook, 2000.
[KdN02] KdNuggets.Com. http://www.kdnuggets.com/polls, 2002.
[Kim96] R. Kimball. The Data Warehouse Toolkit. John Willey and Sons, 1996.
[KinOO] E. King. Auditing PRICE s using enterprise. In PRICE Systems 20th European Sympo-
sium, 2000.
[KPR99] Jon Kleinberg, Christos Papadimitriou, and Prabhakar Raghavan. A microeconomic
view of data mining. /. Data Mining and Knowledge Discovery, 1999.
[KS95] Tom Khabaza and Colin Shearer. Data mining with clementine, February 1995.
[Kus77] A. L. Kustímowitz. System Life cicle estimation (SLICE): A new approach to estimating
resources for application program development. In Proceedings of the IEEE COMSAC,
1977.
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOJ
BIBUOGRAFÍA 124
[KV95] A. Krogh and J. Vedelsby. Neural network ensembles, cross validation, and active learn-
ing. ATeural Information Processing Systems, 7:231-238,1995.
[LCHB99] A. Lee, Ch. Chmi-Hung, and J. Balakrishnan. Software development cost estima-
tion: Integrating neural network with cluster analysis. /nformation and Management,
34(l):l-9, 1999.
[LT75] H. Linstone and M. Turoff. The Delphi Method: Techniques and Applications. Addison-
Wesley, Reading, Massachusets, 1975.
[Mad94] R. Madachy. A Software Project Dynamics Model for Process Cost, Schedule and Risk
Assessment. PhD thesis, University of Southern California, 1994.
[Mad97] R. Madachy. Heuristic risk assessment using cost factors. IEEE Software, May/June
1997.
[Man97] Heikki Mannila. Methods and problems in data mining. In ICDT, pages 41-55,1997.
[Min89] J. Mingers. An empirical comparison of pruning measures for decisión tree induction.
Machine Learning, 4:227-243,1989.
[Moo98] J. Moore. Software Engineering Standards: A Users Road Map. IEEE Computer Society,
Los Alamitos, California, 1998.
[MPS96] B. Masand and G. Piatesky-Shapiro. A comparison of approaches for maximizing busi-
ness payoff of prediction models. In Second International Cnference on Knowledge
Discovery and Data Mining, pages 195-201, Portland, OR, 1996. AAAI Press.
[Nel66] E.H. Nelson. Management handbook for estimation of computer programing cost. AD-
648-750, 1966.
[NES97] Nederlandse Software Metriken Gebruikers Associatie NESMA. NESMA Function Point
Counting Practices Versión 2.0. Nederlandse Software Metriken Gebruikers Associatie,
1997.
[Nor63] RW. Norden. LTseful Tool for Project Management. Editorial Wiley 1963.
[NSN+00] Pete Chapman (NCR), lulian Clinton (SPSS), Randy Kerber (NCR), Thomas Khabaza
(SPSS), Thomas Reinartz (DaimlerChrysler), Colin Shearer (SPSS), and Rüdiger Wirth
(DaimlerChrysler). CRISP-DM 1.0 step-by-step data mining guide. Technical report,
CRISP-DM, 2000.
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DEDATA MINING (DMCOMOf
BIBLIOGRAFÍA 125
[Núñ88] M. P. Núñez. Economic induction: A case study. In Proceedings of the Third Euro-
pean Working Session on Learning, EWSL-88, pages 139-145, California, 1988. Morgan
Kaufmann.
[NúñSl] M. P. Núñez. The use of background knowledge in decisión tree induction. Machine
Learning, 6:231-250,1991.
[OS97] D. W. Opitz and J. W. Shavlik. Connectíonist theory refinement: Genetically searching
the space of networktopologies. /ournal of Artificial Intelligence Research, 6:177-209,
1997.
[Par80] F. Parr. An alternative to rayleight curve model for software development effort. IEEE
Transactions on Software Engineering, 6(3):291-296,1980.
[Pcir92] Robert E. Park. Software size measurement: A framework for counting source state-
ments. Technical Report CMU/SEI-92-TR-20, Carnegie Mellon University, Pittsburgh,
Pennsylvania, 1992.
[PF79] L. Putman and A. Fitzsimmons. Estimating software cost. Datamation, pages 312-315,
Septiembre, Octubre y Noviembre 1979.
[PGCB93] M. C. Paulk, S. M. Garcia, M. B. Chrissis, and M. Bush. Capability maturity model for
software, versión 1.1. Technical Report CMU/SEI-93-TR-25, Software Engineering In-
stitute. Carnegie Mellon University, 1993.
[PM92] L. Putnam and W. Myers. Measures for Excellence. Reliable Software on Time, Within
Budget. Yourdon Press Computing Series, Englewood Cliffs, N.J., 1992.
[PMM+94] M. Pazzani, C. Merz, E Murphy, K. Ali, T. Hume, and C. Brunk. Reducing misclassifica-
tion costs. In fleventh International Conference on Machine Learning, pages 217-225,
New Brunswick, NJ, 1994. Morgan Kaufmann.
[PS98a] LLC PRICE Systems. PRICE H Reference Manual Versión 3.0. Lockheed- Martin, 1998.
[PS98b] LLC PRICE Systems. PRICE S Reference Manual Versión 3.0. Lockheed- Martin, 1998.
[PSF91] G. Piatetsky-Shaphiro and W. Frawley. /Tnowledge Discovery in Databases. AAAI/MIT
Press, MA, 1991.
[Put78] L. Putnam. A general empirical solution to the macro software sizing and estimation
problem. IEEE Transactions on Software Engineering, SE-4:345-361,1978.
[PVS98] K. Patricia P. Vidette and B. Stephen. fiuilding a Data Warehouse for Decisión Support.
Prentice Hall, second edition, 1998.
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
BIBLIOGRAFÍA 126
[PWCC95] M. Paulk, C. Weber, B. Curtís, and M. Chrissis. The Capability Maturity Model for Soft
ware: Guidelines for Improving the Software Process. SEI Series in Software Engineer-
ing. Addison - Wesley, 1995.
[Pyl99] Doricín Pyle. Data Preparation for Data Mining. Morgan Kaufmann, 1999.
[Rij79] C. J. Van Rijsbergen. /nformation Retrieval. Butterworths, London, 2 edition, 1979.
[RKT98] M. Ross R. Kimball, L. Reeves and W. Thronthwaite. The DataWareiiouse Lifecycle
Toolkit. John Willey and Sons, 1998.
[Rub83] H. Rubin. Macroestimation of software development parameters: The estimacs system.
In SOFTFAIR Conference Development Tools, Techniques and Alternatives, Arlington,
1983. IEEE Press.
[She96] Colin Shearer. User driven data mining, 1996. Unicom Data Mining Conference. Lon
don.
[Shr97] T. Shrum. Calibration and validation of the CHECKPOINT model to the air forcé elec-
tronic systems center software databases. Master's thesis, Air Forcé Institute of Tech
nology, 1997.
[SPJROO] L.H. Putnam Sr., Douglas T. Putnam, L.H. Putnam Jr., and M. A. Ross. Software Lifecy
cle Management (SLIM) Training. SLIM Estímate Exercises with Answers, Quantitative
Software Management. Me Lean, VA, 2000.
[StrOO] Mattias Strand. The Business Valué of Data Warehouses - Opportunities, Pitfalls and
Future Directions. PhD thesis, Department of Computer Science, University of Skovde,
December 2000.
[STV97] M. W. Van Someren, C. Torres, and F. Verdenius. A systematic description of greedy
optimisation algorithms for cost sensitive generalisation. In Proceedings of Intelligent
Data Analysis 1997 (IDA97), pages 247-258, New York, 1997. Springer Verlag.
[SW49] C. E. Shannon and W. Weaver. The Mathematical Theory of Communication. Univ. of
Illinois Press, Urbana, USA, 1949.
[Tan91a] M. Tan. Cost-sensitive reinforcement leeirning for adaptive classification and control.
In Proceedings of the Ninth National Conference on Artificial Intelligence, pages 774-
780, San José, CA, 1991. AAAI Press.
[Tan91b] M. Tan. Learning a cost-sensitive internal representation for reinforcement learning.
In Proceedings of the Eighth International Workshop on Machine Learning, pages 358-
362, Evanston, IL, 1991. Morgan Kaufmann.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PHOYECTOS DE DATA MINING ÍOMCOMOy
BIBLIOGRAFÍA 127
[Tan93] M. Tan. Cost-sensitive learning of classification knowledge and its applications in
robotícs. Machine Learning, 13:7-33,1993.
[TauSl] R. Tausworthe. Deep Space Network Software Management Cost Estimation Model,
pages 81-87. Jet Propulsión Laboratory, 1981.
[TD74] R. Taback and J. Ditimore. iíM-1873, chapter Estimation Computer Requeriments and
Software Development Costs. General Research Corporation, 1974.
[The97] The Data Mining Research Group. DBMiner User Manual. Simnon Fraser University,
Intelligent Datábase Systems Laboratory, December 1997.
[Tka98] D.S. Tkach. Information mining with the ibm intelligent miner family, February 1998.
IBM Software Solutions White Paper.
[Too98] SELECT Software Tools. estimation for Component-Based Development Using SE-
LECT Estimator. SELECT Software Tools, 1998.
[TS84] S. Thebaut and V. Shen. An analytic resource model for large-scale software develop
ment. In Inf. Proc. Management, pages 1-2,1984.
[TSH95] R D. Turney C. Schaffer, and R. Holte, editors. Proceedings of the IJCAI-95 Workshop
on Data Engineering for Inductive Learning., Montréal, Canadá, 1995.
[Tur95] Peter D. Turney. Cost-sensitive classification: Empirical evaluation of a hybrid genetic
decisión tree induction algorithm. /ournal of Artificial Intelligence Research, 2:369-
409,1995.
[TurOO] Peter Turney. lypes of cost in inductive concept learning. In l^orkshop on Cost-
Sensitive Learning at the Seventeenth International Conference on Machine Learning
(WCSL at ICML-2000), pages 15-21, Stanford University, California, 2000.
[Ver91] F. Verdenius. A method for inductive cost optimization. In Proceedings of the Fifth
European Working Session on Learning, EWSL-91, pages 179-191, New York, 1991.
Springer-Verlag.
[Wei85] S. Weisberg. Applied Linear Regression. John Wiley & Sons, New York, 1985.
[WF77] C. Walston and C. Félix. A method of programming measurement and estimation. /BM
System Journal, 16(l):54-73,1977.
[WitOO] I. H. Witten. Data Mining: Practical Machine Learning Tools with Java Implementa-
tions. 2000.
' MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOf
BIBLIOGRAFÍA 128
[Wol74] R. Wolverton. The cost of developing large scale software. IEEE Transactions on Com-
puters, C-23(6):615-636,1974.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
Apéndice A
Método Delphi
El Método Delphi se creó en 1948 como método de predicción de acontecimientos futuros [Far70].
El nombre del método hace referencia al Oráculo de Apolo situado en Belfos (Delphi), el cual rea
lizaba profecías o predicciones sobre acontecimientos futuros que debían ser interpretadas. Con
este método se logra obtener la opinión de expertos mediante un proceso de comunicación es
tructurado [LT75].
El procedimiento del Método Delphi consiste en un proceso de retroalimentación de respuestas
con el objetivo de obtener un resultado representativo de la opinión del grupo de expertos consul
tado. Este proceso logra la convergencia de las repuestas sobre la importancia y la ocurrencia de
una serie de sucesos. Las principales características del Método Delphi son:
• Anonimato: contribuye a contestar libremente el cuestionario sin que la opinión de unos
expertos influya en el resto.
• Iteración: se pueden realizar tantas rondas como sean necesarias.
• Retroalimentación: conduce a la convergencia entre las valoraciones de los expertos partici
pantes en función de las opiniones del grupo.
• Resultados estadísticos: la respuesta del grupo puede ser presentada estadísticamente (media
y desviación típica).
El funcionamiento del Método Delphi es el siguiente:
1. Preparación de los formularios con las preguntas a realiza a los expertos.
•MODELO MATEMÁTICO PADMÍÉTRICO DE ESTIMACIÓN PARA PSOWCTOS DE DATA MINING ÍDMCOMOf
APÉNDICE A. MÉTODO DELPHI 130
2. Selección de los participante.
3. Repartir el cuestionario entre los participante y esperar las respuestas de los mismos.
4. Analizar las respuestas para obtener los resultados representativos del grupo.
5. Repartir de nuevo el cuestionario añadiendo los resultados de las respuestas del grupo en la
ronda anterior (Mediana y dispersión). Esto se hace así para que cada experto pueda con
trastar sus respuestas y modificarlas
6. Repetir los pasos 4 y 5 hasta lograr la convergencia en las respuestas. Normalmente es sufi
ciente con un Método Delphi de 3 iteraciones.
Este método se ha utilizado en el campo de la Ingeniería del Software y en concreto en el campo
de la estimación de proyectos. En [Far70] se utiliza este método para estimar el esfuerzo necesario
para el desarrollo de un proyecto de software partiendo de sus especificaciones. En [DC99] se uti
liza el Método Delphi para conseguir información a cerca de un conjunto de drivers determinado,
en concreto drivers para la estimación de errores cometidos durante el proceso de desarrollo de
software (modelo COQUALMO).
En este trabajo de tesis se utilizará el Método Delphi paia establecer los valores "nominales" de
los drivers de coste. A continuación se muestran los formularios Delphi utilizados y los resultados
obtenidos.
A.I. Formularios Delphi utilizados para DMCOMO
En este apartado se muestran los formularios Delphi propuesto para la obtención de los valores de
las descripciones de las tablas de los drivers de coste de DMCOMO propuestos en la sección 4.3.
N. 1 2 3 4
5 6 7
8
9 10 11
Pregunta Número de tablas iniciales que se utilizan en un proyecto de Data Mining Número de tupias que contienen las tablas iniciales Número de atributos que contienen las tablas iniciales Número diferente (en media) de valores diferentes de los atributos. Las posibles repuestas son: Muy pocos, Pocos, Normal, Bastantes, Muchos Porcentaje de valores nulos en los atributos iniciales Porcentaje de criterios de codificación de valores dados por el usuario Porcentaje de modelos de datos operacionales disponibles para la realización del proyecto Porcentaje de datos privado que no se puedan utilizar. Indicar asimismo si los datos se pueden inferir y en que porcentaje Número de fuentes de datos externas que es neceseirio adquirir Número de modelos a generar como salida del proceso de Data Mining Ordenar de mayor a menor dificultad el siguiente tipo de modelos de Data Mining: Asociación, Clustering, Patrones secuenciales,, Clasificación, Predicción, Estimación, Series temporales
Respuesta
' MODELO MATEMÁTICO PAPAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOÍ
APÉNDICE A. MÉTODO DELPHI 131
N. 12
13
14
15
16
17
18 19 20
21 22
23
24
25 26
27
28
29
30
31 32 33
34
35
36
Pregunta Número medio de tupias que se utilizan para la construcción de un modelo de Data Mining Número medio de atributos que se utilizan para la construcción de un modelo de Data Mining y tipo de atributos (numéricos, no numéricos) indicando su proporción Número diferente (en media) de valores diferentes de los atributos que se utilizan para la construcción de un modelo. Las posibles repuestas son: Muy pocos, Pocos, Normal, Bastantes, Muchos Cantidad media de atributos derivados que son necesarios para cada modelo Número de técnicas de Data Mining que se pueden aplicar para resolver problemas de tipo descriptivo Número de técnicas de Data Mining que se pueden aplicar para resolver problemas de tipo predictivo Número de fuentes donde residen los datos objetivo Tipo de fuentes donde residen los datos objetivo Tipo de soportes de almacenamiento de los datos y herramientas de interconexión entre diferentes servidores Localización de los orígenes de datos y forma de comunicación entre ellos Porcentaje de modelos desarrollados mediante la utilización de herramientas de Data Mining Porcentaje de técnicas de Data Mining que se utilizan en el proyecto y no son soportadas por las herramientas de Data Mining Con que otras herramientas (editores de texto, hojas de cálculo, SGBD, etc. son compatibles normalmente la herramientas de Data Mining Nivel de compatibilidad de las herramientas de Data Mining ¿Se dispone de herramientas y máquinas en las que se puedan ejecutar las mismas y con qué modelos? ¿Se pueden modificar los algoritmos implementados por las herramientas de Data Miningl¿En qué manera? Conocimiento de Data Mining y de la herramienta requerido por las herramientas de Data Mining que se utilizan en el proyecto (Experto, Conocimiento, Conocimiento Ligero) Cuál es la forma de interactuar con las herramientas de Data Mining (línea de comandos, interfaz gráfica) y la complejidad de uso (fácil, compleja) Número medio de departamentos involucrados en los proyectos de Data Mining Tipo de documentación a entregar Para cuántos entornos diferentes se desarrollan el mismo tipo de modelos Dónde se encuentran ubicados los diferentes participantes en el proyecto de Data Mining Tipo de comunicación entre los diferentes participantes en el proyecto de Data Mining Nivel de formación en perfiles complementarios de los participantes en los proyectos de Data Mining Conocimiento de los datos que se utilizan en los proyectos de Data Mining Y si hay colaboración de un analista de datos o si hay una descripción de los mismos
Respuesta
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PAfíA PROYECTOS DE DATA MINING (DMCOMO)'
APÉNDICE A. MÉTODO DELPHI 132
N. 37
38
39
40
41
42
Pregunta Nivel de participación en los proyectos de Data Mining del director del departamento para el que se desarrolla el proyecto de Data Mining (apoyo, no apoyo) Nivel de participación en los proyectos de Data Mining la dirección de la empresa para el que se desarrolla el proyecto de Data Mining (apoyo, no apoyo) En cuántos proyectos han trabajado previamente los participantes en un proyecto de Data Mining Familiaridad que tiene el equipo de Data Mining con el tipo de problemas de Data Mining que hay que resolver Experiencia que tiene el equipo de Data Mining con las técnicas y herramientas de Data Mining Conocimiento del funcionamiento del negocio del que forma peirte la empresa a la cual se le desarrolla el proyecto de Data Mining
Respuesta
Tabla A. 1: Formulario Delphi
En el presente trabajo de tesis se realizó un Método Delphi de 2 pasos, sobre 5 expertos en Data
Mining, de acuerdo a los siguientes pasos:
1. Se planteó el formulario de respuesta (tabla A. 1).
2. Se repartió el formulario entre los expertos y se esperó por sus respuestas.
3. Se analizaron las respuestas para en muchos casos plantear los valores que estas pueden
tomar en la siguiente iteración del método. Se calculo la mediana y la dispersión de las re
puestas obtenidas de las preguntas. Para la dispersión se utilizó el rango intercuartílico entre
elP'•.y3^^cuartil.
4. Se repartió de nuevo el formulario especificando para cada pregunta los posibles valores de
respuesta obtenidos en el paso anterior. Junto con el cuestionario se dio la mediana y la
desviación típica de cada respuesta.
5. Recoger las respuestas y calcular su mediana y dispersión en forma P''. y S""". cuartil.
6. Plantear los valores de las descripciones de los drivers de coste propuesto en la sección 4.3.
Una vez realizadas las iteraciones del Método Delphi los resultados obtenidos tras las segunda ite
ración se muestran en la tabla A.2.
N. 1 2 3 4 5 6
Mediana 90 15 X 10 1200 Normal 15% 65%
Dispersión 20 - 300 5 X 10 - 50 X 10^ 500 - 2000 Pocos - Bastantes 10%-25% 30%-80%
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PBOYECTOS DE DATA MINING (DMCOMOf
APÉNDICE A. MÉTODO DELPHI 133
N. 7 8 9 10 11
12 13 14 15 16 17 18 19
20
21
22 23 24
25 26
27
28 29
30 31
32 33 34 35
36
37 38 39
Mediana 75% 25 % (Difícil inferir) 4 4
Dispersión 60 % - 90 % 20 % - 50 % (Inferir un 10 %) 3 - 7 3 - 7
La ordenación más repetida fiíe: Asociación, Clustering, Patrones secuen-ciales, Clasificación, Predicción (Estimación y Series temporales) 15 X 10« 40 Normal 12 2 4 2 distintas Servidores diferentes
SGBD sin herramientas de interconexión Mismo edificio, LAN
60% 60% Editores de texto, hojas de cálculo, SGBD
Compatibles Máquinas y herramientas, todas ejecutan todas pero no toda su funcionalidad
Si, a través de una API documentada
Ligero Gráfica, fácil
2 Para los modelos generados
1 Misma ciudad Banda ancha Un experto en cada área
Ayuda de un analista de datos que los conoce Apoyo Ni apoyo ni no apoyo Hasta 2
5 X 10** - 50 X lO' 10-70 Pocos - Bastantes 5 - 2 0 1-4 1-4 2 iguales - 3 distintas Servidores iguales - Servidores diferentes Ficheros electrónicos - SGBD con herramientas de interconexión Misma base de datos - Lugares diferente comunicados 5 0 % - 7 0 % 50%-70% Editores de texto - Editores de texto, hojas de cálculo, SGBD y herramientas de Data Mining Intecambiables - No compatibles Máquinas y herramientas, pero no todas ejecutan en todas - Máquinas y herramientas todas ejecutan en todas de forma completa Se puede construir un "plug-in" - se dispone del código fuente de los algoritmos Ligero - Experto Línea de comandos, compleja - Gráfica, fácil 1-5 Para el modelo que se implanta - Para todos los modelos y las fases centrales de Data Mining 1 -Varios Mismo edificio - Varias ciudades Banda ancha - Teléfono y fax Gente reciclada de otras áreas - Expertos con perfiles complementarios Descripción de los datos - Experto en los dato y experto en el negocio Apoyo - No Apoyo Apoyo - No apoyo En ninguno - Hasta 4
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOY
APÉNDICE A. MÉTODO DELPHI 134
N. 40
41
42
Mediana Se ha trabajado con problemas de Data Mining similares
Han trabajado con herramientas de Data Mining
Gente con conocimiento del negocio
Dispersión Han trabajado en proyectos de Data Mining en el entorno actual - Han trabajado en proyectos de Data Mining pero nunca similares Conocimiento de la herramientas a utilizar en el proyecto - Nunca han trabajado con herramientas de Data Mining Nadie conoce el negocio - Gente conocedora del negocio que es la empresa a la que se le desarrolla el proyecto
Tabla A.2: Resultados de la segunda iteración del Método Delphi
A partir de los resultados de la tabla A.2 se construyeron las descripciones que aparecen en los
niveles de los drivers de coste propuestos en la sección 4.3. La mediana, resultado del Método Del
phi, se tomo como el valor "nominal" en las descripciones de los drivers de coste, y se utilizó para
construir los valores de menor esfuerzo y mayor esfuerzo. Los rangos de menor esfuerzo (Extra Ba
jo, Muy Bajo, Bajo) y de mayor esfuerzo (Alto, Muy Alto, Extra Alto) se establecieron en función de
la dispersión obtenida con el Método Delphi.
Una vez planteados estos formularios se distribuyeron entre los expertos que participaron en el
Método Delphi para su validación y corrección. Las tablas finales, una vez corregidas y validadas
son las que se muestran en la sección 4.3.
•MODELO MATEMÁTICO PAKAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOr
Apéndice B
Regresión múltiple
Las técnicas de regresión lineal son las más utilizadas en la construcción y calibrado de modelos de
estimación paramétricos (ver sección 2.5.3). La regresión estándar hace referencia al enfoque es
tadístico de la regresión lineal por mínimos cuadrados. Este tipo de regresión se basa en el método
de "Mínimos cuadrados" [Jud85, GHJ93, Wei85].
Los modelos generados por el método de los mínimos cuadrados se pueden representar como se
muestra en la ecuación B.l.
y = bQ + biXi + b2X2 + ... + bkXk + e (B.l)
donde y es la variable de respuesta o a predecir, 6o es el coeficiente de intercepción, Xi es la variable
predictora ¿-ésima, 6¿ es el coeficiente de la variable predictora i-ésima, k es el número de variables
y efc es el error. El error es una variable aleatoria con una distribución normal de probabilidad. Este
método de regresión calcula los coeficiente bi tratando de minimizeir el mínimo error cuadrado r?
donde r es la diferencia entre el valor de respuesta observado y el obtenido por el modelo de re
gresión para el ¿-ésimo valor observado.
La formula de la ecuación (B.l) representa un hiperplano en un espacio fc-dimensional para la
variable predictora Xj ([HM72]). Para obtener los coeficiente (6¿) de las variables predictoras (x¿), se
utiliza el método de los mínimos cuadrados que minimiza el error. La función de mínimos cuadra
dos es la que se muestra en la ecuación (B.2). n n
L = ^ e| ^ Y2[Yj -b'o- biixij - xi) - . . . - bkixkj - x^)]^ (B.2)
1 " í¿ = - 2_^ Xij
b'o = bo + bixi + b2X2 - I - . . . -f bkXk
•MODELO MATEMÁTICO PARAMÍTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING IDMCOMOf
APÉNDICE B. REGRESIÓN MÚLTIPLE 136
donde n es el número de observaciones, Cj es el error para la observación j-ésima, x¡j es la obser
vación j-ésima para la variable z-ésima. El número de observaciones (n) debería ser igual o superior
a fc + 1 para la regresión. Derivando la ecuación (B.2) e igualando a cero para bó y bi
^ = EK-¿ó]=0 {B.3)
7— = SiY — biSii — b2Si2 — ... bkSik = O Obi
n
n
Ors — / \'^TJ '^r) v^sj **'s/
n
donde Su es la suma corregida de los cuadrados para la variable i-ésima, Srs es la suma corregida
de los productos cruzados entre XrY XsY SÍY es la suma de los productos cruzados entre Xi y la
variables de respuesta Y.
Realizando transformaciones algebraicas, se obtienen p = k + l ecuaciones de la siguiente forma
n
nb', = Y.Y¿ (B.4)
biSii + ... + bkSik = SiY
Resolviendo las ecuaciones de la ecuación (B.4), se obtienen los valores de los coeficientes de la
regresión (5¿).
Este método de regresión es apropiado si:
1. El conjunto de datos es lo suficientemente grande. Esto indica que el número de grados de
libertad son mayores que el número de variables a predecir.
2. Hay ausencia de valores "nulos".
3. No hay valores extraños ("outliers").
4. Las variables predictoras no tienen correlación entre ellas.
5. Las variables predictoras son de fácil interpretación cuando se utiliza el modelo.
•MODELO MATEMÁTICO PABAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MININO (DMCOMOt
Apéndice C
Datos utilizados para DÍVICOlVIO
Los datos que se han utilizado (figura C.l) provienen de proyectos de Data Mining realizados por
el grupo de Bases de Datos de la Facultad de Informática de la Universidad Politécnica (Madrid,
España), por la Universidad del Valle (Cali, Colombia), por la Universidad de Stony Brook (Nueva
York, U.SA.) y por el Naval Research Laboratory (Monterrey, U.S.A.).
Este apéndice muestra un resumen de los datos utilizados para la creación de la ecuación de DM-
COMO. Se muestran los datos recogidos (figura C.l), la correlación de los drivers de coste recogidos
(C.2), los datos finales (figura C.3), después de eliminar las variables con alto índice de correlación,
que se han utilizado para la creación de la ecuación de estimación del esftierzo así como las dis
tribuciones, en forma de histogramas, de los 23 drivers de coste de los proyectos utilizados para
crear el modelo.
'MODULO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOf
APÉNDICE C. DATOS UTILIZADOS PARA DMCOMO 138
O
05
co
co
co co
LO
co
co
co co
CN]
co
co
co
CJ) CNI
CNJ
CM
CM
CNJ
CN
co CNI
CNJ CNI
cÑ]
O CNJ
a>
oo
h-
CD
m
•^ co
CM
-O
CfS
co
h-
CD
lO
TT
co
CNJ
• * "
2
2
<
^
z
i <
i ^ •z.
i z
i z
g z
DD
< i <
S <
i i i i i ^ i i §§
^
i ^ i i ^
^
i
i
i
z
i <
<
i i Cü
CQ
i <
m
<
<
i i co
z
i i i m
i m
a.
CQ
Z
< i i i z
i i i i CQ
i <
< i
1
<
z
z
<
z
m
OQ
CQ
<
< CQ
<
<
< CQ
OQ
< CQ
m
<
OQ
OQ
<
OQ
< s. < OQ
OQ
OQ
< OQ
Z
z
OQ
z OQ
<
m
z
z
Q; !< z
OQ
z
i OQ
i CQ
i i <
i i i CQ
i 2
i i <
i <
2
<
i i OQ
i <
i i OQ
z
i i OQ
2
2
<
i i Q3
i
<
i CQ
i OQ
i m
i i CQ
<
z
z
z
i <
< i i i <
i i i z
i <
z
i i i z
OQ
i i CQ
i OQ
i i
i
CQ
<
i QQ
i Z
m
CQ
Z
m
i z
z
OQ
i i OQ
<
Z
<
i ^
i i z:
z
OQ
CQ
z
i m
i < i i
i ^ i z
OQ
<
i i i <
OQ
OQ
Z
OQ
i
Z
m
i i Cü
<
z:
<
i i i i
m
OQ
OQ
z
i m
i < i i z
i i i OQ
1
CQ
Z
CQ
Z
<
z
<
<
<
OQ
<
m
CQ
CQ
CQ
CQ
z
OQ
<
<
<
<
<
<
<
<
CQ
Z
<
<
<
OQ
OQ
<
<
<
Z
OQ
<
OQ
> ce o.
CQ
z
OQ
2-
<
<
i i OQ
<
CQ
OQ
OQ
OQ
OO
Z
CQ
i i i i i i i i 00
z
i i i CQ
OQ
<
i i 2
CQ
i CQ
1
00
<
<
OQ
<
OQ
CQ
CQ
CQ
CO
CQ
OQ
Z
OQ
OQ
<
Z
00
z
CQ
<
<
CQ
CQ
Z
CQ
OQ
m
CD
oo
<
CQ
<
z
z
<
<
CQ
z < 2
o o z
<
< <
<
i CQ
2
<
Z <
2
00
2
m
00
CQ
<
z <
co
2
Z
2
<
< 00
2 00
co
i <
CQ
OQ
00
oo
2
2
2
<
co
<
O 1—
i <
03
z
i i i < i i i z
CQ
i <
<
z
OQ
<
i CQ
CQ
i CQ
<
CQ
<
i i <
OQ
i Z
CQ
i i
i
<
z
<
00
<
i oo
i z
<
OQ
<
i <
<
CQ
CQ
i 00
i i i i 00
CD
z
<
OQ
i i i z
oo
co
<
i <
<
i en
1
00
z <
00
CQ
CQ
OQ
CQ
<
CQ
OQ
00
OQ
< 2 z
00
< 2 <
OQ
<
2
< <
<
OQ
m
<
co
OQ
CQ
z < 2 00
00
z
z
< < 2 CQ
co
C/5
Q
<
z
<
co
<
i CQ
<
<
i CQ
<
i <
<
OQ
OQ
i i i Z
00
00
<
i
<
CQ
i OQ
i i i i CD
m
i z
<
00
1
i i OQ
i i i CQ
i i OQ
i i i 2
<
<
< i 2
z
i i <
OQ
<
<
<
Z
CQ
i i i <
i i z
i i DD
2
Cü
Z
Cü
i z
z
z
i z
OQ
Z
<
Cü
CQ
z
<
i CQ
i i i OQ
i <
CQ
Z
CQ
< OQ
z
z
< i
m
<
<
<
i
z
CQ
z
OQ
Z
z CQ
2
Z
•3
OQ
Z
z
<
CQ
Z
CQ
< OQ
2
CQ
00
2 00
2 CQ
2 00
00 2
<
CQ
Z
OQ
<
m
co
2
<
00
<
00
2
<
<
Ü:
LU
w 2
CQ
2
OQ
2
00
<
CQ
<
Z
<
CQ
CQ
OQ
CÜ
2 CQ
2
Z
00
CD
OO
z OQ
2
CQ
CQ
CQ
2
00
00
<
< CQ
2
z
<
z
OQ
00
00
2 <
<
OQ
Z
CO
2
o O co
<
i i i CQ
i
CQ
2-
i i i i <
00
i i <
i OQ
1 i i i i <
Z
CQ
Z
<
<
Z
Cü
Z
<
<
z
<
i i
^
00
i z
CQ
2-
OQ
<
<
<
<
Z
<
<
Z
OQ
Z
<
<
z
<
i i i i i <
OQ
i i < i co
i i i i i <
z
oo
CQ
i z
CD
i CQ
CO
CQ
i Cü
i i <
00
i i i i z
i OQ
i i <
OQ
i i <
<
i <
<
i 2
i <
z
00
<
z
i
<
<
<
<
OQ
00
2
00
2
00
<
co
<
<
co
OQ
OQ
<
<
OQ
<
<
OO
co
CQ
<
z
CD
z
<
<
z
CQ
z
<
<
z
<
<
CD
2 O ü
<
<
<
<
OQ
OQ
z
oo
z
CQ
<
OQ
<
<
Cü
CÜ
tn
<
<
CQ
<
<
co
CQ
CQ
<
Z
OQ
Z
<
<
2
OQ
Z
<
<
z
<
<
CQ
2 O 1—
<
i i i CQ
i Z
CD
i <
i i <
00
i i <
i OQ
i i CQ
i DO
<
Z
OQ
z
<
<
z
CQ
Z
<
<
z
<
<
i
OQ
CQ
CQ
OQ
i OQ
i 00
<
i z
i i z
z
CÜ
z
00
<
i oo
m
i i i <
i 00
z
DO
<
CQ
<
OQ
<
CO
i i <
i
CQ
CD
CQ
CQ
< 2 00
00
00
< <
z
CQ
<
z
z
CQ
2
CQ
<
CQ
CQ
CQ
< 2 < 2 <
< < 2 CQ
Z
00
<
oo
z
<
OQ
<
OQ
OQ
CQ
<
00
<
CQ
<
Z
z
CQ
z
<
CQ
z
<
z
00
00
00
z
z
<
<
00
00
z
OQ
CQ
z
00
00
00
oo
<
CQ
co
<
<
<
z
Cü
00
z
o. LU
o 2
00
£0
< 2 D3
00
< < 2 OQ
< <
<
<
z
2
CQ
< 2 OQ
<
Z
OQ
<
<
< < 2 <
CQ
CD
00
<
00
<
z
OQ
z
i < <
i CQ
2
o o o
<
CQ
CQ
<
<
<
2
<
CD
<
Z
<
CO
co
2
OQ
<
OQ
Z
<
z
<
<
CD
OQ
<
<
OQ
<
CD
<
<
<
OQ
<
00
CD
<
CQ
z
2 CO
2
<
z CD
2
< < 2 CQ
< CQ
z
z < 2 co 2 < 2 OQ
CQ
<
Z
z
00
^ < 2 ^
<
00
< 2 CQ
2
^
CQ
Z
00
z
<
<
OQ
^
^
z
^
co OQ
2
LU 1— CO
oo
< 2 00
z
<
z
<
z
<
z
<
<
CQ
2
Z
OO
<
CQ
z
<
z
<
oo
z
DO
z
<
CQ
2
00
<
CQ
<
OQ
2
OQ
Z
CQ
2
< 2
2 O ü
<
CD
CQ
<
<
<
2
<
00
<
z
<
00
OQ
2
00
<
00
z
<
z
<
<
CD
OQ
<
<
OO
<
CQ
<
<
<
OQ
<
CO
00
<
CQ
z
2 O O Q.
CQ
z
z
z
00
z
CQ
z
2
i i Z
CQ
Z
i OQ
Z
OQ
i z
CQ
i
2
00
00
z
z
z
z
i i i i
CQ
Cü
00
co
i
co
CQ
i CD
i i CQ
Z
CO
i i i CQ
z
i
i i Cü
CD
i CO
CQ
CQ
CQ
i z
i i CQ
OQ
Z
00
00
CQ
OQ
i z
í
<
OQ
OQ
<
Z
<
Z
<
CO
<
2
<
CO
CQ
2
CO
<
00
z
<
2
<
<
CQ
CQ
<
< OQ
2
<
OQ
2
<
<
CQ
Z
OO
2
<
OQ
2
Q. X LU CL
i 00
i i i i z
i i i
i CQ
i Z
OQ
i OQ
z
<
z
<
i i CQ
i <
CD
<
CO
<
< i i i CQ
CQ
1 i z
i
<
Cü
co
<
co
<
z
<
Cü
<
z
<
oo
oo
z
oo
<
CQ
z
<
2
<
00
CQ
00
<
<
CQ
<
OQ
<
OQ
<
OQ
<
00
CQ
DO
CO
z
CL
X LU 1—
Cü
< 00
z
<
z
<
z
<
z
<
<
co
z
z
OQ
< CQ
<
Z
<
00
.
CQ
Z
< CQ
Z
OO
<
CD
< 00
CQ
z
CQ
Cü
i
CM
o
co
un
CM
t^
CM
IT)
OO
O)
O CM
CM CN
CM
C»
CC7 CM
• *
CO
CD
r
o
CM
r-
CM
CM
•«r
05
CD
CM
CM
oj
1^
m
oo
o
o
CM CVJ
CM
CD
?>J
CD
CM
• *
oo
lO
l-~
LO
lO CM
r
co
co
LO
CD
• t
• ^
l~-
OO
CD
CD
CO
•<3-
h-
00
co
o
-CD
OO
IÍ5
CD
CO
OO
CO
CO
CM
CM
h-
-CO
in
o
a.
Figura C.l: Base de datos inicial de proyectos
• MODELO MATEMÁTICO PAKAMÉTRJCO DE ESTIMACIÓN PARA PROVECTOS DE DATA MINING (DMCOMOf
APÉNDICE C, DATOS UTIUZADOS PARA DMCOMO 139
Figura C.2: Correlación entre variables ' MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO/
APÉNDICE C. DATOS UTILIZADOS PARA DMCOMO 140
i 1 1 i i 1 1 i i 1 i i i i 1 i i i i i 1 i 1 i
o
z
z
CQ
Z
z
<
z
CQ
z
<
co
00
CQ
<
<
m
CQ
< 2
m
z
CQ
CQ
• *
m 2
CQ
CQ
CQ
CQ
CQ
CQ
2
<
<
CQ
<
<
CD
z
CQ
Z
<
CQ
< 2 CQ
Z
<
z
00
<
CQ
CO
^
<
m
CQ
CQ
<
Z
<
< 2
<
CQ
<
CQ
CQ
<
CQ
<
CQ
<
<
oo
CQ
Z
CQ
Z
<
2
CQ
Z
z
m
CQ
z
<
<
z
<
z
<
<
<
<
CQ
g
O)
CQ
CQ
Z
^
<
<
<
<
<
<
z
CQ
2
03
2
CQ
Z
<
< 2
z
co
z
CQ
2
CQ
^
in
< 2
CQ
CQ
^
< 2
<
CQ
< 2
<
<
CQ
2
< 2
<
Z
z
z
< 2
< 2
< 2
z
z
< 2
CQ
2
g
i
CQ
i CQ
Z
<
<
z
z
i
<
<
CQ
s CQ
Z
<
i
i CQ
CQ
i
i
O
< 2
Z
CQ
2
<
CQ
CQ
Z
CQ
2
CQ
CQ
Z
< 2
CQ
CQ
CQ
2
<
CO
<
co
m 2
z
< 2
^
o
<
CQ
OQ
2
<
z
CQ
CQ
<
Z
CQ
Z
CQ
2
Z
z
CQ
OQ
CQ
< 2
Z
< 2
z
< 2
< 2
<
CQ
Z
z
<
<
<
<
<
z
CQ
< 2
CQ
2
<
CQ
<
< 2
m
co 2
z
OQ
2
z
g
co oo
CD
CQ
2
Z
m
CQ
en
CQ
<
<
<
CQ
< 2
< 2
< 2
CQ
< 2
CQ
2
OQ
2
CQ
<
<
CQ X
(
<
CQ
2
Z
z
<
CQ
z
<
z
z
CQ
z
CQ
2
< 2
< 2
CQ
< 2
Z
< 2 CQ
2
m
< 2
2
LO O)
CQ
Z
z
CQ
CQ
CQ
CQ
<
CQ
en 2
z
<
CQ
<
CQ
m
z
CQ
z
CQ
2
CQ
OQ
2
CQ
2
11—
CNJ
<
Z
m
^
OQ
CQ
< 2
CQ
2
Z
<
CQ
<
<
CQ
CQ
m
CQ
m
<
<
CQ
2
<
^
C55
<
CD
CQ
CQ
2
CCI
2
<
< 5
<
<
<
<
2
2
CD
CQ
<
OQ
< 2 CQ
2
<
2
CQ
2
O
CQ
CQ
Z
< 2
<
CD
< 2
CD
CD
2
OQ
2
CD
2
z
OQ
<
<
z
< 2
Z
z
CQ
< 2
m
< 2
lO
CQ
2
CQ
Z
CQ
< 2
CD
< 2
<
CQ
2
CQ
CQ
CQ
CQ
CQ
<
CQ
< 2
< 2
< 2 < 2
CQ
OQ
< 2
< 2
CQ
CQ
2
<
<
z
< 2
< 2
CQ
2
CQ
2
CD
2
<
m 2
< 2
z
CD
< 2
< 2
< 2
< 2
< 2
CD
CQ
2
O Cvj
<
OQ
OQ
í <
CQ
CQ
CQ
2
< 2
CQ
CD
2
co 2
en 2
CQ
Z
<
< 2
< 2
< 2
<
CQ
OQ
2
< 2
O)
Z
CQ
2
2
< 2
<
CQ
CQ
OQ
< 2
OQ
CO
2
CQ
2
CQ
2
CQ
Z
<
< 2
CQ
2
<
z
OQ
CQ
<
00 co
<
OQ
en 2
^
co
<
en 2
< 2
CQ
OQ
2
CQ
Z
CQ
2
CQ
2
CQ
2
en
< 2
<
< 2
<
<
co 2
co X
m
z
CQ
CQ
OQ
Z
<
<
z
< 2
Z
CQ
2
Z
CQ
<
< 2
Z
< 2
Z
< 2 CQ
2
OQ
< 2
<
• *
CQ
CO
2
Z
z
<
2
CQ
< 2
<
OQ
<
< 2
co 2
oo
z
CQ
OQ
<
OQ
2
<
m 2
< 2
CD
2
CM
< 2
co 2
CD
Z
CD
Z
z
< 2
CO
2
CQ
2
<
CQ
Z
<
z
z
CQ
<
< 2
<
z
<
00
co
z
en 2
<
< 2
OQ
CD
< 2
CQ
2
CQ
co
<
OQ
<
CD
2
<
co
< 2
<
co 2
co 2
CD
CO
O
Z
ca 2
z
CD
OQ
OQ
Z
< 2
co
z
OQ
<
<
<
00
CQ
CQ
< 2
CQ
2
2
OQ
2
OQ
2
z
CSJ
CD
2
Z
CD
CD
Z
OQ
Z
CQ
<
CQ
2
<
z
<
OQ
2
en
CQ
co
co
z
< 2
<
< 2
CQ X
O CM
CQ
CQ
Z
< 2
z
z
< 2
<
< 2
en 2
2
OQ
2
< 2
OQ
Z
z
CQ
2
Z
eo
<
<
z
co o
< 2
OQ
2
OQ
2
OQ
2
<
<
CQ
2
< 2
en 2
en
en
< 2
<
z
CQ
CQ
CD
2
2
CD
2
< 2
<
OQ
2
O
z
OQ
2
CQ
2
i <
z
2
< 2
< 2
eo
2
< 2
CQ
< 2
2
OQ
<
CQ
2
<
00
2
CQ
2
CO
2
CO
< 2
co 2
z
z
< 2
OQ
< 2
en
co 2
CQ
CD 2
CD
<
en 2
< 2
CQ
CO
CQ
CQ
00
2
<
<
CO
2
co CO
CQ
2
CQ
Z
z
<
<
<
< 2
z
<
2
< 2
z
co 2
z
m
< 2
2
< 2
<
< 2
< 2
2
CO CM
< 2
2
2
CQ
2
OQ
2
CD
m
en
2
2
< 2
< 2
<
<
co
< 2
m
< 2 CQ
2
CO
OQ
z
oo
Z
OO
co
<
< 2
00
co 2
CQ
Z
<
z
OQ
ca
OQ
2
z
CQ
<
CQ
en
CQ
2
en
co
< 2
o CVJ
< 2
CQ
2
z
03
<
Z
CQ
m
en 2
OQ
OQ
2
CQ
2
co 2
< 2
co
CD
z
<
< 2
CD
CD
< 2
<
O)
< 2
OQ
2
CQ
< 2
en
z
< 2
en 2
OQ
<
2
< 2
<
en 2
< 2
<
<
CD
2
CQ
CQ
2
2
CD
2
00 2
co CM
< 2
CD
2
<
CQ
<
CQ
CQ
< 2
CQ
OQ
< 2
CQ
2
<
CQ
2
OQ
2
< 2
CQ
<
<
Z
•<1-
00
CD 2
co 2
z
CQ
2
< 2
CQ
CQ
2
< 2
2
2
CQ
<
OQ
< 2
<
CD
OQ
2
co
< 2
z
<
^
N-
CD
CD
z
z
CQ
<
CD
< 2
< 2
CD
CD
< 2
z
<
<
<
z
<
CQ
2
z
z
oo 2
<
Tí
< 2
CO
co
<
CQ
CQ
CQ
CQ
<
eo 2
Z
< 2
<
< 2
< 2
CQ
CQ
CD
<
CO
<
z
z
Figura C.3: Base de datos final de proyectos
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DEDATAMINING ÍDMCOMO!
APÉNDICE C. DATOS UTILIZADOS PARA DMCOMO 141
NTAB NTUP
LL O
Std. Dev = 1,99
Mean = 3,1
0,0 1,0 2,0 3,0 4,0 5,0 6,0
IStd. Dev = 1,54
lMean = 3,1
O ^ ^ ^ ^ B ^ ^ ^ ^ g ^ B ^ ^ ^ N = 40,00
1,0 2,0 3,0 4,0 5,0
m"AB Nrrup
NATR DISP
ra
m IStd. Dev = 1,31
I Mean = 2,9 O ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ m ^ ^ ^ ^ N = 40,00
1,0 2,0 3,0 4,0 5,0
0) 2 Std. Dev = 1,51
Mean = 2,7
1,0 2,0 3,0 4,0 5,0
NATR DISP
PNUL CCOD
<0 4 O
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 1 std. Dev = 1,52
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ H tutean = 3,4 O
1,0 2.0 3,0 4,0 5,0 1,0 2,0 3,0 4,0 5,0 6,0
PNUL CCOD
' MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMOf
APÉNDICE C. DATOS UTIUZADOS PARA DMCOMO 142
DMOD PRIV
o I Std. Dev = 1,46
I Mean = 2,9
1,0 2,0 3,0 4,0 5,0
Std. Dev = ,92
Mean = 3,15
N = 40,00
2,00 2,50 3,00 3,50 4,00
DMOD PRIV
DEXT NMOD
'o I Std, Dev = 1,34
I Mean = 3,6
O ^ ^ ^ • • • ^ ^ ^ ^ ^ ^ ^ ^ ^ ( = 40.00
2,0 3,0 4,0 5,0
l l O
Mean = 2,8
N = 40,00
2,0 3,0 4,0 5,0
DEXT NMOD
TMOD MTUP
std. Dev = 1,26
Mean = 3,1
N = 40,00
1,0 2,0 3,0 4,0 5,0
TMOD
1,0 2,0 3,0 4,0 5,0
MTUP
•MODELO MATEMÁTICO PAEAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO!
APÉNDICE C. DATOS UTIUZADOS PARA DMCOMO 143
MATR MDIS
Std. Dev = 1,33
Mean = 2,6
N = 40,00
Std. Dev = 1,19
Mean - 3,0
N = 40.00
1,0 2,0 3,0 4,0 5,0 2,0 3,0 4,0 5,0
MATR MDIS
MDER MTEC
g 4 ü
Std. DBV = 1,33
Mean = 2,6 ; ; 2
1,0 2,0 3,0 4,0 5,0
IStd. Dev = 1,48
I Mean = 3,5
1,0 2,0 3,0 4,0 5,0
MDER MTEC
NFUN NSER
std. Dev = 1,04
Mean = 2,5
N = 40,00
Std. Dev = 1,01
Mean = 2,5
N = 40,00
NSER
• MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MININC ÍDMCOMOf
APÉNDICE C. DATOS UTILIZADOS PARA DMCOMO 144
SCOM TOOL
(O
<u
1.0 2,0 3,0 4,0
IStd.Dev = 1,49
I Mean = 3,1
1,0 2,0 3,0 4,0 5,0
SCOM TOOL
^ "EC COMP
Mean =2,3
N = 40,00
1,0 2,0 3,0 4,0
IStd. Dev = 1,45
I Mean = 3,3
O ^ ^ ^ B I I ^ I ^ ^ ^ ^ ^ ^ B J l J N = 1,0 2,0 3,0 4,0 5.0
NTEC COMP
TCOM TOMM
Std. Dev = ,92
Mean = 3,08
u. O
2,00 2,50 3,00 3,50 4,00 2,00 2,50 3,00 3,50 4,00
TCOM TOMM
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOy
APÉNDICE C. DATOS UTILIZADOS PARA DMCOMO 145
TRAN NFOR
a ISM. Dev = 1,38
|Mean=3,1
O I J j ^ ^ H ^ ^ ^ ^ ^ ^ ^ ^ ^ B N = 40,00 1,0 2,0 3,0 4,0 5,0
Std.Dev = 1,34
Mean = 2,9
N = 40,00
1,0 2,0 3,0 4,0 5,0
TRAN NFOR
TFRI NDEP
Std. Dev = 1,19
2,0 3,0 4,0 5,0 2,00 2,50 3,00 3,50 4,00
TFRI NDEP
DOCU MSIM
std. Dev = 1,17
Mean = 3,4
N = 40,00
Std. Dev = ,93
2,00 2,60 3,00 3,50 4,00
MSIM
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PADA PPOYECTOS DE DATA MINING (DMCOMOf
APÉNDICE C. DATOS UTILIZADOS PARA DMCOMO 146
SITE PCON
ISld.Dev = 1,63
I Mean = 3,4
1,0 2,0 3,0 4,0 5,0 6,0
KDAT
Std. Dev = ,93
N = 40,00
2,00 2,50 3,00 3,60 4,00 1,00 1,50 2,00 2,50 3,00
PCOM KDAT
ADIR PEXP
std. Dev = ,74
Mean = 3,0
N = 40,00
1,00 1,50 2,00 2,50 3,00 1,0 2,0 3,0 4,0
ADIR PEXP
'MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOy
APÉNDICE C. DATOS UTILIZADOS PARA DMCOMO 147
MFAM TEXP
o . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ S t d . Dev = 1,50
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ H Mean
1,0 2,0 3,0 4,0 5,0
Std. Dev = ,93
Mean = 2,90
2,00 2,50 3,00 3,50 4,00
MFAM TEXP
BCON
std. Dev = ,81
Mean = 2,95
2,00 2,50 3,00 3,50 4,00
BCON
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROrSCrOS DE DATA MINING ÍDMCOMOy
Apéndice D
Modelo DMCOMO
En este apéndice se agrupan la ecuación y los drivers de coste propuestos para el modelos DMCO
MO.
E{p) = 78,752 + 2,802 x NTAB + 1,953 x NTUP + 2,115 x NATR + 6,426 x DISP+
+ 0,345 x PNUL + (-2,656) x DMOD + 2,586 x DEXT + (-0,456) x NMOD
+ 6,032 X TMOD + 4,312 x MTUP + 4,966 x MATR + (-2,591) x MTEC+
+ 3,943 X NFUN + 0,896 x SCOM + (-4,615) x TOOL + (-1,831) x COMP+
+ (-4,689) X NFOR + 2,931 x NDEP + (-0,892) x DOCU + 2,135 x SITE
+ (-0,214) X KDAT + (-3,756) x ADIR + (-4,543) x MFAM
(D.l)
Cost Drivers NTAB
NTUP
NATR
DISP' PNUL' DMOD
DEXT
NMOD
Extra bajo
Hasta 20 tablas
Todos los modelos
Muy bajo
De 20 a 50 tablas Menos de 5 * lO'' tupias
Menos de 500 atributos
0 < H < 0,2 1 El 90 % de los modelos
Bajo
De 50 a 80 tablas Entre 5 * 10'' y 10 * lO'' tupias Entre 500 y 1000 atributos 0,2 < H < 0,4 2 Entre el 80 % y el 90% de los modelos Entre 1 y 3 fuentes externas D e l a 3
Nominal
De 80 a 100 tablas Entre 10* 10' y 20 * 10'' tupias Entre 1000 y 1500 atributos 0,4 < H < 0,6 3 Entre el 70 % y el 80% de los modelos Entre 3 y 5 fuentes extemas De3a5
Alto
De 100 a 200 tablas Entre 20* 10' y 50 * 10^ tupias Entre 1500 y 2000 atributos 0,6 < H < 0,8 4 Entre el 60 % y el 70% de los modelos Entre 5 y 7 fuentes externas De5a7
Muy alto
De 200 a 300 tablas Más de 50 * 10'' tupias
Más de 2000 atributos
0,8 < H < 1 5 Menos del 60% de los modelos Más de 7 fiíentes externas Más de 7
Extra alto
Más de 300 tablas
'MODELO MATEMÁTICO PARAMÉTBICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
APÉNDICE D. MODELO DMCOMO 149
Cost Drivers TMOD' MTUP' MATR' MTEC NFUN
SCOM
TOOL
COMP' NFOR" NDEP
DOCU
SITE KDAT
ADIR
MFAM'
Extra bajo
0
Muy bajo
1 1 1 1 Una sola fuente de datos
Datos en la misma máquina donde se van a analizar
Se utilizarán herramientas para el desarrollo de todos los modelos
1 1
Colaboración de personal experto en los datos y en el negocio
Dirección del departamento y de la empresa apoyan
1
Bajo
2 2 2 2 2-3 fuentes homogéneas
Datos en la misma base de datos
Más del 70% de los modelos se desarrollaran utilizando una herramienta
2 2 1 departamento
El modelo que se implanta
Colaboración de personal experto en los datos
Dirección del departamento apoya pero la de la empresa no apoya 2
Nominal
3 3 3 3 2-3 fuentes heterogéneas
Todos los orígenes de datos datos en el mismo edificio, comunicación a través de LAN
Entre el 50 % y el 70% de los modelos se desarrollaran utilizando una herramienta 3 3 2 departamentos
Todos los modelos generados
Ver tabla D.IO No está familiarizado con los datos. Descripción de los datos (no tiene porque ser real) Director del departamento apoya y dirección no se opone
3
Alto
4 4 4 4 Más de 3 fuentes heterogéneas sin ficheros en papel Todos los orígenes de datos en un lugar diferente a donde se van a analizar pero existe comunicación entre ellos Hasta el 50% de los modelos se desarrollaran utilizando una herramienta
4 4 Entre 3 y 5 departamentos Todos los modelos y para las fases centrales de Data Mining
No hay descripción ni modelo de los datos
Dirección del departamento no apoya y dirección de la empresa no apoya 4
Muy alto
5 5 5 5 Más de 3 fuentes heterogéneas con algún fichero en papel Todos los orígenes de datos en un lugar diferente a donde se van a analizar y no existe comunicación entre ellos No se utilizarán herramientas
5 5 Más de 5 departamentos
Todos los modelos y para todas las fases de Data Mining
Extra alto
6
5 Tabla D.i: Descripción de los drivers de coste de DMCOMO
Los valores a utilizar en la ecuación se corresponden con XB = O, MB = 1, B - 2, N = S, A = A,
MA = 5,XA^ 6.
'Ver descripción más abajo
• MODELO MATEMA TICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO)'
APÉNDICE D. MODELO DMCOMO 150
Cakulo del valor DISP
Disp=^lY:-f+j:^]-M (D.2)
siendo i el número de atributos cuantitativos, j el número de atributos cuantitativos, V la varianza
y M la media de todos los valores de las varianzas y las entropías de los atributo. La resta de M y la
división por V se hace para normalizar los valores de la dispersión de los atributos en el intervalo
[0,1]
Calculo del valor PNUL
Calcular el porcentaje de nulos para cada atributo haciendo uso de la tabla D.2.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Hasta un 10 % de valores nulos Desde un 10 % hasta un 15 % de valores nulos Desde un 15 % hasta un 20 % de valores nulos Desde un 20 % hasta un 25 % de valores nulos Más de 25 % de valores nulos
Valor 1 2 3 4 5
Tabla D.2: PNULp. Factor PNUL para cada atributo
Utilizar la ecuación D.3 para calcular el valor de PNUL y consultar el nivel del driver PNUL en la
tabla D.l.
(D.3) PNUL = ROUNDI^^^^^^IM1'^
Calculo del valor TMOD
Calcular TMOD para cada modelo haciendo uso de la tabla D.3.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Modelo descriptivo: Asociación Modelo descriptivo: Clustering Modelo descriptivo: Patrones secuenciales Modelo predictivo: Clasificación Modelo predictivo: Predicción o Estimación o Series temporales
Valor 1 2 3 4 5
Tabla D.3: TMODp. Factor TMOD para cada modelo
Utilizar la ecuación D.4 para calcular el valor de TMOD y consultar el nivel del driver TMOD en la
tabla D.l.
(D.4) TMOD = ROUND(^^^'''''''-^1
Calculo del valor MTUP
Calcular MTUP para cada modelo haciendo uso de la tabla D.4.
•MODELO MATEMÁTICO PARAMÉTUICO DE ESTIMACIÓN PARA PROyECTOS DE DATA MINING (DMCOMOy
APÉNDICE D. MODELO DMCOMO 151
Rango Muy bajo Bajo Nominal Alto Muy alto
Descrípción Menos de 5 * 10* Entre 5 * 10* y 10 * 10** Entrel0*10'*y20*10'' Entre 20 * 10** y 50 * 10* Más de 50 * lO'*
Valor 1 2 3 4 5
Tabla D.4: MTUPp. Factor MTUP para cada modelo
Utilizar la ecuación D.5 para calcular el valor de MTUP y consultar el nivel del driver MTUP en la
tabla D.l.
Calculo del valor MATR
Calcular el número y el tipo de atributos para cada modelo para cada modelo haciendo uso de la
tablas D.5 y D.6.
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Menos de 10 atributos Entre 10 y 20 atributos Entre 30 y 50 atributos Entre 50 y 70 atributos Más de 70 atributos
Valor 1 2 3 4 5
Tabla D.5: MATRnp. Factor MATRn para cada modelo
Rango Muy bajo Bajo Nominal Alto Muy alto
Descripción Todos los atributos no numéricos Mayor número de atributos no numéricos que de atributos numéricos 50 % de atributos numéricos y 50 % de atributos no numéricos Mayor número de atributos numéricos que de atributos no numéricos Todos los atributos numéricos
Valor 1 2 3 4 5
Tabla D.6: MATRtp. Factor MATRt para cada modelo
Calcular los valores MATRn y MATRt de todos los modelos haciendo uso de las ecuaciones (D.6)
MATRn = ROUND(^^-^^^^^^^^^ n
MATRt = R0UND[^^1^Í^^^^)
(D.6)
Para obtener el valor de MATR utilizar la ecuación D.7 para calcular el valor de MATR y consultar el
nivel del driver MATR en la tabla D.l.
. , , ^ „ ^^,,,,^ÍMATRn + MATRt\ MATR = TRUNCi ^ ) (D.7)
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOf
APÉNDICE D. MODELO DMCOMO 152
Calculo del valor MTEC
Calcular MTEC para cada modelo haciendo uso de la tabla D.7.
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Extra alto
Modelos Descriptivos Descripción Existen más de cuatro técnicas para el modelo a generar Existen 3 técnicas para el modelo a generar
Existen 2 técnicas para el modelo a generar Existen 1 técnicas para el modelo a generar "
~
Valor 1
2
3
4
~
-
Modelos Predictivos Descripción
Existen más de cuatro técnicas para el modelo a generar Existen 4 técnicas para el modelo a generar Existen 3 técnicas para el modelo a generar Existen 2 técnicas para el modelo a generar Solo existe 1 técnica para el modelo a generar
Valor
2
3
4
5
6
Tabla D.7: MTECp. Factor MTEC para cada modelo
Utilizar la ecuación D.8 para calcular el valor de MTEC y consultar el nivel del driver MTEC en la
tabla D.l.
MTEC = ROUND(^^^-^^^^^^^) (D.8)
Calculo del valor COMP
Calcular COMP para cada herramienta haciendo uso de la tabla D.8.
Rango Extrabajo
Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción Compatibilidad nula con el resto de herramientas disponibles en la organización Compatibilidad con editores de texto disponibles en la organización Compatibilidad con editores de texto y hojas de cálculo disponibles en la organización Compatibilidad con editores de texto, hojas de cálculo y SGBD disponibles en la organización Compatibilidad con editores de texto, hojas de cálculo, SGBD y herramientas de Data Mining disponibles en la organización Compatibilidad e integración total con el resto de herramientas disponibles en la orgeinización
Valor 0
1
2
3
4
5
Tabla D.8: COMPp. Factor COMP para cada herramienta
Utilizar la ecuación D.9 para calcular el valor de COMP y consultar el nivel del driver COMP en la
tabla D.l.
(D.9) COMP = ROUNDI^^^-^^^)
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING (DMCOMO}'
APÉNDICE D. MODELO DMCOMO 153
Calculo del valor NFOR
Calcular NFOR para cada herramienta haciendo uso de la tabla D.9.
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción La herramienta utiliza asistentes y agentes inteligentes que guían al usuario a través del proceso de Data Mining. El usuario únicamente necesita un leve conocimiento de las técnicas de Data Mining Conocimiento de las técnicas de Data Mining. La herramienta funciona a través de asistentes Conocimiento ligero de las técnicas de Data Mining y de la herramienta Conocimiento de la técnicas de Data Mining y experto en la herramienta Experto tanto en técnicas de Data Mining como en la herramienta
Valor 1
2
3
4
5
Tabla D.9: NFORp. Factor NFOR para cada herramienta
Utilizar la ecuación D.IO para calcular el valor de NFOR y consultar el nivel del driver NFOR en la
tabla D.l.
NFOR ^ ROUND (ELl^íi:2Ml] (D.lO) n
Tabla del driver SITE
Rango
Muy bajo
Bajo
Nominal
Alto
Muy alto
Extra alto
Descripción Ubicación En el mismo lugar
Mismo edificio o complejo
Misma ciudad o área metropolitana Varias ciudades y varias compañías Varias ciudades y varias compañías Internacional
Comunicaciones Comunicación multimedia interactiva Banda ancha de comunicaciones y ocasionalmente videoconferencia Banda ancha de comunicaciones Banda estrecha de comunicaciones, e-mail Teléfono, FAX
Teléfono, correo
Valor
1
2
3
4
5
6
Tabla D.lO: Factor SITE
Calculo del valor MFAM
Para el calculo del valor MFAM, primero hay que calcular el valor de MFAM para cada tipo de pro
blema haciendo uso de la tabla D.ll para posteriormente calcular el valor global del driver MFAM.
•MODELO MATEMÁTICO PARAMÉTRICO DE ESTIMACIÓN PARA PROYECTOS DE DATA MmiNG (DMCOMO)'
APÉNDICE D. MODELO DMCOMO 154
Rango Muy bajo
Bajo
Nominal
Alto
Muy alto
Descripción Los pcirticipantes en el proyecto siempre trabajan con el tipo de problemas de Data Mining del proyecto actual y con datos similares Los participantes en el proyecto han trabajado en problemas de Data Mining como el actual y con datos similares Los participantes en el proyecto han trabajado en problemas de Data Mining pero no con los datos del proyecto real Los participantes en el proyecto han trabajado en problemas de Data Mining pero nunca en el entorno del proyecto actual Los participantes en el proyecto no han trabajado nunca con problemas de Data Mining
Valor 1
2
3
4
5
Tabla D.ll: MFAMp. Factor MFAM para cada modelo
Utilizar la ecuación D.ll para calcular el valor de MFAM y consultar el nivel del driver MFAM en la
tabla D.l.
MFAM = ROUNDÍ^^^^^^:^^^^] (D.ll)
• MODELO MATEMÁTICO PARAMtTRlCO DE ESTIMACIÓN PARA PROYECTOS DE DATA MINING ÍDMCOMOI'