RETOS EN LA GESTIÓN DE PROYECTOS DE DATA MINING

Transcripción

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

2 Índice 1 Introducción y Motivación Relevancia de la gestión de proyectos de Data Mining Problemas de la gestión de proyectos de Data Mining Hechos y Casos de Fracasos Objetivos del Trabajo Tutelado Related work Gestión de Proyectos Ciclo de vida del proyecto Áreas de conocimiento para la gestión de proyectos Framework para la gestión de proyectos Elementos críticos en la gestión de proyectos Gestión de Proyectos de Software Descripción de RUP Dimensiones y disciplinas de RUP Ciclo de vida de RUP Disciplina de gestión de proyectos de RUP Elementos críticos en la gestión de proyectos de software Gestión de Proyectos de Data Mining Metodología CRISP-DM Mapeo desde el modelo genérico al especializado Modelo de referencia CRISP-DM Conclusiones En relación a la gestión de proyectos de data mining Análisis de metodologías hacia la gestión de proyectos de data mining Tendencias en la gestión de proyectos de data mining Referencias

3 Índices de Figuras Figura 1-1 Industrias y Campos de Aplicación de Data Mining (basado en 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 Figura 1-4 Detalle esquemático de cada nodo de la matriz Figura 1-5 Dimensiones de Competencias del Project Management Figura 1-6 Ciclos de vida de proyectos de software Figura 1-7 Framework para la gestión de proyectos Figura 1-8 Rational Unified Process Figura 1-9 Roles, actividades y artefactos Figura 1-10 Ciclo de vida de RUP Figura 1-11 Metodología Data Mining CRISP-DM Figura 1-12 Fases de un proceso de Data Mining Figura 1-13 Resolución de problemas y la técnica de fault-finding Indices de Tablas Tabla 1-1 Grupos de procesos y áreas de conocimiento Tabla 1-2 Tareas genéricas y salidas del modelo de referencia CRISP-DM Tabla 1-3 Mapeo de PMBOK, RUP, CRISP-DM Tabla 1-4 Mapeo de procesos, disciplinas y fases

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 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 4

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 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 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, 5

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

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 estándar. las prácticas 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 7

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 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 8

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% (19) 16% (39) 33% (34) 29% (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 9

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

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 11

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]. 12

13 Executing Level of Activity Planning Project Integration Mgmt Project Plan Execution Project Quality Mgmt Quality Assurance Project HR Mgmt Team Development Project Communication Mgmt Information Distribution Initiating Project Procurement Mgmt Solicitation Source Selection Contract Admin Controlling Closing Phase Start Time Phase End 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 Área Procesos del Conocimiento Gestión de la Integración del Proyecto Grupo de Procesos de Iniciación Desarrollar el acta de constitución del Proyecto Desarrollar el enunciado de alcance del proyecto Grupo de Procesos de Planificación Desarrollar el plan de gestión del proyecto Grupo de Procesos de Ejecución Dirigir y Gestionar la Ejecución del Proyecto Grupo de Procesos de Seguimiento y Control Supervisar y controlar el trabajo del proyecto Control Integrado de Cambios Grupo de Procesos de Cierre Cerrar el proyecto Gestión del Alcance del Proyecto Planificar el alcance. Definir el alcance Crear EDT Verificar el alcance Controlar el alcance Gestión del Tiempo del Proyecto 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 Gestión de los Costos del Proyecto Estimar los costos Preparar el presupuesto de los costos Controlar los Costos Gestión de la Calidad del Proyecto Planificar la calidad Realizar un aseguramiento de la calidad Realizar un control de calidad Gestión de los RRHH del Proyecto Gestión de las Comunicaciones del Proyecto 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 Gestión de los Riesgos del Proyecto 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 Gestión de las Adquisiones del Proyecto Planificar las compras y adquisiones Planificar la contratación Solicitar respuestas de vendedores Seleccionar vendedores Administrar el contrato Cierre del contrato Tabla 1-1 Grupos de procesos y áreas de conocimiento 13

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 Ciclo de vida del proyecto Figura 1-5 Dimensiones de Competencias del Project Management 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. 14

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 Cycle Justification Planning Requirements and Analysis Design Development and Testing Deployment Post Production Support Rational Project Process (RUP) Inception Elaboration Construction Transition RUP Modified Inception Elaboration Construction Transition Operational Support Siebel eroadmap Implementation Methodology Define Discover Design Configure Validate Deploy Sustain Accelerated SAP Methodology (ASAP) Project Preparation Business Blueprint Realization Final Preparation Go-Live and Support Oracle Application Integration Methodology (AIM) Definition Operations Analysis Solution Design Build 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. 15

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

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 Time Figura 1-7 Framework para la gestión de proyectos Plan Development Plan Execution Change Control Quality Planning Quality Assurance Quality Control Organization Planning Staff Acquisition Team Development 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 17

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? 18

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

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 20

21 negocio, análisis y diseño de requerimientos, implementación, pruebas, despliegue, ambiente y administración de configuración y cambios) 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 Dimensiones y disciplinas de RUP RUP implementa las mejores prácticas, presentadas anteriormente, en un proceso de bidimensional. 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]. 21

22 Described by Planeamiento Inicial Planeamiento Requerimientos Administración Del Ambiente Análisis y Diseño Implementación Organized by Prueba Evaluación Distribución Software Engineering Process Concepts Discipline Activity Work Guideline Workflow Role in out Artifact Tool Mentor Workflow Details Artifact Guideline Checkpoints Template Report 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. 22

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 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 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 23

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. Rational Unified Process (RUP) Software Life Cycle Workflow Project Management Environment Configuration And Change Management Business Modeling Requirements Analysis and Design Implementation Test Deployment Activity (57) 1. Conceive new project 2. Evaluate project scope and risk 3. Develop software 4. development plan 5. Monitor and control 6. project 7. Plan for next iteration 8. Manage iteration 9. Close out phase 10.Close out project 1. Prepare environment for 1. Plan project configuration 1. Assess business status 1. Analyze the problem 1. Define a candidate project and change control 2. Describe current business 2. Understand stakeholder architecture 2. Prepare environment for 2. Create a project 3. Identify business needs 2. Refine the architecture an iteration configuration processes 3. Define the system 3. Analyze behavior 3. Prepare guidelines for an management environment 4. Refine business process 4. Manage the scope of the 4. Design components iteration 3. Change and deliver definitions system 5. Design real time 4. Support environment configuration items 5. Design business process 5. Refine the system components during an iteration 4. Manage baselines and realizations definition 6. Design the database releases 6. Refine roles and 6. Manage changing 7. Perform architectural 5. Monitor and report responsibilities requirements synthesis configuration status 7. Explore process 6. Manage change requests automation 8. Develop a domain modeling 1. Structure the 1. Plan test 1. Plan deployment implementation model 2. Design test 2. Develop support material 2. Plan the integration 3. Implement test 3. Manage acceptance tests 3. Implement components 4. Execute tests in 4. Produce deployment unit 4. Integrate each subsystem integration test stage 5. Package product 5. Integrate the system 5. Execute tests in system 6. Provide access to test stage download site 6. Evaluate test 7. Beta test product Artifact (117) 1. Test plan 1. Development case 1. Project measurements 1. Support specifications 1. Software architecture 1. Component 2. Software architecture 2. Development organization 2. Deployment unit 2. Business glossary document 2. Reference architecture document assessment 3. Configuration audit 3. Business rules 2. Requirements 3. Software architecture 3. Iteration assessment 3. Project specific templates findings 4. Business use case model management plan document 4. Business case 4. Manual style guide 4. Configuration 5. Business object model 3. Stakeholder requests 4. Use case realization 5. Software development 5. Use case modeling management plan 6. Target organization 4. Glossary 5. Analysis model plan guidelines 5. Project repository assessment 5. Vision 6. Design model 6. Iteration plan 6. Requirements 6. Change request 7. Business vision 6. Use case model 7. Design subsystem 7. Problem resolution plan management plan 7. Workspace (integration) 8. Business architecture 7. Supplementary 8. Design package 8. Risk management plan 7. Business modeling 8. Work order (completed) document specifications 9. Design class 9. Product acceptance plan guidelines 9. Workspace (development) 9. Supplementary business 8. Use case 10.Interface 10.Measurement plan 8. User interface guidelines specification 9. Software requirements 11.Capsule 11.Work order 9. Test guidelines 10.Business use case specification 12.Protocol 12.Status assessment 10.Design guidelines 11.Business use case 10.User interface prototype 13.Data model 13.Project measurements 11.Programming guidelines realization 11.Use case storyboard 14.Deployment model 14.Review record 12.Tools 12.Organization unit 15.Integration build plan 15.Requirements Attributes 13.Tool support assessment 13.Business entity 16.Test component 16.Vision 14.Tool guidelines 14.Business worker 17.Risk list 15.Support environment 15.Business modeling 18.Change requests guidelines 16.Review record 17.Analysis model 1. Integration build plan 2. Component 3. Implementation subsystem 4. Software architecture document 5. Integration build plan 6. Test component 1. Change requests 1. Installation component 2. Test plan 2. End-user artifacts 3. Test model 3. Support material 4. Test case 4. Deployment plan 5. Test procedure 5. Release notes 6. Test script 6. Bill of materials 7. Test class 7. Training material 8. Test packages 8. Test results 9. Test component 9. Change request 10.Test subsystem 10.Development 11.Test results infrastructure 12.Test evaluation summary 11.Deployment unit 13.Workload analysis 12.Product document Worker (38) 1. Project manager 1. Process engineer 1. Configuration manager 1. Business process analyst 1. System analyst 2. Technical writer 2. System integrator 2. Business designer 2. Use case specifier 3. System analyst 3. Change control manager 3. Stakeholders 3. User interface designer 4. Business process analyst 4. Project member 4. Business reviewer 5. User interface designer 6. Test designer 7. Architect 8. Tool specialist 9. System administrator 1. Architect 2. Designer 3. Database designer 4. Capsule designer 1. Architect 2. System integrator 3. Code reviewer 4. Implementer 1. Test designer 2. Designer 3. Implementer 4. Tester 1. Implementer 2. Technical writer 3. Deployment manager 4. Graphic artist 5. Course developer 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. 24

25 2.3 Gestión de Proyectos de Data Mining 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. 25

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 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 26

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

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