DEPARTAMENTO DE LENGUAJES Y SISTEMAS E INGENIERÍA SOFTWARE · En los estándares de modelo de proceso para desarrollo de software, se encuentran procesos y ta reas similares a los

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)


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


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"


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}'


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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!


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Í


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


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/


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


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


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âre 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


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


ü 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


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


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


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



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


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Í


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


• 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


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


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


• 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


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


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


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/


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/


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


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


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


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


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âlí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)'


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


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


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.


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


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}'


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


ü 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)'


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


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


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^ ô-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.


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


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ôg^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.

ÎSP=¡,(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


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.


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.


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


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.


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Í


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



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'


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.


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


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.


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


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.



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.


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.



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Í


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.


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


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.



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.



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(^^^^^^ÎM1 (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/


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


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.



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


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Í


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Í


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Í


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


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!


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{^:¡Î^^^) (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)'


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Í


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(^Î^:^^M (4.17)

Una vez obtenido el valor de TRAN se hace uso de la tabla 4.36 para obtener el nivel asociado.



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.



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.



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



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.


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



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


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



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


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Í


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.



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


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


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/


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



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


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


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Í'


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


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


• 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


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


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Í


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


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Í


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


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


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


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

http://www.windthrope.com/crm.htm

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

http://www.gartner.com

http://www.gartner.com

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

http://www.chordiant.com

http://www.mosaic.com

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

http://www.kdnuggets.com/polls

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ôrkshop 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.


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Í


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


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


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


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/


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!


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


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


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


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


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


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.


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^^^^^ÎM1'^

Calculo del valor TMOD

Calcular TMOD para cada modelo haciendo uso de la tabla D.3.


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



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.


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


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


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}'


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


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'

Documents

DEPARTAMENTO DE LENGUAJES Y SISTEMAS E INGENIERÍA SOFTWARE · En los estándares de modelo de proceso para desarrollo de software, se encuentran procesos y ta reas similares a los