trabajo tutelado retos en la gestiÓn de proyectos de
TRANSCRIPT
1
UNIVERSIDAD POLITECNCIA DE MADRID
FACULTAD DE INFORMÁTICA
DEPARTAMENTO DE LENGUAJES Y SISTEMAS
INFORMÁTICOS E INGENIERÍA DEL SOFTWARE
Trabajo Tutelado
RETOS EN LA GESTIÓN DE PROYECTOS DE
DATA MINING
Tutora : Dra. Ernestina Menasalvas Ruíz
Alumno : Marco Antonio Gutiérrez F.
Madrid, Agosto 2007
2
Índice
1 Introducción y Motivación...................................................................................................... 4
1.1 Relevancia de la gestión de proyectos de Data Mining .................................................. 4
1.2 Problemas de la gestión de proyectos de Data Mining .................................................. 6
1.3 Hechos y Casos de Fracasos .......................................................................................... 8
1.4 Objetivos del Trabajo Tutelado ................................................................................... 10
2 Related work ...................................................................................................................... 11
2.1 Gestión de Proyectos .................................................................................................. 11
2.1.1 Ciclo de vida del proyecto.................................................................................... 14
2.1.2 Áreas de conocimiento para la gestión de proyectos ........................................... 16
2.1.3 Framework para la gestión de proyectos ............................................................. 17
2.1.4 Elementos críticos en la gestión de proyectos...................................................... 17
2.2 Gestión de Proyectos de Software............................................................................... 20
2.2.1 Descripción de RUP ............................................................................................. 21
2.2.2 Dimensiones y disciplinas de RUP ........................................................................ 21
2.2.3 Ciclo de vida de RUP ............................................................................................ 23
2.2.4 Disciplina de gestión de proyectos de RUP........................................................... 23
2.2.5 Elementos críticos en la gestión de proyectos de software .................................. 23
2.3 Gestión de Proyectos de Data Mining.......................................................................... 25
2.3.1 Metodología CRISP-DM ....................................................................................... 25
2.3.2 Mapeo desde el modelo genérico al especializado.............................................. 26
2.3.3 Modelo de referencia CRISP-DM ......................................................................... 27
3 Conclusiones ...................................................................................................................... 30
3.1.1 En relación a la gestión de proyectos de data mining .......................................... 30
3.1.2 Análisis de metodologías hacia la gestión de proyectos de data mining ............... 31
3.1.3 Tendencias en la gestión de proyectos de data mining ........................................ 33
4 Referencias ........................................................................................................................ 35
3
Índices de Figuras
Figura 1-1 Industrias y Campos de Aplicación de Data Mining (basado en www.Kdnuggets.com) .................. 5 Figura 1-2 de proyectos CRM considerados Fallidos (KDnuggets.com, 2007) ............................................... 9 Figura 1-3 Grupo de procesos que interactúan en un proyecto ................................................................... 13 Figura 1-4 Detalle esquemático de cada nodo de la matriz ......................................................................... 14 Figura 1-5 Dimensiones de Competencias del Project Management ........................................................... 14 Figura 1-6 Ciclos de vida de proyectos de software .................................................................................... 15 Figura 1-7 Framework para la gestión de proyectos ................................................................................... 17 Figura 1-8 Rational Unified Process ........................................................................................................... 20 Figura 1-9 Roles, actividades y artefactos .................................................................................................. 22 Figura 1-10 Ciclo de vida de RUP .............................................................................................................. 24 Figura 1-11 Metodología Data Mining CRISP-DM ...................................................................................... 25 Figura 1-12 Fases de un proceso de Data Mining ...................................................................................... 28 Figura 1-13 Resolución de problemas y la técnica de fault-finding .............................................................. 32
Indices de Tablas
Tabla 1-1 Grupos de procesos y áreas de conocimiento ............................................................................. 13 Tabla 1-2 Tareas genéricas y salidas del modelo de referencia CRISP-DM ................................................ 30 Tabla 1-3 Mapeo de PMBOK, RUP, CRISP-DM ......................................................................................... 32 Tabla 1-4 Mapeo de procesos, disciplinas y fases ...................................................................................... 33
4
1 Introducción y Motivación
1.1 Relevancia de la gestión de proyectos de Data Mining
El éxito de las organizaciones en el siglo veintiuno esta cada vez más asociado al uso
eficiente del conocimiento y la información para el logro de sus objetivos, de ahí que a
este periodo de la historia se le conozca como la Era de la Información ó la Sociedad del
Conocimiento. La sobrevivencia en esta era, donde la competencia es un factor clave,
requiere de las organizaciones un conocimiento profundo de los patrones de
comportamiento de sus clientes y un acceso selectivo a aquella información oculta en la
gran cantidad de datos almacenados en sus repositorios [King, 2005]. 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).
En sus inicios, [Fayyad et al., 1996] se consideró al Data Mining como un paso crucial del
proceso de descubrimiento de conocimiento en bases de datos (KDD), sin embargo hoy
en día el término Data Mining es el proceso de KDD en si mismo [Wasilewska et al.,
2007].
El uso de Data Mining en organizaciones de diversa índole ha ido aumentando
gradualmente en la última década [Piatetsky-Shapiro, 2007] y ha pasado de ser una
herramienta utilizada para conocer más a los clientes a convertirse en el conductor de las
estrategias empresariales [Ingebretsen, 2003]. Data Mining ha sido introducida
exitosamente en el sector público y privado, en un amplio rango de aplicaciones. En el
sector público DM fue usado inicialmente para detectar abusos y fraudes financieros
[Chan et al, 99]; 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 diagnostico,
análisis financiero y detección de fraudes [KDNuggets, 2007]. Adicionalmente, es
interesante constatar como las áreas industriales y campos de aplicación del Data Mining
han experimentado una importante variación en los últimos 5 años. Al comparar las
estadísticas que presenta KDnuggets, en su sitio web, respecto a este tema es posible
ver el área de CRM ocupando un lugar muy importante en el 2006 versus su inexistencia
en el año 2001; así también el área de banking pasa de ser la más importante, a
convertirse en un área sin relevancia en el año 2006 (ver Figura 1-1).
Piatetsky-Shapiro en el 2007 sostiene que el uso de las herramientas de Data Mining se
ha potenciado en los últimos 10 años debido a factores tales como el fuerte surgimiento
del comercio electrónico, los progresos en biología y los requerimientos de la seguridad
antiterrorista entre otros. Asimismo, este autor enfatiza en un análisis de las 10 palabras
utilizadas con mayor frecuencia entre 1996 y 2005, por los especialistas en DM en el sitio
www.KDnuggets.com, que las palabras “data” y “Mining” ocupan el primer y segundo
lugar respectivamente. Sin embargo, la palabra que llega a ocupar el tercer lugar en
1996 es “universidad”, mientras que en el 2005 la nueva palabra que aparece en su
reemplazo es “negocios”, reflejando el cambio de enfoque de uso con fines de
investigación a utilización con fines comerciales [Piatetsky-Shapiro, 2007]. Asimismo, la
consultora Gartner, en diciembre de 2006, da a conocer el conjunto de tecnologías que
5
tendrían mayor impacto en el mediano y largo plazo, y considera la “Gestión de la
información Empresarial (GIE)” en el tercer lugar. Gartner destaca además, que para el
2007 el 20% de las principales empresas de Fortune utilizaran esquemas de
administración GIE en apoyo a la Arquitectura Orientada al Servicio (SOA).
Figura 1-1 Industrias y Campos de Aplicación de Data Mining (basado en www.Kdnuggets.com)
A pesar que las organizaciones ya han entendido la relevancia de los proyectos de data
mining para alcanzar un mejor posicionamiento competitivo, existen hoy serias
problemáticas asociadas a la puesta en marcha y administración de proyectos de esta
naturaleza [Brachman, 1996]; [Richardson and Butler 2006]; [Becker, 2005].
Investigadores del área de DM y personal de empresas están conscientes de las
problemáticas que se enfrentan en el desarrollo de proyectos de esta naturaleza; sin
embargo, no existe consenso entre los investigadores en el área de gestión de proyectos
de Tecnologías de Información acerca de lo que constituye un proyecto fallido, aunque
en general se distinguen dos tipos de problemáticas, las económicas y aquellas
relacionadas con los requerimientos, costos y parámetros de tiempo [Becker and
Ghedini, 2005]. Es decir, si un proyecto no genera el retorno esperado, si los costos
asociados a su implementación exceden lo presupuestado, constituiría una falla
económica; no obstante, aquel que no entrega las características prometidas a tiempo y
dentro de los presupuestos, también sería un proyecto fallido, cuya causa puede darse
por una mala implementación y gestión. Un reporte de Extreme Chaos [Standish
Group’s, 2004] manifiesta que en los Estados Unidos se gastan más de 250 billones de
dólares cada año en cerca de 175.000 proyectos de aplicaciones de tecnologías de la
información. Indica además, que el costo promedio de un proyecto en una compañía
grande es de aproximadamente 2,3 millones de dólares, en una compañía mediana de
1,3 millones de dólares y de 0,4 millones en una pequeña empresa. Pero, sin embargo,
6
muchos de estos proyectos fallan en sus resultados. Las estadísticas más abrumadoras
en este reporte señalan que el 31,1% de los proyectos serian cancelados antes de ser
completados, el 52,7% de los proyectos costarían 189% más que su presupuesto original
y eso no considera la pérdida del costo de oportunidad de los recursos. El mismo reporte
de Extreme Chaos en el año 2001, [Standish Group’s, 2001], indica que la tasa de éxito
de los proyectos de TI aumentó alrededor del 75% sobre la tasa del año 1994 y entre las
principales razones que se esgrimen fue el uso de: “Mejores herramientas” y “Monitoreo
y control del progreso de los proyectos y administradores de proyectos con mejores
habilidades”.
1.2 Problemas de la gestión de proyectos de Data Mining
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.
Existen variadas razones que ayudan a explicar esta paradoja. [Becker ,2005] sostiene
que muchos de los problemas que enfrentan los proyectos de DM se pueden asociar a:
dificultades para definir objetivos compatibles con lo que pueden revelar los datos que se
encuentran disponibles; al esfuerzo concentrado en la fase de preparación de datos; la
experimentación con parámetros y transformaciones de datos en la fase de minería; falta
de apoyo metodológico, sobrecarga de rehacer el trabajo, dificultad de administrar y
relacionar recurso y resultados de una aplicación de DM. Adicionalmente, existen
problemas que se producen al inicio del proceso y se arrastran durante toda la ejecución
del proyecto. Jean Que Louie [Louie, 2003] Presidente de Nautilus Systems, Inc.,
menciona que los desarrolladores de proyectos en el área de DM cometen serios errores
al considerar válidas las siguientes cuatro falacias del Data Mining [Larose, 2005]:
Falacia 1: Hay herramientas de Data Mining que pueden convertir nuestros repositorios
de datos y dar respuestas a nuestros problemas.
Falacia 2: El proceso del Data Mining es autónomo, requiere poco o nada del cuidado
humano.
Falacia 3: El Data Mining se paga solo muy rápidamente.
Falacia 4: Los paquetes de software de Data Mining son intuitivos y fáciles de usar.
A la lista de arriba, el autor agrega dos falacias comunes adicionales:
Falacia 5: Data Mining identificará las causas de los problemas del negocio o de la
investigación.
Falacia 6: Data Mining limpiará una base de datos sucia automáticamente.
Las falacias presentadas por el autor [Larose, 2005] permiten entender las principales
problemáticas que conlleva un proyecto de Data Mining en la organización. Una buena
administración, gestión y puesta en marcha de los mismos permite evitar las pérdidas de
tiempo y recursos tras su implementación y permitirá obtener mejores resultados para las
metas propuestas por parte de la empresa.
7
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. Los
profesionales de la minería de datos que se dirigen hacia el fracaso, parecen seguir
patrones (reglas), o peores prácticas, así como quienes intentan seguir el éxito, buscan
las mejores prácticas. Existen nueve simples reglas, que se deben evitar, para no
fracasar en un proyecto de minería de datos:
Regla 1: Hacer Data Mining directamente de los datos que se recogen.
Regla 2: Modelar el problema en términos de datos.
Regla 3: Enfocarse solamente en la manera más obvia de enmarcar el problema.
Regla 4: Confiar en su propio juicio.
Regla 5: Encontrar los mejores algoritmos (no buscar el que se ajusta mejor al proyecto).
Regla 6: Confiar en la memoria (no documentar).
Regla 7: Utilizar la intuición como elemento fundamental en lugar de las prácticas
estándar.
Regla 8: Reducir al mínimo la interacción entre los profesionales de data mining y los
encargados del negocio.
Regla 9: Reducir al mínimo la preparación de los datos.
[Pyle, 2004] enfatiza que necesario entender que Data Mining es parte, y más aún, una
pequeña parte, de un proceso de negocios mucho mayor y que además puede ser una
parte esencial de un proyecto de Data Mining, pero al incorporar los resultados de la
minería de datos con todas las otras partes relacionadas del proyecto corporativo es
igualmente, sino la mas, importante para el éxito final.
Standish Group’s (2001), en el extreme report sostiene que los 10 principales factores
considerados más relevantes por los ejecutivos de IT, para el éxito de proyectos de data
mining son los siguientes: el involucramiento del usuario, el apoyo de los ejecutivos
máximos, un claro planteamiento de los requerimientos, una adecuada planificación,
expectativas realistas, pequeños hitos del proyecto, staff competente, apropiabilidad por
parte del equipo, visión y objetivos claros y un staff enfocado que trabaja duro. Asimismo,
[Becker, 2005], sostiene que una gestión efectiva del proyecto es una factor clave de
éxito de proyectos de KDD. En este sentido los mismos autores mencionan la
documentación sistemática de conocimientos, experimentos, datos y resultados previos
como un medio invaluable para mantener un seguimiento del estatus actual del proyecto.
La literatura destaca la importancia de la utilización de herramientas de aceptación
generalizada y profesionales para la gestión de proyectos en general y de proyectos de
data mining en particular. En dicho contexto se hace relevante la incorporación
sistemática y la adecuación de metodologías de gestión de proyectos integrales
aceptadas universalmente para la administración de proyectos de Data Mining. En este
8
sentido destacan como herramientas de uso generalizado para gestionar proyectos el
PMBOK y RUP.
1.3 Hechos y Casos de Fracasos
El desarrollo de proyectos de Data Mining ha evolucionado desde una disciplina
reservada al medio científico y universitario a constituirse en una de las armas
estratégicas más importantes en el mundo de los negocios. Esta evolución incluye
nuevas áreas de investigación, tales como Web Mining, Redes Sociales, y Multimedia
Mining [Piatesky, 2007]. Lo anterior, se puede observar a través de algunas de las
estadísticas obtenidas del sitio www.kdnuggets.com, que fueron presentadas por
Piatesky-Sahpiro en un artículo el año 2007, que se muestra que el número de trabajos
ofrecidos en KDnuggets (ver Figura N° 1.1) en el año 1997 se concentraban en el sector
académico, y que los trabajos solicitados para el sector Industrial comenzaron a ser
significativamente mayores a partir del año 2000 seguido de una baja y una importante
recuperación desde el 2003 en adelante.
Figura N° 1.1 Trabajos ofrecidos en KDnuggets (Extraído de Piatesky-Sahpiro, 2007)
Sin embargo, estos avances del Data Mining en las áreas de negocios no han estado
exentos de problemas, errores y fracasos. Es posible mencionar casos donde proyectos
de gran envergadura han fallado y debido a diversas problemáticas. [Kelley, 2003]
presenta también algunas de las principales fallas en proyectos de DataWarehouse y
Data Mining e identifica los once tipos de problemas que se pueden asociar a fallas de
proyectos de esta naturaleza:
1. El proyecto sobrepasa el presupuesto inicial
2. El proyecto se sale de la programación inicial
9
3. Funciones y capacidades no implementadas en el proyecto
4. Usuarios insatisfechos
5. Desempeño del proyecto inaceptable
6. Disponibilidad de las aplicaciones limitada y pobre
7. Inhabilidad para expandirse
8. Mala calidad de datos y reportes
9. Muy complejo para ser usado por los usuarios
10. Costos no justificados inicialmente en el proyecto
11. La administración no reconoce los beneficios del proyecto
Como ejemplo de las problemáticas que se enfrentan en la gestión de proyectos de Data
Mining es posible mencionar los variados intentos para desarrollar aplicaciones en áreas
comerciales, específicamente en la ejecución de proyectos de CRM. El sitio
KDnuggets.com realiza permanentemente encuestas a profesionales en Data Mining y
en el año 2001 consultó respecto a la experiencia con proyectos CRM y su percepción
sobre el porcentaje de fracasos. Como resultado alrededor del 73% de los que
respondieron consideran que entre el 40 y el 100% fueron proyectos fallidos y de ellos
un 11% respondió que entre un 81 y un 100% de los proyectos fallaron (ver Figura 1-2)
Encuesta KDnuggets
En su experiencia, que % de proyectos de CRM fallaron? [118 votes total]
0 - 20 (13) 11%
21 - 40 (19) 16%
41 - 60 (39) 33%
61 - 80 (34) 29%
81 - 100 (13) 11%
Figura 1-2 de proyectos CRM considerados Fallidos (KDnuggets.com, 2007)
En la actualidad existe una gran variedad de campos de aplicación de proyectos de Data
Mining y como mencionan Platetsky-Shapiro, Djeraba, Getoor, Grossman, Feldman y
Zaki (2006) los mayores desafíos se encuentran en dos grandes áreas de investigación
que involucran áreas de uso y datos: 1) Hacer minería del comportamiento de los
usuarios en la interacción con datos multimedia y el uso del conocimiento extraído en
este proceso para anticipar el futuro comportamiento o para diagnósticos médicos o
condiciones sicológicas de los usuarios es un tema que requiere de atención 2) Cruzar
la brecha semántica entre datos de multimedia y semánticos donde la dificultad es
10
extraer automáticamente el significado del contenido multimedia de manera que la
explotación usando información semántica pueda ser hecha a la medida de aplicaciones
individuales (ej. Seguridad, marketing, negocios, otras.) Estos autores también sugieren
que las investigaciones actuales se enfocan principalmente en tareas únicas tales como
ranking o predicción de links, pero en los escenarios reales de análisis de datos se
requieren una mezcla de todas las capacidades.
Finalmente, los desafíos que enfrenta el desarrollo de proyectos de Data Mining residen
en la necesidad de abordar problemáticas complejas que no se enfocan solo en áreas
tradicionales de los negocios sino que irán mas allá hacia temas que implican la esencia
del comportamiento social y humano y es aquí donde es necesario contar con
metodologías integrales y de un nivel multidimensional donde los errores y las fallas en la
gestión de los proyectos tienen un efecto catastrófico.
1.4 Objetivos del Trabajo Tutelado
Analizados los problemas que conlleva la gestión de los proyectos de data mining y
teniendo en cuenta las buenas prácticas, el tiempo de desarrollo y la aplicación de
metodologías en gestión de proyectos en dominios como la ingeniería del software, se
plantea como objetivo central de este trabajo tutelado el análisis de la gestión de
proyectos y su posible adaptación para la gestión de Proyectos DM. Este objetivo
considera la revisión de los avances y desarrollos en el área de la gestión de proyectos
con particular énfasis en proyectos de software. Asimismo, se estudiarán los fracasos y
las buenas prácticas en la gestión de proyectos de Data Mining.
Con el propósito de alcanzar el objetivo propuesto en este trabajo se plantea un análisis
en profundidad de la disciplina de gestión de proyectos basada fundamentalmente en los
conceptos del PMBOK y su aplicación en diversas areas del conocimiento.
Paralelamente, se estudiaran las herramientas y metodologías actualmente usadas para
gestionar proyectos de Data Mining y las principales problemáticas que se aprecian en
los procesos de concepción, diseño, implementación y puesta en marcha.
Consecuentemente, las siguientes secciones de este documento muestran en primer
lugar un análisis de la gestión de proyectos, su ciclo de vida, areas de conocimiento,
frameworks utilizadas y los elementos críticos en la gestión de proyectos. En segundo
lugar se presenta un análisis de la gestión de proyectos de software en el que se detalla
la metodología RUP, su ciclo de vida, las disciplinas de gestión de proyectos de RUP y
los elementos críticos en la gestión de proyectos de software. Posteriormente, se analiza
la gestión de proyectos de Data Mining considerando la metodología CRISP-DM, se
presenta el mapeo desde el modelo genérico al especializado y posteriormente se
presenta el modelo de referencia. El documento termina con las consecuencias extraídas
en relación ala gestión de proyectos de DM, un análisis comparativo de metodologías
hacia la gestión de proyectos de DM y finalmente las tendencias en la gestión de
proyectos de Data Mining.
11
2 Related work
2.1 Gestión de Proyectos
La práctica del Project Management ha evolucionado durante la mitad del último siglo
para formar parte de todas las industrias y gobiernos a nivel mundial. El trabajo
denominado “Project Management State of the Art” [Russell, 2004] presenta una visión
general de la disciplina, y ciertas tendencias de la gestión de proyectos, respecto de su
continua evolución.
Para poner un proyecto en perspectiva se requiere una definición [Charvat, 2003]. Una
de las definiciones de proyecto más aceptadas y utilizadas en la industria es la del
Project Management Institute (PMI) [PMBOK, 2004]. Organización que ha definido
Proyecto como “un esfuerzo temporal que se lleva a cabo para crear un producto,
servicio o resultado único”.
Adicionalmente, el PMI ha desarrollado el Project Management Body of Knowledge
[PMBOK, 2004], con la finalidad de identificar los fundamentos de la Gestión de
Proyectos generalmente reconocidos como buenas prácticas en las organizaciones. En
donde “identificar” significa proporcionar una descripción general en contraposición a una
descripción exhaustiva; por su parte, “generalmente reconocido” apunta a que los
conocimientos y las practicas descritos son aplicables a la mayoría de los proyectos, la
mayor parte del tiempo, y que existe un amplio consenso sobre su valor y utilidad; en
tanto que, “buenas prácticas” dice relación con que existe un acuerdo general en que la
correcta aplicación de estas habilidades, herramientas y técnicas puede aumentar las
posibilidades de éxito de una amplia gama de proyectos [Phillips, 2004].
Por otro lado, los autores de “Effective Project Management: Traditional, Adaptive,
Extreme” [Wysocki, 2003], definen que un proyecto “es una secuencia de actividades
únicas, complejas, y conectadas que tienen una meta o propósito y que se deben
terminar en un tiempo específico, dentro de presupuesto, y de acuerdo con las
especificaciones”.
Como señala el PMBOK® Guide, la gestión de proyectos es: “la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto
para satisfacer los requisitos del proyecto”. La gestión de proyecto incluye: Identificar los
requerimientos, además supone establecer un equilibrio entre demandas contrapuestas
a través de objetivos claros y posibles de realizar, equilibrar demandas concurrentes de
calidad, alcance, tiempo y costo, y adaptar las especificaciones, los planes y el enfoque
de los stakeholder (necesidades y expectativas).
A partir de lo anterior y según [PMBOK, 2004], se desprende que los proyectos están
compuestos de procesos, en donde cada proceso es “una serie de acciones que
producen un resultado”, procesos que, a su vez, son realizados por personas. En
[Phillips, 2004] se ha identificado dos categorías que interactúan a lo largo del proyecto.
Los procesos de gestión de proyectos (universales a todos los proyectos y controlan
12
el ciclo de vida del proyecto), relacionados con la descripción y la organización del
trabajo del proyecto; y los procesos orientados al producto (son únicos al producto en
creación): relacionados con especificar y crear el producto del proyecto, que varían
según el campo de aplicación.
La Gestión de Proyectos se materializa mediante la aplicación e integración de los
siguientes cinco Grupos de Procesos de Gestión de Proyectos [Phillips, 2004]. Los
grupos de procesos tienen dependencias claras y se llevan a cabo siguiendo la misma
secuencia en cada proyecto. Son independientes de los enfoques de las áreas de
aplicación o de la industria.
Los cinco grupos de procesos componen proyectos y fases de proyectos. Cada uno tiene
un conjunto de acciones que llevan el proyecto a su finalización [PMBOK, 2004]:
Iniciación: reconocimiento de que un proyecto o una fase de un proyecto deben
comenzar; y compromiso de su puesta en marcha.
Planificación: inventar y mantener un esquema de trabajo para conseguir los objetivos
del negocio que motivaron la realización del proyecto.
Ejecución: coordinar a las personas y demás recursos para la puesta en marcha del
plan del proyecto.
Control: asegurar que los objetivos del proyecto están cumpliéndose, mediante la
supervisión y medición de los progresos y tomando acciones correctivas cuando es
necesario.
Finalización: aceptación formal de los resultados de un proyecto o fase y realización
ordenada de su cierre.
Dentro de los 5 grupos mencionados, hay 2 categorías de procesos: centrales (son
lógicos en orden y siguen una progresión algo rigurosa) y los facilitadores (son más
flexibles, apoyan los procesos centrales) [Phillips, 2004].
Al interior de cada uno de estos cincos grupos de procesos, se gestan procesos
adicionales que pertenecen a diversas áreas de conocimiento requeridas para la gestión
de proyectos. Estos procesos representan la utilización de las mejores prácticas en
materia de aplicación de métodos y técnicas para disminuir los riesgos y asegurar el
éxito del proyecto [Competency PMBOK, 2001].
13
Level
ofActivity
Phase Start Time Phase End
Planning
Executing
ClosingInitiating
Controlling
• Project Integration Mgmt• Project Plan Execution
• Project Quality Mgmt• Quality Assurance
• Project HR Mgmt• Team Development
• Project Communication Mgmt
• Information Distribution
• Project Procurement Mgmt
• Solicitation• Source Selection
• Contract Admin
Figura 1-3 Grupo de procesos que interactúan en un proyecto
Cada área del conocimiento está constantemente evolucionando respecto de sus
técnicas, métodos y aplicación, esto hace que la gestión de proyectos este en
mejoramiento permanente. En la Tabla 1-1 se presenta en forma matricial lo expuesto
anteriormente, y en la Figura 1-4 el detalle esquemático de cada nodo de la matriz.
Grupo de Procesos
de Iniciación
Grupo de Procesos
de Planificación
Grupo de Procesos
de Seguimiento y
Control
Grupo de Procesos
de Ejecución
Grupo de Procesos
de Cierre
• Desarrollar el acta de
constitución del Proyecto
• Desarrollar el enunciado de
alcance del proyecto
• Desarrollar el plan de gestión
del proyecto
• Dirigir y Gestionar la
Ejecución del Proyecto
• Supervisar y controlar el
trabajo del proyecto
• Control Integrado de
Cambios
• Cerrar el proyecto
• Planificar el alcance.
• Definir el alcance
• Crear EDT
• Verificar el alcance
• Controlar el alcance
• Definir las actividades.
• Establecer una secuencia de
las actividades.
• Estimar los recursos de las
actividades.
• Estimar la duración de las
actividades.
• Desarrollar el cronograma
• Controlar el cronograma
• Estimar los costos
• Preparar el presupuesto de
los costos
• Controlar los Costos
• Planificar la calidad • Realizar un aseguramiento
de la calidad
• Realizar un control de
calidad
• Planificar los RRHH • Adquirir al equipo del
proyecto
• Desarrollar al equipo del
proyecto
• Gestionar el equipo del
proyecto
• Planificar las comunicaciones • Distrinuir la información • Informar el rendimiento
• Gestionar a los interesados
• Planificar la gestión riesgos
• Identificar los riesgos
• Realizar un analisis
cualitativo de los riesgos
• Realizar un analisis
cuantitativo de los riesgos
• Planificar las respuestasa los
riesgos
• Realizar un seguimiento y
Control a los riesgos
• Planificar las compras y
adquisiones
• Planificar la contratación
• Solicitar respuestas de
vendedores
• Seleccionar vendedores
• Administrar el contrato • Cierre del contrato
Gestión de la
Integración del
Proyecto
Gestión del Alcance del
Proyecto
Gestión del Tiempo del
Proyecto
Gestión de los Costos
del Proyecto
Gestión de la Calidad
del Proyecto
Gestión de los RRHH
del Proyecto
Gestión de las
Comunicaciones del
Proyecto
Gestión de los Riesgos
del Proyecto
Gestión de las
Adquisiones del
Proyecto
Grupo deProcesosÁrea
del Conocimiento
Tabla 1-1 Grupos de procesos y áreas de conocimiento
14
Figura 1-4 Detalle esquemático de cada nodo de la matriz
Competency PMBOK, 2001] muestra en la ¡Error! No se encuentra el origen de la
referencia. las dimensiones de competencias del Project Management.
Figura 1-5 Dimensiones de Competencias del Project Management
2.1.1 Ciclo de vida del proyecto
Cada proyecto suele descomponerse temporalmente en “fases” o “etapas” [Phillips,
2004], [Charvat, 2003], [Wysocki, 2003], [Charvat, 2002], [Hughes, 1999], [Royce, 1998].
Con ello se busca: un mejor control de la gestión y adecuados enlaces con las
operaciones habituales de la organización. Además, cada fase supone la realización
completa de uno o varios entregables. Un entregable es un producto tangible y
comprobable [Guía PMBOK, 2004].
La conclusión de una fase supone revisar sus entregables y la ejecución del proyecto
para: determinar si el proyecto debe continuar y para detectar y corregir errores con un
costo aceptable.
15
De allí, que los proyectos se dividen en fases, puesto que en cada fase las personas
involucradas son diferentes [Competency PMBOK, 2001], y las actividades que se
ejecutan son también de diferentes índoles. Además, cada fase termina con un
“entregable” que es el inicio de la siguiente fase.
Los ciclos de vida de un proyecto generalmente se definen en función del trabajo técnico
que se debe realizar en cada etapa; cuándo se deben generar los productos entregables
en cada fase; cómo se revisa, verifica y valida cada producto entregable; y quién está
involucrado en cada fase para controlar y aprobar cada una de ellas. En la Figura 1-6 se
presenta una comparación de ciclos de vida de proyectos de software [McGilvray, 2007].
Typical Project
Life CycleJustification Planning
Requirements
and AnalysisDesign
Development
and TestingDeployment
Post
Production
Support
Rational Project
Process (RUP)Inception Elaboration TransitionConstruction
RUP Modified Inception Elaboration TransitionConstructionOperational
Support
Siebel eRoadmap
Implementation
Methodology
Define Discover ConfigureDesign Validate Deploy Sustain
Accelerated SAP
Methodology
(ASAP)
Project
Preparation
Business
BlueprintRealization
Final
Preparation
Go-Live and
Support
Oracle Application
Integration
Methodology (AIM)
DefinitionOperations
Analysis
Solution
DesignBuild Transition Production
Figura 1-6 Ciclos de vida de proyectos de software
Las fases siguen una secuencia lógica que asegura una adecuada definición del
producto del proyecto [Charvat, 2003]. Se debe diferenciar entre los objetivos del
proyecto y los objetivos del producto, servicio o resultado que dicho proyecto entrega
[PMBOK, 2004].
Objetivos del proyecto: son aquellos asociados a los parámetros de tiempo
(programa), costo (presupuesto y flujo de gastos) y calidad (aseguramiento de la
calidad de los procesos) y otros que se definan en el contrato.
Objetivo del producto, servicio o resultado: son aquellos asociados a los
requerimientos del Cliente y especificaciones técnicas que definen el producto,
servicio o resultado a entregar.
16
2.1.2 Áreas de conocimiento para la gestión de proyectos
Los grupos de procesos actúan recíprocamente el uno con el otro y con los procesos de
otras áreas del conocimiento (técnicos y de gestión). Generalmente cada proceso ocurre
por lo menos una vez en cada fase del proyecto [Charvat, 2003], [Phillips, 2004] y
[PMBOK, 2004].
1. Alcance (iniciación, planificación y definición; verificación - control de cambios).
Involucra los procesos necesarios para asegurar que el proyecto incluye todo el
trabajo requerido, y sólo el trabajo requerido para completar el proyecto
exitosamente.
2. Tiempo (definición -secuenciamiento- desarrollo cronograma- estimación duración de
actividades; control del cronograma). Involucra los procesos requeridos para
asegurar el oportuno término del proyecto.
3. Costos (planificación recursos- estimación- asignación del presupuesto; control de
costos). Involucra los procesos requeridos para asegurar que el proyecto es
completado dentro del presupuesto aprobado.
4. Calidad (planificación, aseguramiento, seguimiento y control). Involucra los procesos
requeridos para asegurar que el proyecto cumpla los objetivos para los cuales fue
emprendido.
5. Recursos humanos (planificación organización y asignación personal; desarrollo del
equipo). Involucra los procesos que organizan y dirigen el equipo del proyecto.
6. Comunicaciones (planificación, distribución de información, informes de realización,
cierre administrativo). Involucra los procesos relacionados con la generación,
recolección, distribución, almacenamiento y disposición final de la información del
proyecto, en tiempo y forma.
7. Riesgos (planificación de la gestión (identificación, análisis cualitativo y cuantitativo,
plan de respuesta; supervisión y control). Involucra los procesos relacionados con la
gestión de riesgos del proyecto.
8. Adquisiciones (planificación-petición ofertas, -selección proveedores- administración
del contrato; conclusión del contrato). Involucra los procesos requeridos para comprar
o adquirir bienes, servicios o resultados, así como para contratar procesos de
dirección.
9. Integración (Desarrollo, ejecución del plan, control integrado de cambios). Involucra
los procesos requeridos para asegurar que los distintos elementos del proyecto estén
adecuadamente coordinados.
17
2.1.3 Framework para la gestión de proyectos
Dentro de cada proceso, las herramientas y las técnicas, tales como juicio experto,
dirigen e influyen las salidas de un proceso. Una salida deficiente influenciará
probablemente todos los procesos hacia atrás negativamente. Los procesos de un
proyecto se pueden modificar para cumplir con los requisitos particulares y para resolver
las necesidades y las demandas del proyecto. Algunos procesos podrían no ser
considerados para mejorar las condiciones de integración y los requisitos de un proyecto
dado. A veces, un proceso se puede quitar de un proyecto. Un proceso que no se
termina no significa necesariamente que no era necesario [PMBOK, 2004] y [Phillips,
2004].
Process Groups Knowledge Areas PM Processes
Initiating
Planning
Executing
Controlling
Closing
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Procurement Management
Project Communications Management
Project Risk Management
Project Human Resource Management
Plan Development
Plan Execution
Change Control
Quality Planning
Quality Assurance
Quality Control
Organization Planning
Staff Acquisition
Team Development
Time
Figura 1-7 Framework para la gestión de proyectos
2.1.4 Elementos críticos en la gestión de proyectos
La metodología de PMBOK describe un conjunto de prácticas generalmente aceptadas
por los expertos y que utilizan para la gestión de todo tipo de proyectos, incluyendo el
desarrollo de software y el despliegue de proyectos [PMBOK, 2004]. Esta metodología
define un proyecto como “Un esfuerzo temporal emprendido para crear un único
producto o servicio”. Y la gestión de proyecto como “La aplicación de conocimientos,
habilidades, herramientas y técnicas a las actividades de un proyecto para responder a
sus requerimientos”. En forma resumida se puede decir que el PMBOK se estructura en
grupos lógicos de gestión de proyectos, donde una dimensión describe “Áreas de
conocimiento” mientras que en la otra se describen los 39 procesos de gestión de
18
proyectos organizados en cincos “grupos de procesos”. Una de las características de
esta metodología es que en ella cada área de conocimiento describe conocimientos y
prácticas de gestión de proyectos en término de uno o más procesos, a su vez, cada
proceso se describe en términos de entradas, salidas, herramientas y técnicas. Las
entradas y salidas son documentos y las herramientas y técnicas son mecanismos
aplicados a las entradas para crear salidas. PMBOK no prescribe un ciclo de vida
específico para los proyectos, sólo señala que el ciclo de vida de un proyecto se puede
dividir en fases, de acuerdo a su alcance y dominio de aplicación.
Un elemento que complica a las metodologías para la gestión de proyectos diferentes de
PMBOK es que ellas se orientan a un sólo proyecto, sin tomar en cuenta que muchos
otros proyectos de la organización compiten por los mismos recursos y atención.
Adicionalmente, de acuerdo al análisis y revisión realizado previamente, estas
metodologías en general son abstractas y de alto nivel, no contienen la suficiente
narrativa, no son funcionales ni se adaptan a las áreas operacionales, ignoran los
estándares de la industria y las buenas prácticas, lucen impresionantes pero les falta
integración con el negocio, utilizan terminologías no estándares, compiten por recursos
similares sin orientarse al problema, no tienen métricas de rendimiento y son difíciles de
completar debido a la burocracia y administración. Una metodología adecuada para la
gestión de proyectos debe proveer a los administradores de proyectos de la organización
de una perspectiva del framework para la gestión de proyectos y las metodologías
presentes en la misma.
La implantación exitosa de una metodología de gestión de proyecto es en sí un proyecto
y la parte más difícil es hacerla parte de la cultura organizacional, ya que no basta con
que toda la organización comience a utilizar una nueva metodología simplemente
pegando las planificaciones a un muro y esperando los resultados. La implantación de
una metodología puede tomar meses. Muchos ciclos de vida de los proyectos requieren:
Automatización y flujos de trabajo, facilidades de uso, apropiada metodología de
documentación, y la aceptación de toda la organización.
Uno de los pasos más importantes para una exitosa a implantación de una metodología
para la gestión de proyectos es la planificación y las siguientes preguntas pueden
permitir orientar una buena implantación en la etapa de la planificación:
¿Conseguiremos agregar valor con esta metodología?
¿Cómo construimos las competencias del proyecto?
¿Los procesos de gestión de proyecto y las prácticas son los apropiados?
¿Hemos elegido la metodología correcta?
¿Es lo bastante flexible para cualquier tamaño del proyecto?
¿Como la organización aprende y mejora continuamente desde la metodología?
19
¿Podremos medir los beneficios del proyecto? ¿Cómo los sabemos?
¿Obtenemos una productividad óptima durante el ciclo de vida?
Los expertos en gestión de proyectos sugieren tener una cierta modestia antes de poner
en marcha la metodología y ellos se preguntan ¿Quién puede hablar autoritariamente en
todos los asuntos que conciernen a la implantación de la metodología de proyecto?.
Respecto al punto anterior, ellos argumentan que el ciclo de vida del proyecto distingue
a un proyecto de un no-proyecto y que para comprender las disciplinas genéricas de
gestión de proyectos, los administradores de proyectos y los ejecutivos deben tratar con
todos los asuntos que afectan a las etapas de ciclo de vida en todo tipo de proyectos.
Por lo tanto ello será un reto que requiere de análisis y entendimiento y mantener una
visión conceptual coherente de las disciplinas que a este nivel es difícil.
La utilización de un framework para la gestión de proyecto permite que la gestión de
proyectos opere y fluctúe de organización en organización donde un proyecto siga la
cultura y practicas esperadas de la organización y opere para entregan soporte a la
organización y sus propósitos. Asimismo, un proyecto debería seguir una secuencia
lógica de fases hasta completarse. Las fases son diferentes de proyecto a proyecto ya
que el trabajo del proyecto se diferenciará de uno al siguiente. El proyecto se debería
segmentar en fases para tener secciones más pequeñas, manejables y proporcionar
entregables para apoyar las operaciones continuas.
Al conjunto de fases del proyecto (como un todo) se le denomina el ciclo de vida del
proyecto y este define el comienzo, medio y termino de un proyecto. En las fases
iniciales, un proyecto tiene más riesgos e incertidumbres, es más susceptible a cambios,
fallas e influencias de los stakeholder. Estos stakeholders son individuos, negocios o
comunidades que tienen un interés en el logro del proyecto. Típicamente, están
involucrados en el proceso del proyecto y sus expectativas conducen los requerimientos
del proyecto. Es esencial explorar los stakeholder tempranamente en el ciclo de vida del
proyecto para eliminar la necesidad de cambios cuando el stakeholder se incluya más
tarde en el proyecto. Los costos y demandas de recursos alcanzan son mínimos al inicio
y alcanzan su peak al final del trabajo del proyecto, para luego disminuir.
Un elemento fundamental que aparece en la gestión de proyectos es la estructura
organizacional, la que influye directamente a lo largo del proyecto ya que determina los
procedimientos que debe seguir el administrador de proyectos y el nivel de autoridad
(poder) que posee. Similarmente, un administrador de proyectos debe considerar las
influencias sociales, económicas y ambientales y debe tener orientación externa de estas
áreas (estándares y regulaciones). Los estándares son pautas que generalmente se
siguen pero no son impuestas. Las regulaciones son leyes y demandas de la industria,
que son impuestas por los gobiernos.
20
2.2 Gestión de Proyectos de Software
Muchas organizaciones desean estandarizar sus prácticas de ingeniería de software
[Luckey, 2006] y [Booch et al, 1998] al igual que sus prácticas en gestión de proyectos
[Phillips, 2004]. El Rational Unified Process o RUP [RationalUnifiedProcess, 2007],
presenta un enfoque prescriptivo para la estandarización de las mejores prácticas de la
ingeniería de software, y el Project Management Institute (PMI) Guide to the Project
Management Body of Knowledge [PMBOK, 2004] ofrece un enfoque descriptivo para
estandarizar las mejores prácticas en la gestión de proyectos en una organización.
Esencialmente RUP se enfoca en las mejores prácticas de la gestión de proyectos en el
contexto del desarrollo del software y del despliegue de proyectos; mientras que las
mejores prácticas del PMBOK son genéricas y aplicables para la gestión de proyectos en
cualquier domino de aplicación – desde el desarrollo de un proyecto de data mining
hasta la implementación de nuevos procesos de negocios en una organización. Así,
desde la perspectiva de un dominio de aplicación, la disciplina de gestión de proyectos
del RUP es una instancia especifica de las mejores prácticas de la gestión de proyectos
del PMBOK’s, [ePMbook, 2007].
Figura 1-8 Rational Unified Process
Las mejores prácticas en la gestión de proyectos del RUP identificadas en
[Charbonneau, 2004] son aquellas presentadas en la disciplina Project Management
(PM) del RUP (ver Figura 1-8); otras mejores prácticas más o menos relacionadas al PM
se describen en las otras disciplinas de RUP (tales como en el modelamiento del
21
negocio, análisis y diseño de requerimientos, implementación, pruebas, despliegue,
ambiente y administración de configuración y cambios).
2.2.1 Descripción de RUP
RUP es un proceso de ingeniería de software, que describe quién hace qué, cuándo y
cómo en el desarrollo de software y el despliegue del proyecto [Rational Unified Process,
2007]. Este proceso tiene la característica de ser conducido por los casos de uso, se
centrada en la arquitectura, se conduce por los riesgos [Ravindranath, 2007], y es
iterativo.
En el desarrollo de un proyecto guiado mediante RUP [Ambler et al., 2005], los
requerimientos funcionales están expresados en forma de casos de uso, los que
conducen al desarrollo de una arquitectura ejecutable de aplicaciones. Por lo tanto, el
proceso focaliza los esfuerzos del equipo en la construcción de los comportamientos más
importantes y los elementos estructurales de las aplicaciones (es decir, lo elementos de
la arquitectura), antes de construir los elementos menos importantes. La disminución de
los elementos de riesgos importantes conduce a una definición temprana del ámbito y de
las primeras iteraciones de su ciclo de vida. Por último, RUP realiza particiones del ciclo
de vida del desarrollo de software en iteraciones que producen versiones incrementales
ejecutables del software.
RUP implementa las siguientes mejores prácticas de ingeniería de software [Kroll, 2003]
y [RationalUnifiedProcess, 2007]:
1. Desarrollo iterativo
2. Gestión de requerimientos
3. Uso de arquitecturas componentes
4. Modelamiento visual
5. Calidad continuamente verificable
6. Gestión de cambio
2.2.2 Dimensiones y disciplinas de RUP
RUP implementa las mejores prácticas, presentadas anteriormente, en un proceso de bi-
dimensional. Una dimensión describe “Disciplinas” mientras que la otra dimensión
describe “Fases” dentro del ciclo de vida de los procesos (ver Figura 1-8).
Las disciplinas RUP representan roles individuales, para los miembros o subgrupos
dentro de equipo de desarrollo. Las disciplinas son: Modelamiento del negocio,
requerimientos, análisis y diseño, implementación, pruebas, despliegue, gestión de
proyecto, ámbito, gestión de la configuración y cambios [RationalUnifiedProcess, 2007].
22
PlaneamientoInicial
PlaneamientoRequerimientos
Análisis y Diseño
Implementación
Prueba
Distribución
Evaluación
AdministraciónDel Ambiente
Software Engineering Process
Organized by
Discipline
Concepts
Activity WorkGuideline
Role
ToolMentor
in out
Artifact
ArtifactGuideline
Checkpoints Template Report
De
scri
be
d b
y
Workflow Details
Workflow
Figura 1-9 Roles, actividades y artefactos
La Figura 1-9, grafica los roles, artefactos y actividades y además otros elementos
complementarios de RUP [RationalUnifiedProcess, 2007].
Dentro de RUP, cada disciplina se expresa en término de roles (quien desarrolla la
tarea), actividades (como ellos desarrollan las tareas) y artefactos (que actividades se
realizará). Un rol define el comportamiento y las responsabilidades de un individuo o un
grupo de individuos, responsables de las actividades y los artefactos. Una actividad es
una tarea de la cual un rol es responsable y se puede solicitar su desarrollo. Estas
también describen los pasos requeridos para crear o actualizar uno o muchos artefactos.
Un artefacto es una entrada y/o salida a una actividad [Ambler et al., 2005]. Otros
elementos complementarios a los tres primordiales son aquellos, tales como conceptos,
guías de trabajo, gestores de herramienta, reportes, guías de artefactos, plantillas y
puntos de control.
23
2.2.3 Ciclo de vida de RUP
El ciclo de vida de RUP es iterativo, y las dimensiones de su ciclo de vida se dividen en
cuatro fases: Concepción, Elaboración, Construcción y Transición.
Cada fase tiene una clara definición de un conjunto de objetivos y términos con hitos
principales. Los hitos al final de cada fase son:
1. Objetivo del ciclo de vida en el final de la Concepción.
2. Arquitectura del ciclo de vida en el final de la Elaboración.
3. Capacidad operacional inicial en el final de la Construcción.
4. Lanzamiento del producto en el final de la Transición.
El objetivo de la Concepción es definir el alcance del proyecto; El de la Elaboración es
construir una arquitectura ejecutable para la aplicación. El de la Construcción es dar
forma a lo que será sostenido por estructura de la arquitectura completando la mayoría
de las capacidades y características de la aplicación. Y finalmente, el objetivo de la
Transición es entregar la aplicación a los usuarios finales. A su vez, cada fase de RUP
se divide en iteraciones, cada una de las cuales finaliza con un hito menor.
2.2.4 Disciplina de gestión de proyectos de RUP
De las disciplinas del RUP señaladas anteriormente, son de mayor interés aquellas
relacionadas a las disciplinas de Project Management (PM).
RUP define su disciplina de gestión de proyecto de software como el arte de balancear
los objetivos contrapuestos, la gestión del riesgo, y la superación de apremios y
restricciones para la entrega exitosa de un producto que cumpla las necesidades de los
clientes (que son aquellos que han solicitado el desarrollo del software) y de los usuarios
del software.
La disciplina de gestión de proyecto de RUP provee: Un marco para la gestión de
proyectos orientados al desarrollo de software; guías prácticas para la planificación,
dirección de personal, ejecución, monitoreo y supervisión de proyectos; además, provee
un marco para la gestión de riesgos. Esta disciplina está enfocada principalmente en los
aspectos más importantes de un proceso de desarrollo iterativo: gestionar los riesgos;
planificar un proyecto iterativo, en todo su ciclo de vida y para cada una de las
iteraciones en particular; supervisar el progreso de un proyecto iterativo, y sus métricas.
2.2.5 Elementos críticos en la gestión de proyectos de software
La gestión de proyectos de software ha utilizado en los últimos años el framework RUP
que es una metodología de proyectos adaptable utilizada por las organizaciones para el
desarrollo de software. Los procesos derivados pueden ser muy livianos y hasta muy
24
complejos para grandes proyectos. Esta metodología promete aumentar la productividad
del equipo y proveer las mejores prácticas de desarrollo de software para el equipo del
proyecto, mediante un conjunto de componentes (pautas, plantillas y las mejores
prácticas de miles de proyectos de desarrollo) para el desarrollo de proyectos rápidos y
entregables de calidad. El framework lo componen 4 fases, 8 iteraciones (mínimas), 9
flujos de trabajo, 57 actividades, 270 actividades detalladas (aproximadamente), 114
artefactos y 38 roles (hasta 38 personas).
Una de las características relevantes de RUP es que provee una terminología común
para el equipo de proyecto.
WorkflowProject
ManagementEnvironment
ConfigurationAnd ChangeManagement
BusinessModeling
RequirementsAnalysis
and DesignImplementation Test Deployment
1. Conceive new project2. Evaluate project scope
and risk3. Develop software4. development plan5. Monitor and control6. project7. Plan for next iteration8. Manage iteration9. Close out phase10.Close out project
1. Prepare environment for project
2. Prepare environment for an iteration
3. Prepare guidelines for an iteration
4. Support environment during an iteration
1. Plan project configuration and change control
2. Create a project configuration management environment
3. Change and deliver configuration items
4. Manage baselines and releases
5. Monitor and report configuration status
6. Manage change requests
1. Assess business status2. Describe current business3. Identify business
processes4. Refine business process
definitions5. Design business process
realizations6. Refine roles and
responsibilities7. Explore process
automation8. Develop a domain
modeling
1. Analyze the problem2. Understand stakeholder
needs3. Define the system4. Manage the scope of the
system5. Refine the system
definition6. Manage changing
requirements
1. Define a candidate architecture
2. Refine the architecture3. Analyze behavior4. Design components5. Design real time
components6. Design the database7. Perform architectural
synthesis
1. Structure the implementation model
2. Plan the integration3. Implement components4. Integrate each subsystem5. Integrate the system
1. Plan test2. Design test3. Implement test4. Execute tests in
integration test stage5. Execute tests in system
test stage6. Evaluate test
1. Plan deployment2. Develop support material3. Manage acceptance tests4. Produce deployment unit5. Package product6. Provide access to
download site7. Beta test product
Activity(57)
Artifact(117)
1. Test plan2. Software architecture
document3. Iteration assessment4. Business case5. Software development
plan6. Iteration plan7. Problem resolution plan8. Risk management plan9. Product acceptance plan10.Measurement plan11.Work order12.Status assessment13.Project measurements14.Review record15.Requirements Attributes16.Vision17.Risk list18.Change requests
1. Development case2. Development organization
assessment3. Project specific templates4. Manual style guide5. Use case modeling
guidelines6. Requirements
management plan7. Business modeling
guidelines8. User interface guidelines9. Test guidelines10.Design guidelines11.Programming guidelines12.Tools13.Tool support assessment14.Tool guidelines15.Support environment
1. Project measurements2. Deployment unit3. Configuration audit
findings4. Configuration
management plan5. Project repository6. Change request7. Workspace (integration)8. Work order (completed)9. Workspace (development)
1. Support specifications2. Business glossary3. Business rules4. Business use case model5. Business object model6. Target organization
assessment7. Business vision8. Business architecture
document9. Supplementary business
specification10.Business use case11.Business use case
realization12.Organization unit13.Business entity14.Business worker15.Business modeling
guidelines16.Review record17.Analysis model
1. Software architecture document
2. Requirements management plan
3. Stakeholder requests4. Glossary5. Vision6. Use case model7. Supplementary
specifications8. Use case9. Software requirements
specification10.User interface prototype11.Use case storyboard
1. Component2. Reference architecture3. Software architecture
document4. Use case realization5. Analysis model6. Design model7. Design subsystem8. Design package9. Design class10.Interface11.Capsule12.Protocol13.Data model14.Deployment model15.Integration build plan16.Test component
1. Integration build plan2. Component3. Implementation
subsystem4. Software architecture
document5. Integration build plan6. Test component
1. Change requests2. Test plan3. Test model4. Test case5. Test procedure6. Test script7. Test class8. Test packages9. Test component10.Test subsystem11.Test results12.Test evaluation summary13.Workload analysis
document
1. Installation component2. End-user artifacts3. Support material4. Deployment plan5. Release notes6. Bill of materials7. Training material8. Test results9. Change request10.Development
infrastructure11.Deployment unit12.Product
Worker(38)
1. Project manager 1. Process engineer2. Technical writer3. System analyst4. Business process analyst5. User interface designer6. Test designer7. Architect8. Tool specialist9. System administrator
1. Configuration manager2. System integrator3. Change control manager4. Project member
1. Business process analyst2. Business designer3. Stakeholders4. Business reviewer
1. System analyst2. Use case specifier3. User interface designer
1. Architect2. Designer3. Database designer4. Capsule designer
1. Architect2. System integrator3. Code reviewer4. Implementer
1. Test designer2. Designer3. Implementer4. Tester
1. Implementer2. Technical writer3. Deployment manager4. Graphic artist5. Course developer
Rational Unified Process (RUP) Software Life Cycle
Figura 1-10 Ciclo de vida de RUP
RUP define la gestión de proyectos de software como el arte de balancear los objetivos,
administrar riesgos y superar restricciones para entregar un producto que cumpla con las
necesidades de los clientes y usuarios
Sin embargo están fuera del alcance de RUP los siguientes temas de gestión de
proyectos:
Administración de RRHH (Contrataciones, capacitación, entrenamiento)
Administración de presupuestos (definición, destinos y otros)
Administración de Contratos (con proveedores y clientes)
Para una correcta utilización de RUP, primero se debe determinar los requerimientos del
entorno de gestión de proyectos de la organización, y luego decidir los cambios posibles
de realizar.
25
2.3 Gestión de Proyectos de Data Mining
2.3.1 Metodología CRISP-DM
La metodología de Data Mining CRISP-DM que está definida en términos de un modelo
jerárquico de procesos, consiste de un conjunto de tareas descritas en 4 niveles de
abstracción (desde lo general a los especifico): Fases, Tareas Genéricas, Tareas
Especializadas e Instancias de procesos (ver ¡Error! No se encuentra el origen de la
referencia.)
Figura 1-11 Metodología Data Mining CRISP-DM
En el nivel superior, el proceso de Data Mining se organiza en cuatro fases, cada una de
ellas comprende varias tareas genéricas de segundo nivel. Este segundo nivel es
llamado genérico porque pretende ser lo más amplio posible de manera que cubra una
vasta gama de situaciones de Data Mining. A su vez las tareas deben ser lo más
completas y estables posible. Completa significa que cubre el proceso entero de Data
Mining y todas las posibles aplicaciones de Data Mining. Estable significa que el modelo
debe ser válido aun para desarrollos inesperados como nuevas técnicas de
modelamiento.
El tercer nivel comprende las tareas especializadas, se describen como las acciones de
las tareas genéricas se deben efectuar en situaciones específicas. Por ejemplo, en el
segundo nivel puede haber una tarea llamada limpiar datos, en cambio en el tercer nivel
se describe como esta tarea se lleva a cabo en diferentes situaciones, tales como limpiar
valores numéricos versus limpiar valores categóricos o si el tipo de problema es
clustering o modelamiento predictivo.
26
La descripción de fases y tareas como pasos discretos efectuados en orden específico
representa una secuencia idealizada de eventos. En la práctica, muchas de las tareas
pueden llevarse a cabo en distinto orden y a menudo será necesario volver atrás
repetidamente a las tareas previas (backtracking) y repetir ciertas acciones. Este modelo
de proceso no intenta capturar todas las posibles rutas a través del proceso de Data
Mining, porque esto requeriría un modelo de procesos demasiado complejo.
El cuarto nivel, la instancia de los procesos, es un registro de acciones, decisiones y
resultados del contrato actual de Data Mining. Una instancia de proceso es organizada
de acuerdo a las tareas definidas en los niveles superiores, pero grafica que está
ocurriendo realmente en un compromiso en particular, más que lo que pasa en general.
En el modelo de referencia y guía de usuario, considerado en a metodología CRISP-DM
distingue entre el modelo de referencia y la guía de usuario. El modelo de referencia
presenta una visión general de las fases, tareas y sus salidas y describe que hacer en un
proyecto de data mining. Por el contrario la guía de usuario es más detallada, y da
consejos para cada fase y cada tarea dentro de una fase y además explicita como hacer
un proyecto de Data Mining.
Este documento cubre, para el modelo de referencia y la guía de usuario, hasta el nivel
genérico.
2.3.2 Mapeo desde el modelo genérico al especializado
El contexto de Data Mining conduce a un mapeo entre el nivel genérico y el
especializado en CRISP-DM. Actualmente, se distinguen cuatro diferentes dimensiones
de contextos de data mining:
El dominio de la aplicación es el área específica de cómo toma lugar un
proyecto de data mining.
El tipo de problema de data mining describe las clases especificas de objetivos
que el proyecto debe tratar.
Los aspectos técnicos cubren temas específicos en data mining que describen
diferentes desafíos (técnicos) que usualmente ocurren durante data mining.
Las dimensión de las herramientas y técnicas, especifica que herramientas de
data mining y/o técnicas serán aplicadas durante el proyecto.
Mapeo con contexto
Se distinguen dos tipos de mapeos entre los niveles genéricos y especializados en
CRISP-DM:
Mapeo para el presente
27
Si sólo se aplica el modelo genérico de proceso para realizar un único proyecto de data
mining y se intenta mapear las tareas genéricas y sus descripciones como lo requiere el
proyecto; se trata entonces de un solo mapeo para un probable un uso único.
Mapeo para el futuro
Si sistemáticamente se especializa el modelo genérico de proceso de acuerdo a un
contexto pre-definido (o sistemáticamente se analiza y consolida experiencias de un
proyecto para especializar un modelo de procesos que se podría utilizar a futuro en
contextos comparables) se esta tratando explícitamente de escribir un proceso
especializado en términos de CRISP-DM.
Cual sea el tipo de mapeo más apropiado para sus propósitos, dependerá de su contexto
de data mining y las necesidades de la Organización.
¿Cómo mapear?
La estrategia básica para mapear el modelo de proceso genérico a nivel especializado es
el mismo para ambos tipos de mapeo y comprende:
Analizar su contexto específico.
Remover cualquier dato no aplicable en su contexto.
Agregar cualquier detalle específico a su contexto.
Especializar (o instanciar) contextos genéricos de acuerdo a las características
concretas de su contexto.
Posiblemente redefinir los contenidos genéricos para entregar significados más
explícitos en su contexto por el bien de la claridad.
2.3.3 Modelo de referencia CRISP-DM
El modelo de proceso actual para data mining entrega una visión general del ciclo de
vida de un proyecto de data mining. Contiene las fases de un proyecto, sus tareas
respectivas y relaciones entre estas.
En este nivel de descripción, no es posible identificar todas las relaciones que pueden
existir entre las tareas de data mining, dado que dependen de las metas, el background y
los intereses de los usuarios y en especial de los datos.
28
Figura 1-12 Fases de un proceso de Data Mining
El ciclo de vida de un proyecto de data mining comporta 6 fases. La Figura 1-12
muestra que las fases de un proceso de data mining no son secuenciales, dado que se
requiere una movilidad de avance y retroceso entre las diferentes fases. Depende de los
resultados de cada fase, la definición de que fase o que tarea en particular de cada fase
se realizará a continuación. Las flechas indican las dependencias más importantes y
frecuentes entre las fases.
El circulo externo en la figura, simboliza la naturaleza cíclica de data mining. Data mining
no es sólo una simple solución lineal. Las lecciones aprendidas durante el proceso y la
solución pueden gatillar nuevas preguntas enfocadas al negocio. Subsecuentemente, el
proceso de data mining traerá beneficios provenientes de experiencias de otros
proyectos.
En las siguientes líneas se describe cada fase brevemente:
Business understanding
Esta fase inicial se enfoca en el entendimiento del los objetivos del proyecto y los
requerimientos, desde una perspectiva de negocio, luego se convierte este conocimiento
en una definición de problema de data mining y un plan preliminar diseñado para
alcanzar estos objetivos.
29
Data understanding
La fase de data understanding comienza con una recolección inicial de los datos y
continúa con actividades de familiarización de los mismos, a fin de: identificar los
problemas de calidad de los datos; revelar los primeros “descubrimientos” en los datos o
detectar subconjuntos interesantes; y formar hipótesis de posible información oculta.
Data preparation
La fase de data preparation cubre todas las actividades de construcción del conjunto final
de datos (datos que se utilizarán en la herramienta de modelamiento) a partir de los
datos originales. Las tareas de data preparation pueden realizarse muchas veces y no en
un orden prescrito. Las tareas incluyen selección de tablas, registros y atributos; junto
con transformación y limpieza de datos para las herramientas de modelamiento.
Modeling
En esta fase, varias herramientas de modelamiento son seleccionadas y aplicadas, y sus
parámetros se ajustan para valores óptimos. Típicamente, hay muchas técnicas para el
mismo tipo de problema de data Mining, algunas de ellas tienen requerimientos
específicos en la forma de los datos; por eso, a veces es necesario volver a la fase de
data preparation.
Evaluation
En esta etapa del proyecto se ha construido un modelo (o modelos) de aparente alta
calidad desde la perspectiva del análisis de los datos. Antes de comenzar el deployment
final del modelo, es importante evaluar y revisar los pasos ejecutaros para construir el
modelo que busca alcanzar los objetivos del negocio. Un objetivo clave es determinar si
hay temas de negocio importantes que no han sido considerados. Al final de esta fase,
se tomará una decisión de cómo emplear los resultados de data mining.
Deployment
Generalmente la creación del modelo no es el fin del proyecto, aunque el propósito del
modelo es incrementar el conocimiento de los datos, el conocimiento ganado se debe
organizar y presentar de una forma que el cliente pueda usarlo. A veces involucra la
aplicación de modelos “vivos”, dentro los procesos de toma de decisiones de la
organización, por ejemplo, una personalización en tiempo real de un sitio Web. Sin
embargo, dependiendo de los requerimientos, la fase de deployment puede ser tan
simple como la generación de un reporte o tan compleja como la implementación de un
proceso de data mining repetible en la empresa. En muchos casos, es el cliente, no el
analista de datos, quien lleva a cabo los pasos de deployment. Sin embargo, aunque el
analista no lleve a cabo el deployement, es importante que el cliente entienda que
acciones debe ejecutar para hacer uso de los modelos creados.
En la tabla siguiente se presenta el resumen de las tareas genéricas y salidas del modelo
de referencia CRISP-DM.
30
Business
Understanding
Data
Understanding
Data
PreparationModelling Evaluation Deployment
Determine Business
Objectives
Background Business
objectives
Business success
criteria
Assess Situation
Inventory of resources
Requirements,
assumptions &
constraints
Risks & contingencies
Terminology
Costs & benef its
Determine Data
Mining
Goals
Data Mining goals
Data Mining success
criteria
Produce Project Plan
Project Plan
Initial assignment of
tools &
techniques
Collect Initial Data
Initial data collection
report
Describe Data
Data description report
Explore Data
Data exploration report
Verify Data Quality
Data quality report
Data set
Data set description
Select Data
Rationale for inclusion/
exclusion
Clean Data
Data cleansing report
Construct Data
Derived attributes
Generated records
Integrate Data
Merged data
Format data
Reformatted data
Select Modelling
Techniques
Modelling technique
Modelling assumptions
Generate Text Design
Text design
Build Model
Parameter settings
Models
Model description
Assess Model
Model assessment
Revised parameter
settings
Evaluate Results
Assessment of Data
Mining
results w.r.t. Business
Success Criteria
Approved models
Review Process
Review of process
Determine Next Steps
List of possible actions
Decision
Plan Deployment
Deployment plan
Plan Monitoring and
Maintenance
Monitoring &
maintenance
plan
Produce Final Report
Final report
Final presentation
Review Project
Experience
documentation
Tabla 1-2 Tareas genéricas y salidas del modelo de referencia CRISP-DM
3 Conclusiones
3.1.1 En relación a la gestión de proyectos de data mining
La gestión de proyectos es un área de creciente interés para los académicos y
profesionales del área tecnológica, sin embargo aun existen muchas dificultades para
lograr una gestión exitosa de proyectos [Schwalbe, 2007]. En este sentido es innegable
el aporte a la sistematización de la disciplina de gestión de proyectos de la metodologías
PMBOK [PMBOK, 2004] la que se ha constituido en el marco de referencia y estándar
para la gestión integral de proyectos.
Data Mining es un proceso creativo que requiere de un número significativo de diferentes
habilidades y conocimientos. Aunque actualmente se asocia la metodología CRISP-DM
con la gestión de proyectos de Data Mining, esta presenta problemas para gestionar
integralmente los proyectos. Por lo anterior, es posible decir que no hay un framework
estándar para desarrollar este tipo de proyectos, que el éxito o fracaso de un proyecto
depende altamente de la persona que lo lleva a cabo, y que su práctica exitosa no
necesariamente es repetible en la organización. Es posible decir también que un proceso
de Data Mining exitoso requiere una metodología y una efectiva gestión del proyecto, y
que esto va a depender de la mezcla apropiada de herramientas y analistas expertos.
El reto para este trabajo es proponer un framework unificado para la gestión de
proyectos de data mining, cuyo proceso sea altamente creativo e iterativo, y que posea
múltiples actividades paralelas. Lo anterior se fundamenta en las fallas que se han
31
producido en la gestión de proyectos de Data Mining al utilizar la metodología CRISP-
DM. Algunas de estas fallas son:
A veces los “expertos en Data Mining” obvian las fases de planificación y
documentación (porque consumen mucho tiempo).
Se presentan fallas de comunicación entre los miembros del equipo debido a que
se basan en falsos supuestos para realizar el trabajo o porque re-hacen algo que
estaba hecho.
Existen dificultades para trabajar con el modelo genérico propuesto por CRISP-
DM. Las fases no son estrictamente secuenciales.
Con CRISP-DM no resulta fácil evaluar la personas, los plazos y costos del
proyecto
Sin embargo, un punto a favor de CRISP es el modelo estructurado de documentación
(entregables) que propone y que resulta fácil escribir modelos de procesos
especializados basados en checklist genéricos.
El reto en el trabajo futuro está en proponer una framework unificado para la gestión de
proyectos de Data Mining cuyo proceso es altamente creativo, iterativo y que posee
muchas actividades paralelas.
.
3.1.2 Análisis de metodologías hacia la gestión de proyectos de data mining
Las metodologías analizadas en este trabajo presentan características diversas en su
planificación, organización, dirección, ejecución, control y seguimiento. Asimismo, sus
ámbitos de aplicación parecen ser diversos. A continuación se caracterizan y comparan
las metodologías principales analizadas en este estudio y se presentan los principales
resultados y conclusiones.
Problem resolution and fault-finding technique
La identificación de un problema en la gestión de proyectos de data mining requiere
conocer las causas que lo originaron y a partir de ello es posible, entonces encontrar
una solución. Si este análisis se realiza considerando los problemas que la literatura
tradicionalmente asocia a los proyectos de data mining es posible identificar posibles
soluciones. El cuadro siguiente (ver Figura 1-13) muestra como a partir de un conjunto
de problemas mencionados los investigadores de gestión de proyectos surgen
interesantes patrones que facilitan la identificación de soluciones.
32
Problems Identified Caused by Solved by
Requirements not included
Not a quality product
Product does not work
Too much maintenance
Difficult to use
Performance is poor
No user documentation
Client won’t accept product
Over schedule
Ineffective user requirements
Poor testing
Poor change control
Waterfall approach (i.e. lengthy)
Poor communications
No user involvement
Scope creep
No documentation developed
Training
Change control process
Test plan
User guides & documentation
Iterative methodology
Service level agreements
Figura 1-13 Resolución de problemas y la técnica de fault-finding
El cuadro de la Tabla 1-3 identifica los elementos fundamentales para realizar una
comparación de las tres principales metodologías para la gestión de proyectos
estudiadas en esta investigación y clasifica las características de cada metodología para
cada elemento.
ELEMENTOS PMBOK RUP CRISP-DM
Tipo de Proyecto Cualquier tipo de proyecto Proyectos de desarrollo de software proyectos de Data Mining
Project Lifecycle Dividido en fases. Tipicamente en 4 o 5, a
veces más de 9. El termino de cada fase
esta dado por uno o más entregables.
Dividido en 4 fases. Cada una de ellas
dividida en una o más iteraciones, que
incluyen actividades de todas las disciplinas
en distinta intensidad. Cada iteracion
produce una versión ejecutable del software,
aplicación o sistema.
Divido en 6 fases no secuenciales, se
requiere que se pueda mover entre las
diferentes fases. Dependiendo de las
resultados de cada fase, se define que
fase o que tarea en particular de cada fase
se realizará después.
End of Phase Hito (Milestone) Hito mayor Se puede pasar de una fase a otra, no hay
hitos de termino de fase.
End of Phase Artifact Entregable Artefacto Salida(Output)
Activity El proceso se describe en terminos de
entredas, salidas, herramientas y tecnicas.
Las actividades se describe en terminos de
artefactos de entrada, artifactos resultantes
y pasos con mentores de herramietnas y
pautas.
Tareas genericas que deben ser
instanciadas a un proyecto en particular.
Para cada tarea se definen las salidas
(output) y las actividades a realizar.
Input Artifact Entrada Artefacto de entrada -
Output Artifact Salida Artefacto resultante Salida(Output)
End of Phase Review Salida de la fase, Stage Gates o Kill Point Revisión de los hitos del ciclo de vida No existe un termino (hito) definitivo para
cada fase, ya que es posible devolverse y
volver a ejecutar una fase.
Structural Activity Grouping Area del Conocimiento Disciplina Fase
Temporal Activity Grouping Grupo de Procesos Workflow Secuencia entre fases.
Tabla 1-3 Mapeo de PMBOK, RUP, CRISP-DM
La Tabla 1-4, lista las areas de conocimiento del pmbok en comparación con las
disciplinas de RUP y las fases de Crisp-dm.
33
PMBOK Knowledge Area RUP Disciplines CRISP-DM Fases
Project Integration Management Project Management
Requirements
Deployment
Configuration & Change Management
Business Understanding
Evaluation
Deployment
Project Scope Management Project Management
Requirements
Configuration & Change Management
Business Understanding
Project Time Management Project Management Business Understanding
Project Time Management Project Management Business Understanding
Project Quality Management Project Management
Configuration & Change Management
Business Understanding
Data Understanding
Data Preparation
Modeling
Evaluation
Project Human Resource Management Project Management Business Understanding
Project Communications Management Project Management Business Understanding
Evaluation
Project Risk Management Project Management Business Understanding
Project Procurement Management Requirements Business Understanding
Tabla 1-4 Mapeo de procesos, disciplinas y fases
3.1.3 Tendencias en la gestión de proyectos de data mining
Un Proyecto de Data Mining debe dirigir las actividades, tanto de gestión como técnicas,
involucradas en el proceso de transformación de necesidades de conocimiento en
patrones de Data Mining, para que el conocimiento aporte valor al proceso operacional o
estratégico que lo requiera.
Cabe destacar, que el valor del conocimiento depende en cada momento de la misión del
área de negocio al que pertenece el proceso dentro de la organización. Por lo tanto, se
puede señalar que las actividades principales de un Proyecto de Data Mining involucran:
1. Descubrir los objetivos primordiales del área de negocio en la que se enmarca el
proyecto.
2. Establecer las actividades y las necesidades de conocimiento de esa área en un
particular momento del tiempo. Estos criterios nos permitirán evaluar los
resultados obtenidos y en todo caso marcan el fin del proyecto.
3. Transformar las necesidades de conocimiento, en conocimiento a través de un
proceso de descubrimiento del mismo. Las tareas técnicas involucradas en
este proceso vienen descritas por Crisp-dm.
4. Identificar los factores de éxito del Proyecto de Data Mining: requiere
establecimiento de metas y de requisitos. Evaluar si las metas requieren de un
proceso de gestión, que a lo largo del proyecto evalúe la factibilidad de
34
conseguir los resultados esperados. Esas actividades tienen que ser
definidas, y son: validación, verificación entre otras.
5. Establecer secuencialidad en las tareas: definir el ciclo de vida para el proyecto
que dependerá de las características del mismo en cada momento en
particular.
El presente documento corresponde al trabajo tutelado cuyo objetivo es ir a desarrollo de
una propuesta de tesis doctoral que denominaremos: Un framework unificado para la
gestión de proyectos de data mining.
35
4 Referencias
[Ravindranath, 2007] C. Ravindranath Pandian, Appliend Software Risk Management: A
guide for Software Project Manager, Auerbach, 2007.
[Luckey, 2006] Teresa Luckey,PMP,MBA, and Joseph Phillips,PMP, Software Project
Management for Dummies, Wiley Publishing, Inc., 2006.
[Guía PMBOK, 2004] Project Management Institute, Inc., Guía de los Fundamentos de la
Dirección de Proyectos, Tercera Edición, Project Management Institute Inc., 2004
[Phillips, 2004] Joseph Phillips, PMP Project Management Professional Study Guide,
McGraw-Hill, 2004.
[PMBOK, 2004] Project Management Institute, Inc., A Guide to the Project Management
Body of Knowledge (PMBOK® Guide) - Third Edition. Project Management Institute, Inc.,
2004.
[Charvat, 2003] Jason Charvat, Project Management Methodologies: Selecting,
Implementing, and Supporting Methodologies and Processes for Projects, John Wiley &
Sons, Inc., 2003.
[Wysocki, 2003] Robert K. Wysocki and Rudd McGary, Effective Project Management,
Third Edition, John Wiley & Sons, Inc., 2003.
[Charvat, 2002] Jason Charvat, Project Management Nation: Tools, Techniques, and
Goals for the New and Practicing IT Project Manager, John Wiley & Sons, Inc., 2002.
[Jalote, 2002] Pankaj Jalote, Software Project Management in Practice, Pearson
Education, Inc., 2002.
[Competency PMBOK, 2001] Project Management Institute Inc., Project Manager
Competency Development Framework Exposure Draft, Project Management Institute,
Inc., 2001.
[WBS PMBOK, 2001] Project Management Institute Inc., Practice Standard for Work
Breakdown Structures, Project Management Institute, Inc., 2001.
[Hughes, 1999] Bob Hughes and Mike Cotterell, Software Project Management, Second
Edition, McGraw-Hill, 1999.
[Royce, 1998] Walker Royce, Software Project Management: A unified Framework,
Addison-Wesley, 1998.
36
[PMBOK® Guide, 2004] Project Management Institute, Inc (2004): A Guide to the Project
Management Body of Knowledge (PMBOK® Guide) - Third Edition. Four Campus
Boulevard, Newtown Square, Pennsylvania USA, 2004 edition.
[Russell, 2004] Russell D. Archibald, Project Management State of the Art - 2004, Fellow
PMI and APM/IPMA, MSc, PMP PMB 90A, 521 Logan Ave., Laredo, TX 78040-6633
[Wysocki, 2003] Robert K. Wysocki, Ph.D. with contributions by Rudd McGary, Ph.D.,
PMP: “Effective Project Management Traditional, Adaptive, Extreme”. Third Edition,
Published by Wiley Publishing, Inc., Indianapolis, Indiana, 2003.
[Chapman, 2000] Pete Chapman, Julian Cliton, Randy Kerber, Thomas Khabaza,
Thomas Reinartz, Colin Shearer and Rüdiger Wirth: “CRISP-DM: Step-by-Step”. , 2000.
[Charvat, 2002] Janson Charvat: “Project Management Nation: Tools, Techniques and
Goals for the New and Practicing IT Project Manager”, John Wiley & Sons, Inc. 2002.
[Kappelman, 2006] Leon A Kappelman; Robert McKeeman; Lixuan Zhang: EARLY
WARNING SIGNS OF IT PROJECT FAILURE: THE DOMINANT DOZEN. Information
Systems Management; Fall 2006; 23, 4; ABI/INFORM Global pg. 31
[McGilvray, 2007] Danette McGilvray; Data Quality and the Project Life Cycle; Granite
Falls Consulting, Inc., Published: July 10, 2007, www.gfalls.com.
[Wasilewska et al., 2007] Wasilewska, Menasalvas, E, Scharff, A model PM fro
preprocessing and data Mining Proper Process. In Transacción on Rouge Sets VI, pp
397-399, Springer-verlag Berlin Heidelberg
[Fayyad et al., 1996] Fayyad, Piatetsky-Shapiro, Smyth, From Data Mining to Knowledge
Discovery: An Overview, Advances in Knowledge Discovery and Data Mining, Fayyad,
Piatetsky-Shapiro, Smyth, Uthurusamy, editors, AAAI Press / The MIT Press,Menlo Park,
CA, 1996, pp.1-34.
[Piatetsky-Shapiro, 2007] Gregory Piatetsky-Shapiro, 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.
[Ingebretsen, 2003] Ingebretsen, M. (2003) Mining for Gold, Using data resources to meet
key corporates objetives and Launch, PM Network, pp. 29 -34
[KDnuggets, 2007] Portal www.gartner.com [en línea] disponible en:
http://www.gartner.com/ [Consulta: 20 de agosto de 2007].
[Louie, 2003] Jen Que Louie, President of Nautilus Systems, Inc. (www.nautilus-
systems.com), testimony before the U.S. House of Representatives Subcommittee on
37
Technology, Information Policy, Intergovernmental Relations, and Census, Congressional
Testimony, March 25, 2003.
[Larose, 2005] Daniel T. Larose, Discovering Knowledge In Data: An Introduction to Data
Mining, John Wiley & Sons, Director of Data Mining, Central Connecticut State University,
2005.
[Gartner, 2007] Portal www.kdnuggets.com/ [en línea] disponible en:
http://www.kdnuggets.com/ [Consulta: 10 de agosto de 2007].
[Brachman, 1996] Brachman, R. & Anand, T. (1996) The process of knowledge discovery
in databases: a human-centered approach, in: U. Fayyad, et al. (Eds.), Advances in
Knowledge Discovery and Data Mining, AAAI Press, Menlo Park, 1996, pp. 36–57.
[Becker, 2005] Becker K. & Ghedini, C., A documentation infrastructure for the
management of data mining projects, Information and Software Technology 47 , pp. 95–
111, 2005
[Kelley, 2003] Kelley Ch, Adelman, S., Where can I find sources about failed data mining
projects and the reason for their failure?, DM Review Online Published in April 2003.
DMReview.com
[Pyle, 2004] Pyle, D. This Way Failure Lies, DB2 Magazine, Vol 1, issue1. 2004
[Richardson, 2006] Richardson G. & Butler, C., Readings in Information Technology
Project Management, Thomson Learning, United States, pp. 40-41, 2006
[Standish Group’s, 2004] Standish Group’s The Chaos Report 2004, Extreme CHAOS,
summary online at http://www.standishgroup.com/, retrieved 30 agosto 2007.
[Charbonneau, 2004] Serge Charbonneau, Software Project Management - A Mapping
between RUP and the PMBOK, Xelaration Software Corporation, IBM Corporation 2004
[ePMbook, 2007] Portal www.epmbook.com [en línea] disponible en:
http://www.epmbook.com/, Simon Wallace, 1999 – 2007 [Consulta: 30 de agosto de
2007].
[RationalUnifiedProcess, 2007] Portal www.ts.mah.se, [en línea] disponible en:
http://www.ts.mah.se/RUP/RationalUnifiedProcess/, [Consulta: 30 de agosto de 2007].
[Ambler et al., 2005] Scott W. Ambler, John Nalbone and Michael J. Vizdos, The
Enterprise Unified Process: Extending the Rational Unified Process, Prentice Hall PTR,
2005.
[Kroll, 2003] Per Kroll and Philippe Kruchten, Rational Unified Process Made Easy: A
Practitioner's Guide to the RUP, Addison Wesley, 2003.
38
[Booch et al, 1998] Grady Booch, Robert C, Martin and James Newkirk , ''Object Oriented
Analysis and Design with Applications'', 2d. ed., Addison Wesley Longman, Inc., 1998.
[Markov, 2007] Zdravko Markov and Daniel T. Larose, Data Mining The Web: Uncovering
Patterns in Web Content, Structure, and Usage, John Wiley & Sons, Inc., 2007.
[Myatt, 2007] Glenn J. Myatt, Making Sense of Data: A Practical Guide to Exploratory
Data Analysis and Data Mining, John Wiley & Sons, Inc., 2007.
[Larose, 2006] Daniel T. Larose, Data Mining Methods and Models, John Wiley & Sons,
Inc., 2006.
[Larose, 2005] Daniel T. Larose, Discovering Knowledge in Data An Introduction to Data
Mining, John Wiley & Sons, Inc., 2005.
[Berry, 2004] Michael J.A. Berry, Gordon S. Linoff, Data Mining Techniques: For
Marketing, Sales, and Customer Relationship Management, Second Edition, Wiley
Publishing, Inc., Indianapolis, Indiana, 2004.
[Kudyba, 2004] Stephan Kudyba Ph.D., Managing Data Mining: Advice from Experts,
CyberTech Publishing, 2004.
[Wang, 2003] John Wang, Data Mining: Opportunities and Challenges, Idea Group Inc.,
2003.
[Parr, 2001] Olivia Parr Rud, Data Mining Cookbook: Modeling Data for Marketing, Risk,
and Customer Relationship Management, John Wiley & Sons, Inc., 2001.
[Schwalbe, 2007] Kathy Schwalbe, Project Management, Information Technology, Fifth
Edition, Thomson Course Technolgy, 2007.