elementos para un modelo de ciclo de vida … · dra. paola britos (unrn) y mg. darío rodríguez...

ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE

INFORMACIÓN

Alumna

Ing. Gabriela Ana REINOSO

Directores

Dra. Paola Britos (UNRN) y Mg. Darío Rodríguez (UNLa)

TRABAJO FINAL PRESENTADO PARA OBTENER EL GRADO

DE ESPECIALISTA EN INGENIERÍA EN SISTEMAS DE INFORMACIÓN

ESCUELA DE POSGRADO

FACULTAD REGIONAL DE BUENOS AIRES

UNIVERSIDAD TECNÓLOGICA NACIONAL

Febrero, 2014

RESUMEN

La idea de buscar ciclos de vida que describan los estados por los que pasa el producto, surge de la

necesidad de tener un esquema que sirva como base para planificar, organizar, asignar personal,

coordinar, presupuestar, y dirigir las actividades de la construcción de software.

Al comienzo de un proyecto resulta crítica la decisión sobre qué ciclo de vida se elegirá para el

proyecto en cuestión.

Progresivamente, los proyectos de explotación de información, fueron adquiriendo mayor relevancia,

con características propias que los diferencian de los demás tipos de proyectos de Software

tradicionales. Las clásicas etapas de análisis, diseño, desarrollo, integración y testeo, no encajan con

las etapas naturales de los procesos de desarrollo de este tipo de proyectos. En consecuencia,

herramientas de la Ingeniería de Software clásica no son aplicables a este tipo de proyectos.

Además, se ha constatado que muchos de estos proyectos no terminan y que incluso habiendo

terminado, éstos no lo hacen en los plazos y/o con los presupuestos previstos o no corresponden con

las expectativas de los clientes. Entre las principales causas identificadas y que explican estos

hechos, están las relacionadas con la falta de procesos de desarrollo estandarizados que incorporen

un enfoque ingenieril al desarrollo de proyectos de Explotación de Información.

El éxito de un proyecto dependerá del ciclo de vida seleccionado para llevar a cabo el desarrollo del

proyecto en cuestión, ya que puede ayudar a garantizar que se ejecuten los pasos necesarios para

alcanzar el objetivo planteado.

Palabras clave: Explotación de Información, Modelo de Ciclo de Vida, Proceso de desarrollo,

Proyecto.

ABSTRACT

The idea of seeking life cycles that describe the states through which the product passes, arises from

the need for a framework that serves as a basis for planning, organizing, assigning staff,

coordinating, budgeting, and directing the activities of building software.

At the beginning of a project is critical to decide which life cycle is chosen for the project.

Increasingly, data mining projects were gaining in importance, with its own characteristics that

differentiate them from other types of traditional software projects. The classic stages of analysis,

design, development, integration and testing, do not fit with the natural stages of the development

process of these projects. Consequently, the tools of classical Software Engineering are not

applicable to this type of project.

Also, it was found that many of these projects do not end and that having even finished, they do not

on time and / or budget planned or do not match the expectations of customers. The main causes

identified and explain these facts are related to the lack of standardized development processes that

incorporate an engineering approach to the development of data mining projects.

The success of a project depends on the life cycle selected to carry out the project in question, as it

may help to ensure that the necessary steps are executed to achieve the objective.

Key words: Data Mining - Life Cycle Model - Development Process – Project.

ÍNDICE ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN

TRABAJO FINAL DE ESPECIALIZACIÓN EN ING. EN SISTEMAS DE INFORMACIÓN GABRIELA REINOSO

i

ÍNDICE

1. INTRODUCCIÓN 1

1.1 IMPORTANCIA DEL TRABAJO DE ESPECIALIDAD 1

1.2 OBJETIVOS 2

1.2.1 Objetivo General 2

1.2.2 Objetivos Específicos 2

1.3 ALCANCE 3

2. ESTADO DE LA CUESTIÓN 5

2.1 DOMINIO DE APLICACIÓN DE PROYECTOS DE EXPLOTACIÓN

DE INFORMACION 6

2.2 CICLO DE VIDA DE UN PROYECTO DE EXPLOTACIÓN DE SOFTWARE 7

2.2.1 Modelo Cascada 8

2.2.2 Modelo Iterativo 11

2.2.3 Modelo de Desarrollo Incremental 12

2.2.4 Modelo Espiral 13

2.2.5 Metodología IDEAL 15

2.2.6 Metodología CRISP-DM (Cross Industry Standard Process for

Data Mining) 19

2.2.7 Modelo de Procesos para Proyectos de Explotación de Información 23

2.3 CONSIDERACIONES 25

2.3.1 Comparativa de Modelos 25

2.4 PROYECTOS DE EXPLOTACION DE INFORMACION 31

2.4.1 Conceptos 31

2.4.2 Orígenes y evolución 31

2.4.3 Contexto 33

3. CONCLUSIONES 35

4. REFERENCIAS 37



ii



iii

ÍNDICE DE FIGURAS

Figura 2.1 Modelo de ciclo de vida Cascada 9

Figura 2.2 Relación Funcionalidad – Tiempo 11

Figura 2.3 MODELO ITERATIVO 12

Figura 2.4 MODELO INCREMENTAL 13

Figura 2.5 MODELO ESPIRAL 14

Figura 2.6 Visión lateral del modelo tronco-cónico del ciclo de vida de la Metodología

IDEAL 17

Figura 2.7 Fases de la Metodología IDEAL 18

[García Martínez R., Britos P., 2008] Introducción a la Ingeniería del Conocimiento

Figura 2.8 Visión desde arriba del Modelo Tronco-Cónico del Ciclo de Vida de la

Metodología IDEAL 19

Figura 2.9 Fases del modelo de referencia CRISP – DM [Chapman et al, 2000] 21

Figura 2.10 Fases CRISP-DM 22

Figura 2.11 Niveles de abstracción de procesos de CRISP-DM 23

Extraído de [Chapman et al., 2000]

Figura 2.12 Modelo Espiral en Fases DM 30



iv



v

ÍNDICE DE TABLAS

Tabla 2.1 Industrias y Campos de Aplicación de Data Mining 6

(Basado en www.Kdnuggets.com)

Tabla 2.2 Metodologías utilizadas en Data Mining ([kdnuggets, 2007]) 20

Tabla 2.3 Comparativa de Modelos presentados 25

http://www.kdnuggets.com/


TRABAJO FINAL DE ESPECIALIZACIÓN EN ING. EN SISTEMAS DE INFORMACIÓN GABRIELA REINOSO vi

NOMENCLATURA ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN


vii

NOMENCLATURA

AG Empresa creadora de CRISP-DM.

DM Explotación de Información (Data Mining).

CRISP - DM Metodología para desarrollo de proyectos de Explotación de Información

(Cross Industry Standard Process for Data Mining).

COMPETISOFT Modelo de procesos basado en MoProSoft.

E.I. Explotación de Información.

ER-DM Metodología de la definición de requisitos en proyectos de Explotación de

Información.

IDEAL Metodología para el desarrollo de Sistemas Basados en Conocimientos

(Identificación, Desarrollo, Ejecución, Acción, Logro).

IEEE Instituto de Ingenieros Eléctricos y Electrónicos (Institute of Electrical and

Electronics Engineers).

ISO Organización Internacional para la Estandarización para el desarrollo y

publicación de normas internacionales. (International Organization for

Standardization).

KDD Descubrimiento de Conocimiento (Knowledge Discovery in Databases).

KDNUGGETS Portal de información sobre la Explotación de Datos y Descubrimiento de

Conocimiento.

MoProSoft Modelo de Procesos para la Industria del Software.

NCR Empresa creadora de CRISP-DM.

OHRA Empresa creadora de CRISP-DM.

P3TQ Metodología para el desarrollo de proyectos de Explotación de Información:

Producto (Product), Lugar (Place), Precio (Price), Tiempo (Time) y Cantidad

(Quantity).

SEMMA Metodología para el desarrollo de proyectos de Explotación de Información:

Muestreo (Sample), Exploración (Explore), Modificación (Modify), Modelado

(Model) y Valoración (Assess).

SPSS Empresa creadora de CRISP-DM.

NOMENCLATURA ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN


viii

INTRODUCCIÓN ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN


1

1. INTRODUCCIÓN

En este Capítulo se plantea la importancia del Trabajo de Especialidad (sección 1.1), se establecen

los objetivos (sección 1.2), y se resume la estructura de la misma (sección 1.3).

1.1. IMPORTANCIA DEL TRABAJO DE ESPECIALIDAD

En los últimos años, debido al desarrollo tecnológico a niveles exponenciales tanto en el área de

cómputo como en la de transmisión de datos, ha sido posible que se gestionen de una mejor manera

el manejo y almacenamiento de la información [Molina Félix, 2002]. Es así, que existen factores

importantes que nos han llevado a este suceso:

- El abaratamiento de los sistemas de almacenamiento tanto temporal como permanente.

- El incremento de las velocidades de cómputo en los procesadores.

- Las mejoras en la confiabilidad y aumento de la velocidad en la transmisión de datos.

- El desarrollo de sistemas administradores de bases de datos más poderosos.

Como consecuencia, el almacenamiento de la información en las bases de datos ha crecido

considerablemente. Sin embargo la utilidad de este crecimiento en cuanto al volumen de información

con que se cuenta, es que se pueda obtener un uso eficiente del conocimiento y la información para

lograr el éxito de una organización.

La necesidad de las organizaciones, de obtener un mayor conocimiento del mercado en general y de

sus clientes, las ha llevado al desarrollo de la disciplina conocida como “Data Mining” (DM).

[Gutiérrez F., 2007].

Es así que los proyectos de explotación de información, adquieren relevancia, con características

propias que los diferencian de los demás tipos de proyectos de Software tradicionales. Las clásicas

etapas de análisis, diseño, desarrollo, integración y testeo, no encajan con las etapas naturales de los

procesos de desarrollo de este tipo de proyectos. En consecuencia, herramientas de la Ingeniería de

Software clásica no son aplicables a este tipo de proyectos [García Martínez et al., 2011].

Según señala [Pyle, 2004] en su artículo “This Way Failures Lies”, no todos los proyectos de minería

son exitosos y agrega además que aunque hay muchas vías hacia el éxito de la minería de datos, las

trayectorias a la fallas se siguen demasiado a menudo.


proyecto en cuestión. [Britos et al., 2006; Juristo, 2003].



2

La idea de buscar ciclos de vida que describan los estados por los que pasa el producto, surge de la

necesidad de tener un esquema que sirva como base para planificar, organizar, asignar personal,

coordinar, presupuestar, y dirigir las actividades de la construcción de software. [Juristo, 2003].

En ese contexto resulta relevante, la planificación y organización sistemática y la adecuación de

metodologías y modelos al especificar el ciclo de vida que seguirá el producto en proyectos de

explotación de información.


proyecto en cuestión.

El éxito de un proyecto dependerá del ciclo de vida seleccionado para llevar a cabo el desarrollo del

proyecto en cuestión, ya que puede ayudar a garantizar que se ejecuten los pasos necesarios para

alcanzar el objetivo planteado [Mariscal et al., 2007].

1.2. OBJETIVOS

1.2.1. Objetivo General

- Construir un estado del arte sobre modelos de ciclo de vida para proyectos de

explotación de información.

1.2.2. Objetivos Específicos

- Presentación del dominio de la aplicación del proyecto. Orígenes y su

crecimiento en la actualidad.

- Conceptualizar la importancia de la selección un modelo de ciclo de vida acorde

a un proyecto del tipo explotación de información.

- Descripción de diferentes ciclos de vida conocidos en ingeniería del software y

metodologías de desarrollo de proyectos de explotación de información

considerados en el estudio.

- Definición de los modelos que más se adapten a proyectos de Dataminig,

teniendo en cuenta aspectos tales como la adaptación a los cambios en las

iteraciones, la prueba y verificación en cada momento del ciclo y los riesgos

existentes en cualquier Proyecto de Explotación de Información, entre otros.



3

1.3. ALCANCE

El alcance del trabajo se orienta, en un principio a establecer los modelos de ciclo de vida de los

proyectos de ingeniería de software.

En el Capítulo 1, se plantea la importancia del Trabajo de Especialidad, Objetivos, tanto general,

como los objetivos específicos, y se resume el enfoque a dar a la investigación.

En el Capítulo 2, se realiza una presentación de los distintos modelos de ciclo de vida, junto con la

importancia de empezar un proyecto a partir de tener definido el modelo a aplicar, y se presentan las

características asociadas a cada uno de los modelos, a partir de allí, se orienta a los proyectos de

explotación de Información, conceptos y el estado de desarrollo de este tipo de proyectos, se hace

referencia al Modelo de Procesos para proyectos de Explotación de Información desarrollado por

Vanrell.

En el Capítulo 3, se presentan las conclusiones resultantes de este trabajo y la orientación de esta

investigación.

Queda excluida de este trabajo el desarrollo del modelo de ciclo de vida a especificar a partir del

modelo espiral referenciado aplicado a los proyectos de explotación de la información que deberá

incluirse en un modelo creado para dichos proyectos así como la construcción del modelo.



4

ESTADO DE LA CUESTIÓN ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN


5

2. ESTADO DE LA CUESTION

En este capítulo se describe en primera instancia, el dominio de aplicación del Proyecto. Se presenta

el concepto de Ciclo de Vida. Se describen los modelos de ciclos de vida que se consideran en este

proyecto:

Para el estudio, se tendrán en cuenta los siguientes modelos:

- Modelo en cascada

- Modelo iterativo

- Modelo de desarrollo incremental

- Modelo en espiral

- Metodología IDEAL

- Modelo Propuesto

Se hace una breve introducción de los conceptos básicos, se describen las fases que los constituyen y

en algunos casos se presentan las ventajas y desventajas.

Si bien, como consecuencia de la experiencia acumulada en proyectos de Explotación de

Información se han ido desarrollando metodologías que permiten gestionar esta complejidad de una

manera uniforme. La comunidad científica considera metodologías probadas a CRISP-DM, SEMMA

y P3TQ [Rodríguez et al., 2010].

En esta ocasión, se tomará como objeto de presentación la metodología CRISP-DM, tomando

inicialmente como referencia el análisis de Vanrell en su tesis (2012) y debido a que está diseñada

como una metodología independiente de la herramienta tecnológica a utilizar en la Explotación de

Datos, haciéndola más flexible. Identifica problemas de inteligencia de negocio y a su vez, identifica

las relaciones entre las técnicas de explotación de información y las variables que modelan los

problemas de inteligencia de negocio esbozando parcialmente los procesos a desarrollar [Gambin D.,

Pallota E., 2009]

Consecutivamente, se presenta la definición de lo que es un proyecto de Explotación de Información

teniendo en cuenta diferentes conceptos. Su Evolución y su importancia en el contexto de Negocios.

Se explica la importancia de establecer un modelo de ciclo de vida para este tipo de proyectos.

Esta Investigación tiene como meta principal presentar una serie de modelos de ciclo de vida para

proponer un Modelo de Ciclo de Vida que contemple aspectos tales como la posibilidad de

adaptación a los cambios sin afectar la salida en cada etapa del proyecto de software, los riesgos

existentes en cualquier Proyecto de Explotación de Información, el compromiso de los interesados,

entre otros, teniendo en cuenta inicialmente la metodología CRISP-DM y, luego, el Modelo de



6

Procesos presentado por Vanrell, agregándole las actividades pertenecientes a los procesos de

Administración de Proyectos .

2.1. Dominio de aplicación de proyectos de explotación de información

El uso de Data Mining en organizaciones de diversa índole ha ido aumentando gradualmente en la

última década [Piatetsky-Shapiro, 2007].

En la actualidad se utiliza en procesos que incluyen CRM, investigación de mercado, análisis de la

cadena de abastecimiento, análisis médico y diagnóstico, análisis financiero y detección de fraudes

[KDNuggets, 2007].

Industries / Fields where you applied Analytics / Data Mining in 2012? [196] electores 2.012% de los votantes 2011% de los votantes

Analíticos de CRM / Consumidor (56) 28.6% 25.0%

Cuidado de la salud / HR (32) 16,3% 16,7%

Venta al por menor (29) 14,8% 10,5%

Banca (28) 14,3% 18,9%

Educación (28) 14,3% 16,2%

Publicidad (26) 13,3% 7,0%

Detección de Fraude (25) 12,8% 14,0%

Social Media / Redes Sociales (24) 12,2% 13,2%

Ciencia (23) 11,7% 13,6%

Finanzas (20) 10.2% 11.4%

Marketing / Fundraising (19) directo 9,7% 12,3%

Buscar / Web content mining (16) 8,2% 5,3%

Biotech / Genómica (15) 7.7% 9.2%

Seguros (15) 7,7% 12,3%

Credit Scoring (14) 7,1% 12,7%



7

Manufactura (14) 7,1% 5,3%

Médico / Farmacia (13) 6,6% 9,6%

Telecom / Cable (13) 6,6% 11,0%

web usage mining (13) 6,6% 7,0%

Software (11) 5,6% 7,0%

Comercio electrónico (10) 5,1% 5,3%

Gobierno / Militar (10) 5,1% 7,5%

Entretenimiento / Música / TV / Cine (9) 4,6% 3,5%

Inversiones / Acciones (8) 4,1% 4,4%

Seguridad / Anti-terrorismo (7) 3,6% 1,8%

Viajes / Hospitalidad (6) 3,1% 7,5%

Análisis de políticas / Estudios Sociales (2) 1,0% 1,8%

Junk email / Anti-spam (1) 0,5% 1,3%

Otros (20) 10,2% 7,5%

TABLA 2.1 Industrias y Campos de Aplicación de Data Mining (basado en www.Kdnuggets.com)

http://www.kdnuggets.com/polls/2012/where-applied-analytics-data-mining.html

Sin embargo, estos avances del Data Mining en las áreas de negocios no han estado exentos de

problemas, errores y fracasos. A pesar del fuerte desarrollo de herramientas y técnicas de DM y del

creciente uso en las organizaciones públicas y privadas, para el logro de sus objetivos estratégicos,

los resultados obtenidos no reflejan la gran inversión y difusión de dichas herramientas. [Gutiérrez

F., 2007]

2.2. CICLO DE VIDA DE UN PROYECTO DE SOFTWARE

La norma IEEE 1074 (Estándar IEEE del Ciclo de Vida para el Proceso de Desarrollo de Software)

[IEEE, 1991] define ciclo de vida como: “una aproximación lógica de la adquisición, el suministro,

el desarrollo, la explotación y el mantenimiento del software”.

http://www.kdnuggets.com/

http://www.kdnuggets.com/polls/2012/where-applied-analytics-data-mining.html



8

La norma ISO 12207-1 (Proceso del Ciclo de Vida del Software) [ISO, 1994], define ciclo de vida

como: “un marco de referencia, que contiene los procesos, las actividades y tareas involucradas en el

desarrollo, la explotación y el mantenimiento de un producto software, abarcando la vida del sistema

desde la definición de los requisitos hasta la finalización de su uso”.

Un modelo de ciclo de vida es la descripción de las distintas formas de desarrollo de un proyecto. El

“Ciclo de Vida” determina el orden en que se realizaran cada una de las actividades [Mariscal G. et

al. 2007]. Del ciclo de vida seleccionado para desarrollar un proyecto dependerá el éxito del mismo,

puesto que puede ayudar a asegurar que cada paso que se dé nos lleve a la consecución del objetivo.

El proceso de construcción de software puede verse como una cadena de tareas. Las cadenas de

tareas son planes idealizados de qué acciones deben realizarse y en qué orden. El software obtenido

tras el proceso puede ser visto como el “producto” que entra al proceso, se transforma (a lo largo de

la cadena de tareas) y que sale del proceso hasta obtener el producto deseado. Desde esta perspectiva

del producto, se pueden establecer los estados por los que va pasando el producto en un proceso

software: la entrada al proceso es una necesidad, que una vez estudiada se convierte en una

especificación de requisitos, que posteriormente se transforma en un diseño del sistema, para pasar

más adelante a ser un código y finalmente un sistema software completo e integrado. Este enfoque

orientado al producto, focalizado en el producto transformado (en lugar del proceso que lo

transforma) se llama ciclo de vida. Es decir, el ciclo que el producto software sufre a lo largo de su

vida, desde que nace (o se detecta la necesidad) hasta que muere (o se retira el sistema). [Juristo

Juzgado, N. b 1996].

El propósito del ciclo de vida es planear, ejecutar y controlar el proyecto de desarrollo de un sistema.

El ciclo de vida define las fases y las tareas esenciales para el desarrollo de sistemas, sin importar el

tipo o la envergadura del sistema que se intenta construir. [Rossi B. et al. 2003].

Existen varias alternativas de modelos de ciclo de vida conocidos en los proyectos de software.

Aunque hay que tener en cuenta, entre otras cosas, el tipo de proyecto en cuanto a complejidad,

experiencia con el dominio del problema, conocimiento de los datos que se están analizando,

variabilidad, o la caducidad de los mismos. Así pues el proceso de selección de ciclo de vida se

considera de utilidad en los proyectos de DM [Mariscal et al., 2007]. Por lo que, se identificarán y

analizarán posibles modelos de ciclo de vida para este tipo de proyectos, de tal manera de poder

analizar y realizar un proceso de selección del ciclo de vida y llegar a proponer un modelo que

resulte adecuado.

2.2.1. Modelo Cascada



9

Este modelo de ciclo de vida fue propuesto por Winston Royce en 1970. Es un modelo que admite

iteraciones, aunque sólo de una etapa a su inmediata anterior, por más que se represente como un

simple modelo en forma de cascada al igual que un ciclo de vida secuencial como el lineal. Después

de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente.

Como se puede observar, la necesidad de tener en claro los requerimientos al inicio del proyecto es

primordial al optar por este modelo.

Figura 2.1 Modelo de ciclo de vida Cascada

Características

Cada fase empieza cuando se ha terminado la fase anterior.

Las etapas están organizadas de un modo lógico. Cada etapa incluye una revisión y se necesita de

una aceptación antes de poder seguir avanzando a la etapa siguiente.

Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa. [Böehm,

B.W. 1981]

En este modelo, se debe contar con todos los requerimientos al comienzo del proyecto, y si se han

cometido errores y no se detectan en la siguiente etapa, es difícil y costoso corregirlo posteriormente

a esa etapa.

No refleja el proceso real de desarrollo de software. Los proyectos rara vez siguen el flujo

secuencial, puesto que siempre hay iteraciones. Aunque en este modelo la iteración está permitida en

etapas contiguas [Macro, A. 1990], en la práctica real la iteración abarca más de una etapa. [Rossi B.,

2001]



10

Facilita la gestión de control del progreso del desarrollo del sistema, de las fechas de entrega y de los

costos esperados.

Ventajas

Tiene una planificación sencilla

Provee un producto con un elevado grado de calidad sin necesidad de un personal altamente

calificado.

Es adecuado para proyectos en los que se cuenta con todos los requerimientos al comienzo,

para desarrollar productos con funcionalidades conocidas, o para proyectos que se entiendan

perfectamente desde el principio.

Facilita la gestión de control del progreso del desarrollo del sistema, de las fechas de entrega

y de los costos esperados.

Requiere que el proceso de desarrollo genere una serie de documentos que posteriormente

pueden utilizarse para la validación y el mantenimiento del sistema.

Desventajas

No refleja realmente el proceso de desarrollo del software

Se tarda mucho tiempo en pasar por todo el ciclo

El mantenimiento se realiza en el código fuente

Las revisiones de proyectos de gran complejidad son muy difíciles

A menudo, durante el desarrollo, se pueden tomar decisiones que den lugar a diferentes

alternativas. El modelo en cascada no reconoce esta situación.

Asume que los requisitos de un sistema pueden ser congelados antes de comenzar el diseño.

Esto es como decir que el usuario rara vez evoluciona en cuanto a sus necesidades.

Cuando se entrega el sistema, éste obviamente no satisfará las expectativas actuales del

cliente; en el mejor de los casos sólo cumplirá con las expectativas que tenía tiempo atrás,

cuando se comenzó el desarrollo.



11

De acuerdo a esto, se presenta la siguiente figura, donde se representa cómo varían las necesidades y

expectativas del usuario en el tiempo. Llamando a cada intervalo t0, t1,….tn

Figura 2.2 Relación Funcionalidad - Tiempo

Resumido, desde el primer momento, cuando empieza el proyecto, no se tiene en claro totalmente

todos los requerimientos, después se obtienen requerimientos que no han sido bien traducidos, y

cuando se quiere corregir, seguramente se emplea más recursos que el necesario, por ende, el costo

es elevado. Hasta que se decide empezar con un nuevo sistema.

Por otro lado, si los requerimientos se congelan en un principio. Se pone toda la energía en

cumplirlos estrictamente, lo que genera que cuando se llegue a satisfacerlos, la solución sea

difícilmente adaptable a otros requerimientos del usuario.

2.2.2. Modelo Iterativo

También derivado del ciclo de vida en cascada puro, este modelo busca reducir el riesgo que surge

entre las necesidades del usuario y el producto final, cuando los requerimientos no están claros de

parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y

conseguir la conformidad del cliente.

Es la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente

una versión mejorada o con mayores funcionalidades del producto. El cliente es quien luego de cada

iteración, evalúa el producto y lo corrige o propone mejoras.

Estas iteraciones se repetirán hasta obtener un producto que satisfaga al cliente.



12

Es un modelo ideal a seguir cuando el usuario necesita entregas rápidas aunque el proyecto no esté

terminado.

Figura 2.3 MODELO ITERATIVO

Este modelo de ciclo de vida está estructurado de tal modo que, en cada etapa, se define qué debe

hacerse en el próximo paso de descomposición, pero también se documentan los criterios para

determinar si el producto compuesto que resulta satisface las expectativas que se tenían hacia él.

2.2.3. Modelo de Desarrollo Incremental

El primero que habló de este nuevo modelo fue Hirsch en 1985. Este modelo de ciclo de vida se basa

en la filosofía de construir incrementando las funcionalidades del programa.

Se realiza construyendo módulos que cumplen las diferentes funciones del sistema. Esto permite ir

aumentando gradualmente las capacidades del software. De esta manera, en el caso de que el

proyecto sea realizado por un equipo de programadores, puede permitirle a cada miembro desarrollar

un módulo particular.

Es una repetición del ciclo de vida en cascada, aplicándose este ciclo en cada funcionalidad del

programa a construir. Al final de cada ciclo se entrega una versión al cliente que contiene una nueva

funcionalidad. Así se obtiene una mayor adaptabilidad y se logra mejorar el software.

Una forma de reducir los riesgos es ir construyendo partes del sistema adoptando este modelo.



13

Este modelo propone desarrollar sistemas produciendo en primer lugar las funciones esenciales de

operación y, a continuación, proporcionar a los usuarios mejoras y versiones más capaces del sistema

a intervalos regulares. Combina el ciclo de vida clásico del software con mejoras iterativas a nivel

del desarrollo del sistema global.

Figura 2.4 MODELO INCREMENTAL

Es un modelo ideal a seguir cuando el usuario necesita realizar entregas rápidas y el proyecto aún no

esté terminado.

2.2.4. Modelo Espiral

El desarrollo en Espiral es un modelo de ciclo de vida del software definido por primera vez por

Barry Boehm en 1986.El modelo en espiral es un modelo de proceso de software evolutivo. Este

modelo acepta que los requerimientos del usuario pueden cambiar en cualquier momento.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las

primeras iteraciones la versión incremental podría ser un prototipo, durante las últimas iteraciones se

producen versiones cada vez más completas del sistema diseñado.



14

El modelo en espiral para el desarrollo de software representa un enfoque dirigido por el riesgo para

el análisis y estructuración del proceso software. Fue presentado por primera vez por Böehm en

1986.

El enfoque incorpora métodos de proceso dirigidos por las especificaciones y por los prototipos. Esto

se lleva a cabo representando ciclos de desarrollo iterativos en forma de espiral, denotando los ciclos

internos del ciclo de vida análisis y prototipado precoz, y los externos, el modelo clásico. La

dimensión radial indica los costes de desarrollo acumulativos y la angular el progreso hecho en

cumplimentar cada desarrollo en espiral. El análisis de riesgos, que busca identificar situaciones que

pueden causar el fracaso o sobrepasar el presupuesto o plazo, aparecen durante cada ciclo de la

espiral. En cada ciclo, el análisis del riesgo representa groseramente la misma cantidad de

desplazamiento angular, mientras que el volumen desplazado barrido denota crecimiento de los

niveles de esfuerzo requeridos para el análisis del riesgo como se ve en la figura 2.5.

Figura 2.5 modelo espiral

No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión de

proyecto.

Cada vuelta se divide en 4 sectores:

Planeación: determinación de los objetivos, alternativas y restricciones



15

Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos

Ingeniería: desarrollo del producto hasta "el siguiente nivel".

Evaluación: valoración por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se

van construyendo versiones sucesivas del software, cada vez más completas.

Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las

actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de

los resultados del software.

Este modelo de Böehm permite observar mejor todos los elementos del proceso (incluidos riesgos,

objetivos, etc.). Es una mejor representación de los modelos de ciclo de vida.

Combinan la naturaleza iterativa del prototipado con los aspectos de control sistemático del modelo

en cascada. El modelo evolutivo, en espiral o dirigido por riesgos consiste en desarrollar el sistema a

través de varias iteraciones por un conjunto de tareas. En cada iteración se producen versiones

incrementales. Las regiones básicas que se identifican en el modelo en espiral son: identificación de

objetivos, restricciones y alternativas para el ciclo de desarrollo; evaluación de las alternativas con

respecto a los objetivos y restricciones, que conlleva la identificación y clasificación de los riesgos

asociados a las alternativas; desarrollo de dichas alternativas a través de un plan de trabajo y, por

último, evaluación por parte del cliente de los productos desarrollados en esa fase. Los principales

problemas de este modelo es que aún no ha sido probada su eficacia y los clientes pueden ser reacios

a su aplicación. [Boehm B. W., 1993]

Algunas ventajas es que puede adaptarse y aplicarse a lo largo de la vida del software, como el

software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y

reaccionan mejor ante riesgos en cada uno de los nivele evolutivos. Además, si se aplica

adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.

La contra es que resulta difícil convencer a grandes clientes de que el enfoque evolutivo es

controlable, debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas ya que

genera mucho tiempo en el desarrollo del sistema, además de ser costoso. Requiere experiencia en la

identificación de riesgos.

2.2.5. Metodología IDEAL

La metodología I.D.E.A.L. propone el desarrollo de un Sistema Basado en Conocimientos - SBC,

presenta un ciclo de vida troncocónico en tres dimensiones [Gómez, A. et al. 1997]. Su base es un

modelo en espiral [Böehm, B.W. 1987] y la tercera dimensión representa el mantenimiento

perfectivo una vez implementado el Sistema Experto. El eje del cono representa la calidad de nuevos



16

conocimientos, la espiral va de mayor diámetro (más conocimientos) a menor y de abajo a arriba

(menor calidad a mayor calidad). En efecto, al principio del uso del SBC (una vez implementado) se

pueden obtener conocimientos de distintas calidades, pero a medida que se usa el sistema, se refina y

cada vez se obtiene menos conocimientos pero de una mayor calidad.

Esta metodología se ajusta a la tendencia del software actual, esto es: (1) Ser reutilizable. (2) Ser

integrable. (3) Poseer requisitos abiertos. (4) Diversidad de modelos computacionales. Los requisitos

están sometidos a constantes cambios y por ende el sistema también, por lo que como resultado se

obtiene un sistema en constante evolución, debido a esto puede considerarse como un prototipo en

constante perfeccionamiento, mediante el agregado de nuevos marcos compuestos, mediante nuevas

técnicas de descomposición del problema, mediante nuevas formas de documentación o estándares a

los que debe ajustarse.

El objetivo de esta metodología es conseguir un proceso de mejora gradual en base al conocimiento

del experto.

Características del Ciclo de vida en espiral cónico de tres dimensiones:

- Estructura en espiral: cada fase finaliza con el desarrollo de un prototipo y el sistema final a

un cierto nivel de conocimiento.

- Estructura cónica: para adición de nuevos conocimientos durante la vida del Sistema

Basado en Conocimiento con respecto al eje de “adquisición de conocimiento”.

IDEAL es el acrónimo de las fases que la componen (Identificación, Desarrollo, Ejecución, Acción,

Logro), es apta para la generación de sistemas informáticos con requisitos abiertos y diversidad,

reutilizables e integrables. Plantea en forma sistemática una serie de etapas a seguir para desarrollar

un sistema basado en conocimientos: Definición del Problema, Viabilidad del Proyecto, Adquisición,

Conceptualización y Formalización de conocimientos, lmplementación del Prototipo, Evaluación de

la lmplementación. Propone un ciclo de vida en espiral cónico en tres dimensiones, en donde cada

fase del ciclo finaliza con el desarrollo de un prototipo. El prototipo desarrollado conduce a la

siguiente fase del ciclo mediante la incorporación sistemática de conocimientos producidos por el

propio uso del mismo (Gómez et al., 1997). Las etapas más importantes del desarrollo de cada uno

de los prototipos son la Adquisición, la Conceptualización y la Formalización de los Conocimientos

que dominan los expertos y la Evaluación de los Conocimientos implementados como un sistema de

información.



17

Figura 2.6 Visión lateral del modelo tronco-cónico del ciclo de vida de la Metodología IDEAL.

Según Rossi, en la tesis de maestría escrita el año 2001 titulada “Sistema experto de ayuda para la

selección del modelo de ciclo de vida”, el objetivo de esta metodología es conseguir un proceso de

mejora gradual en base al conocimiento del experto y consta de las siguientes fases:

FASE I: Requerimientos, viabilidad, especificación técnica

I.1. Plan de requisitos y adquisición de conocimientos.

I.2. Evaluación y selección de la tarea.

I.3 Definición de las características de las tareas.

FASE II: desarrollo de los prototipos de demostración, investigación, campo y operacional.

II.1. Concepción de la solución: Descomposición en subproblemas y determinación de

analogías.

II.2. Adquisición y Conceptualización de los conocimientos.

II.3. Formalización de los conocimientos y definición de la arquitectura.

II.4. Selección de la herramienta e implementación.

II.5. Validación y evaluación del prototipo.

II.6. Definición de nuevos requisitos, especificaciones y diseño.

FASE III: Ejecución de la construcción del sistema integrado.

III.1. Requisitos y diseño de la integración con otros sistemas.

III.2. Implementación y evaluación de la integración.

III.3. Aceptación por el usuario del sistema final.

FASE IV: Actuación para conseguir el mantenimiento perfectivo.



18

IV.1. Definir el mantenimiento del sistema global.

IV.2. Definir el mantenimiento de las bases de conocimientos.

IV.3. Adquisición de nuevos conocimientos y actualización del sistema.

FASE V: Lograr una adecuada transferencia tecnológica.

V.1. Organizar la transferencia tecnológica.

V.2. Completar la documentación del sistema basado en conocimientos construido.

Figura 2.7 Fases de la Metodología IDEAL [García Martínez R., Britos P., 2008] Introducción a la

Ingeniería del Conocimiento



19

Figura 2.8 Visión desde arriba del Modelo Tronco-Cónico del Ciclo de Vida de la Metodología

IDEAL.

2.2.6. Metodología CRISP-DM (Cross Industry Standard Process for Data

Mining)

CRISP–DM, fue creada por el grupo de empresas SPSS, NCR y Daimer Chrysler en el año 2000, y

es actualmente la guía de referencia más utilizada en el desarrollo de proyectos de minería de datos.

Como se puede constatar en la gráfica publicada el año 2007 por kdnuggets.com, que representa el

resultado obtenido en sucesivas encuestas efectuadas durante los últimos años, respecto del grado de

utilización de las principales guías de desarrollo de proyectos de Data Mining. En ella se puede

observar que es la guía de referencia más ampliamente utilizada.



20

Encuesta

¿Qué metodología principal está utilizando para la minería de datos? [150 votos total]

CRISP-DM (63) 42%

Owner (29) 19%

Seguro Médico para Maestros (19) 13%

Proceso KDD (11) 7%

Mis organizaciones (8) 5%

Metodología de dominio específico (7) 5%

Otros metodología, no específico de dominio (6) 4%

Ninguno (7) 5%

TABLA 2.2 Metodologías utilizadas en Data Mining ([kdnuggets, 2007])

La metodología CRISP-DM [Chapman et al., 2000] se encuentra definida en base a un modelo

jerárquico de procesos. Nos enfocaremos en los procesos del nivel superior que son lo

suficientemente genéricos como para cubrir todas las posibles aplicaciones de explotación de

información. Esta metodología define un ciclo de vida de los proyectos de explotación de

Información que define las principales fases de un proyecto de este tipo: Entendimiento de

Negocios, Entendimiento de los Datos, Preparación de los Datos, Modelado, Evaluación y

Despliegue, sus tareas respectivas, y las relaciones entre estas tareas.

En este nivel de descripción, no es posible identificar todas las relaciones. Las relaciones podrían

existir entre cualquier tarea de minería de datos según los objetivos, el contexto, y el interés del

usuario sobre los datos.

Además, se puede observar que estas fases difieren de las fases definidas para un proyecto de

desarrollo de software clásico (inicio, requerimientos, análisis y diseño, construcción, integración y

pruebas y cierre).



21

Figura 2.9 Fases del modelo de referencia CRISP – DM [Chapman et al, 2000]

Características:

La secuencia de las fases no es rígida.

El movimiento hacia adelante y hacia atrás entre fases diferentes es siempre requerido.

El resultado de cada fase determina que la fase, o la tarea particular de una fase, tienen que ser

realizados después. Las flechas indican las más importantes y frecuentes dependencias entre fases.

El círculo externo en la Figura 2 simboliza la naturaleza cíclica de la minería de datos. La minería de

datos no se termina una vez que la solución es desplegada. Las informaciones ocultas durante el

proceso y la solución desplegada pueden provocar nuevas, a menudo más - preguntas enfocadas en el

negocio. Los procesos de minería subsecuentes se beneficiarán de las experiencias previas [Gutiérrez

F. M., 2007].

A continuación se refiere sintéticamente, cada una de las fases identificadas por CRISP-DM.

- Entendimiento del Negocio: se deben entender los objetivos del proyecto y los requerimientos

desde una perspectiva del negocio y luego convertir este conocimiento en una definición de

un problema de explotación de información y diseñar un plan preliminar para lograr dichos

objetivos.

- Entendimiento de los Datos: comienza con la recolección inicial de datos y procede con las

acciones para familiarizarse con ellos, identificar problemas de calidad, identificar primeras

pautas en los datos o detectar subconjuntos interesantes de las hipótesis de información

oculta.



22

- Preparación de los Datos: cubre todas las actividades para construir el conjunto de datos final

desde los datos iniciales, las tareas de esta fase pueden ser realizadas muchas veces y sin un

orden preestablecido, incluye tanto la selección de tablas, registros y atributos como

transformación y limpieza de datos para herramientas de modelado.

- El Modelado: incluye la selección de técnicas de modelado y la calibración de sus parámetros

a los valores óptimos, suelen existir distintas técnicas para un mismo problema de

explotación de información y cada una de ellas suele tener ciertos requisitos sobre los datos,

muchas veces es necesario volver a la fase de preparación de los datos.

- La Evaluación: requiere la construcción de uno o varios modelos que aparentan tener la

mayor calidad desde una perspectiva de análisis, requiere la evaluación del modelo y revisión

de los pasos ejecutados para la construcción del modelo para asegurarnos de lograr los

objetivos de negocio, al final de esta fase se debería poder tomar una decisión respecto de la

utilización de los resultados.

- El Despliegue o Implementación: puede ser tan simple como generar un reporte o tan

compleja como implementar un proceso de explotación de información repetible a través de

toda la empresa. [Vanrell J., 2012]

En la siguiente figura podemos ver claramente las fases que componen la metodología CRISP-DM

en el orden secuencial natural de las mismas.

Fases componentes de la metodología CRISP-DM. Extraído de [Britos, 2008]

Cada una de estas fases se divide en distintas fases de nivel inferior que indican tareas generales a

realizar dentro de la misma. A su vez, estas tareas de segundo nivel, son divididas en tareas

específicas donde se describen las acciones que deben ser desarrolladas en situaciones específicas.

Figura 2.10 Fases CRISP-DM

Por ejemplo, si entre las tareas generales se encuentra “limpieza de datos” en el tercer nivel se

indican las tareas que deben desarrollarse para un caso específico como por ejemplo “limpieza de

datos numéricos” o “limpieza de datos categóricos”. En un cuarto nivel se recogen acciones,

decisiones y resultados sobre el proyecto de Explotación de Información [Britos, 2008]. Esta

abstracción de procesos puede verse gráficamente en la figura 2.11.



23

Figura 2.11 Niveles de abstracción de procesos de CRISP-DM. Extraído de [Chapman et al., 2000]

Para asistir al usuario de la metodología se proporcionan dos documentos distintos que serán

utilizados como herramienta de ayuda al desarrollo de los proyectos de explotación de información:

el modelo de referencia y la guía de usuario.

En el primer documento se describen en forma general las fases, tareas generales y salidas del

proyecto de Explotación de Información en general.

La guía del usuario proporciona información más detallada sobre cómo aplicar el modelo de

referencia a los proyectos específicos. Proporciona consejos y listas de comprobación sobre las tareas

correspondientes a cada una de las fases.

2.2.7. Modelo de Procesos para Proyectos de Explotación de Información

Basado en la tesis de Vanrell [2012], donde a partir de las investigaciones realizadas en ese trabajo se

detectaron distintos problemas en las herramientas actuales para el desarrollo de proyectos de

Explotación de Información, entre ellos se mencionan: las carencias detectadas en el área de gestión

de proyectos y de la empresa en las metodologías utilizadas actualmente para el desarrollo de

proyectos de Explotación de Información; los modelos de desarrollo tradicionales no se adecúan a

los proyectos de Explotación de Información, dado que las etapas naturales de los procesos de

desarrollo de software clásico son diferentes a las de los proyectos de Explotación de Información.



24

Para la solución de los problemas presentados, en la tesis de Vanrell, se propone una solución basada

en el modelo de procesos Competisoft, utilizado para proyectos tradicionales de software, como

punto de partida a una adecuación a los proyectos de explotación de información, y utilizando la

metodología CRISP-DM, considerada la más completa para este tipo de proyectos.

La diferencia más significativa se presenta en los procesos de desarrollo y mantenimiento de

software en los cuales Competisoft define como proceso natural el ciclo de fases de un proyecto de

software tradicional. Las fases de Inicio, Requisitos, Análisis y Diseño, Construcción, Integración,

Pruebas y Cierre no resultan naturales en un proyecto de explotación de información.

En este modelo propuesto se incluyeron fases definidas en CRISP-DM y se propusieron actividades

y herramientas nuevas que fueron consideradas de utilidad para el modelo. De esta manera, el

modelo de procesos presentado, contempla dos procesos bien definidos:

- El proceso de Administración de Proyectos cuyo fin es mantener el proceso de desarrollo en

movimiento y corregir aquellos desvíos que se produzcan con el fin de lograr una finalización

exitosa del proyecto.

- El proceso de Desarrollo de Proyectos cuyo fin es la producción del proyecto en sí, e intenta

cubrir todas las etapas de ejecución del mismo, desde la toma de requerimientos hasta la

entrega del producto final al cliente.

Fases del Proceso de Administración de Proyectos:

- Planificación/Entendimiento del negocio

- Realización

- Evaluación y Control

- Cierre/Entrega

Fases del Proceso de desarrollo de Proyectos

- Entendimiento del negocio

- Entendimiento de los datos

- Preparación de los datos

- Modelado

- Evaluación

- Entrega

Entre los resultados obtenidos por el modelo propuesto, se pueden señalar: la ampliación de los

procesos de gestión de COMPETISOFT para que soporten proyectos de explotación de información,

una propuesta de reordenamiento de las actividades de CRISP-DM, separando las actividades de

desarrollo de las de gestión y la integración de las actividades de gestión de CRISP con las de

COMPETISOFT, adaptando estas últimas a proyectos de explotación de información.



25

2.3. CONSIDERACIONES

Las principales diferencias entre distintos modelos de ciclo de vida están en:

- El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Es decir,

si es viable el desarrollo de un producto, el desarrollo completo o el desarrollo completo

incluída las actualizaciones y el mantenimiento.

- Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del

propio tema al que se refiere el proyecto, o de la organización donde se aplique.

- La estructura y la sucesión de las fases que puede ser lineal, con prototipado, o en espiral.

2.3.1. Comparativa de Modelos

En una primera aproximación, la tabla 2.3 busca reflejar, a grandes rasgos, algunos aspectos

evaluados en los modelos de ciclo de vida presentados. Por un lado, para proyectos de desarrollo de

software clásicos y luego para los proyectos de explotación.

MODELOS DE CICLO DE VIDA DE PROYECTOS

CLASICOS

METODOLOGIA

SSBBCC

METODOLOGIA

PROYECTOS DE

E.I.

CASCADA INCREMENTAL ESPIRAL IDEAL CRISP-DM

Resumen Es un enfoque

metodológico

que ordena

rigurosamente

las etapas del

ciclo de vida del

software, de

forma tal que el

inicio década

etapa debe

esperar a la

finalización de

la

inmediatamente

anterior.

Es un enfoque

incremental de

desarrollo; busca la

forma de disminuir la

repetición del trabajo

en el proceso de

desarrollo y dar

oportunidad de

retrasar la toma de

decisiones en los

requisitos hasta

adquirir experiencia

con el sistema

El modelo en espiral

es una de las

metodologías más

recomendables para

el desarrollo y

creación de un

programa, ya que

consta de pocas

etapas o fases, las

cuales se van

realizando en una

manera continua y

cíclica

El ciclo de vida del

sistema se basa en

prototipado

incremental. Lo cual

implica, que para

haber logrado un

buen prototipo es

necesario haber

desarrollado una

serie de prototipos

hasta lograr aquel

que satisface los

requisitos

considerados por el

experto.

Define un ciclo de

vida de los proyectos

de explotación de

información que

establece las

principales fases de

un proyecto junto

con las relaciones

entre las mismas,

estas relaciones son

las más comunes

aunque pueden

establecerse entre

cualquiera de las

fases.

Etapas /

Fases

1. Análisis de

Requisitos.

1. Requisitos del

software.

1. Planificación

Determinación de los

objetivos,

alternativas y

restricciones

1. Identificación de

la tarea

1. Comprensión del

negocio

2. Diseño del

Sistema

2. Diseño 2. Análisis de riesgo

Análisis de

alternativas e

identificación/resoluc

ión de riesgos

2. Desarrollo de los

prototipos

2. Comprensión de

los datos

3. Codificación 3. Codificación 3. Ingeniería

Desarrollo del

3. Ejecución de la

construcción del

3. Preparación de

datos



26

producto hasta "el

siguiente nivel"

sistema integrado

4. Prueba 4. Mantenimiento 4. Evaluación

Valoración por parte

del cliente de los

resultados obtenidos.

4. Actuación para

conseguir el

mantenimiento

perfectivo

4. Modelado

5.

Mantenimiento

5. Lograr una

adecuada

transferencia

tecnológica

5. Evaluación

6.

Implementación

6. Desarrollo


Comparac

ión

1. Tiende a no

reflejar

realmente el

proceso de

desarrollo del

software

1. Se evitan

proyectos largos y se

entrega “Algo de

valor” a los usuarios

con cierta frecuencia

1. Trata de mejorar

los ciclos de vida

clásicos y prototipos.

1. Propone un ciclo

de vida en espiral

cónico en tres

dimensiones, en

donde cada fase del

ciclo finaliza con el

desarrollo de un

prototipo.

1.Identifican técnicas

de

explotación de

información

utilizables

2. Insume

mucho tiempo

en pasar por

todo el ciclo

2. El usuario se

involucra más

2. Permite acomodar

otros modelos

2. El cada fase el

prototipo

desarrollado

incorpora

conocimientos

producidos por el

propio uso del

mismo

2. Identifica los

distintos

problemas de

inteligencia de

negocio y hace una

caracterización

parcialmente

abstracta de los

mismos.

3. Su

comunicación

con el usuario

final es poco

interactiva

3. Difícil de evaluar

el costo total

3. Incorpora

objetivos de calidad

y gestión de riesgos

3. Los requisitos

están sometidos a

constantes cambios.

3. La sucesión de

fases, no es

necesariamente

rígida.

4. El

mantenimiento

se realiza en el

código fuente.

4. Difícil de aplicar a

sistemas

transaccionales que

tienden a ser

integrados y a operar

como un todo.

4. Elimina errores y

alternativas

innecesarias al

comienzo.

4. El resultado es un

sistema en constante

evolución.

4. Tiene un único

proceso en el cual se

realizan todas las

tareas

propuestas.

5. Las revisiones

de proyectos de

gran

complejidad son

muy difíciles.

5. Requiere gestores

experimentados

5. Permite

iteraciones, vuelta

atrás y finalizaciones

rápidas

6. Impone una

estructura de

gestión de

proyectos.

6. Los errores en los

requisitos se detectan

tarde.

6. Cada ciclo

empieza

identificando: Los

objetivos de la

porción

correspondiente, Las

alternativas,

Restricciones



27

7. El resultado puede

ser muy positivo.

7. Cada ciclo se

completa con una

revisión que incluye

todo el ciclo anterior.


Ventajas 1. Se tiene todo

bien organizado

y no se mezclan

las fases.

1. Se reduce el

tiempo de desarrollo

inicial, ya que se

implementa la

funcionalidad

parcial.

1. Reduce riesgos del

proyecto

1. Consiste en un

ciclo de vida en

espiral de 3

dimensiones

1. Permite elección

libre de las

herramientas

2. Es perfecto

para proyectos

que son rígidos.

2. Provee al cliente la

entrega temprana de

partes operativas del

Software.

2. Incorpora

objetivos de calidad

2. Permite resolver

problemas complejos

y de gran dificultad

sin tener que dividir

en subproblemas

para aplicar distintas

metodologías en cada

uno.

2. Todas las fases

pueden relacionarse

3. Ideal para

proyectos donde

se especifiquen

muy bien los

requerimientos.

3. El modelo

proporciona todas las

ventajas del modelo

en cascada

realimentado,

reduciendo sus

desventajas sólo al

ámbito de cada

incremento.

3. Integra el

desarrollo con el

mantenimiento.

3. Se construye de

forma incremental

3. Es el estándar en

el ámbito de este tipo

de proyectos.

4. Ideal para

proyectos en

que se conozca

muy bien la

herramienta a

utilizar.

4. Resulta más

sencillo acomodar

cambios al acotar el

tamaño de los

incrementos.

4. Es posible tener en

cuenta mejoras y

nuevos

requerimientos sin

romper con la

metodología

4. Permite adquirir

con el tiempo menos

conocimientos pero

de mejor calidad que

etapas

anteriores.

5. Siguen los

pasos intuitivos

necesarios a la

hora de

desarrollar el

Software. El

análisis del

riesgo se hace

de forma

explícita y clara.

Une los mejores

elementos de los

restantes

modelos.

5. Por su versatilidad

requiere de una

planeación cuidadosa

tanto a nivel

administrativo como

técnico.

5. El ciclo de vida no

es rígido ni estático.


Desventaj

as

1. Difícilmente

un cliente va a

establecer al

principio todos

los

requerimientos

1. El modelo

Incremental no es

recomendable para

casos de sistemas de

tiempo real, de alto

nivel de seguridad,

1. Genera mucho

tiempo en el

desarrollo del

sistema

1. No proporciona

mecanismos

específicos para

reutilizar

conocimientos

obtenidos de SBC

1. Establece un

conjunto de tareas y

actividades para cada

fase del proyecto

pero no especifica

cómo llevarlas a



28

necesarios. de procesamiento

distribuido, y/o de

alto índice de

riesgos.

previamente

desarrollados.

cabo.

2. Se observa un

gran atraso

trabajando en

este modelo, si

no hay buena

relación con el

cliente.

2. Requiere de

mucha planeación,

tanto administrativa

como técnica.3.

Requiere de metas

claras para conocer

el estado del

proyecto.

2. Modelo costoso 2. No incluye fases

que mencionen nada

respecto de la

estrategia de

la organización,

como disparador del

requerimiento del

sistema software.

2. No tiene en cuenta

ni analiza los riesgos

de los proyectos de

E.I.

3. Es muy

restrictivo y no

permite

movilizarse

entre fases.

3. Requiere

experiencia en la

identificación de

riesgos

3. No se explicitan

tareas de seguimiento

y control

4. Deja de lado

aspectos a nivel

gestión de los

proyectos y de

empresa.


Proyectos

donde se

utiliza

1. Aquellos

donde se

dispone de todas

las

especificaciones

desde el

principio.

1. Sistemas de

tiempo no real

1. Sistemas de gran

tamaño

1. Sistemas basados

en conocimiento

1. Negocios

Identifica problemas

de inteligencia de

negocio (PIN)

2. Proyectos de

reingeniería

2. Sistemas de bajo

nivel de seguridad

2. Proyectos donde

sea importante el

factor de riesgo

2. Identifica técnicas

de Explotación

deInformación (TEI)

utilizables

3. Proyectos

complejos que

se entienden

bien desde el

principio.

3. Sistemas de bajo

porcentaje de

riesgos.

3. Cuando no es

posible definir al

principio todos los

requisitos.

3. Juegos – Ciencia

e Ingeniería – FBI -

Fraudes

Tabla 2.3 Comparativa de los Modelos descriptos

Una de las diferencias más significativas de los proyectos de explotación de información con

respecto a los proyectos de desarrollo de software tradicional se observa en cuanto a las fases

definidas en uno u otro tipo de proyectos. Las fases de Inicio, Requisitos, Análisis y Diseño,

Construcción, Integración, Pruebas y Cierre no resultan naturales en un proyecto de explotación de

información. Los modelos tradicionales en los procesos de desarrollo de software a gran escala,

como es el caso, por ejemplo, del Modelo Cascada, Iterativo, por lo general, altamente estructurado,

con una secuencia fija de actividades, presentan varios inconvenientes, por ejemplo, cada tarea tiene



29

que estar completamente terminada a fin de poder continuar con el estudio y además los riesgos no se

tratan adecuadamente.

Para el caso de aquellos proyectos clásicos, los modelos conocidos presentados, Cascada, Iterativo,

Incremental contemplan todas las fases del ciclo de vida de los mismos. En cambio, para el

desarrollo de los proyectos de explotación de información y la aplicación de su metodología más

conocida CRISP-DM, se puede observar que no contempla, entre otras cosas, la definición de los

potenciales riesgos a los que se podría enfrentar en este tipo de proyectos, y que pueden llevar a

resultados no buscados.

La gestión de riesgo en este tipo de proyectos consiste en el análisis de la organización a través de

métodos, y herramientas para la gestión. La misma mantiene un ambiente disciplinado proactivo que

evalúa lo que puede salir mal continuamente; determina qué riesgos son importantes; y las acciones

para tratar con esos riesgos [Britos P. et al. 2007].

Sin embargo, a partir del modelo espiral, donde se presentan modelos de procesos iterativos e

interactivos, teniendo presente el análisis de riesgos, se observa el enfoque cíclico con mayor grado

de definición e implementación, con mayor compromiso de las partes interesadas, y por lo tanto

poseen una mejor adaptación a los cambios.

Por lo tanto, este modelo de Boehm se presenta como una alternativa válida, ya que es necesario

contar con un modelo de ciclo de vida que contemple estos aspectos y que a su vez, pueda ser

aplicado a los proyectos de explotación de información.

Además, CRISP-DM, estructura el proyecto de Data Mining en fases que se encuentran

interrelacionadas entre sí, convirtiendo el proceso de Data Mining en un proceso iterativo e

interactivo.

Recordando el modelo de procesos presentado por Vanrell en su tesis “UN MODELO DE

PROCESOS PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN” (2012), se habían

agregado dos procesos en comparación con CRISP-DM, el primero vinculado a la administración de

proyectos de Explotación de Información, cuyo fin es mantener el proceso de desarrollo en

movimiento y corregir aquellos desvíos que se produzcan con el fin de lograr una finalización exitosa

del proyecto. Además, este proceso, se encarga de recolectar información necesaria para aumentar la

calidad del proceso de desarrollo permitiendo realizar ajustes en el mismo y de mantener un estándar

en la realización de proyectos convirtiendo un proceso aislado y posiblemente caótico, en un proceso

controlado y repetible del cual podemos esperar una finalización exitosa con mayor probabilidad. El

segundo de estos procesos, es el relacionado con el desarrollo de proyectos de explotación de

información, cuyo fin es la producción del proyecto en sí, e intenta cubrir todas las etapas de

ejecución del mismo, desde la toma de requerimientos hasta la entrega del producto final al cliente.



30

Otro aporte a tener en cuenta es, como lo establece la Metodología IDEAL, el ciclo de vida del

sistema se basa en prototipado incremental. Lo cual implica, que para haber logrado un buen

prototipo es necesario haber desarrollado una serie de prototipos hasta lograr aquel que satisface los

requisitos considerados por el experto [Britos P., 2001].

Es decir, tomando todas las consideraciones desde el modelo propuesto con respecto a las fases a

desarrollar, y teniendo en cuenta que en cada iteración se realiza un análisis de riesgo y un prototipo.

Siendo el producto obtenido en cada vuelta, refinado en cuanto a la especificación de las necesidades

y la calidad de lo producido (reduciendo riesgos), ya que se cuenta con el valor agregado de lo

“aprendido”, en base a los sucesivos refinamientos.

Figura 2.12 Modelo Espiral en Fases DM



31

Basado en la tesis: “Metodología de la definición de requisitos en proyectos de Data Mining (ER-

DM)” de José Alberto Gallardo Arancibia

2.4. PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN

2.4.1. Conceptos

Un proceso de Explotación de Información puede definirse como un conjunto de tareas relacionadas

lógicamente [Curtis et al., 1992], el cual engloba un conjunto de técnicas de Minería de Datos (en

inglés Data Mining, DM) que pueden ser elegidas para realizarlas y así lograr extraer de

conocimiento procesable, implícito en el almacén de datos (en inglés Data Warehouse, DW) de la

organización. Las bases de estas técnicas se encuentran en el análisis estadístico y en los sistemas

inteligentes. Así se aborda la solución a problemas de predicción, clasificación y segmentación

[Umapathy, 2007].

La Explotación de Información se centra en la búsqueda de patrones interesantes y regularidades

importantes en grandes bases de datos (llamado conocimiento cualitativo) [Fayad et al., 1996]. Es la

subdisciplina Informática que aporta a la Inteligencia de Negocio [Langseth y Vivatrat, 2003] las

herramientas para la transformación de información en conocimiento [Mobasher et al., 1999;

Srivastava et al., 2000; Abraham, 2003; Coley, 2003].

La Minería de Datos o Explotación de Información, es el proceso de extraer conocimiento útil,

comprensible y novedoso de grandes volúmenes de datos, siendo su principal objetivo encontrar

información oculta o implícita, que no es posible obtener mediante métodos estadísticos

convencionales. El proceso de minería se basa en el análisis de registros provenientes de bases de

datos operacionales o bien bodegas de datos (Datawarehouse).

Por lo tanto, los retos de la Minería de Datos son: por un lado, trabajar con grandes volúmenes de

datos, procedentes mayoritariamente de sistemas de información, con los problemas que ello

conlleva (ruido, datos ausentes, intratabilidad, volatilidad de los datos...), y por el otro usar técnicas

adecuadas para analizar los mismos y extraer conocimiento novedoso y útil. En muchos casos la

utilidad del conocimiento minado está íntimamente relacionada con la comprensibilidad del modelo

inferido [Carreras Gómez A., 2005].

2.4.2. Orígenes y evolución

Según, Los orígenes del Data Mining se pueden establecer a principios de la década de 1980, cuando

la administración de hacienda estadounidense desarrolló un programa de investigación para detectar



32

fraudes en la declaración y evasión de impuestos, mediante lógica difusa, redes neuronales y técnicas

de reconocimiento de patrones [Rodríguez Montequín, M. et al. 2003]. Sin embargo, la gran

expansión del Data Mining se produce en la década de 1990 originada principalmente por tres

factores:

- Incremento de la potencia de las computadoras.

- Incremento del ritmo de adquisición de datos.

- Aparición de nuevos métodos de técnicas de aprendizaje y almacenamiento de datos.

En este sentido, la expansión implica el desarrollo de proyectos cada vez más grandes en un sector en

el que difícilmente se pueden extraer conclusiones a priori y en el que la selección de la mejor

técnica no se puede hacer en las primeras fases sino que se precisa un modelo evolutivo, similar al

modelo espiral del ciclo de vida de desarrollo software. Por otra parte, el hecho de que más del 75%

del esfuerzo se produzca en las primeras fases (en este caso en el pre tratamiento de datos) provoca

que este tipo de proyectos sea en general subestimado en cuanto a coste y tiempo y que las

desviaciones producidas excedan con mucho el 90%.

Ante la necesidad existente en el mercado de una aproximación sistemática para la realización de los

proyectos de Data Mining, diversas empresas y consultorías han especificado un proceso de

modelado diseñado para guiar al usuario a través de una sucesión de pasos que le dirijan a obtener

buenos resultados. Así SAS propone la utilización de la metodología SEMMA (Sample, Explore,

Modify, Model, Assess). En 1999 un importante consorcio de empresas europeas, NCR (Dinamarca),

AG (Alemania), SPSS (Inglaterra) y OHRA (Holanda), unieron sus recursos para el desarrollo de la

metodología de libre distribución CRISP-DM (Cross- Industry Standard Process for Data Mining).

Esta metodología, junto con la metodología SEMMA, son las dos principales metodologías utilizadas

por los analistas en los proyectos de Data Mining. [Huerta J.]

Desde el punto de vista de la Inteligencia de Negocios [Britos P., García Martínez R.,

TECNOLOGÍAS INTELIGENTES PARA EXPLOTACIÓN DE INFORMACIÓN]

- La explotación de Información es la sub-disciplina Informática que aporta a la Inteligencia de

Negocio las herramientas (procesos y tecnologías) para la transformación de información en

conocimiento.

- La explotación de información basada en tecnologías de sistemas inteligentes se refiere a la

aplicación de métodos de sistemas inteligentes, para descubrir y enumerar patrones de

conocimiento presentes en la información

Un proyecto de Explotación de Información involucra, en general las siguientes fases [Maimon y

Rokach, 2005]: comprensión del negocio y del problema que se quiere resolver, determinación,



33

obtención y limpieza de los datos necesarios, creación de modelos matemáticos, ejecución,

validación de los algoritmos, comunicación de los resultados obtenidos; e integración de los mismos,

si procede, con los resultados en un sistema transaccional o similar. La relación entre todas estas

fases tiene una complejidad que se traduce en una jerarquía de subfases. [Britos P., 2008].

2.4.3. Contexto

Sin embargo, y a pesar de que en la actualidad se cuenta herramientas de procesamiento poderosas y

quizás las limitaciones, en cuanto a infraestructura no se presentan como en los inicios del

Dataminig. Se ha constatado que muchos de estos proyectos no terminan y que incluso habiendo

terminado, éstos no lo hacen en los plazos y/o con los presupuestos previstos o no corresponden con

las expectativas de los clientes. Entre las principales causas identificadas y que explican estos

hechos, están las relacionadas con la falta de procesos de desarrollo estandarizados que incorporen

un enfoque ingenieril al desarrollo de proyectos de Data Mining [Gallardo Arancibia, 2009]

Los proyectos de Explotación de Información son un tipo especial de proyecto de Ingeniería en

Software. En lugar de requerir desarrollar un software específico, herramientas disponibles son

utilizadas que ya incluyen las técnicas y algoritmos necesarios. Como resultado las características de

los proyectos de Explotación de Información son diferentes a los de la Ingeniería en Software

Tradicional y de la Ingeniería del Conocimiento. Pero de todas formas posee problemas similares.

Estudios realizados sobre sobre proyectos de Explotación de Información han detectado que la

mayoría de los proyectos finaliza en fracaso. En el año 2000 se ha había determinado que el 85% de

los proyectos no alcanzan sus metas, mientras que en el 2005 el porcentaje de fracaso bajo a

aproximadamente el 60%. Por lo tanto se puede decir que la comunidad ha estado trabajando en el

camino correcto pero hay cuestiones de gestión que todavía deben ser mejorados. [García Martínez

R., et al. 2013].



34

FUTURAS LÍNEAS DE INVESTIGACIÓN ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN


35

3. CONCLUSIONES

En este trabajo, se buscaba implícitamente poder resolver algunas cuestiones, después de definir y

contextualizar los proyectos de explotación de información, tales como: si una vez presentados los

distintos modelos conocidos de ciclo de vida de proyectos de software, cómo se podrían adecuar a

los proyectos de explotación de datos. Cuáles iban a ser los criterios en base a los que debería

elegirse el ciclo de vida más apropiado para un proyecto de este tipo. O bien, qué modelo de ciclo de

vida convenía usar, uno de entre varios o una combinación de ellos.

Por todo lo anteriormente expuesto, y la importancia de elegir el Ciclo de Vida que seguirá el

producto a construir, al comienzo de un proyecto de software, teniendo en cuenta lo que esta decisión

representa en un proyecto de explotación de información. Se justifica el desarrollo de un Modelo de

Ciclo de Vida que contemple las tareas y actividades del Modelo de Proceso del Proyecto de

Explotación de Información presentado por Vanrell en su tesis 2012, y que tome como base y

referente, debido a las característica de los proyectos de DM, el modelo de ciclo de vida en espiral

desarrollado por Boehm.

Esta opción se debe a varias características propias definidas por el modelo espiral como lo son: el

enfoque cíclico de forma incremental cuyo grado de definición se va refinando, disminuyendo a su

vez el riesgo; los hitos que presenta en cada fase de desarrollo, y que permite asegurar el

compromiso de las partes interesadas; la capacidad de adaptarse a los cambios que se presentan; la

incorporación de la calidad en los objetivos y el manejo de los riesgos. Estas características se

corresponden en mayor medida con las propias de los proyectos de explotación de información por lo

que, a través de su implementación, sobre el modelo de procesos presentado en última instancia, se

podría lograr una mayor calidad y refinamiento de los resultados obtenidos del proceso de desarrollo

de los proyectos de explotación de Información.

FUTURAS LÍNEAS DE INVESTIGACIÓN ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN


36

REFERENCIAS ELEMENTOS PARA UN MODELO DE CICLO DE VIDA PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN


37

4. REFERENCIAS

Abraham, A. (2003). Business Intelligence from Web Usage Mining. Journal of Information &

Knowledge Management, 2(4): 375-390.

Boehm, B. (1981) Software Engineering Economics. Prentice Hall, Upper Saddle River, N.J.

Böehm, B.W., 1987. A Spiral Model of Software Development and Enhancement.Software

Engineering Project Management, IEEE Computer Society.

Boehm, B.W., C. Abts, A.W. Brown, S. Chulani, B.K.Clark, E. Horowitz, R. Madachy, D. Reifer, B.

Steece.(2000). Software Cost Estimation with COCOMO II, Prentice-Hall, Englewood

Cliffs Boehm, Barry W., TRW Defense Systems Group (1988), A Spiral Model of

Software Development and Enhancement.

Boehm B. W., 1993. A spiral model of software development and enhancement. In R. Donald, editor,

Software Management, pages 120–131. IEEE Computer Society Press, 1993. Reprinted

from em Computer, Vol. 21, No. 5, May 1988, pp. 61-72.

Britos P., 2001. Sistema de Ayuda sobre Legislación Argentina en Riesgos de Trabajo. Tesis de

Máster en Ingeniería del Conocimiento. Universidad Politécnica de Madrid.

Britos, P., Fernández, E., García-Martínez, R. (2006). Propuesta Matriz de Actividades para un Ciclo

de Vida de Explotación de Datos. Reportes Técnicos en Ingeniería del Software. 8(2):

36-42. ISSN 1667-5002.

Britos P., Fernández E., García-Martinez R., (2007). PROPUESTA METODOLOGICA PARA LA

EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE

INFORMACIÓN. IX Workshop de Investigadores en Ciencias de la Computación

(2007) Pág. 497-501

Britos P., 2008. Procesos de Explotación de Información basados en Sistemas Inteligentes. Tesis

presentada para obtener el grado de Doctor en Ciencias Informáticas. UNIVERSIDAD

NACIONAL DE LA PLATA - FACULTAD DE INFORMÁTICA.

Britos P., García Martínez R. TECNOLOGÍAS INTELIGENTES PARA EXPLOTACIÓN DE

INFORMACIÓN – FUNDAMENTOS. Material de consulta Facultad de Ingeniería.

Universidad de Buenos Aires. http://laboratorios.fi.uba.ar/lsi/rgm/CD-TIpEI/Ap-

Fundamentos.pdf , actualizado a Nov 2013.

Carreras Gómez A. (2005). Proceso de Data Mining en sistema de medición de calidad en plazo del

correo nacional. Tesis de Ingeniero en Informática. UNIVERSIDAD PONTIFICIA

COMILLAS - ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI).

http://www.iit.upcomillas.es/pfc/resumenes/42c18fb7dc010.pdf, actualizado a Dic 2013.

http://laboratorios.fi.uba.ar/lsi/rgm/CD-TIpEI/Ap-Fundamentos.pdf

http://laboratorios.fi.uba.ar/lsi/rgm/CD-TIpEI/Ap-Fundamentos.pdf

http://www.iit.upcomillas.es/pfc/resumenes/42c18fb7dc010.pdf



38

Cooley, R. (2003). The Use of Web Structure and Content to Identify Subjectively Interesting Web

Usage Patterns. ACM Transactions on Internet Technology, 3(2): 93-116.

Curtis, B.; Kellner, M.; Over, J. (1992). Process Modelling. Communications of the ACM, 35(9): 75-

90.

Chapman, P., Clinton, J., Kerber, R., Khabaza, T., Reinartz, T., Shearer, C. y Wirth, R. (2000).

CRISP-DM 1.0 Step-by-step Data Mining guide. U.S.A.

ftp://ftp.software.ibm.com/software/analytics/spss/support/Modeler/Documentation/14/U

serManual/CRISP-DM.pdf actualizado a Nov 2013.

Diez, E., Britos, P., Rossi, B., García-Martínez, R. (2003). Generación Asistida del Mapa de

Actividades de Proyectos de Desarrollo de Software. Reportes Técnicos en Ingeniería del

Software. (5)1:13-18. ISSN 1667-5002.

Fayad, U. M., Piatetsky-Shapiro, G., Smyth, P., Uhturudsamy, R. (1996). Advances in Knowledge

Discovery and Data Mining, (editors). AAAI Press.

Gallardo Arancibia J. A., 2009. Metodología para la Definición de Requisitos en Proyectos de Data

Mining (ER-DM). DEPARTAMENTO DE LENGUAJES Y SISTEMAS

INFORMÁTICOS E INGENIERÍA DE SOFTWARE. Facultad de Informática.

Gambin D., Pallota E., 2009. Minería de datos aplicada a cultivos de maíz. Trabajo Profesional para

obtener grado de Ingeniero en Informática. Facultad de Ingeniería. Universidad de

Buenos Aires.

García-Martínez, R., Lelli, R., Merlino, H., Cornachia, L., Rodriguez, D., Pytel, P., Arboleya, H,

2011. INGENIERÍA DE PROYECTOS DE EXPLOTACION DE INFORMACION

PARA PYMES. Proceedings XIII Workshop de Investigadores en Ciencias de la

Computación. Pág. 253-257. ISBN 978-950-673-892-1. 5 y 6 de Mayo de 2011.

Universidad Nacional de Rosario. Rosario. Santa Fe. Argentina

Gómez, A., Juristo, N., Montes, C., Pazos, J. Ingeniería del Conocimiento. Centro de Estudios

Ramón Areces. S.A., Madrid, 1997.

Gutiérrez, F. (2007), RETOS EN LA GESTIÓN DE PROYECTOS DE DATA MINING, trabajo

tutelado Universidad Politécnica de Madrid - Facultad de Informática - Departamento de

Lenguajes y Sistemas Informáticos e Ingeniería del Software.

Juristo Juzgado, N. (1996), Proceso de Construcción de Software y Ciclos de vida. Máster en

Ingeniería del Software e Ingeniería del Conocimiento, unidad 2, Madrid, 1996.

Juristo, N. (2003). Proceso Software. Material Maestría en Ingeniería del Software, Módulo I:

CONTROL Y GESTIÓN DE PROYECTOS SOFTWARE, del Instituto Tecnológico de

Buenos Aires – Facultad de Informática de la Universidad Politécnica de Madrid.

ftp://ftp.software.ibm.com/software/analytics/spss/support/Modeler/Documentation/14/UserManual/CRISP-DM.pdf

ftp://ftp.software.ibm.com/software/analytics/spss/support/Modeler/Documentation/14/UserManual/CRISP-DM.pdf



39

Langseth, J., Vivatrat, N. (2003). Why Proactive Business Intelligence is a Hallmark of the Real-

Time Enterprise: Outward Bound. Intelligent Enterprise 5(18): 34-41.

Maimon, O., Rokach, L. (2005). The Data Mining and Knowledge Discovery Handbook. Springer

Science + Business Media Publishers.

Macro, A., 1990. Software Engineering concepts and management. Prentice-Hall, Nueva York, 1990.

Mariscal G, Marbán O., Gonzalez A., Segovia J. (2007), Hacia la Ingeniería de Data Mining: Un

modelo de proceso para el desarrollo de proyectos. II Congreso Español de Informática.

http://www.lsi.us.es/redmidas/CEDI07/%5B14%5D.pdf

Mobasher, B, R Cooley and J Srivastava (1999). Creating adaptive web sites through usagebased

clustering of URLs. ProceedingsWorkshop on Knowledge and Data Engineering

Exchange, Pág. 19-25.

Molina Félix, L. (2002), Data mining: torturando a los datos hasta que confiesen.

http://www.uoc.edu/web/esp/art/uoc/molina1102/molina1102.html, actualizado hasta

Nov 2013.

Piatetsky-Shapiro G., 2007, Data mining and knowledge discovery 1996 to 2005: overcoming the

hype and moving from “university” to “business” and “analytics”. Published online: 27

January 2007, Springer Science+Business Media, LLC 2007.

http://link.springer.com/article/10.1007%2Fs10618-006-0058-2

Pyle, D. (2004), THIS WAY FAILURE LIES, DB2 Magazine, Vol 1, issue1.2004.

Pytel P., Britos P., García Martínez R., 2013. Modelos para Asistir la Gestión de Proyectos de

Explotación de Información. Revista Latinoamericana de Ingeniería de Software, 1(1): 8-

17, ISSN 2314-2642.

Rodríguez Montequín M. T., Álvarez Cabal J., Mesa Fernández J. M., González Valdés A., 2003.

METODOLOGÍAS PARA LA REALIZACIÓN DE PROYECTOS DE DATA

MINING. Congreso Pamplona 2003 de AEIPRO, Asociación Española representante de

IPMA (International Project Management Association).

http://aeipro.com/files/congresos/2003pamplona/ciip03_0257_0265.2134.pdf actualizado

a Nov 2013.

Rodríguez, D., Pollo-Cattaneo, F., Britos, P., García-Martínez, R. (2010). Estimación Empírica de

Carga de Trabajo en Proyectos de Explotación de Información. Anales del XVI Congreso

Argentino de Ciencias de la Computación. Pp. 664-673. ISBN 978-950-9474-49-9.

Rossi B., 2001. SISTEMA EXPERTO DE AYUDA PARA LA SELECCIÓN DEL MODELO DE

CICLO DE VIDA. Tesis de Master. Instituto Tecnológico de Buenos Aires –

Universidad Politécnica de Madrid.

http://www.lsi.us.es/redmidas/CEDI07/%5B14%5D.pdf

http://www.uoc.edu/web/esp/art/uoc/molina1102/molina1102.html

http://link.springer.com/article/10.1007%2Fs10618-006-0058-2

http://aeipro.com/files/congresos/2003pamplona/ciip03_0257_0265.2134.pdf



40

Srivastava, J., Cooley, R., Deshpande, M., Tan, P. (2000). Web Usage Mining: Discovery and

Applications of Usage Patterns from Web Data. SIGKDD Explorations, 1(2): 12-23.

Umapathy, K. (2007). Towards Co-Design of Business Processes and Information Systems Using

Web Services. Proceedings 40th Annual Hawaii International Conference on System

Sciences

http://www.kdnuggets.com/news/2004/n08/18i.html actualizado a Nov 2013.

Vanrell, J. (2012). Un Modelo de Procesos para Proyectos de Explotación de Información. Tesis

de Magister en Ingeniería de Sistemas de Información. Facultad Regional Buenos Aires.

Universidad Tecnológica Nacional.

http://www.kdnuggets.com/news/2004/n08/18i.html

elementos para un modelo de ciclo de vida … · dra. paola britos (unrn) y mg. darío rodríguez...

Documents