RETOS EN LA GESTIÓN DE PROYECTOS DE DATA MINING

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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

INGENIERÍA DE SOFTWARE Rational Unified Process RUP

INGENIERÍA DE SOFTWARE Rational Unified Process RUP 1 INGENIERÍA DE SOFTWARE Rational Unified Process RUP Rubby Casallas Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Referencias 2 http://www.rational.com/ http://www-306.ibm.com/software/awdtools/rup/

Más detalles

Introducción a Rational Unified Process (RUP)

Introducción a Rational Unified Process (RUP) Qué es un Proceso de Desarrollo de SW? Introducción a Patricio Letelier letelier@dsic.upv.es Departamento Sistemas Informáticos y Computación (DSIC) (UPV) - España Define Quién debe hacer Qué, Cuándo y

Más detalles

Integración del PMBOK al RUP para proyectos de Desarrollo de Software

Integración del PMBOK al RUP para proyectos de Desarrollo de Software Integración del PMBOK al RUP para proyectos de Desarrollo de Software Fernando Torres UPG-FISI, Universidad Nacional Mayor de San Marcos (UNMSM), Av. German Amezaga s/n, Ciudad Universitaria, Lima, Perú

Más detalles

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras Recibido: 06 de agosto de 2009 Aceptado: 21 de octubre de 2009 SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI MSc. Mauricio Rojas Contreras

Más detalles

RESUMEN de la GESTIÓN de PROYECTOS

RESUMEN de la GESTIÓN de PROYECTOS RESUMEN de la GESTIÓN de PROYECTOS Basado en la Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK ) Contenidos Introducción...2 PMI...2 Objetivos...2 PMBOK...2 Proyecto...3 Concepto...3

Más detalles

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Introducción al Unified Process Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Unified Process - UP Un framework de Proceso de Desarrollo de Software, una de cuyas versiones es el más documentado

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Diplomado de. Administración. de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI

Diplomado de. Administración. de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI Diplomado de Administración de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI Módulo 1. Conceptos básicos de la Administración de Proyectos Conceptos básicos

Más detalles

Dennis Garcia - PMP Ingeniero Electrónico de la universidad Javeriana, Magister Negocios TI del Korean Advanced Institute of Science and Technology.

Dennis Garcia - PMP Ingeniero Electrónico de la universidad Javeriana, Magister Negocios TI del Korean Advanced Institute of Science and Technology. Dennis Garcia - PMP Ingeniero Electrónico de la universidad Javeriana, Magister Negocios TI del Korean Advanced Institute of Science and Technology. Mas de 10 años de experiencia en formulación de proyectos

Más detalles

Grupo de procesos de Planificación

Grupo de procesos de Planificación Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Quinta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje

Más detalles

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA

Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Implementación de Procesos Business Process Management BPM Services Oriented Architecture SOA Título Área específica de la publicación 2 Implementación de Procesos Business Process Management BPM Services

Más detalles

Mejorando las debilidades de RUP para la gestión de proyectos

Mejorando las debilidades de RUP para la gestión de proyectos RISI 7(2), 2010 (49-56) Revista de Investigación de Sistemas e Informática Facultad de Ingeniería de Sistemas e Informática Universidad Nacional Mayor de San Marcos ISSN 1815-0268 (versión impresa) ISSN

Más detalles

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA INGENIERÍA INFORMÁTICA

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA INGENIERÍA INFORMÁTICA PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA INGENIERÍA INFORMÁTICA Grupo de Investigación y Desarrollo en Ingeniería de Software Estructura de Desagregación del Trabajo Versión

Más detalles

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE Recibido: 23 de febrero de 2011 Aceptado: 29 de marzo de 2011 SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE MSc. Ailin Orjuela, MSc. Luis Alberto Esteban, MSc.

Más detalles

Gerenciamiento de Proyectos. Estándar PMI. Cambio Organizacional UDELAR

Gerenciamiento de Proyectos. Estándar PMI. Cambio Organizacional UDELAR Gerenciamiento de Proyectos Estándar PMI Cambio Organizacional UDELAR Agenda Concepto de Proyecto Qué es la dirección de proyectos? PMI y Guía del PMBOK Dirección de Proyectos Áreas de Conocimiento 2 Definición

Más detalles

Portales Oracle WebCenter

Portales Oracle WebCenter Portales Oracle WebCenter El perfil del cliente y el marco en el que las empresas desarrollan sus actividades están cambiando rápidamente. Hoy la mayoría de las compañías se mueve en mercados altamente

Más detalles

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

MSF. Microsoft Solutions Framework

MSF. Microsoft Solutions Framework MSF Microsoft Solutions Framework Breve Historia Desarrollado como resultado de los procesos en Microsoft: Mejores prácticas de la Industria. 25 años del grupo desarrollo + MS Consulting. Primera versión

Más detalles

IBM Software Development Platform

IBM Software Development Platform IBM Group IBM Development Platform Seminario. antonio.alonso@es.ibm.com IBM Group software Agenda 1. Introducir plataforma de desarrollo de IBM. 2. DEMO: Construcción de aplicaciones J2EE con RAD. 3. Café

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Syllabus. 1. Descripción del curso Tu curso está integrado con la siguiente información: Clave y nombre del programa o curso:

Syllabus. 1. Descripción del curso Tu curso está integrado con la siguiente información: Clave y nombre del programa o curso: 1. Descripción del curso Tu curso está integrado con la siguiente información: Área Responsable: Clave y nombre del programa o curso: Modalidad: Dirección de proyectos SPMP05 Seminario de Administración

Más detalles

Global Business Services. Claves para la implantación de un Sistema de Gestión Documental: demostración práctica.

Global Business Services. Claves para la implantación de un Sistema de Gestión Documental: demostración práctica. Claves para la implantación de un Sistema de Gestión Documental: demostración práctica. Claves para la implantación de un Sistema de Gestión Documental: demostración práctica. Los cuatro pilares básicosb

Más detalles

Grupos de procesos y áreas de conocimiento

Grupos de procesos y áreas de conocimiento Grupos de procesos y áreas de conocimiento 1 Índice Inicio... 3 - Introducción - Objetivo - Contenido - Antecedentes Tema 1. Grupos de procesos y áreas de conocimiento... 6 - Introducción - Objetivo -

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

Más detalles

Visual Studio Team System

Visual Studio Team System Visual Studio Team System MSF for CMMi Process Improvement Aurelio Porras Development Tools Advisor aureliop@microsoft.com Microsoft Ibérica El éxito es raro Fallidos Problemáticos Existosos 2004 15% 51%

Más detalles

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos Capítulo 2 Ideas generales de CMMI-SW 2.1 Introducción El Capability Maturity Model Integration (en adelante CMMI), se compone de un conjunto de modelos, métodos de evaluación y cursos de formación para

Más detalles

Administración del Tiempo en el Desarrollo de un Sistema de Información

Administración del Tiempo en el Desarrollo de un Sistema de Información Administración del Tiempo en el Desarrollo de un Sistema de Información José Jimmy Camacho Martínez (1) Ramón David Chávez Cevallos (2) Ing. Lennin Freire (3) Facultad de Ingeniería en Electricidad y Computación

Más detalles

Diplomado en Administración de Proyectos

Diplomado en Administración de Proyectos Diplomado en Administración de Proyectos HP221 Grupos de procesos y áreas de conocimiento 1 Bienvenida Bienvenido al curso Grupos de procesos y áreas de conocimiento! El PMBOK Guide -Project Management

Más detalles

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO - 1 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Setiembre 2004 TABLA DE CONTENIDO 1 INTRODUCCIÓN...1 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP...2 2.1 WORKFLOWS ESENCIALES DEL RUP...2

Más detalles

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría Gestión del Portfolio de Proyectos HP Portfolio & Project Información de Producto 2010 Dirección de Consultoría 2 1. Introducción Actualmente las organizaciones necesitan hacer frente a la complejidad

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

Diplomado en Administración de Proyectos

Diplomado en Administración de Proyectos Diplomado en Administración de Proyectos HP222 Administración de la integración 1 Bienvenido al curso Administración de la Integración! La Administración de la Integración describe el trabajo de alto nivel

Más detalles

2. Administración de Proyectos en el contexto de TI

2. Administración de Proyectos en el contexto de TI 2. Administración de Proyectos en el contexto de TI 2.1 Los proyectos no pueden estar aislados Los proyectos deben operar en un ambiente organizacional amplio Los Project managers necesitan tener una visión

Más detalles

Comparativa ISO 21500 y PMBOK Versión 5

Comparativa ISO 21500 y PMBOK Versión 5 Comparativa ISO 21500 y PMBOK Versión 5 Luis Fernando Cruz Caicedo, MBA, PMP Universidad de San Buenaventura Cali PMI Capitulo Madrid España Nombre Proyecto Guía Conferencista de Implantación ISO 21500

Más detalles

Ges3ón de Proyectos So9ware

Ges3ón de Proyectos So9ware Ges3ón de Proyectos So9ware Tema 2.1 Integración Carlos Blanco Bueno Félix Óscar García Rubio Este tema se publica bajo Licencia: Crea5ve Commons BY- NC- ND 4.0 Objetivos Ampliar los conocimientos básicos

Más detalles

Examinando los procesos de la Dirección de proyectos

Examinando los procesos de la Dirección de proyectos IX Congreso de Ingeniería de Organización Gijón 8 y 9 Septiembre de 2005 Examinando los procesos de la Dirección de proyectos Marinka Varas Parra ( 1 ) ( 1 )Depto. Ingeniería Industrial. Facultad de Ingeniería.Avda

Más detalles

El documento consiste en un resumen de los tres primeros capítulos de cada uno de los siguientes estándares:

El documento consiste en un resumen de los tres primeros capítulos de cada uno de los siguientes estándares: RESUMEN (Borrador) DE LOS CAPÍTULOS 1, 2 Y 3 DE LOS DOCUMENTOS Estándar de la Gestión de Programas Estándar de la Gestión de Portafolios Modelo de Madurez Organizacional en Gestión de Proyectos- OPM3 Nota

Más detalles

13. Project Integration Management

13. Project Integration Management 13. Project Integration Management 13.1 Un pieza importante para el exito de un proyecto: " Excelente Project Integration Management" Project managers deben coordinar todas las áreas de conocimiento durante

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

IBM Rational for Power i. The business-driven development lifecycle

IBM Rational for Power i. The business-driven development lifecycle IBM Rational for Power i The business-driven development lifecycle Agenda Business Driven Development Rational Development Lifecycle DEMO 2 The business-driven development lifecycle Prioritize Plan Manage

Más detalles

Definición de PMO Características de una PMO

Definición de PMO Características de una PMO Definición de PMO Existen varios conceptos de una oficina de proyectos (PMO) una de ella la define como una unidad organizacional, física o virtual, especialmente diseñada para dirigir y controlar el desarrollo

Más detalles

Clase 1: Introducción a la Dirección y Gestión de Proyectos Clase 2: PMBOK (Project Management Body of Knowledge) Clase 3: Gestión de la Integración

Clase 1: Introducción a la Dirección y Gestión de Proyectos Clase 2: PMBOK (Project Management Body of Knowledge) Clase 3: Gestión de la Integración Project Management Objetivos - Adquirir los conocimientos y herramientas fundamentales aplicables al gerenciamiento de proyectos de acuerdo a la metodología de Project Management, contenidas en el Project

Más detalles

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Agenda Contexto Ciclos de vida: Modelo

Más detalles

Diplomado en Administración de Proyectos Administración del alcance y del tiempo

Diplomado en Administración de Proyectos Administración del alcance y del tiempo Diplomado en Administración de Proyectos Administración del alcance y del tiempo Conceptos básicos de la Administración de Proyectos Los materiales están basados en Project Management Institute, A Guide

Más detalles

Proyectos exitosos y excelencia en Proyectos: Sinónimos? Midiendo resultados. Por: Yaravi Cardoze IT, MBA, PMP, ITIL

Proyectos exitosos y excelencia en Proyectos: Sinónimos? Midiendo resultados. Por: Yaravi Cardoze IT, MBA, PMP, ITIL Proyectos exitosos y excelencia en Proyectos: Sinónimos? Midiendo resultados Por: Yaravi Cardoze IT, MBA, PMP, ITIL Introducción Dirigido a: PMs y profesionales de nivel básico, intermedio o en cargos

Más detalles

Preparación al Examen PMP - Introducción al PMBOK

Preparación al Examen PMP - Introducción al PMBOK La Guía del PMBOK ó Guía de los Fundamentos de la Dirección de Proyectos constituye un compendio de conocimientos de la profesión de dirección de proyectos. Al igual que en otras profesiones, como la abogacía,

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción 1.1. Propósito de la Guía BABOK El propósito principal de la Guía BABOK Guide es definir la profesión del Análisis de Negocio y proveer un conjunto de prácticas comúnmente aceptadas.

Más detalles

ITIL V3 Por dónde empezar?

ITIL V3 Por dónde empezar? ITIL V3 Por dónde empezar? Autor: Norberto Figuerola Introducción La gestión de servicios de TI (ITSM) suministra los servicios que necesita una empresa para cumplir sus objetivos de negocio. ITSM respalda

Más detalles

Planificación TI con Rational Focal Point

Planificación TI con Rational Focal Point IBM Software Group Planificación TI con Rational Focal Point Plataforma para la gestión del portfolio de proyectos y aplicaciones Luis Reyes Technical Solution Architect luis.reyes@es.ibm.com Innovation

Más detalles

HP205 Fundamentos de la administración de proyectos

HP205 Fundamentos de la administración de proyectos Diplomado en Administración de Proyectos HP205 Fundamentos de la administración de proyectos 1 Bienvenido al curso! Fundamentos de administración de proyectos Actualmente las organizaciones han reconocido

Más detalles

Cobit 4.1 y su relación con otros frameworks

Cobit 4.1 y su relación con otros frameworks Cobit 4.1 y su relación con otros frameworks Pablo Caneo G. CISA, CGEIT, ITIL, COBIT Presidente Isaca Capítulo Santiago de Chile Sobre el Presentador Pablo Caneo es Ingeniero Informático y Contador Auditor,

Más detalles

PROPUESTA PARA LA IMPLEMENTACIÓN DE UNA OFICINA DE ADMINISTRACIÓN DE PROYECTOS

PROPUESTA PARA LA IMPLEMENTACIÓN DE UNA OFICINA DE ADMINISTRACIÓN DE PROYECTOS PROPUESTA PARA LA IMPLEMENTACIÓN DE UNA OFICINA DE ADMINISTRACIÓN DE PROYECTOS PMO (Parte 1 de 2) Sergio Salimbeni Mayo, 2014 CONTENIDO 1. Abstract... 4 2. Planteamiento del problema... 5 3. Justificación...

Más detalles

IT Project Portfolio Management y su vinculación con la Estrategia Corporativa

IT Project Portfolio Management y su vinculación con la Estrategia Corporativa IT Project Portfolio Management y su vinculación con la Estrategia Corporativa Norberto Figuerola Mayo 2014 IT Management Los CIO deben gestionar eficazmente la entrega de los servicios de TI para lograr

Más detalles

Fundamentos de la administración de proyectos

Fundamentos de la administración de proyectos Fundamentos de la administración de proyectos Body of Knowledge, (PMBOK Guide) Fifth Edition, Project Management Institute, Inc., 2013. 1 Índice Inicio... 3 - Introducción - Objetivo - Contenido - Antecedentes

Más detalles

Introducción a la Gerencia de Proyectos. Resumen. Introducción.

Introducción a la Gerencia de Proyectos. Resumen. Introducción. Introducción a la Gerencia de Proyectos Edwin Monzón C. Ing. de Planeamiento y Control de Proyectos, Compañía Minera San Martín Resumen A nivel mundial la utilización de estándares en la dirección de proyectos

Más detalles

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez Ing. De Software Ingeniería de Software La Ingeniería de Software es la ciencia

Más detalles

Gerencia de Proyectos Proceso de Software

Gerencia de Proyectos Proceso de Software Gerencia de Proyectos Proceso de Software Victor Manuel Toro C. VictorToro@cincosoft.com CincoSOFT Ltda. Compañía de Ingenieros Constructures de Software Tel. (+57)(1) 6230180 * Fax (+57)(1) 2566774 Carrera

Más detalles

Ingeniería del So:ware II

Ingeniería del So:ware II Ingeniería del So:ware II Tema 04 (1). Integración de Proyectos So:ware Carlos Blanco Bueno DPTO. DE MATEMÁTICAS, ESTADÍSTICA Y COMPUTACIÓN carlos.blanco@unican.es Este tema se publica bajo Licencia: CreaRve

Más detalles

Conceptos Básicos. El Instituto de administración de Proyectos, PMI, define un proyecto como:

Conceptos Básicos. El Instituto de administración de Proyectos, PMI, define un proyecto como: Existen diferentes modelos y metodologías para la administración de proyectos y modelos de calidad para el desarrollo del software. Por lo que mencionaremos los siguientes conceptos importantes. a) Qué

Más detalles

La madurez de los servicios TI. de los servicios. La Gestión n de Servicios de TI (ITSM) Antoni Lluís s Mesquida, Antònia Mas, Esperança Amengual

La madurez de los servicios TI. de los servicios. La Gestión n de Servicios de TI (ITSM) Antoni Lluís s Mesquida, Antònia Mas, Esperança Amengual La madurez de los servicios TI Antoni Lluís s Mesquida, Antònia Mas, Esperança Amengual 4 de Septiembre de 2009 XI Jornadas de Innovación n y Calidad del Software (JICS) 1 La Gestión n de Servicios de

Más detalles

Preparación para la Certificación ITIL V3 Online

Preparación para la Certificación ITIL V3 Online ITIL V3 Preparación para la ITpreneurs líder mundial de soluciones formativas en el Área de IT Service Management & Governance (Gestión y Gobierno de Servicios TI) para ofrecer una amplia gama cursos especializados

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Mejorando los procesos de negocio para asegurar la excelencia operativa. Daniel Vidales / Business Transformation Services Marzo, 2014

Mejorando los procesos de negocio para asegurar la excelencia operativa. Daniel Vidales / Business Transformation Services Marzo, 2014 Mejorando los procesos de negocio para asegurar la excelencia operativa Daniel Vidales / Business Transformation Services Marzo, 2014 Business Transformation Motores de la Transformación de Negocios Qué

Más detalles

Iniciación y Planificación del Proyecto

Iniciación y Planificación del Proyecto Iniciación y Planificación del Proyecto Para cuando dijo que lo quería??? Ingeniería de Software 2 Iniciación y Planificación del Proyecto 1 Agenda Iniciación del Proyecto: Entradas Iniciación del Proyecto:

Más detalles

Syllabus. www.techeraperu.com cursos@techeraperu.com

Syllabus. www.techeraperu.com cursos@techeraperu.com Syllabus www.techeraperu.com cursos@techeraperu.com Este curso está dirigido para los Encargados de Desarrollar los Sistemas de Información y aplicar una Metodología basada en RUP para controlar el Ciclo

Más detalles

La Dirección de Proyectos y las Relaciones Interpersonales en las Instituciones

La Dirección de Proyectos y las Relaciones Interpersonales en las Instituciones La Dirección de Proyectos y las Relaciones Interpersonales en las Instituciones Duración del curso 5 meses Dirección del curso Magister Analía Ruth Rymberg Lic. en Psicopedagogía. Psicoanalista. Lic. en

Más detalles

Ciclos desde su nacimiento hasta su muerte. Nacimiento. Muerte

Ciclos desde su nacimiento hasta su muerte. Nacimiento. Muerte Ciclos de Vida y HCI Interacción Hombre-Máquina 2008-1 El ciclo de vida del Software Tiempo Ciclos desde su nacimiento hasta su muerte Nacimiento Muerte Proceso General Estándar 1074: Conjunto de actividades

Más detalles

El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los

El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los ALEXANDRA PSICA, CMC DIRECTORA GENERAL INTERIS CONSULTING INC. El enfoque ideal para la erm se diseña de forma personalizada para que se adecue a los objetivos de la organización, al nivel de riesgo inherente

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

CMMi. Lic. Virginia Cuomo

CMMi. Lic. Virginia Cuomo CMMi Lic. Virginia Cuomo 1 Agenda Repaso CMMI Introducción Arquitectura Niveles de Madurez Representaciones Representación Discreta Representación Continua Discreta VS Continua 2 Repaso Qué vimos la tercer

Más detalles

Cómo gestionar proyectos en condiciones de riesgo

Cómo gestionar proyectos en condiciones de riesgo 1 de 8 CLAVES PARA EL ÉXITO DE LOS PROYECTOS Cómo gestionar proyectos en condiciones de riesgo Las empresas necesitan desarrollar proyectos que exigen estructuras y tratamientos distintos a los tradicionales.

Más detalles

ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA

ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA ANEXO 4 - REQUERIMIENTOS DE GESTIÓN DE PROYECTOS PMO DE INFORMATICA ETB requiere que el CONTRATISTA cumpla los lineamientos para la Dirección y Gestión de proyectos, éstos últimos definidos a nivel corporativo

Más detalles

Diseño e Implementación de los Procesos de Gestión TI

Diseño e Implementación de los Procesos de Gestión TI Diseño e Implementación de los Procesos de Gestión TI Alumno(s): Año Académico: 2012 Profesor Guía: Contraparte: ALEJANDRO JESUS ARAVENA ORTIZ LORENA ANDREA ALBORNOZ POBLETE DANIEL HORMAZABAL Escuela de

Más detalles

Dennis L. Bolles, PMP DLB Associates, LLC

Dennis L. Bolles, PMP DLB Associates, LLC Dennis L. Bolles, PMP DLB Associates, LLC Agenda Qué es la Gestión de Proyectos de Negocios? Qué es la Gestión de Proyectos de Negocios Corporativos? Qué es: un Marco y un Modelo de PMO? Cómo se Posicionan

Más detalles

RUP: Disciplina de Manejo de Cambios y Configuraciones

RUP: Disciplina de Manejo de Cambios y Configuraciones RUP: Disciplina de Preparado por: Amelia Soriano Mayo 2005 Tomado de: Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Curso Rational Unified Process Rational

Más detalles

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI MODELO Y HERRAMIENTA DE AUTOMATIZACIÓN PARA AGREGAR VALOR A LOS PRINCIPIOS ÁGILES DE DESARROLLO

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular. El proceso software Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software Especificación: Definir la funcionalidad y las restricciones en

Más detalles

Mejora de los procesos de gestión de proyectos a través de la combinación de PMBOK y CMMi

Mejora de los procesos de gestión de proyectos a través de la combinación de PMBOK y CMMi Mejora de los procesos de gestión de proyectos a través de la combinación de PMBOK y CMMi Alejandro Sacomani, Adriana Chalar, Leandro Antonelli, Andrés Lisse Centro de Informática, Fiscalia de Estado,

Más detalles

Definición de principios de arquitectura para arquitectura empresarial de la organización

Definición de principios de arquitectura para arquitectura empresarial de la organización Definición de principios de arquitectura para arquitectura empresarial de la organización 35 Enrique Arroyo E. Arroyo Universidad Iberoamericana, Prolongación Paseo de la Reforma 880, Alvaro Obregon, Lomas

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

GESTIÓN DE PROYECTOS DE SOFTWARE

GESTIÓN DE PROYECTOS DE SOFTWARE GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de

Más detalles

Curso Sistemas de Información Hospitalarios. Principios de COBIT 5 (Control Objectives for Information and related Technology)

Curso Sistemas de Información Hospitalarios. Principios de COBIT 5 (Control Objectives for Information and related Technology) Curso Sistemas de Información Hospitalarios Principios de COBIT 5 (Control Objectives for Information and related Technology) Aplicación a Sistemas de Información Hospitalarios Docente: Ing. Luis Osorio

Más detalles

UNIVERSIDAD NACIONAL DE INGENIERÍA

UNIVERSIDAD NACIONAL DE INGENIERÍA UNIVERSIDAD NACIONAL DE INGENIERÍA FACULTAD DE INGENIERÍA CIVIL EVALUACION DE LAS FASES DE ÉXITO EN EL PROYECTO CONSTRUCCION DEL ALMACEN DE PRODUCTOS TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE: INGENIERO

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Auditando con COBIT una Oficina de Gestión de Proyectos (PMO) basada en PMBOK 5. Lic. Franco N. Rigante, CISA,CRISC,PMP

Auditando con COBIT una Oficina de Gestión de Proyectos (PMO) basada en PMBOK 5. Lic. Franco N. Rigante, CISA,CRISC,PMP Auditando con COBIT una Oficina de Gestión de Proyectos (PMO) basada en PMBOK 5 Lic. Franco N. Rigante, CISA,CRISC,PMP Conferencista Biografía Franco Nelson Rigante, CISA, CRISC licenciado en Sistemas

Más detalles

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de 2. EL MODELO CMMI 2.1 ANTECEDENTES DE CMMI En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de Capacidad de Madurez (CMM). Dicho modelo está orientado a la mejora de los procesos

Más detalles

GRAY WATCH. Jonás Montilva C. Judith Barrios A. Milagro Rivero A. MÉTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES EMPRESARIALES. Versión preliminar

GRAY WATCH. Jonás Montilva C. Judith Barrios A. Milagro Rivero A. MÉTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES EMPRESARIALES. Versión preliminar GRAY WATCH MÉTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES EMPRESARIALES Versión preliminar Proyecto METHODIUS FONACIT 2005000165 Jonás Montilva C. Judith Barrios A. Milagro Rivero A. MÉRIDA, VENEZUELA

Más detalles

I Edición Curso de Dirección y Gestión de Proyectos en Ingeniería en Informática

I Edición Curso de Dirección y Gestión de Proyectos en Ingeniería en Informática I Edición Curso de Dirección y Gestión de Proyectos en Ingeniería en Informática Modalidad presencial y online Junio de 2012 C/ Mayor, 4 6ª planta 28013 Madrid Teléfono: 91.523.86.20 Fax: 91.521.48.25

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de portafolios de acuerdo con el estándar del Project Management Institute 1 Conceptos básicos Qué es un portafolio? Es una colección de proyectos, programas y otras actividades

Más detalles

2ª Convención Nacional de Informática. Para Organismos de Agua Querétaro 2008 1, 2 y 3 de Octubre

2ª Convención Nacional de Informática. Para Organismos de Agua Querétaro 2008 1, 2 y 3 de Octubre 2ª Convención Nacional de Informática Para Organismos de Agua Querétaro 2008 1, 2 y 3 de Octubre 2 Administración n de Servicios de TI 3 Orden del día 1. El Departamento de TI. 2. ITIL. 3. Modelos de certificación.

Más detalles

Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO

Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO Dante Guerrero Piura, 2013 FACULTAD DE INGENIERÍA Área Departamental de Ingeniería Industrial y de Sistemas Capítulo 4. GESTIÓN DE LA INTEGRACIÓN DEL

Más detalles

Técnico Certified Software Engineer Professional (CSIP)

Técnico Certified Software Engineer Professional (CSIP) Técnico Certified Software Engineer Professional (CSIP) Dirigido a: Profesionales de la ingeniería de sistemas Estudiantes universitarios de ingeniería en sistemas Requisitos: Requisitos para aplicar a

Más detalles