Source: http://docplayer.es/1833185-Universidad-catolica-andres-bello-vicerrectorado-academico-estudios-de-postgrado-area-de-ingenieria-postgrado-en-sistemas-de-informacion.html
Timestamp: 2017-07-24 09:39:49+00:00

Document:
UNIVERSIDAD CATÓLICA ANDRÉS BELLO VICERRECTORADO ACADÉMICO ESTUDIOS DE POSTGRADO. ÁREA DE INGENIERÍA Postgrado en Sistemas de Información - PDF
Download "UNIVERSIDAD CATÓLICA ANDRÉS BELLO VICERRECTORADO ACADÉMICO ESTUDIOS DE POSTGRADO. ÁREA DE INGENIERÍA Postgrado en Sistemas de Información"
María Antonia Gallego Ortega
1 UNIVERSIDAD CATÓLICA ANDRÉS BELLO VICERRECTORADO ACADÉMICO ESTUDIOS DE POSTGRADO ÁREA DE INGENIERÍA Postgrado en Sistemas de Información DISEÑO DE UNA METODOLOGÍA DE DESARROLLO DE SOFTWARE BASADA EN LA METODOLOGÍA ÁGIL SCRUM Y LAS MEJORES PRÁCTICAS DE LA GERENCIA DE PROYECTOS Caso de Estudio: Farmahorro presentado por Hung Campos Marco Luis para optar al título de Especialista en Sistemas de Información Asesora María Esther Remedios Caracas, Julio 20112 Señores Universidad Católica Andrés Bello Dirección General de los Estudios de Postgrado Postgrado en Sistemas de Información Caracas, 11 de Julio de 2011 Por la presente me permito comunicar que acepto ser la asesora del Trabajo de Grado del estudiante Hung Campos Marco Luis, C.I , quien opta por el título de Especialista en Sistemas de Información, intitulado: Diseño de una Metodología de Desarrollo de Software basada en la Metodología Ágil SCRUM y las mejores prácticas de la Gerencia de Proyectos. Sin otro particular al cual hacer referencia, se despide cordialmente, María Esther Remedios C.I i3 DEDICATORIA Ante todo a Dios por estar siempre a mi lado acompañándome y guiándome. A Mirelys mi esposa, que con ayuda, apoyo y amor, me motivó a seguir hacia delante y cumplir este reto. El amor lo hace posible, eres mi inspiración y lo logramos!. A mi Familia por ser siempre mi apoyo incondicional, recordándome siempre lo importante del estudio y de culminarlo. Son mi modelo a seguir. A mi suegro Miguel, por ser un ejemplo de superación y ser otro impulsor de este reto. Este logro también es tuyo. A familiares que se encuentran lejos, tíos, primos y abuela. Aunque la distancia nos separe, siempre me han apoyado y gracias por ofrecerme su ayuda. A aquellos que de alguna u otra forma han estado pendiente de mí. A mí mismo: Marco, al fín!. ii4 AGRADECIMIENTO A la profesora María Esther Remedios. Mejor tutora, imposible. Gracias por sus consejos y guía durante la realización del trabajo de grado. iii5 UNIVERSIDAD CATÓLICA ANDRÉS BELLO VICERRECTORADO ACADÉMICO ESTUDIOS DE POSTGRADO ÁREA DE INGENIERÍA Postgrado en Sistemas de Información Diseño de una Metodología de Desarrollo de Software basada en la Metodología Ágil SCRUM y las mejores prácticas de la Gerencia de Proyectos Caso de Estudio: Farmahorro RESUMEN Autor: Marco Luis Hung Campos Asesora: María Esther Remedios Año: 2011 La Gerencia de Desarrollo de la cadena de farmacias Farmahorro, es la responsable de ejecutar los desarrollos de Software implementados en la compañía. Actualmente se carece de una Metodología de Desarrollo bien definida. Esta investigación de grado se enfocará en realizar un levantamiento de información para poder recolectar todos los datos necesarios y definir cuál es la situación actual de la Gerencia en términos de Gestión de Proyectos de Software y de esta manera establecer cuáles son sus requerimientos en cuanto al tema de estudio. Posteriormente se procederá a realizar un análisis en base a la metodología Ágil SCRUM y las mejores prácticas del Project Management Institute, Inc. (PMI), partiendo de una lista de requerimientos, de fortalezas y debilidades de la Gerencia para poder establecer cuáles son las mejores prácticas que se pueden implementar en el desarrollo de Software. Al tener estas mejores prácticas, se realizará el diseño de la metodología a proponer basada en SCRUM y en el PMI adaptada a los requerimientos de la Gerencia. Finalmente se pondrá a prueba esta metodología en un proyecto piloto que nos permitirá documentar luego la experiencia y recomendaciones Palabras clave: Proyectos, Procesos, Planificación, Software, Metodología Ágil, PMI. Línea de Investigación: Ingeniería de Software y Gerencia de Proyectos. iv6 INDICE GENERAL INDICE GENERAL... v INDICE DE FIGURAS... x INDICE DE TABLAS... xiii INTRODUCCIÓN CAPÍTULO I EL PROBLEMA DE INVESTIGACIÓN Planteamiento del problema Formulación del Problema Objetivos de la Investigación Objetivo General Objetivos Específicos Justificación Alcance y Limitaciones Resultados esperados CAPÍTULO II MARCO TEÓRICO Antecedentes de la Investigación Base Teóricas Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) Procesos de la Dirección de Proyectos para un Proyecto Interacciones comunes entre procesos de la dirección de proyectos Grupos de Procesos de la Dirección de Proyectos Grupo del Proceso de Iniciación Grupo del Proceso de Planificación v7 Grupo del Proceso de Ejecución Grupo del Proceso de Seguimiento y Control Grupo del Proceso de Cierre Áreas del Conocimiento Gestión de la Integración de Proyectos Gestión del Alcance del Proyecto Gestión del Tiempo del Proyecto Gestión de la Calidad del Proyecto Gestión de los Recursos Humanos del Proyecto Gestión de las Comunicaciones del Proyecto Gestión de los Riesgos del Proyecto Gestión de Proyectos Predictiva El nuevo escenario en la gestión de Proyectos El Manifiesto Ágil El Ciclo de Desarrollo Ágil El Modelo de SCRUM Prácticas de SCRUM El Diagrama General de SCRUM Los Elementos Los Roles en Scrum Prácticas relativas del PMBOK a las prácticas Ágiles Grupo de Procesos de la Gestión de Proyectos Áreas de Conocimiento y la Gestión Ágil Gestión de Integración Gestión de Alcance y del Tiempo Calidad vi8 Priorización de prácticas Ágiles en un proyecto Corto CAPÍTULO III MARCO ORGANIZACIONAL Historia de Farmahorro Misión Visión Atributos de Farmahorro Bienestar Cercano Aliado Principios CAPÍTULO IV MARCO METODOLÓGICO Tipo de Investigación Técnicas e instrumentos de recolección de datos Población y muestra Operacionalización de objetivos Fases de la Investigación Estructura Desagregada de Trabajo (EDT) CAPÍTULO V PRESENTACIÓN Y ANÁLISIS DE LOS DATOS Estudio de la situación actual Análisis de los procesos actuales Análisis de las fases y herramientas de SCRUM versus los procesos actuales de la gerencia de desarrollo Análisis de los procesos y áreas del conocimiento del PMI versus los procesos actuales de la gerencia de desarrollo vii9 1.5 Resultados de los procesos del PMI y de SCRUM versus los procesos actuales de la gerencia de desarrollo CAPÍTULO VI DESARROLLO DE LA METODOLOGÍA Fases y herramientas de SCRUM a incorporar en la metodología Procesos y Áreas de Conocimiento del PMI a incorporar en la metodología Integración de SCRUM y PMI en la metodología Descripción de la metodología Descripción de las Fases CAPÍTULO VII PROYECTO PILOTO Fase de Visión Fase Planificación Fase de Desarrollo Fase de Adaptación Fase de Planificación Fase de Desarrollo Fase de Adaptación CAPÍTULO VIII EVALUACIÓN DEL PROYECTO Objetivo General Objetivos Específicos CONCLUSIONES RECOMENDACIONES REFERENCIA BIBLIOGRÁFICA ANEXOS ANEXO ANEXO viii10 ANEXO ANEXO ANEXO ANEXO ANEXO ix11 INDICE DE FIGURAS Figura N Pág. 1: PROYECTOS PARA DESARROLLO DE SISTEMAS DE INFORMACIÓN : INTERACCIÓN DE LOS GRUPOS DE PROCESOS EN UNA FASE O PROYECTO : GRUPOS DE PROCESOS DE LA DIRECCIÓN DE PROYECTOS : DESARROLLAR EL ACTA DE CONSTITUCIÓN DEL PROYECTO: ENTRADAS, SALIDAS, HERRAMIENTAS Y TÉCNICAS : DESARROLLAR EL PLAN PARA LA DIRECCIÓN DE PROYECTOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : DIRIGIR Y GESTIONAR LA DIRECCIÓN: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : MONITOREAR Y CONTROLAR EL TRABAJO DEL PROYECTO: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : REALIZAR EL CONTROL INTEGRADO DE CAMBIOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : CERRAR PROYECTO O FASE: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : RECOPILAR REQUISITOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : DEFINIR EL ALCANCE: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : CREAR LA EDT: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : VERIFICAR ALCANCE: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS CONTROLAR EL ALCANCE: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : DEFINIR LAS ACTIVIDADES: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : SECUENCIAR LAS ACTIVIDADES: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : ESTIMAR LOS RECURSOS DE LAS ACTIVIDADES: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : ESTIMAR LA DURACIÓN DE LAS ACTIVIDADES: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : DESARROLLAR EL CRONOGRAMA: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS x12 20: CONTROLAR EL CRONOGRAMA: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : PLANIFICAR LA CALIDAD: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : REALIZAR EL ASEGURAMIENTO DE CALIDAD: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : REALIZAR CONTROL DE CALIDAD: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : DESARROLLAR EL PLAN DE RECURSOS HUMANOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : IDENTIFICAR A LOS INTERESADOS: ENTRADAS, SALIDAS, HERRAMIENTAS Y TÉCNICAS : PLANIFICAR LAS COMUNICACIONES: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : DISTRIBUIR LA INFORMACIÓN: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : GESTIONAR LAS EXPECTATIVAS DE LOS INTERESADOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : INFORMAR EL DESEMPEÑO: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : PLANIFICAR LA GESTIÓN DE RIESGOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : IDENTIFICAR LOS RIESGOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : REALIZAR ANÁLISIS CUALITATIVO DE LOS RIESGOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : REALIZAR ANÁLISIS CUANTITATIVO DE LOS RIESGOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : PLANIFICAR LA RESPUESTA A LOS RIESGOS: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : MONITOREAR Y CONTROLAR EL TRABAJO DEL PROYECTO: ENTRADAS, SALIDAS Y HERRAMIENTAS Y TÉCNICAS : CICLO DE VIDA SECUENCIAL O DE CASCADA : PRODUCCIÓN CON FASES SECUENCIALES O SOLAPADAS : MANIFIESTO ÁGIL : CICLO DE DESARROLLO ÁGIL xi13 40: DIAGRAMA DE SCRUM : LAS REUNIONES HABITUALES EN SCRUM : FICHA SINÓPTICA DE SCRUM : GRUPO DE PROCESOS DEL PMBOK REFERENCIADOS CON EL MARCO DE TRABAJO DE LA GESTIÓN ÁGIL DE JIM HIGHSMITH : CASCADA VERSUS ÁGIL: EL CAMBIO DE PARADIGMA : RELEASE PLAN : PLAN DE ITERACIÓN PARCIAL : PRIORIZACIÓN DE PRÁCTICAS ÁGILES : DIVISIÓN DEL GRUPO MISTRAL : FASES DEL PRESENTE TRABAJO DE INVESTIGACIÓN : EDT DEL DESARROLLO DEL TEG : CASO DE USO DE LOS PROCESOS DE INICIO Y PLANIFICACIÓN DE LA GERENCIA DE DESARROLLO : CASO DE USO DE LOS PROCESOS DE EJECUCIÓN, CONTROL Y CIERRE DE LA GERENCIA DE DESARROLLO : METODOLOGÍA DE DESARROLLO CON SCRUM, PMI Y PRÁCTICAS ACTUALES xii14 Tabla N INDICE DE TABLAS Pág. 1: Correspondencia entre grupos de procesos y áreas de conocimiento de la dirección de proyectos : Operacionalización de los Objetivos, Dimensión y Visualización : Tabla de Fortaleza, Oportunidad y Debilidad de los procesos actuales de la gerencia : Tabla de Proceso de Inicio de Scrum Vs. Procesos actuales de la gerencia : Tabla de Proceso de Planificación de Scrum Vs. Procesos actuales de la gerencia : Tabla de Proceso de Exploración de Scrum Vs. Procesos actuales de la gerencia : Tabla de Proceso de Control de Scrum Vs. Procesos actuales de la gerencia : Tabla de Proceso de Cierre de Scrum Vs. Procesos actuales de la gerencia.122 9: Tabla de Proceso de Iniciación del PMI Vs. Procesos actuales de la gerencia : Tabla de Proceso de Planificación del PMI Vs. Procesos actuales de la gerencia : Tabla de Proceso de Ejecución del PMI Vs. Procesos actuales de la gerencia : Tabla de Proceso de Seguimiento y Control del PMI Vs. Procesos actuales de la gerencia : Tabla de Proceso de Exploración y Especulación de Scrum que no son utilizados en la gerencia : Tabla de Procesos de Planificación, Ejecución, Seguimiento y Control del PMI que no se utilizan en la gerencia xiii15 INTRODUCCIÓN Hoy en día existe una diversidad de metodología de desarrollo de software en el mercado pero las estadísticas acerca del éxito de los Proyectos de Software apuntan a que independientemente de tener a disposición estas mejores prácticas, aún el fracaso es alto. Ya el hecho de que existan muchas metodologías nos conlleva a pensar que no es una tarea fácil gestionar un proyecto de Software y más aún en un mercado muy cambiante, desafiante e impredecible. La Gerencia de Desarrollo de Farmahorro no cuenta con una metodología bien definida para el desarrollo de Software y esto puede traer diversas consecuencias negativas, tomando en cuenta que Farmahorro actualmente está en un proceso de crecimiento muy acelerado y la necesidad de disponer de programas informáticos que los apoyen en sus actividades diarias, es cada vez mayor. De allí es el interés de este proyecto de trabajo especial de grado, diseñar una Metodología de Desarrollo de Software adaptada a los requerimientos de la Gerencia y sobre todo, basada en las mejores prácticas del PMI y de la metodología Ágil SCRUM, ya que esta última se enfoca en aplicarse en ambientes muy cambiantes o variables. Para el desarrollo de este proyecto de trabajo especial de grado, se formularon 7 capítulos: Capítulo 1: El Problema de Investigación En este capítulo de desarrollará la definición o el planteamiento del problema, los objetivos generales y específicos, la justificación, el alcance y los resultados esperados. 1416 Capítulo 2: Marco Teórico Se desarrollará el marco teórico o las bases teóricas que sustentan esta investigación de grado. Se presentará diversos tópicos del PMI como sus áreas del conocimiento y como se definen los procesos en el. El marco de trabajo de SCRUM y conceptos que involucran la agilidad y la gestión de proyectos. Artículos publicados que hacen referencia al uso del PMI con las metodologías Ágiles. Capítulo 3: Marco Organizacional Se describirá la empresa, su historia, misión, visión, atributos y principios. Capítulo 4: Marco Metodológico Se enfoca el marco Metodológico en que se definen el tipo de investigación, las herramientas de recolección de datos y las fases a aplicar. 1517 CAPÍTULO I EL PROBLEMA DE INVESTIGACIÓN Planteamiento del problema Carecer de una metodología de desarrollo o de trabajo para proyectos de Software trae diversas consecuencias y la construcción del mismo no es una tarea fácil y esto lo podemos evidenciar por la existencia de diversas metodologías para facilitar el desarrollo de Software. El origen de la Gestión de Proyectos comienza en los años 50 donde en los grandes proyectos militares se evidenciaba la necesidad de la coordinación en las actividades y equipos involucrados en el desarrollo del sistema. En los años 60 es donde se establece un modelo de gestión y organización para evitar los problemas comunes que surgían en los proyectos, donde existía desbordamiento de los costos, incumplimiento en la agenda y un producto que no satisfacía a los usuarios. Todo comenzó en un ámbito militar para la Gestión de Proyectos, transformándose esta en una disciplina. A partir de entonces, diversas empresas comenzaron aplicar estas metodologías para la gestión, hasta llegar a los proyectos que involucraban el desarrollo de sistemas, surgiendo así cualquier cantidad de Metodologías especializadas para el Desarrollo de Software. 16 18 Esta necesidad de tener una guía para construir un producto que satisfaga las necesidades del cliente tiene su origen desde hace unas décadas y hoy en día las estadísticas muestran que la crisis del Desarrollo de Software aún está impactando fuertemente en las Empresas, donde el desarrollo de estos proyectos, la mayoría son un fracaso y son problemáticos. Hay que destacar que muchas empresas tienen a su disposición una metodología bien definida y aún así fracasan los desarrollos de Software, bien sea porque no cumplen con los tiempos establecidos para la entrega del producto, porque los costos aumentan notablemente o por que el producto no contiene el valor necesario para los usuarios. En el libro de Flexibilidad con Scrum de Juan Palacios, 2007, menciona que el nuevo escenario del desarrollo de nuevos productos, fue modificado por dos variables en el siglo pasado estas son la Velocidad y la Incertidumbre. Esto lo podemos evidenciar en los productos que ha lanzado Apple en donde en 6 años a desarrollado más de un modelo de Ipod. Antes los productos permanecían más tiempo en catálogos y en novedades, hoy en día son más breves los tiempos y rápidamente están fuera del mercado. Figura 1: Proyectos para desarrollo de sistemas de información Fuente: Flexibilidad con Scrum p.82 1719 La cadena de Farmacia Farmahorro cuenta con un departamento de Tecnología de Información (T.I), que a su vez contiene una Gerencia de Desarrollo. Esta gerencia se encarga de desarrollar y dar soporte a los programas de uso interno de la compañía. Farmahorro actualmente se encuentra en un proceso de crecimiento muy acelerado y por lo tanto cada vez las exigencias y la realización de nuevos sistemas que controlen ciertos procesos internos del mismo, es cada vez mayor. En el año 2009 se hizo una auditoria en la Gerencia de Desarrollo y el resultado no fue favorable para la Gerencia, ya que unos de los puntos en contra fue que no se hace uso de una Metodología definida de Desarrollo de Software en Farmahorro. Diversos proyectos de Software desarrollados dentro de la compañía, al culminar, no cumplen con los requerimientos que inicialmente se presentaron por el usuario y debido a esto, se atrasan y finalmente no responden a las necesidades. El equipo de desarrollo actualmente es de cuatro personas y carecer de una metodología de trabajo o desarrollo, en donde cada integrante tiene su forma de trabajar y donde existe una cultura laboral en la cual un usuario de un proyecto ya culminado se dirige hacia el lugar de trabajo de los desarrolladores y les piden alguna solicitud de cambiar o agregar alguna funcionalidad a ese proyecto, donde las exigencias y la excusa de ejecutar dicha solicitud al momento, es porque es urgente trae diversos problemas. Por lo general el desarrollo de los Sistemas, comienza con un levantamiento de información, se desarrollan los requerimientos y finalmente se le entrega al usuario para que este lo certifique. Hay que destacar que por lo general, los integrantes del equipo de Desarrollo, atienden más de una solicitud por la Gerencia, por la cual los tiempos están compartidos por Incidencias, Modificaciones y Nuevos desarrollos. 1820 Formulación del Problema Farmahorro está experimentando un crecimiento acelerado en la que la necesidad de disponer herramientas de Software que los apoyen en medir lo que se vende, facturar, llevar el control del inventario, entre otros, se torna crítico y se convierte en un tema sumamente importante, ya que estos sistemas tienen que cumplir correctamente con los requerimientos de los usuarios y a su vez que estos estén culminados a tiempo con el mayor valor posible. Debido a este acelerado crecimiento, los usuarios cada vez exigen mejores programas en una realidad que es cambiante, donde procesos y buenas prácticas para la gestión de proyectos de Software de forma predictiva, no son necesariamente los más adecuados para el control y la planificación dentro de la compañía, ya que se comienza con una visión del producto que permanece intacta durante el desarrollo del mismo, donde los requerimientos y tiempos están ajustados al alcance preestablecido y los cambios a los productos no son bien recibidos durante la ejecución. En consecuencia se formulan las siguientes interrogantes: Se hace uso de una Metodología de Desarrollo bien definida en la Gerencia de Desarrollo? Qué fases usualmente aplican para el Desarrollo de Software? Existe algún criterio para seleccionar o definir fases para del Desarrollo de Software? En la mayoría de los proyectos, son constantes las solicitudes de cambios sobre el desarrollo por parte del usuario? Son recurrentes los incidentes de los productos entregables puestos en producción? Los integrantes del equipo de Desarrollo tienen roles definidos? 1921 Los usuarios de los Proyectos de Software, en su mayoría están realmente satisfechos con los productos desarrollados? La entrega de los Desarrollos en su mayoría son entregados a tiempo? Se aplican buenas prácticas como las mencionadas en el PMBOK para el Desarrollo de Software? Se ha intentado implementar alguna metodología Ágil? Realmente los productos cumplen con el mayor valor para el usuario? Objetivos de la Investigación Objetivo General Diseñar una Metodología de Desarrollo basada en la Metodología Ágil Scrum y las mejores prácticas del PMI para los Proyectos de Software desarrollados en la cadena de farmacia Famahorro. Objetivos Específicos Realizar un estudio de la situación actual en la compañía sobre Coordinación y Desarrollo de Proyectos de Software. Determinar las fases y herramientas de la metodología SCRUM que se puedan adaptar a los requerimientos de la Empresa. Identificar los procesos y áreas de conocimientos del PMI que se puedan aplicar a los requerimientos de la Empresa. Integrar los elementos de la Metodología SCRUM y del PMI adaptadas a los requerimientos de la Empresa. Aplicar la metodología propuesta en un caso de estudio o proyecto piloto. 2022 Justificación Considerando lo anteriormente expuesto, cada vez se hace más exigente la respuesta rápida a la finalización de los proyectos. La compañía se encuentra en un entorno muy cambiante por motivo del crecimiento acelerado de la misma donde cada Gerencia solicita reportes que los apoyen en las mediciones de las ventas, del inventario, en las tomas de decisiones y en diversas actividades. Hoy en día por definir e implementar alguna metodología de desarrollo de software, se han dado éxitos en compañías, permitiendo que sus proyectos se entreguen a tiempo y adaptados a los requerimientos que el usuario necesita, de tal manera de reducir el fracaso del desarrollo de un proyecto de software. Al contar con una Metodología de Desarrollo basada en las mejores prácticas descritas por el PMI y la metodología Scrum, la gerencia de desarrollo de Farmahorro estaría no solo a la altura de las empresas que usan tecnología de punta, sino que los proyectos a desarrollar, estarían a nivel de lo que desean los usuarios, el equipo de desarrollo estaría trabajando de una misma forma teniendo a disposición una metodología para la gestión y desarrollo de Software adaptada a la Empresa. Alcance y Limitaciones La propuesta para el proyecto de trabajo especial de grado tiene como alcance una Metodología de Desarrollo de Software la cual consiste en un marco de trabajo (FrameWork) para estructurar, planificar y controlar el proceso de desarrollo de Sistemas de Información en la cadena de farmacias Farmahorro. Hay que destacar que esta metodología estará conformada bajo las mejores prácticas adoptadas de la guía de Fundamentos para la Dirección de Proyectos (PMBOK) y de la metodología Ágil SCRUM adaptadas a los requerimientos de la Empresa en términos de dirección de proyectos. 2123 Este proyecto de Investigación se focalizará en los procesos directamente seleccionados en el Departamento de TI responsable de los proyectos de Sistemas de Información, no incluye los procesos de la unidad Administrativa de Apoyo tales como Compra, Legal, RRHHH y Contabilidad. Para el desarrollo del trabajo se contará con el apoyo de Farmahorro para el levantamiento de Información de los procesos internos que se utilizan para la Gestión de Proyectos de Software. Resultados esperados Para el presente proyecto de trabajo especial de grado en un comienzo se espera obtener una lista de requerimientos para la Coordinación y Desarrollo de Proyectos de Software en Farmahorro mediante un estudio y diagnóstico de la situación actual entorno a prácticas utilizadas o no dentro de la compañía. Durante el desarrollo de la Investigación, además de lo descrito anteriormente, se espera obtener un estudio comparativo entre la lista de requerimientos versus las mejores prácticas del PMI y de SCRUM. De esta forma podremos adicionalmente definir una matriz FODA analizando los procesos que se utilizan en la Gerencia de Desarrollo para la Ingeniería de Software y aquellos procesos faltantes o que se puedan adaptar a los requerimientos una vez realizado el estudio comparativo. Conociendo la situación actual y teniendo en cuenta los requerimientos que posteriormente son comparados con las mejores prácticas del PMI y de la metodología Ágil SCRUM, poder diseñar la metodología basada en las mejores prácticas adaptada a Farmahorro. Finalmente, se aplicará la metodología propuesta a fin de establecer la factibilidad de implantación. 2224 CAPÍTULO II MARCO TEÓRICO 1.1 Antecedentes de la Investigación Como antecedentes de la investigación se incluyen los siguientes: El trabajo de grado de Schenone Marcelo Hernán, titulado Diseño de una Metodología Ágil de Desarrollo de Software (2004), tiene como propósito la construcción de una metodología Ágil de Desarrollo de Software. En el describe en sus capítulos en que consiste un modelo de proceso de desarrollo de software, las ventajas que incluye al aplicar algún proceso dentro de la organización y una descripción extensa de varias metodologías Ágiles mas destacables en la actualidad indicando en cada una de ellas un resumen y el contexto de aplicación en la que son utilizadas. El diseño de esta metodología está basado en la propuesta de Alistair CockBurn en la cual define una metodología en 10 elementos como mínimo. Este trabajo de grado nos permitirá tener una base teórica para definir la metodología a diseñar en esta investigación. Otro trabajo de grado en que se tomará en cuenta es el de Elvia Méndez, titulado Modelo de Evaluación de Metodologías para el Desarrollo de Software. Esta investigación identifica unas variables que permiten evaluar la metodología de desarrollo. 2325 Esto nos permitirá tener una guía para poder definir la metodología a Diseñar al igual que el poder identificar cuáles de las mejores prácticas definidas en el PMI y en SCRUM, son las más adecuadas para el diseño de la metodología. En la misma línea de investigación tenemos el trabajo titulado, Análisis Diseño e Implementación de un Software para el apoyo del dictado de clases simulando el uso de una pizarra mediante un dispositivo electrónico Pen Tablet (2009). En este trabajo de grado para la metodología que se utilizó para la gestión de proyectos, se basa en las mejores prácticas propuestas por el PMI, de esta forma nos serviría de apoyo para la inclusión de las prácticas del PMI en la metodología a Diseñar. Igualmente se tomará en cuenta el artículo publicado por Michele Sliger titulado, Relating PMBOK Practices to Agile Practices (2006), la cual consiste en que el PMBOK no menciona que las mejores prácticas descritas en él, deban aplicarse a metodología tradicionales enfocadas en Cascada. La autora menciona que ha encontrado que muchas de estas prácticas pueden ser aplicadas en otros tipos de modelos de metodologías, incluyendo las de la familia Ágil. Este artículo nos servirá de guía para poder incluir las prácticas del PMI con el enfoque de la metodología SCRUM. 1.2 Base Teóricas Para sustentar teóricamente la investigación es necesario tener conocimientos relacionados a Metodologías de Desarrollo de Software, buenas prácticas en la Gestión de Proyectos como la Guía Práctica descrita en el PMBOK, casos de éxitos del uso de Metodologías Ágiles, diferencias entre metodologías Ágiles y las secuenciales o tradicionales y por supuesto, modelos de Metodologías de Desarrollo siendo esto la base para definir la metodología. 2426 Project Management Institute (PMI) Project Management Institute (PMI) es una de las mayores asociaciones de membresía profesional del mundo, con medio millón de miembros y poseedores de credenciales en más de 185 países. Es una organización sin fines de lucro que promueve la profesión de gestión de proyectos a través de estándares mundialmente reconocidos y certificados, las comunidades de colaboración, un extenso programa de investigación, y oportunidades de desarrollo profesional. What is PMI?. Extraido el 29 de mayo de 2011 desde Según Michele Sliger y Stacia Broderick (2008): El Instituto de Manejo de Proyectos fue fundado en el año 1969 en el Instituto de Tecnología en Georgia por cinco voluntarios: James Synder, Gordon Davis, Eric Jenett, A.E. Engman, y Susan C. Gallagher. Su objetivo original era crear una organización donde los miembros pudiesen compartir sus experiencias en gestión de proyectos y discutir temas relacionados. El objetivo se ha ampliado hoy para el avance del conocimiento y la aplicación práctica en la profesión de gestión de proyectos Project Management Body of Knowledge (PMBOK) En 1983 el PMI creó una publicación titulada PMI Informe Especial sobre Ética, Normas y Acreditación". Las normas de este documento fue el "Project Management Body of Knowledge". En 1996 la primera edición de una Guía para el Project Management Body of Knowledge (PMBOK Guide), un libro que describe las áreas del proyecto de gestión del conocimiento, procesos y prácticas, se publicó. La Guía del PMBOK se convirtió en un estándar para el reconocimiento general de buenas prácticas en gestión de proyectos (Sliger y Broderick, 2008). Tomando en cuenta la cuarta edición del PMBOK, según el PMI (2008): 2527 La Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK ) es una norma reconocida en la profesión de la dirección de proyectos. Por norma se hace referencia a un documento formal que describe normas, métodos, procesos y prácticas establecidos. Al igual que en otras profesiones, como la abogacía, la medicina y las ciencias económicas, el conocimiento contenido en esta norma evolucionó a partir de las buenas prácticas reconocidas por profesionales dedicados a la dirección de proyectos, quienes contribuyeron a su desarrollo. El PMBOK afirma que el aumento de la aceptación de la dirección de proyectos no hace más que recalcar que la aplicación de procesos, conocimientos, habilidades y técnicas adecuadas puede llegar a impactar en el éxito de un proyecto. De esta forma según el PMBOK (2008): Se identifica ese subconjunto de fundamentos de la dirección de proyectos generalmente reconocido como buenas prácticas. Generalmente reconocido significa que los conocimientos y prácticas descritos se aplican a la mayoría de los proyectos, la mayor parte del tiempo, y que existe consenso sobre su valor y utilidad. Buenas prácticas significa que se está de acuerdo, en general, en que la aplicación de estas habilidades, herramientas y técnicas puede aumentar las posibilidades de éxito de una amplia variedad de proyectos. Buenas prácticas no significa que el conocimiento descrito deba aplicarse siempre de la misma manera en todos los proyectos; la organización y/o el equipo de dirección del proyecto son responsables de establecer lo que es apropiado para un proyecto determinado. Es de suma importancia indicar que el PMI considera la norma como una referencia para la dirección de proyectos y por ser de carácter de referencia fundamental, esta norma no está completa y por supuesto no contiene todos los conocimientos y de ser así se trata de una guía mas que propusiera una metodología por la cual para hacer uso del marco de referencia, se puede usar cualquier tipo de metodología. Además de las normas, el PMBOK establece las pautas para los procesos, herramientas y técnicas de la dirección de proyectos. 2628 Procesos de la Dirección de Proyectos para un Proyecto Según el PMBOK cuarta edición (2008) define la Dirección de Proyectos como: La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. La aplicación de conocimientos requiere de la dirección eficaz de los procesos apropiados. Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener un producto, resultado o servicio predefinido. Cada proceso se caracteriza por sus entradas, por las herramientas y técnicas que puedan aplicarse y por las salidas que se obtienen. El equipo de proyecto ejecuta los procesos donde generalmente son enmarcados en unas de las siguientes categorías principales: Los procesos de dirección de proyectos aseguran que el proyecto avance de manera eficaz durante toda su existencia. Estos procesos incluyen las herramientas y técnicas involucradas en la aplicación de las habilidades y capacidades que se describen en las Áreas de Conocimiento. Los procesos orientados al producto especifican y crean el producto del proyecto. Estos procesos normalmente son definidos por el ciclo de vida del proyecto y varían según el área de aplicación. El alcance del proyecto no puede definirse si no se cuenta con una comprensión básica acerca de cómo generar el producto especificado. Por ejemplo, al determinar la complejidad global de una casa que se planifica construir, se deben tener en cuenta diversas técnicas y herramientas de construcción. Esta norma describe únicamente los procesos de la dirección de proyectos. Si bien los procesos orientados al producto están fuera del alcance de esta norma, no deben ser ignorados por el director del proyecto. Los procesos de la dirección de proyectos y los procesos orientados al producto se superponen e interactúan a lo largo de la vida de un proyecto (PMI, 2008). 2729 La norma descrita en esta guía, realiza una descripción de los procesos, sus interacciones, la integración entre ellos y el propósito para los cuales sirven. Los procesos de la Dirección de Proyectos se agrupan en cinco categorías descritas a continuación, según el PMBOK: Grupo del Proceso de Iniciación. Aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto o fase. Grupo del Proceso de Planificación. Aquellos procesos requeridos para establecer el alcance del proyecto, refinar los objetivos y definir el curso de acción necesario para alcanzar los objetivos para cuyo logro se emprendió el proyecto. Grupo del Proceso de Ejecución. Aquellos procesos realizados para completar el trabajo definido en el plan para la dirección del proyecto a fin de cumplir con las especificaciones del mismo. Grupo del Proceso de Seguimiento y Control. Aquellos procesos requeridos para dar seguimiento, analizar y regular el progreso y el desempeño del proyecto, para identificar áreas en las que el plan requiera cambios y para iniciar los cambios correspondientes. Grupo del Proceso de Cierre. Aquellos procesos realizados para finalizar todas las actividades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo. Interacciones comunes entre procesos de la dirección de proyectos En el PMBOK los procesos para la dirección de proyectos se presentan como elementos que se diferencian por sus interfaces bien definidas. En la realidad se superponen e interactúan de tal forma que el PMBOK no se detalla totalmente. Los grupos de procesos y los procesos que los conforman, sirven de guía para poder aplicar los conocimientos y habilidades apropiados en el ámbito de la 2830 dirección de proyectos, siendo esta aplicación de forma iterativa donde muchos procesos se repiten durante el proyecto. La naturaleza integradora de la dirección de proyectos requiere que el Grupo del Proceso de Seguimiento y Control interactúe con los otros grupos de procesos. Además, dado que la dirección de un proyecto es un esfuerzo finito, el Grupo del Proceso de Iniciación comienza el proyecto mientras que el Grupo del Proceso de Cierre lo finaliza (PMI, 2008). Esta interacción entre los grupos de procesos lo podemos visualizar en la figura N 3. Figura 2: Interacción de los grupos de procesos en una fase o proyecto. Fuente: PMI (2008) p.23 29 31 Figura 3: Grupos de Procesos de la Dirección de Proyectos Fuente: PMI (2008) p.43 Grupos de Procesos de la Dirección de Proyectos Los Cinco grupos de procesos son independientes del enfoque de la industria y del área en que se apliquen donde estos grupos de procesos y los procesos que los constituyen a menudo se repiten durante el transcurso del proyecto. Los procesos constitutivos pueden interactuar dentro de un grupo de procesos y entre grupos de procesos, en la cual esto varía dependiendo de cada proyecto. En la tabla N 1 podremos visualizar como se corresponden los 42 procesos de la Dirección de Proyectos con los 5 grupos de la Dirección de Proyectos y las 9 Áreas de Conocimiento de la Dirección de Proyectos. Tabla 1: Correspondencia entre grupos de procesos y áreas de conocimiento de la dirección de proyectos Fuente: PMI (2008) Áreas del Conocimiento 1. Gestión de la Integración del Proyecto Grupo del Proceso de Iniciación 1.1 Desarrollar el Acta de Constitución del Proyecto Grupos de Procesos de la Dirección de Proyectos Grupo del Proceso de Planificación 1.2 Desarrollar el Plan para la Dirección del Proyecto Grupo del Proceso de Ejecución 1.3 Dirigir y Gestionar la Ejecución del Proyecto Grupo del Proceso de Seguimiento y Control 1.4 Monitorear y Controlar el Trabajo del Proyecto 1.5 Realizar el Control Grupo del Proceso de Cierre 1.6 Cerrar el Proyecto o Fase 3032 2. Gestión del Alcance del Proyecto 3. Gestión del Tiempo del Proyecto 2.1 Recopilar Requisitos 2.2 Definir el Alcance 2.3 Crear la EDT 3.1 Definir las Actividades 3.2 Secuenciar las actividades 3.3 Estimar los recursos de las Actividades 3.4 Estimar la Duración de las actividades 3.5 Desarrollar el Cronograma Integrado de Cambios 2.3 Verificar el Alcance 2.4 Controlar el Alcance 3.6 Controlar el Cronograma 4. Gestión de los Costos del Proyecto 5. Gestión de la Calidad del Proyecto 6. Gestión de los Recursos Humanos del Proyecto 7. Gestión de las Comunicaciones del Proyecto 8. Gestión de los Riesgos del Proyecto 7.1 Identificar a los Interesados 4.1 Estimar lo Costos 4.2 Determinar los Costos 5.1 Planificar la Calidad 6.1 Desarrollar el Plan de Recursos Humanos 7.2 Planificar las Comunicaciones 8.1 Planificar la Gestión de Riesgos 8.2 Identificar los Riesgos 8.3 Realizar el Análisis Cualitativo de Riesgos 8.4 Realizar el Análisis Cuantitativo de Riesgos 8.5 Planificar la Respuesta a los Riesgos 5.2 Realizar el Aseguramiento de Calidad 6.2 Adquirir el Equipo del Proyecto 6.3 Desarrollar el Equipo del Proyecto 6.4 Dirigir el Equipo del Proyecto 7.3 Distribuir la Información 7.4 Gestionar las Expectativas de los Interesados 4.3 Controlar los Costos 5.3 Realizar el Control de Calidad 7.5 Informar el Desempeño 8.6 Monitorear y Controlar los Riesgos 9. Gestión de las Adquisiciones del Proyecto 91. Planificar las Adquisiciones 9.2 Efectuar las Adquisiciones 9.3 Administrar las Adquisiciones 9.4 Cerrar las Adquisiciones 3133 Grupo del Proceso de Iniciación Este grupo de proceso involucra todos aquellos procesos relacionados a la definición de un nuevo proyecto o fase de un proyecto ya existente, una vez obtenida la autorización para el comienzo del proyecto o de la fase. En estos procesos se define el alcance inicial y se comprometen los recursos financieros previamente establecidos y se identifican todos aquellos interesados como internos o externos que van a interactuar y ejercer algún efecto sobre el resultado global del proyecto. El PMI (2008) menciona lo siguiente: Si aún no fue nombrado, se seleccionará el director del proyecto. Esta información se plasma en el acta de constitución del proyecto y registro de interesados. Cuando el acta de constitución del proyecto recibe aprobación, el proyecto se considera autorizado oficialmente. Aunque el equipo de dirección del proyecto pueda colaborar en la redacción de esta acta, la aprobación y el financiamiento se manejan fuera de los límites del proyecto (p.47). Como parte del Grupo del Proceso de Iniciación, varios proyectos complejos o de gran tamaño pueden dividirse en fases independientes. En dichos proyectos, los procesos de iniciación se llevan a cabo en las fases subsiguientes a fin de validar las decisiones tomadas durante el proceso Desarrollar el Acta de Constitución y el proceso Identificar a los Interesados. Activar los procesos de iniciación al comienzo de cada fase ayuda a mantener el proyecto centrado en la necesidad de negocio que el proyecto se comprometió a abordar. Se verifican los criterios de éxito y se revisan la influencia y los objetivos de los interesados en el proyecto. Se toma entonces una decisión sobre la necesidad de continuar, posponer o suspender el proyecto (PMI, 2008, p.47). Realmente al involucrar a los clientes y a todos los interesados en la etapa de Iniciación, aumentamos la probabilidad de contar con propiedad los requerimientos iniciales del proyecto, con la aceptación de los entregables y por supuesto de lograr una satisfacción del cliente y de todos los interesados. 3234 Los procesos que integran este grupo de procesos son los siguientes: Desarrollar el Acta de Constitución del Proyecto. Identificar a los Interesados. Grupo del Proceso de Planificación En la guía del PMI (2008) se menciona que: El Grupo del Proceso de Planificación está compuesto por aquellos procesos realizados para establecer el alcance total del esfuerzo, definir y refinar los objetivos, y desarrollar la línea de acción requerida para alcanzar dichos objetivos (p. 49). En este proceso se desarrolla el plan para la dirección del proyecto y aquellos documentos que se utilizarán en el desarrollo del proyecto. A medida que se recopilan o se comprenden más características o informaciones sobre el proyecto, puede ser necesaria una mayor planificación. Los cambios importantes que ocurren a lo largo del ciclo de vida del proyecto generan la necesidad de reconsiderar uno o más de los procesos de planificación y, posiblemente, algunos de los procesos de iniciación (PMI, 2008, p.49). En la guía se hace énfasis en que el incorporar detalles progresivamente al plan para la dirección de proyectos, se recibe el nombre de Planificación gradual y de esta forma indicar que la documentación y la planificación son procesos que se repiten y son continuos. El plan para la dirección de proyectos y los documentos del proyecto, siendo estos las salidas de este proceso, se tomarán en cuenta todos los aspectos del tiempo, alcance, costo, riesgos, comunicación y adquisición. Debido a las actualizaciones que puedan surgir por los cambios aprobados durante el proyecto y que estos pueden tener un impacto importante en el éxito del proyecto, es sumamente importante que todos los interesados del mismo 3335 participen durante la planificación del proyecto y en el desarrollo del plan para la dirección y documentos del proyecto. Esta retroalimentación no puede ser indefinida y el PMI (2008) menciona que: los procedimientos establecidos por la organización dictan cuándo se termina el esfuerzo de planificación inicial. Estos procedimientos se verán afectados por la naturaleza del proyecto, por los límites establecidos del proyecto, por las actividades de seguimiento y control apropiadas y por el entorno en el que el proyecto se llevará a cabo (p.51). Vale destacar que dentro de este grupo de procesos, se definen los procesos de la Estimación de Costos, la Determinación del Presupuesto y Planificar la Adquisiciones. Estos no los incluiremos debido a que no están definidos en el alcance de la investigación del proyecto. Los grupos de procesos que integran este grupo de procesos según el alcance definido en la investigación del proyecto son los siguientes: Desarrollar el Plan para la Dirección de Proyectos Recopilar Requisitos Definir el Alcance Crear la EDT (Estructura de Desglose del Trabajo) Definir las Actividades Secuenciar las Actividades Estimar los Recursos de las Actividades Estimar la Duración de las Actividades Desarrollar el Cronograma Planificar la Calidad Desarrollar el Plan de Recursos Humanos 3436 Planificar las Comunicaciones Planificar la Gestión de Riesgos Identificar los Riesgos Realizar Análisis Cualitativo de los riesgos Realizar Análisis Cuantitativo de los riesgos Planificar la Respuesta a los Riesgos 3537 Grupo del Proceso de Ejecución El grupo del Proceso de Ejecución está conformado por todos aquellos procesos que ayudan a completar el trabajo definido en el plan para la dirección del proyecto. Consiste en coordinar recursos y personas, integrar y ejecutar actividades del proyecto siguiendo el plan para la dirección de proyectos. Cada proyecto es único y por lo tanto puede ocurrir que se requiera actualizar la planificación y así requerir establecer una nueva línea base. El PMI (2008) menciona que: Esto puede incluir cambios en la duración prevista de las actividades, cambios en la disponibilidad y productividad de recursos, así como en los riesgos no anticipados. Tales variaciones pueden afectar el plan para la dirección del proyecto o los documentos del proyecto, y pueden requerir un análisis detallado y el desarrollo de respuestas de dirección de proyectos apropiadas. Los resultados del análisis pueden generar la solicitud de cambios que, en caso de ser aprobados, podrían modificar el plan para la dirección del proyecto u otros documentos del proyecto, y requerir posiblemente el establecimiento de una nueva línea base. Gran parte del presupuesto del proyecto se utilizará en la realización de los procesos del grupo de procesos de ejecución (p.58). Los grupos de procesos que integran este grupo de procesos son los siguientes sin incluir el grupo de proceso de Efectuar las Adquisiciones, ya que el mismo no está en el alcance del proyecto: Dirigir y Gestionar la Ejecución del Proyecto Realizar Aseguramiento de Calidad Distribuir la Información Gestionar las expectativas de los Interesados 3638 Grupo del Proceso de Seguimiento y Control Este grupo de proceso involucra todos aquellos procesos que supervisan, controlan y regulan el progreso y el desempeño del proyecto, para identificar aquellas áreas en las que el plan requiera modificaciones o cambios. La ventaja que posee este grupo de proceso radica en que el desempeño del proyecto se puede medir y observar regularmente a fin de identificar posibles variaciones en relación al plan establecido. Según el PMI (2008) se así énfasis de que: En proyectos de fases múltiples, el grupo de proceso de seguimiento y control coordina las fases del proyecto a fin de implementar acciones correctivas o preventivas, de modo que el proyecto cumpla con el plan para la dirección del proyecto. Esta revisión puede dar lugar a actualizaciones recomendadas y aprobadas al plan para la dirección del proyecto. Por ejemplo, el incumplimiento de una fecha de finalización de una actividad puede requerir ajustes al plan de personal vigente, la implementación de horas extra, o que se realicen concesiones entre los objetivos de presupuesto y cronograma (p.62). El proceso de Controlar los Costos y el de Administrar las Adquisiciones no se incluye. Los procesos que se definen en este grupo de procesos son los siguientes: Monitorear y Controlar el Trabajo del Proyecto Realizar el Control Integrado de Cambios Verificar el Alcance Controlar el Alcance Controlar el Cronograma Realizar el Control de Calidad Informar el Desempeño 3739 Monitorear y Controlar los Riesgos Grupo del Proceso de Cierre Este grupo de procesos lo conforman todos aquellos procesos realizados para finalizar todas las actividades por medio de todos los procesos de a dirección de proyectos con la finalidad de poder completar el proyecto, una fase del mismo u otras cosas que están pendientes a nivel contractual. Una vez culminado este grupo de procesos, verifica que todos los procesos definidos se hayan completado dentro de todos los grupos de procesos y así poder cerrar el proyecto o una fase. Según el PMI (2008) indica que puede ocurrir lo siguiente: obtener la aceptación del cliente o del patrocinador, realizar una revisión tras el cierre del proyecto o la finalización de una fase, registrar los impactos de la adaptación a un proceso, documentar las lecciones aprendidas, aplicar actualizaciones apropiadas a los activos de los procesos de la organización, archivar todos los documentos relevantes del proyecto en el sistema de información para la dirección de proyectos para ser utilizados como datos históricos y cerrar las adquisiciones (p. 66). El proceso de Cierre de las Adquisiciones no se incluye en el alcance del proyecto. El grupo de proceso que se incluye en este grupo de proceso es el siguiente: Cerrar el Proyecto o Fase 3840 Áreas del Conocimiento En la vida real, los grupos de procesos de la dirección de proyectos, son iterativos y pueden superponerse e interactuar de formas en que la guía para la dirección de proyectos no define. Las Áreas del Conocimiento incluye las herramientas y técnicas que se aplican en los grupos de procesos, definiéndose sus entradas y salidas por cada uno de los procesos. En total en la guía para la dirección de proyectos, se definen 9 Áreas del Conocimiento pero para el caso de esta investigación de grado, solo se incluyen los siguientes en el marco teórico: Gestión de la Integración del Proyecto Gestión del Alcance del Proyecto Gestión del Tiempo del Proyecto Gestión de la Calidad del Proyecto Gestión de los Recursos Humanos del Proyecto Gestión de las Comunicaciones del Proyecto Gestión de los Riesgos del Proyecto Las áreas no incluidas son las siguientes: Gestión de los Costos del Proyecto Gestión de las Adquisiciones del Proyecto 3941 Gestión de la Integración de Proyectos Según el PMI (2008) se menciona que: La Gestión de la Integración del Proyecto incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades de la dirección de proyectos dentro de los grupos de procesos de dirección de proyectos (p. 70). En el ámbito de la dirección de proyectos, el área de integración incluye características de unificación, consolidación, articulación y todas aquellas acciones integradoras que son críticas para la finalización del proyecto, el cumplimiento de las expectativas de los interesados y de los requisitos. La gestión de la integración del proyecto implica tomar decisiones en cuanto a la asignación de recursos, balancear objetivos y alternativas contrapuestas, y manejar las interdependencias entre las áreas de conocimiento de la dirección de proyectos (PMI, 2008, p.70). Los procesos de la Gestión de Integración se definen a continuación: 1 Desarrollar el Acta de Constitución del Proyecto Este proceso consiste en desarrollar un documento que formaliza la autorización de un proyecto o fase y en documentar los requisitos iniciales que definen la satisfacción del Cliente. Si el proyecto es realizado en fases, este proceso de utiliza para refinar las decisiones tomadas en la anterior ejecución de este proceso. Las entradas, salidas y herramientas de este proceso lo podemos visualizar en la figura 4. 40 42 Figura 4: Desarrollar el Acta de Constitución del Proyecto: Entradas, Salidas, Herramientas y Técnicas Fuente: PMI (2008) p.73 2 Desarrollar el Plan para la Dirección de Proyectos Desarrollar el Plan para la Dirección del Proyecto es el proceso que consiste en documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los planes subsidiarios. El plan para la dirección del proyecto se convierte en la fuente primaria de información para determinar la manera en que se planificará, ejecutará, supervisará y controlará, y cerrará el proyecto (PMI, 2008, p. 51). A continuación podemos ver las Entradas, Salidas y Herramientas de este proceso. Figura 5: Desarrollar el Plan para la Dirección de Proyectos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.76 4143 3 Dirigir y Gestionar la Ejecución del Proyecto Dirigir y Gestionar la ejecución del proyecto es el proceso que consiste en ejecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del proyecto (PMI, 2008, p.59). Las actividades que este proceso abarca, entre otras son las siguientes: Realizar las actividades necesarias para cumplir con los requisitos del proyecto. Crear los entregables del proyecto. Reunir, capacitar y dirigir a los miembros del equipo asignado al proyecto. Obtener, gestionar y utilizar los recursos, incluyendo materiales, herramientas, equipos e instalaciones. Implementar los métodos y normas planificados. Establecer y gestionar los canales de comunicación del proyecto, tanto externos como internos al equipo del proyecto. Generar los datos del proyecto, tales como costo, cronograma, avance técnico y de calidad y el estado, a fin de facilitar las proyecciones. Emitir las solicitudes de cambio y adaptar los cambios aprobados al alcance, a los planes y al entorno del proyecto. Gestionar los riesgos e implementar las actividades de respuesta a los mismos. Gestionar a los vendedores y proveedores. Recopilar y documentar las lecciones aprendidas e implementar las actividades aprobadas de mejora del proceso. 42 44 El director del proyecto, junto con el equipo de dirección del proyecto, dirige el desempeño de las actividades planificadas del proyecto y gestiona las diversas interfaces técnicas y organizacionales que existen dentro del proyecto (PMI, 2008, p.80). Figura 6: Dirigir y Gestionar la Dirección: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.81 4 Dar Seguimiento y Controlar el Trabajo del Proyecto Este proceso consiste en analizar, monitorear y regular el avance del proyecto con la finalidad de poder cumplir los objetivos de desempeño definidos en el plan para la dirección del proyecto, recopilando, midiendo y distribuyendo la información relativa al desempeño permitiendo posteriormente poder efectuar mejoras al proceso. Según el PMI (2008) el proceso consiste en: comparar el desempeño real del proyecto con respecto al plan para la dirección del proyecto; evaluar el desempeño para determinar la necesidad de una acción preventiva o correctiva y para recomendar aquéllas que se consideran pertinentes, identificar nuevos riesgos y analizar, revisar y monitorear los riesgos existentes del proyecto, para asegurarse de que se identifiquen los riesgos, 4345 se informe sobre su estado y se implementen los planes apropiados de respuesta a los riesgos, mantener, durante la ejecución del proyecto, una base de información precisa y oportuna relativa al producto o a los productos del proyecto y su documentación relacionada, proporcionar la información necesaria para sustentar el informe de estado, la medición del avance y las proyecciones, proporcionar proyecciones que permitan actualizar la información relativa al costo y al cronograma actuales, y monitorear la implementación de los cambios aprobados cuando éstos se produzcan (p. 85). Figura 7: Monitorear y Controlar el Trabajo del Proyecto: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.85 5 Realizar Control Integrado de Cambios En el PMI (2008) se menciona que: Realizar el Control Integrado de cambios es el proceso que consiste en revisar todas las solicitudes de cambios, aprobar los mismos y gestionar los cambios a los entregables, a los activos de los procesos de la organización, a los documentos del proyecto y al plan para la dirección del proyecto. El proceso Realizar el Control Integrado de Cambios interviene desde el inicio del proyecto 4446 hasta su terminación. El plan para la dirección del proyecto, la declaración del alcance del proyecto y otros entregables se mantienen actualizados por medio de una gestión rigurosa y continua de los cambios, ya sea rechazándolos o aprobándolos, de manera tal que se asegure que sólo los cambios aprobados se incorporen a una línea base revisada (p. 88). Las actividades comprendidas en este proceso son las siguientes: Influir en los factores que eluden el control integrado de cambios, de modo que únicamente se implementen cambios aprobados. Revisar, analizar y aprobar las solicitudes de cambio de forma rápida, lo cual es esencial ya que una decisión tardía puede influir negativamente en el tiempo, el costo o la viabilidad de un cambio, Gestionar los cambios aprobados. Mantener la integridad de las líneas base, incorporando al plan para la dirección del proyecto y a los documentos del proyecto únicamente los cambios aprobados. Revisar, aprobar o rechazar todas las acciones preventivas y correctivas recomendadas. Coordinar los cambios a través de todo el proyecto (por ejemplo, un cambio propuesto en el cronograma a menudo influirá en el costo, el riesgo, la calidad y los recursos humanos). Documentar el impacto total de las solicitudes de cambio. 45 47 Figura 8: Realizar el Control Integrado de Cambios: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.89 6 Cerrar el proyecto o Fase Cerrar el Proyecto o Fase es el proceso que consiste en finalizar todas aquellas actividades definidas en todos los grupos de procesos de la dirección de proyectos para poder completar formalmente el proyecto o fase. Al cierre del proyecto, el director del proyecto revisará toda la información anterior procedente de los cierres de las fases previas para asegurarse de que todo el trabajo del proyecto está completo y de que el proyecto ha alcanzado sus objetivos. Puesto que el alcance del proyecto se mide con relación al plan para la dirección del proyecto, el director del proyecto revisará este documento para cerciorarse de su culminación antes de considerar que el proyecto está cerrado (PMI, 2008, p.92). Hay que destacar que en este proceso también se establecen los procedimientos de análisis y documentación del porqué se tomaron ciertas acciones en caso de que un proyecto no se dé por culminado antes de su finalización. Según el PMI (2008) se menciona que: Esto incluye todas las actividades necesarias para el cierre administrativo del proyecto o fase, incluyendo metodologías paso a paso relativas a: Las acciones y actividades necesarias para satisfacer los criterios de terminación o salida de la fase o del proyecto 46 48 Las acciones y actividades necesarias para transferir los productos, servicios o resultados del proyecto a la siguiente fase o a la producción y/u operaciones Las actividades necesarias para recopilar los registros del proyecto o fase, auditar el éxito o fracaso del proyecto, reunir las lecciones aprendidas y archivar la información del proyecto para su uso futuro por parte de la organización. Figura 9: Cerrar Proyecto o Fase: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.93 Gestión del Alcance del Proyecto En esta gestión de incluyen todos los procesos que garantizan que el proyecto incluya todo y únicamente todo el trabajo requerido para culminar con éxito el proyecto, definiéndose y controlando lo que se incluye en el mismo. Estos procesos que conforman la Gestión del Alcance del Proyecto, interactúan entre sí y con las demás áreas del conocimiento. Cada proceso se ejecuta por lo menos una vez en cada proyecto y en una o más fases del proyecto, en caso de que el mismo esté dividido en fases. Aunque los procesos se presentan aquí como componentes diferenciados con interfaces bien definidas, en la práctica se superponen e interactúan de formas que no se detallan aquí (PMI, 2008, p.95). Según el PMI (2008) se definen los siguientes conceptos dentro el contexto del proyecto: 47 49 Alcance del producto. Las características y funciones que definen un producto, servicio o resultado. Alcance del proyecto. El trabajo que debe realizarse para entregar un producto, servicio o resultado con las características y funciones especificadas. Los procesos usados para gestionar el alcance del proyecto, así como las herramientas y técnicas asociadas, varían según el área de aplicación y normalmente se definen como parte del ciclo de vida del proyecto. La Declaración del Alcance del Proyecto detallada y aprobada, y su EDT asociada junto con el diccionario de la EDT, constituyen la línea base del alcance del proyecto. Esta línea base del alcance se monitorea, se verifica y se controla durante todo el ciclo de vida del proyecto (p. 95). Los procesos de la Gestión del Alcance del Proyecto se definen a continuación: 1. Recopilar Requisitos Este proceso consiste en definir y documentar las necesidades de los interesados (Ver figura 10). Figura 10: Recopilar Requisitos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.97 48 50 2. Definir el Alcance Este proceso consiste en realizar una descripción detallada del proyecto y del producto. Figura 11: Definir el Alcance: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Crear la EDT (Estructura de Desglose del Trabajo) Crear la EDT consiste en subdividir los entregables y el trabajo del proyecto en partes más pequeñas y por supuesto más fáciles de dirigir. Figura 12: Crear la EDT: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Verificar el Alcance La verificación del alcance consiste en formalizar la aceptación de los entregables con el cliente a fin de asegurarse de que se han completado satisfactoriamente y para obtener de ellos su aceptación formal. 49 51 Figura 13: Verificar Alcance: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Controlar el Alcance Según el PMI (2008) se define que: Controlar el Alcance es el proceso por el que se monitorea el estado del alcance del proyecto y del producto, y se gestionan cambios a la línea base del alcance. El control del alcance del proyecto asegura que todos los cambios solicitados o las acciones preventivas o correctivas recomendadas se procesen a través del proceso Realizar el Control Integrado de Cambios (p. 113). Los cambios son inevitables y es por esto que se aplica algún tipo de proceso de control de cambio. Figura 14 Controlar el Alcance: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p 52 Gestión del Tiempo del Proyecto La Gestión del Tiempo del Proyecto incluye los procesos que son necesarios para administrar la finalización del proyecto a tiempo. Al desarrollar el Plan para la Dirección de Proyecto, generándose un plan para la gestión del cronograma, se selecciona una metodología, una herramienta para la planificación, estableciéndose un formato y criterios para desarrollar y controlar el cronograma del proyecto. Entre las metodologías más conocidas se encuentran el método de la ruta crítica y el de la cadena crítica. Los procesos de la Gestión del Tiempo del Proyecto se definen a continuación: 1. Definir las Actividades Consiste en definir o identificar todas aquellas acciones necesarias para el desarrollo de los entregables del proyecto. Las herramientas y técnicas a utilizar por este proceso, están relacionadas al proceso anterior, la de crear la EDT. Figura 15: Definir las Actividades: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Secuenciar las Actividades Consiste en definir o identificar y documentar las relaciones entres las actividades del proyecto. 51 53 Figura 16: Secuenciar las Actividades: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Estimar los recursos de las Actividades En este proceso se determina la cantidad de materiales, recursos, personas, equipos o suministros requeridos para la realización de las actividades del proyecto. Figura 17: Estimar los recursos de las Actividades: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Estimar la duración de las Actividades Este proceso trata de definir aproximadamente los periodos de tiempo necesario para la realización de las actividades con los recursos estimados del proyecto. 52 54 Figura 18: Estimar la duración de las Actividades: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Desarrollar el Cronograma Desarrollar el Cronograma es el proceso que consiste en analizar el orden de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto (PMI, 2008, p.53). Figura 19: Desarrollar el Cronograma: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Controlar el Cronograma Según el PMI (2008) se define que: Controlar el Cronograma es el proceso por el que se da seguimiento al estado del proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma (p. 141). 53 55 Figura 20: Controlar el Cronograma: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.142 Gestión de la Calidad del Proyecto La Gestión de la Calidad del Proyecto incluye los procesos y actividades de la organización ejecutante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por la cuales fue emprendido. Implementa el sistema de gestión de calidad por medio de políticas y procedimientos, con actividades de mejora continua de los procesos llevados a cabo durante todo el proyecto, según corresponda (PMI, 2008, p.166). Los procesos de la Gestión de la Calidad del Proyecto se definen a continuación: 1. Planificar la Calidad El proceso de Planificar la Calidad según el PMI (2008), menciona que: Planificar la Calidad es el proceso por el cual se identifican los requisitos de calidad y/o normas para el proyecto y el producto, y se documenta la manera en que el proyecto demostrará el cumplimiento con los mismos (p.54). 54 56 Figura 21: Planificar la Calidad: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Realizar el Aseguramiento de Calidad Este proceso consiste en auditar todos los requisitos de calidad y aquellos resultados obtenidos por medio de medidas de calidad con la finalidad de que se cumplan la normas de calidad adecuadas. A menudo todas estas actividades relacionadas al aseguramiento de calidad son supervisadas por alguna entidad o una organización similar pero no necesariamente tiene que ser de esa manera, ya que el soporte de aseguramiento de calidad puede proporcionarse al equipo del proyecto. Según el PMI (2008, p.177) se menciona que: Realizar el Aseguramiento de Calidad cubre también la mejora continua del proceso, que es un medio iterativo de mejorar la calidad de todos los procesos. La mejora continua del proceso reduce las actividades inútiles y elimina aquéllas que no agregan valor al proyecto. Esto permite que los procesos operen con niveles más altos de eficiencia y efectividad. 55 57 Figura 22: Realizar el Aseguramiento de Calidad: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Realizar Control de Calidad Ejecutar este proceso, consiste en registrar y monitorear los resultados obtenidos en la ejecución de las actividades de calidad. Según el PMI (2008) se dice que: El control de calidad se lleva a cabo durante todo el proyecto. Los estándares de calidad incluyen las metas de los procesos y del producto del proyecto. Los resultados del proyecto incluyen los entregables y los resultados de la dirección de proyectos, tales como el desempeño de costos y del cronograma. A menudo, el control de calidad es realizado por un departamento de control de calidad o una unidad de la organización con una denominación similar. Las actividades de control de calidad permiten identificar las causas de una calidad deficiente del proceso o del producto, y recomiendan y/o implementan acciones para eliminarlas (p. 180). 56 58 Figura 23: Realizar Control de Calidad: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.181 Gestión de los Recursos Humanos del Proyecto En la Gestión de los recursos Humanos del Proyecto, se incluyen todos aquellos procesos que gestionar el equipo del proyecto, siendo conformado este por aquellas personas en las que se le han asignando roles y responsabilidades para completar el proyecto. El tipo y la cantidad de miembros del equipo del proyecto pueden variar con frecuencia, a medida que el proyecto avanza. Los miembros del equipo del proyecto también pueden denominarse personal del proyecto. Si bien se asignan roles y responsabilidades específicos a cada miembro del equipo del proyecto, la participación de todos los miembros en la toma de decisiones y en la planificación del proyecto puede resultar beneficiosa. La intervención y la participación tempranas de los miembros del equipo les aportan su experiencia profesional durante el proceso de planificación y fortalecen su compromiso con el proyecto (PMI, 2008, p.188). 57 59 A continuación definiremos solamente el proceso de Desarrollar el Plan de Recursos Humanos para esta área del conocimiento. 1. Desarrollar el Plan de Recursos Humanos Desarrollar el Plan de Recursos Humanos es el proceso por el cual se identifican y documentan los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación, y se crea el plan para la dirección de personal (PMI, 2008, p.55). Figura 24: Desarrollar el Plan de Recursos Humanos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.191 Gestión de las Comunicaciones del Proyecto Según el PMI (2008) se dice que: La Gestión de las Comunicaciones del Proyecto incluye los procesos requeridos para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto sean adecuados y oportunos. Los directores del proyecto pasan la mayor parte del tiempo comunicándose con los miembros del equipo y otros interesados en el proyecto, tanto si son internos (en todos los niveles de la organización) como externos a la misma. Una comunicación eficaz crea un puente entre los diferentes interesados involucrados en un proyecto, conectando diferentes entornos culturales y organizacionales, diferentes niveles de 58 60 experiencia, y perspectivas e intereses diversos en la ejecución o resultado del proyecto (p. 211). A continuación describiremos los procesos que se incluyen en esta gestión: 1. Identificar a los Interesados Este proceso consiste en identificar todas las personas u organizaciones que se ven afectados por el proyecto, documentando todo lo relacionado a sus intereses, participación e impacto en el éxito del proyecto. En la figura número 25 podemos visualizar las entradas, salidas y herramientas de este proceso. Figura 25: Identificar a los Interesados: Entradas, Salidas, Herramientas y Técnicas Fuente: PMI (2008) p Planificar las Comunicaciones Es el proceso que consiste en determinar las necesidades de información de los interesados del proyecto y de definir como se llevará a cabo las comunicaciones en el proyecto. Figura 26: Planificar las Comunicaciones: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p61 3. Distribuir la Información Es el proceso que consiste en disponer de la información relevante a los interesados en el proyecto de acuerdo a un plan anteriormente establecido. Este proceso se ejecuta a lo largo de todo el ciclo de vida del proyecto y en todos los procesos de dirección. En este caso, el enfoque está puesto principalmente en el proceso de ejecución, que incluye la implementación del plan de gestión de las comunicaciones, así como la respuesta a solicitudes de información inesperadas (PMI, 2008, p.222). El distribuir la información eficazmente involucra la aplicación de las siguientes técnicas: Modelos emisor-receptor. Ciclos de retroalimentación y barreras a la comunicación. Elección del medio. Descripción precisa de las situaciones en las que es preferible una comunicación escrita u oral, cuándo escribir un memorando informal o un informe formal, y cuándo comunicarse cara a cara o por correo electrónico. Estilo de redacción. Voz pasiva o voz activa, estructura de las oraciones y selección de palabras. Técnicas de gestión de reuniones. Preparar una agenda y abordar los conflictos. Técnicas de presentación. Lenguaje corporal y diseño de soportes visuales. Técnicas de facilitación. Lograr el consenso y superar los obstáculos. 60 62 Figura 27: Distribuir la Información: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Gestionar las Expectativas de los Interesados Este proceso consiste en comunicarse y trabajar en conjunto con los interesados del proyecto con el fin de satisfacer las necesidades de los mismos y a su vez abordar cualquier incidente que se pueda presentar. Estas inquietudes y asuntos a resolver pueden ser como: Gestionar activamente las expectativas de los interesados para aumentar la probabilidad de aceptación del proyecto, negociando y ejerciendo influencia sobre sus deseos para alcanzar y mantener los objetivos del proyecto. Abordar inquietudes que aún no representan incidentes, por lo general relacionadas con la anticipación de problemas futuros. Es preciso revelar y tratar estas inquietudes, así como evaluar los riesgos. Aclarar y resolver los incidentes identificados. La resolución puede generar una solicitud de cambio o puede abordarse fuera del proyecto, por ejemplo, puede posponerse para otro proyecto o fase, o derivarse a otra entidad de la organización. Aplicar este proceso ayuda a aumentar las probabilidades de éxito del proyecto ya que permite que los interesados del mismo comprendan los beneficios y riesgos en el proyecto. Según el PMI (2008), se menciona que: 61 63 Esto les permite apoyar el proyecto de forma activa y ayudar en la evaluación de los riesgos asociados con las elecciones del proyecto. Al anticipar la reacción de las personas frente al proyecto, pueden implementarse acciones preventivas a fin de obtener su apoyo o minimizar los impactos negativos potenciales. El director del proyecto es responsable de gestionar las expectativas de los interesados. La gestión activa de estas expectativas disminuye el riesgo de que el proyecto no alcance sus objetivos y metas por causa de incidentes no resueltos a nivel de los interesados, y limita las interrupciones durante el proyecto. (p.225). Figura 28: Gestionar las Expectativas de los Interesados: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Informar el Desempeño En este proceso se recopila y se distribuye la información sobre el desempeño, se incluyen los informes de estado, de mediciones del avance y de las proyecciones en el proyecto. 62 64 Figura 29: Informar el Desempeño: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.229 Gestión de los Riesgos del Proyecto La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo la planificación de la gestión, la identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitoreo y control en un proyecto. Los objetivos de la Gestión de los Riesgos del Proyecto son aumentar la probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos negativos para el proyecto (PMI, 2008, p.234). A continuación describiremos los procesos que se incluyen en esta gestión: 1. Planificar la Gestión de Riesgos Es el proceso por el cual se definen todas aquellas actividades para gestionar el riesgo en el proyecto. Figura 30: Planificar la Gestión de Riesgos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p 65 2. Identificar los Riesgos Es el proceso por el cual se identifican cuales son los riesgos que pueden afectar al proyecto y se documentan sus características. Según el PMI (2008): Identificar los Riesgos es un proceso iterativo debido a que se pueden descubrir nuevos riesgos o pueden evolucionar conforme el proyecto avanza a lo largo de su ciclo de vida. La frecuencia de iteración y quiénes participan en cada ciclo varía de una situación a otra (p. 241). Figura 31: Identificar los Riesgos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Realizar Análisis Cualitativo de los Riesgos Realizar Análisis Cualitativo de Riesgos es el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos (PMI, 2008, p.56). 64 66 Figura 32: Realizar Análisis Cualitativo de los Riesgos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Realizar Análisis Cuantitativo de los Riesgos Este proceso consiste en analizar numéricamente el efecto que puede causar los riesgos identificados sobre todos los objetivos generales del proyecto. Figura 33: Realizar Análisis Cuantitativo de los Riesgos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Planificar la Respuesta a los Riesgos Según el PMI (2008), este proceso consiste en: 65 67 Planificar la Respuesta a los Riesgos es el proceso por el cual se desarrollan opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Figura 34: Planificar la Respuesta a los Riesgos: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p Dar Seguimiento y Controlar el Trabajo del Proyecto Este proceso consiste en analizar, monitorear y regular el avance del proyecto con la finalidad de poder cumplir los objetivos de desempeño definidos en el plan para la dirección del proyecto, recopilando, midiendo y distribuyendo la información relativa al desempeño permitiendo posteriormente poder efectuar mejoras al proceso. Según el PMI (2008) el proceso consiste en: comparar el desempeño real del proyecto con respecto al plan para la dirección del proyecto; evaluar el desempeño para determinar la necesidad de una acción preventiva o correctiva y para recomendar aquéllas que se consideran pertinentes, identificar nuevos riesgos y analizar, revisar y monitorear los riesgos existentes del proyecto, para asegurarse de que se identifiquen los riesgos, se informe sobre su estado y se implementen los planes apropiados de respuesta a los riesgos, 66 68 mantener, durante la ejecución del proyecto, una base de información precisa y oportuna relativa al producto o a los productos del proyecto y su documentación relacionada, proporcionar la información necesaria para sustentar el informe de estado, la medición del avance y las proyecciones, proporcionar proyecciones que permitan actualizar la información relativa al costo y al cronograma actuales, y monitorear la implementación de los cambios aprobados cuando éstos se produzcan (p. 85). Figura 35: Monitorear y Controlar el Trabajo del Proyecto: Entradas, Salidas y Herramientas y Técnicas Fuente: PMI (2008) p.85 Gestión de Proyectos Predictiva En los años 50 en el ámbito militar surge la necesidad de profesionalizar la Gestión de Proyectos con el fin de abordar el desarrollo de sistemas complejos que involucraban un conjunto de equipos y disciplinas diferentes. A pasar de los años, la industria del automóvil siguió los pasos de la militar aplicando técnicas de Gestión de Proyectos para coordinar el trabajo, las áreas y los equipos. Surgen luego técnicas específicas como el cronograma, histograma, los conceptos de Ciclo de Vida del Proyecto o la descomposición en tareas (WBS Work Breakdown Structure). 6769 Definiendo la Gestión de Proyectos Predictiva, según Julio Palacio y Claudia Ruata (2009) dicen que: La gestión de proyectos predictiva o clásica es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles (p. 18). Aproximadamente en los años 80 se define que la Gestión de Proyectos debía cumplir ciertos objetivos para poder considerar un éxito el proyecto: Que el proyecto se ejecute en el tiempo planificado. No se debe de salir del presupuesto estimado. Satisfacer las necesidades del cliente. El producto posee las funcionalidades que se necesitan. Estas funcionalidades funcionan correctamente y sin errores. Las características de un proyecto predictivo son las siguientes: Establece como criterios de éxito: obtener el producto definido, en el tiempo previsto y con el coste estimado. Asume que el proyecto se desarrolla en un entorno estable y predecible. El objetivo de su esfuerzo es mantener el cronograma, el presupuesto y los recursos. Divide el desarrollo en fases a las que considera ciclo de vida, con una secuencia de tipo: concepto, requisitos, diseño, planificación, desarrollo, cierre (p. 19). En esa misma década de los 80, el ciclo de vida de los proyectos lo denominaban en Cascada. El proyecto se divide en fases ejecutándose estas secuencialmente: Definición del producto, diseño, construcción de elementos, integración y pruebas (Ver Figura N 36). 6870 Figura 36: Ciclo de vida secuencial o de cascada Fuente: SCRUM Manager Gestión de Proyectos (2011) p.35 Cada una de las fases que conforman el modelo de cascada la realiza un equipo, departamento o personas con distintas especialidades. Según Julio Palacio y Claudia Ruata (2009) mencionan que: La gestión de proyectos desarrolla modelos de estructuras organizativas de tipo matricial, con diferentes variaciones, para facilitar la comunicación y coordinación entre equipos diferentes. En las mismas fechas, a la par de la consolidación del conocimiento de gestión de proyectos, se estaban desarrollando las teorías de producción basada en procesos, promovidas por Michel Hammer, como mejor medio para garantizar la calidad, eficiencia y repetitividad (p. 35). 6971 El nuevo escenario en la gestión de Proyectos Una nueva forma de gestionar proyectos en entornos rápidos e inestables, comienza quizás en un estudio realizado por Hirotaka Takeuchi e Ikujijo Nonaka en 1986, el artículo tiene como nombre de The New New Product Development Game. Los autores de este artículo observaron que en algunas empresas no se aplicaban o ignoraban la teoría de la gestión de proyectos, empresas envueltas en ambientes muy competitivos relacionadas a productos de vanguardia tecnológica. Según Julio Palacio y Claudia Ruata (2009) en este artículo se dice que: Muchas compañías han descubierto que para mantenerse en el actual mercado competitivo necesitan algo más que los conceptos básicos de calidad elevada, costes reducidos y diferenciación. Además de esto, también es necesario velocidad y flexibilidad. En 1981 las encuestas realizadas a 700 empresas americanas revelan que el 30% de sus beneficios se debe a nuevos productos (p. 36). Hasta ese entonces los proyectos se desarrollaban en fases donde una dependía de la ejecución de la otra de manera secuencial. Este modelo y la nueva forma observada por Nonaka y Takeuchi en empresas que no aplicaban los principios de la gestión clásica de proyectos la podemos visualizar en la figura N 72 Figura 37: Producción con fases secuenciales o solapadas Fuente: SCRUM Manager Gestión de Proyectos p.36 Los desarrollos secuenciales puros suelen ser más teóricos que prácticos, y en realidad quienes los adoptan, generalmente producen ciclos secuenciales con solapamiento, donde una fase no suele necesitar para empezar que esté completamente terminada la anterior (Julio Palacio y Claudia Ruata, 2009, p. 36). Nonaka y Takeuchi al estudiar estas empresas americanas y japonesas de primera línea en tecnología, observaron que las mismas tenían ventajas en relación a sus competidores en rapidez e innovación, compartían las mismas pautas de trabajo comunes siendo estas ajenas al modelo clásico secuencial de la gestión de proyectos. Las compañías analizadas fueron Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M, Xerox y Hewlett-Packard, específicamente en el desarrollo de los siguientes 6 productos: La fotocopiadora Fuji-Xerox FX (1978) La copiadora personal Canon PC-10 (1982) El coche urbano de 1200cc de Honda (1981) 7173 El ordenador personal NEC PC 8000 (1979) La cámara Canon AE-1 (1976) Cámara Canon Auto Boy (1979). Según Julio Palacio y Claudia Ruata (2009), Nonaka y Takeuchi mencionan en su artículo que: El producto emerge de la interacción constante de un equipo de élite, multidisciplinario que trabaja conjuntamente desde el principio hasta el final (p. 36). Nonaka y Takeuchi compararon la forma de trabajar de estos equipos únicos y multi-disciplinarios, con los equipos de rugby, y el ambiente y entorno de trabajo que les proporcionaba la empresa lo llamaron Campo de Scrum ( Julio Palacio y Claudia Ruata, 2009, p.36) El Manifiesto Ágil En los años 90 algunos profesionales de la industria del software dejan de lado a la clásica gestión de proyectos predictiva y comienzan a adoptar los principios de agilidad que fueron identificados en la década anterior por Nonaka y Takeuchi. En marzo de 2001, 17 críticos de los modelos de mejora para el desarrollo de software basados en procesos, convocados por Kent Beck, que había publicado un par de años antes el libro "Extreme Programming Explained" (Beck, extreme Programming explained Embrace Change, 1999)en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre el desarrollo de software (Juan Palacio, 2007, p. 55). En esa reunión se asignó el término de Métodos Ágiles a lo que estaba surgiendo como alternativa de los modelos formales, (CMM-SW, SPICE, ETC) que los definían como pesados y muy rígidos debido a que tenían muchas normas y 72 74 fuertes dependencias de planificación muy detalladas siendo estas previas al desarrollo. Los integrantes de esa reunión, resumieron esto en 4 postulados llamándose Manifiesto Ágil, siendo estos los principios en que se basan estos métodos (Ver figura N 38). Figura 38: Manifiesto Ágil Fuente: Flexibilidad con Scrum (2008) p.56 Juan Palacio (2007), describe cada valor del manifiesto: Los individuos y su interacción por encima de los procesos y las herramientas. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero en trabajos que requieren conocimiento tácito, sin personas con conocimiento técnico y actitud adecuada, no producen resultados. 7375 Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la reingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan. Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación. Valoramos más el software que funciona que la documentación exhaustiva. Poder ver anticipadamente cómo se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto. El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascenden-tales para aportar valor al producto. Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto. Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a 7476 emplear a los documentos como barricadas entre departamentos o entre personas. Valoramos más la colaboración con el cliente que la negociación contractual. Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle al principio del proyecto, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retroinformación continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio del cliente. Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido imple-mentado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias de responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor. En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan. Valoramos más la respuesta al cambio que el seguimiento de un plan Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente el cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan. 7577 El Ciclo de Desarrollo Ágil En este tipo de desarrollo el equipo parte de una visión, del concepto general del producto y sobre la misma se van produciendo de forma continua incrementos del producto en la dirección de la visión, con un orden de prioridad establecido por el cliente. Estos ciclos breves son denominados como iteraciones y se ejecutan hasta que se decida no evolucionar más el producto. Este esquema se conforma por 5 fases que son las siguientes: 1- Concepto 2- Especulación 3- Exploración 4- Revisión 5- Cierre Según Julio Palacio y Claudia Ruata (2009), mencionan que estas fases se definen de esta forma: 1. Concepto: En esta fase se crea la visión del producto y se determina el equipo que lo llevará a cabo. Partir sin una visión genera esfuerzo baldío. La visión es un factor crítico para el éxito del proyecto. Se necesita tener el concepto de lo que se quiere, y conocer el alcance del proyecto. Es además una información que deben compartir todos los miembros del equipo 7678 2. Especulación: Una vez que se sabe qué hay que construir, el equipo especula y formula hipótesis basadas en la información de la visión, que per se es muy general e insuficiente para determinar las implicaciones de un desarrollo (requisitos, diseño, costes ). En esta fase se determinan las limitaciones impuestas por el entorno de negocio: costes y agendas principalmente, y se cierra la primera aproximación de lo que se puede producir. La gestión ágil investiga y construye a partir de la visión del producto. Durante el desarrollo confronta las partes terminadas: su valor, posibilidades, y la situación del entorno en cada momento. La fase de especulación se repite en cada iteración, y teniendo como referencia la visión y el alcance del proyecto consiste en: Desarrollo y revisión de los requisitos generales. Mantenimiento de una lista con las funcionalidades esperadas. Mantenimiento de un plan de entrega: fechas en las que se necesitan las versiones, hitos e iteraciones del desarrollo. Este plan refleja ya el esfuerzo que consumirá el proyecto durante el tiempo. En función de las características del modelo de gestión y del proyecto puede incluir también una estrategia o planes para la gestión de riesgos. Si las exigencias formales de la organización lo requieren, también se produce información administrativa y financiera. 3. Exploración: Se desarrolla un incremento del producto, que incluye las funcionalidades determinadas en la fase anterior. 7779 4. Revisión: Equipo y usuarios revisan lo construido hasta ese momento. Trabajan y operan con el producto real contrastando su alineación con el objetivo. 5. Cierre: Al llegar a la fecha de entrega de una versión de producto (fijada en la fase de concepto y revisada en las diferentes fases de especulación), se obtiene el producto esperado. Posiblemente éste seguirá en el mercado, y por emplear gestión ágil, es presumible que se trata de un producto que necesita versiones y mejoras frecuentes para no quedar obsoleto. El cierre no implica el fin del proyecto. Lo que se denomina mantenimiento supondrá la continuidad del proyecto en ciclos incrementales hacia la siguiente versión para ir acercándose a la visión del producto. (p. 44). Para poder visualizar este ciclo podemos ver la figura N 39. Figura 39: Ciclo de desarrollo ágil Fuente: Scrum Manager. Gestión de Proyectos (2011) p.44 7880 El Modelo de SCRUM La metodología ágil Scrum es un marco de trabajo para ejecutar prácticas ágiles en los desarrollos de proyectos. Su nombre nace de las observaciones realizadas por Nonaka y Takeuchi a mediados de los 80. El estudio de las prácticas observadas por Takeuchi y Nonaka fueron enfocadas en empresas de productos tecnológicos y a pesar de esto, también Scrum se emplea en entornos que trabajan requisitos que son inestables requirieron que exista flexibilidad y rapidez, siendo estas situaciones muy recurrentes en el desarrollo de Software. En 1995 Ken Schwaber presentó en OOPSLA 95 (Object-Oriented Programming Systems & Applications conference) (Schwaber, 1995), la implementación de Scrum Para software que él empleaba en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation (compañía que en los macrojuegos de compras y fusiones se integraría en VMARK, y luego en Informix y finalmente en Ascential Software Corporation)(Juan Palacio, Claudia Ruata)(Juan Palacio y Claudia Ruata, 2011, p. 59). A partir de entonces esta metodología ha venido evolucionando poco a poco y según Julio Palacio y Claudia Ruata (2011), mencionan que: Las implementaciones de Scrum para desarrollo de software se vienen enriqueciendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken (Schwaber, 1995). Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones ) el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o Epics de producto. La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc. (p. 59). En el año 2001 aparece la herramienta del gráfico Burndown, la estimación de tiempo por medio de póquer y el uso de tableros llamados kanban. 7981 Scrum es una metodología de desarrollo muy sencilla que no se basa en el seguimiento de un plan, sino en la adaptación continua del producto desarrollado en el proyecto, en su evolución. Esta metodología tiene como características lo siguiente: Antes de ser predictiva, es un modelo de desarrollo adaptable. Es orientado a las personas más que en los procesos. Se basa en un modelo de desarrollo incremental con iteraciones y revisiones periódicas. Como podemos ver, Scrum comparte los principios básicos del desarrollo ágil (Ver figura N 39). Parte de la visón del cliente acerca del producto, se construye el mismo aplicando el modelo incremental a través de iteraciones cortas que comprenden en fases de especulación, exploración y revisión. Estas iteraciones son llamadas Sprints y se repiten continuamente hasta que el cliente decide cerrar el desarrollo del producto. Según Juan Palacio y Claudia Ruata (2011) mencionan que: Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de negocio, y que pueden llevarse a cabo en un periodo de tiempo breve (según los casos pueden tener duraciones desde una semana hasta no más de dos meses). Cada uno de estos periodos de desarrollo es una iteración que finaliza con la entrega de una parte (incremento) operativa del producto. Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución en reuniones breves diarias donde todo el equipo revisa el trabajo realizado el día anterior y el previsto para el siguiente (p.59). 8082 Prácticas de SCRUM Scrum controla la evolución del proyecto de forma empírica y adaptable mediante el uso de las siguientes prácticas de la gestión ágil: 1. Revisión de las Iteraciones: Al finalizar cada una de las iteraciones (Sprint), se lleva a cabo una revisión entre todas las personas involucradas en el proyecto. Según Juan Palacio y Claudia Ruata (2011), dicen que: Es por tanto la duración del sprint, el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto (p. 60). 2. Desarrollo Incremental: Al final de cada iteración se dispone de una parte del producto de forma operativa que se puede inspeccionar y evaluar. 3. Desarrollo Evolutivo: Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos (Juan Palacio y Claudia Ruata, 2011, p. 60). El predecir al comenzar el proyecto, en las fases iniciales, como será el resultado final de la visión del producto, y sobre esto implementar el diseño y desarrollar la arquitectura del mismo, es muy alejado a la realidad donde las circunstancias obligarán rotundamente remodelar muchas veces lo que se predijo desde un principio y por lo tanto modificar cualquier cantidad de veces lo antes desarrollado. A partir de esto nace la siguiente pregunta, De que sirve predecir el cómo será la arquitectura final o el diseño del producto si constantemente cambia? De esta forma Scrum acepta la inestabilidad convirtiéndola en premisa adoptando técnicas que permite la evolución sin afectar negativamente la calidad de la arquitectura del producto donde la misma va evolucionando a medida que avanza el proyecto. 8183 Según Juan Palacio y Claudia Ruata (2011), mencionan que: Durante el desarrollo se genera el diseño y la arquitectura final de forma evolutiva. Scrum no los considera como productos que deban realizarse en la primera fase del proyecto. (El desarrollo ágil no es un desarrollo en fases)(p. 60). 4. Auto-organización: En la ejecución de un proyecto son muchos los factores impredecibles en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor de proyectos. En Scrum los equipos son auto-organizados (no auto-dirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas (Juan Palacio y Claudia Ruata, 2011, p60). 5. Colaboración: El utilizar práctica ágiles y el entorno de proyectos ágiles, facilita el trabajo en equipo, la colaboración entre los integrantes del mismo. Para que se pueda dar la auto-organización, los integrantes del equipo, tienen que colaborar en forma abierta con los demás, según las capacidades de cada uno y no según su rol o el puesto que dispongan dentro del proyecto. El Diagrama General de SCRUM En esta metodología, Sprint se le denomina a cada Iteración de desarrollo. La duración de cada Sprint lo determinarán las características del proyecto y las circunstancias del mismo, siendo este tiempo desde uno hasta dos meses aunque no se suele recomendar que se deba realizar más de un mes. El Sprint es el Núcleo central en que se basa el desarrollo iterativo e incremental (Ver figura N 40). 82 84 Figura 40: Diagrama de Scrum Fuente: Scrum Manager. Gestión de Proyectos (2011) p.60 Las Reuniones en Scrum Como hemos mencionado anteriormente, Sprint son las iteraciones que se van aplicando en el transcurso del desarrollo del producto. Planificación de Sprint: Antes del inicio de cada Sprints, se realiza una jornada de trabajo en las que se definen cuales van a ser los objetivos que se van a conseguir en el desarrollo de cada iteración. Seguimiento del Sprint: Son revisiones diarias en la que cada miembro del equipo describe tres cosas: 1. El trabajo que se realizó el día anterior. 2. El que se tiene previsto a realizar. 3. Lo que se necesita o aquellos impedimentos que son necesarios suprimir para realizar correctamente el trabajo. Cada persona actualiza en la pila del Sprint el tiempo pendiente en las tareas y posteriormente al tener esta información, se procede a actualizar 83 85 también el gráfico en la que el equipo monitoriza el avance del Sprint (burndown). Revisión del Sprint: Análisis y revisión del incremento generado sobre el producto. En la figura N 41 se puede visualizar esta serie de jornadas de trabajos. Figura 41: Las reuniones habituales en Scrum Fuente: Scrum Manager. Gestión de Proyectos (2011) p.61 Los Elementos Pila del producto (Product Baklog): Es la lista de requerimiento definida por el usuario partiendo de la visión inicial del producto en la cual crece y evoluciona durante el desarrollo. Pila del Sprint (Srpint Backlog): Es la lista de los trabajos que se deben de realizar en el sprint para así generar el incremento del desarrollo al finalizar cada iteración. Incremento: Es el resultado de cada Sprint. 8486 Los Roles en Scrum En el proyecto intervienen dos grupos de personas, las que están relacionadas directamente y las que están indirectamente. Estas se clasifican como los Comprometidos e implicados. Según Juan Palacio y Claudia Ruata (2011), indican que estos dos grupos se llaman frecuentemente en Scrum de la siguiente forma: En círculos de Scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa) cerdos y a los segundos gallinas. El origen de estos nombres es esta metáfora que ilustra de forma gráfica la diferencia entre compromiso e implicación con el proyecto: Una gallina y un cerdo paseaban por la carretera. La gallina preguntó al cerdo: Quieres abrir un restaurante conmigo?. El cerdo consideró la propuesta y respondió: Sí, me gustaría. Y cómo lo llamaríamos?. La gallina respondió: Jamón con huevos. El cerdo se detuvo, hizo una pausa y contestó: Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que tu estarías sólo implicada. (p. 61). Comprometidos (Cerdos): Propietario del producto Equipo Implicados (Gallinas): Otros Interesados. (Dirección General, Dirección comercial, Marketing Usuarios, etc) 8587 El Propietario del Producto: Es la persona responsable de que se logre el mayor valor del producto para los clientes, usuarios y del resto de los implicados, Equipo de Desarrollo: Grupo o grupos de trabajo que desarrollan el producto. Scrum Manager: Es el responsable de que la metodología funcione correctamente en la Organización. En la figura N 42 podemos ver una ficha que representa la metodología Scrum, sus elementos, reuniones y como es el flujo de trabajo 8688 Figura 42: Ficha Sinóptica de Scrum Fuente: Scrum Manager. Gestión de Proyectos (2011) p.64 8789 Prácticas relativas del PMBOK a las prácticas Ágiles Como se ha descrito anteriormente, el PMBOK es una guía de las mejores prácticas en relación a la Gestión de Proyectos y por tratarse de una guía, no se menciona que se deba aplicar alguna metodología en específico, sino más bien se aclara que cada Organización debe aplicar estas prácticas bajo su propio criterio. Como menciona en su artículo Michele Sliger (2006), dice que: Al igual que los autores del Capability Maturity Model (CMM), los profesionales en el estado de Project Management Institute (PMI) que el Consejo de Dirección de Proyectos (PMBOK) es una guía de mejores prácticas y las organizaciones que deben utilizar su propio criterio en la aplicación de las prácticas.esto es importante tener en cuenta, porque la asociación que muchos profesionales de TI tienen con el PMBOK es que aboga por la metodología de cascada, cuando en realidad no es así(párr. 1). Grupo de Procesos de la Gestión de Proyectos La primera traslación mencionada en el artículo de Michele Sliger, del PMBOK en relación a los grupos de procesos con el marco de trabajo de la Gestión Ágil descrita por Jim Highsmith es la Gestión del Ciclo de Vida. El PMBOK define este conjunto de procesos como procesos de Iniciación, de Planificación, Ejecución, Control y Cierre. Para el marco de trabajo de la Gestión Ágil se pueden ver como la fase de Imaginar la cual consiste en la visión del producto, la fase de Especulación se traduce como la transformación de la visión en un conjunto de características enmarcadas en un tiempo de desarrollo, indicando el tiempo de entrega de estas características, la fase de Explorar, la cual se traduce en la fase que es Iterativa y el desarrollo Incremental del producto potencialmente entregable, la fase de Adaptación en la que se adaptan todas aquellas características del producto pasando nuevamente por la fase de Especulación y finalmente la fase de Cierre en la que el equipo tiene la oportunidad de reflexionar sobre los logros y tomar decisiones basadas en el aprendizaje. Esta translación la podemos ver en la figura N90 Figura 43: Grupo de Procesos del PMBOK referenciados con el marco de trabajo de la Gestión Ágil de Jim Highsmith Fuente: Michele Sliger (2006) Áreas de Conocimiento y la Gestión Ágil Micele Sliger (2006) en su artículo menciona que: Una traducción más de algunas de las actividades realizadas en cada fase, es de importancia tomarle atención. Seis áreas clave de la Gestión del Conocimiento en las que se definen en el PMBOK y merecen la atención especial, es la Integración del Proyecto de Gestión, Gestión de Proyectos y Gestión de Alcance del Tiempo del Proyecto, Gestión de la Calidad del Proyecto y Gestión de Riesgos del Proyecto y Gestión de Recursos Humanos. Para cada una de estas áreas, las prácticas defendidas por el PMBOK tienen sus primos en ágiles, pero son muy diferentes en su aplicación (párr. 3). Gestión de Integración En el artículo de Michelle Sliger, se menciona que: 8991 Un resultado clave en la gestión de la integración es el documento del plan de proyecto, siendo este preparado y propiedad del gerente del proyecto. En el desarrollo ágil de software, con su énfasis en el diseño de justo a tiempo y toma de decisiones participativa, esta actividad se traduce en varias pero en diferentes fases de la fase de Imaginación y en diferentes ejercicios de planificación que se realiza de forma iterativa. En lugar de definir todos los elementos de un plan de proyecto en el inicio del proyecto, el alcance, la estructura de desglose del trabajo, el horario, las hipótesis y los controles, el director del proyecto ágil se centrará en la planificación con un nivel de detalle que es más apropiado y realistas para el horizonte de tiempo. La gestión de proyectos en cascada, se traduce en la planificación continua ágil, donde a groso modo las características y las estimaciones se define en el comienzo de una liberación y una planificación más detallada de las tareas y el esfuerzo se hace al comienzo de cada iteración semana 1-4.El gran esfuerzo por adelantado, la documentación que se fue mano a mano con la planificación también se redujo drásticamente, y las ceremonias, la documentación apropiada para el tipo y número de los nodos de comunicación en cuestión, es aceptado en su lugar. Las pocas ceremonias, o de baja tecnología de la liberación de documentación ágiles y planes de iteración puede consistir en varios pizarrones blancos en una sala de guerra con las marcas de colores, o puede ser rotafolio de papel pegadas a la pared con brillantes notas de color en cada uno (párr. 4). Al igual que el Plan de Salida que indica la fecha esperada del lanzamiento y las características a trabajar, el Plan de las Iteraciones indica el nivel de esfuerzo en la ejecución del conjunto de características dentro de la definición enmarcada del tiempo estableciéndose esto en la planificación de reuniones con todo el equipo. Planes de liberación, los planes de iteración, y otros productos de planificación de las fases de imaginar y la especulación se comparten con todos los interesados de la forma más llamativa posible. Para integrantes del equipo que no están en el mismo lugar de trabajo, esto puede significar algo tan simple como poner el plan en la pared. Las soluciones técnicas para la comunicación son necesarias para equipos geográficamente dispersos, SharePoint, wikis y otras herramientas de 9092 terceros están bien equipadas para proporcionar esto. Los gerentes de proyecto van desde escribir un documento de gran tamaño, que determinen el plan para todo el proyecto, para facilitar al equipo en sus esfuerzos de planificación iterativa y compartir esta información en la forma más visible (Michele Sliger, 2006, párr. 5). Michele Sliger (2006) menciona que: Control integrado de cambio también cambia dramáticamente en metodologías ágiles. De acuerdo con la idea de proceso mínimo para conseguir el máximo valor, el proceso de cambio de control es más eficaz e integrada en la rutina diaria de los equipos ágiles. El cambio de producto se gestiona a través de la acumulación ordenada de funciones. Esta cartera de productos está gestionado por el cliente o el cliente proxy (gerente de producto, experto en la materia), que es responsable de mantener la lista de temas que se trabajó, con las características que ofrecen el mayor valor de negocio a los clientes mejor clasificados (párr. 6). Este Backlog contiene los elementos más allá de la funcionalidad de las solicitudes, el trabajo técnico de apoyo y los defectos también se colocan en el atraso y el puesto. Durante la liberación y la iteración, el mayor movimiento de elementos clasificados en la cartera de las iteraciones ha de ser codificados, probado y aceptado por el cliente. Durante la iteración, diaria de 15 minutos de pie se realizan reuniones para informar a todos los demás del estado, un elemento clave de comunicación que mantiene el equipo en sincronía y con mayor capacidad para hacer frente a imprevistos. Al final de cada iteración, el código de trabajo que se ha desarrollado se demuestra, y la retroalimentación que pueden afectar las decisiones futuras sobre los elementos de la cartera de pedidos y la clasificación se obtiene de las partes interesadas. Cambios en el proceso también se hacen al final de las iteraciones, lo que permite al equipo hacer correcciones de rumbo no sólo en el producto, sino también en la forma de trabajar. El equipo - administrador de cliente, desarrollador, probador, analista, escritor técnico, y el proyecto - se convierte en el equivalente de un tablero de control de cambios. Que agilizar el proceso para 9193 que las decisiones se toman rápidamente, en colaboración, y con poca o ninguna ceremonia (Michele Sliger, 2006, párr. 8.). Gestión de Alcance y del Tiempo En estas Áreas del Conocimiento, Michele Sliger, menciona que: "El arrastramiento del alcance" siempre ha sido la perdición de los directores de proyectos tradicionales. Necesidades en constante cambio en respuesta a las necesidades empresariales del cliente, los cambios en la industria, los avances en la tecnología, y las cosas que se aprendieron durante el proceso de desarrollo. La planificación de alcance, definición, verificación y control son todas las áreas de conocimiento que se les da una gran atención en el PMBOK. Estas áreas de atraer la atención de grandes metodologías ágiles también, pero la filosofía en el ámbito de la gestión es totalmente diferente. Plan impulsado por los enfoques de trabajo para evitar cambios en el alcance, mientras que los enfoques ágiles tratan de esperar y aceptar el cambio del alcance. La estrategia ágil para fijar el costo y horario y luego trabajar para implementar las funcionalidades de alto valor definido por el cliente, de modo que alcance sigue siendo flexible. Esto se contrasta contra un enfoque en cascada, donde las características (alcance) en primer lugar se definen en detalle, llevando el costo y el calendario. Agile simplemente dio la vuelta al triángulo (Michele Sliger, 2006, párr. 1). Esto se puede visualizar en la figura N 44 92 94 Figura 44: Cascada versus ágil: El cambio de paradigma Fuente: Michele Sliger (2006) El proyecto de "caja" que se utiliza es una cuestión de tiempo. Sin embargo, en lugar de llenar de características de "ladrillos" en una sola caja débil hasta que sobrepasa la línea de tiempo, usamos líneas de tiempo múltiples de acero y dejar de añadir ladrillos, cuando la caja está llena. Entonces la caja es "candado" para que la iteración y sólo las características de la caja (iteración) se trabajen a través de la aceptación. Pero debido a que estamos haciendo esta caja de carga y echar el candado a una iteración a la vez, es difícil entender la cantidad de trabajo que se completará en un plazo más largo. Ágil utiliza técnicas como la planificación de lanzamiento para estimar lo que ese período de tiempo más largo podría ser similar (Michele Sliger, 2006, párr. 2.). Las prácticas del PMBOK de definición del alcance, la estructura de desglose del trabajo (WBS) la creación, y la verificación del alcance se producen en forma iterativa ágil. Durante la planificación de entregas, las funciones se definen en un nivel muy alto y se coloca en iteraciones en orden de prioridad. En este punto, la WBS no sólo tiene resultados, los paquetes de trabajo. Estas características, o resultados, se pueden estimar en un nivel bruto solamente. Una vez que se inicia la iteración, las funciones programadas para esa iteración - y sólo esa iteración - se elaboran. Piense en ello como la elaboración just-in-time que impide la 93 Mostrar más
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 GESTION DE PROYECTOS SEGÚN LA GUIA DEL PMBOK
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 3 - PROCESOS DE LA DIRECCIÓN DE PROYECTOS
PROCESOS DE LA DIRECCIÓN DE PROYECTOS La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del Más detalles RESUMEN de la GESTIÓN de PROYECTOS
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 COMPILACION BIBLIOGRAFICA PMBOK - OPM3. Presentado por: LAURA MARCELA GIRALDO HOYOS Cód.: 1700622521
COMPILACION BIBLIOGRAFICA PMBOK - OPM3 Presentado por: LAURA MARCELA GIRALDO HOYOS Cód.: 1700622521 UNIVERSIDAD DE CALDAS INGENIERÍA DE SISTEMAS Y COMPUTACIÓN Manizales, septiembre de 2010 COMPILACION Más detalles 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 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
16-0079 / 29-0952 FORMULACIÓN PROYECTOS Descripción General: Provee una introducción que abarca el ciclo de vida completo del desarrollo de un proyecto, desde que se concibe en los niveles más altos de Más detalles Tracción PM! PMBOK. Organización del texto
PMBOK Organización del texto El libro de texto La Guía del PMBOK es el estándar global para administración de proyectos. Representa las prácticas que son generalmente reconocidas como las mejores en la Más detalles 1. PROCESOS DEL PROJECT MANAGEMENT
INDICE 1. PROCESOS DEL PROJECT MANAGEMENT 1.1 Procesos del Proyecto 1.2 Grupos de Proceso 1.3 Interacciones del Proceso 1.4 Adaptación de las interacciones del proceso 2. AREAS DEL CONOCIMIENTO DEL PROJECT Más detalles Ingeniería del So=ware II
Ingeniería del So=ware II Tema 03. Fundamentos de Ges1ón de Proyectos Juan Hernández Marqués DPTO. DE MATEMÁTICAS, ESTADÍSTICA Y COMPUTACIÓN juan.hernandez@unican.es Este tema se publica bajo Licencia: Más detalles 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 Ges0ón de Proyectos So7ware
Ges0ón de Proyectos So7ware Tema 1. Fundamentos Carlos Blanco Bueno Félix Óscar García Rubio Este tema se publica bajo Licencia: Crea5ve Commons BY- NC- ND 4.0 Objetivos Conocer los conceptos básicos de 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 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 IMPLEMENTACIÓN DE INDICADORES DE GESTIÓN PARA EL CONTROL DE COSTOS Y DE TIEMPO BAJO LA METODOLOGÍA DEL PMI EN UN PROYECTO DE CONSTRUCCIÓN
IMPLEMENTACIÓN DE INDICADORES DE GESTIÓN PARA EL CONTROL DE COSTOS Y DE TIEMPO BAJO LA METODOLOGÍA DEL PMI EN UN PROYECTO DE CONSTRUCCIÓN SANTIAGO VARGAS RESTREPO UNIVERSIDAD EAFIT ESCUELA DE INGENIERÍA 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 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 PREPARACIÓN PARA LA CERTIFICACION PROJECT MANAGEMENT PROFESSIONAL PMP, CAMP CERTIFIED ASSOCIATE IN PROJECT MANAGEMENT DEL PMI PMBOK 5TA EDICIÓN.
Programa de Formación de Auditores Sistemas de Gestión de la Calidad Módulo 2 Sistema de Gestión de la Calidad Requisitos Objetivo del módulo Comprender: Los requisitos de la norma ISO 9001:2008 para el Más detalles 5.1 Planificación del Alcance
5.1 Planificación del Alcance Procesos de un Área de Conocimiento Iniciación Planificación Ejecución Seguimiento y Control Cierre 4. Gestión de la Integración de s 4.1 Desarrollar el Acta de Constitución Más detalles 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 Taller de Secretos para Dominar la Gestión de Riesgos en Proyectos
Taller de Secretos para Dominar la Gestión de Riesgos en Proyectos Desarrollado por la reconocida autora Lic. Liliana Buchtik, PMP, PMI-RMP autora del libro Secretos para Dominar la Gestión de Riesgos Más detalles 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 UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) METODOLOGÍA PARA ADMINISTRAR PROYECTOS DE TECNOLOGÍA BASADOS EN ARQUITECTURA ORIENTADA A SERVICIOS
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) METODOLOGÍA PARA ADMINISTRAR PROYECTOS DE TECNOLOGÍA BASADOS EN ARQUITECTURA ORIENTADA A SERVICIOS JEFFRY AGÜERO CORDERO PROYECTO FINAL DE GRADUACION Más detalles UNIVERSIDAD NACIONAL DE INGENIERÍA CENTRO DE EXTENSIÓN Y PROYECCIÓN SOCIAL AREA DE CURSOS DE ESPECIALIZACIÓN EN TECNOLOGÍAS DE LA INFORMACIÓN
UNIVERSIDAD NACIONAL DE INGENIERÍA TALLER DE PREPARACIÓN PARA CERTIFICACIÓN EN DIRECCIÓN DE PROYECTOS PMP CERTIFICA ORGANIZA Mayor Información: informes@uni.edu.pe Visite Nuestra Web http://www.ceps.uni.edu..pe Más detalles Curso. Introducción a la Administracion de Proyectos
Curso Introducción a la Administracion de Proyectos Tema 5 Procesos del área de Integración INICIAR PLANEAR EJECUTAR CONTROL CERRAR Desarrollar el Acta de Proyecto Desarrollar el Plan de Proyecto Dirigir Más detalles 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 DIRECCIÓN DE PROYECTOS. GESTIÓN AVANZADA DE PROYECTOS DESDE LA PERSPECTIVA DEL Project Management Institute (PMI)
DIRECCIÓN DE PROYECTOS. GESTIÓN AVANZADA DE PROYECTOS DESDE LA PERSPECTIVA DEL Project Management Institute (PMI) Objetivos Curso preparatorio del examen de Certificación de Project Management Professional Más detalles Seminario de Certificación CAPM
Seminario de Certificación CAPM Revisa a detalle los componentes de los procesos de dirección de proyectos de cada una de las áreas de conocimiento contenido en el A Guide to the Project Management Body Más detalles El documento consiste en un resumen de los tres primeros capítulos de cada uno de los siguientes estándares:
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 Cómo Puede Ser Usada la Dirección de Proyectos en TU Sin fines de lucro
Cómo Puede Ser Usada la Dirección de Proyectos en TU Sin fines de lucro Ing. Mónica González, MBA, PMP Liaison PMIEF 1 Cómo Puede Ser Usada la Dirección de Proyectos en TU Sin fines de lucro Este programa Más detalles Diplomado Gestión de proyectos TI
2015 Diplomado Gestión de proyectos TI Escuela de Administración y Negocios Duoc UC Educación continua w w w. d u o c. c l / e d u c a c i o n c o n t i n u a Diplomado Gestión de proyectos TI Escuela Más detalles UNIVERSIDAD CATÓLICA ANDRÉS BELLO VICERRECTORADO ACADÉMICO ÁREA DE INGENIERÍA DIRECCIÓN DE POSTGRADO ESPECIALIDAD EN SISTEMA DE LA CALIDAD
UNIVERSIDAD CATÓLICA ANDRÉS BELLO VICERRECTORADO ACADÉMICO ÁREA DE INGENIERÍA DIRECCIÓN DE POSTGRADO ESPECIALIDAD EN SISTEMA DE LA CALIDAD TRABAJO ESPECIAL DE GRADO PROPUESTA DE UN SISTEMA DE GESTIÓN DE Más detalles 5 La Gerencia de Proyectos
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
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 Resumen del Contenido del Examen PMP
Resumen del Contenido del Examen PMP Tareas Dominio I Inicio del Proyecto - 13 % Realizar una valoración del proyecto basada en la información disponible, mediante reuniones con el patrocinador, el cliente, Más detalles PROGRAMA DE FORMACIÓN CERTIFICACIÓN PMP alineada con el PMBOK 5th
Diplomado Administración de proyectos: Preparación para el examen de certificación PMP Duración 164 horas Objetivo general: Este diplomado proporciona los conocimientos, técnicas y herramientas necesarias Más detalles APLICACIÓN DE LA GUIA DEL PMBOK EN EL DESARROLLO DE UN PROYECTO EDUCATIVO
UNIVERSIDAD RICARDO PALMA FACULTAD DE INGENIERIA ESCUELA ACADEMICA PROFESIONAL DE INGENIERIA CIVIL APLICACIÓN DE LA GUIA DEL PMBOK EN EL DESARROLLO DE UN PROYECTO EDUCATIVO TESIS PARA OPTAR EL TITULO PROFESIONAL Más detalles GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN EN UNA EMPRESA DE CONSUMO MASIVO
UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS DE POSTGRADO COORDINACIÓN DE POSTGRADO EN GERENCIA ESPECIALIZACIÓN EN GERENCIA DE PROYECTOS TRABAJO ESPECIAL DE GRADO GESTIÓN DE PROYECTOS DE TECNOLOGÍAS Más detalles GUÍA AVANZADA DE GESTIÓN DE PROYECTOS
GUÍA AVANZADA DE GESTIÓN DE PROYECTOS Laboratorio Nacional de Calidad del Software Mayo 2009 NOTA DE EDICIÓN Esta guía ha sido desarrollada por el Laboratorio Nacional de Calidad del Software de INTECO. Más detalles Universidad Autónoma de Manizales Departamento de Ciencias Computacionales
Universidad Autónoma de Manizales Departamento de Ciencias Computacionales ASIGNATURA CÓDIGO 103118 NÚMERO DE CRÉDITOS 2 Trabajo Presencial 3 PRERREQUISITOS Trabajo dirigido PERIODO ACADÉMICO 2014-1 Gerencia Más detalles Aplicación de la norma ISO 9001 para la mejora de la gestión: el caso de la. Dirección del Sistema Nacional de Capacitación del Instituto Nacional de
Aplicación de la norma ISO 9001 para la mejora de la gestión: el caso de la Dirección del Sistema Nacional de Capacitación del Instituto Nacional de Administración Pública Mg. Marcelo Calavia Introducción Más detalles de Proyectos Instructor:
Gerencia de de Proyectos Parte I Instructor: Ing. Guillermo Muñoz R. MBA, CRM Ficha Curricular Prof. Guillermo Muñoz Ingeniero industrial (1980) y Magister en Administración de Empresas, mención finanzas Más detalles GESTIÓN DE PROYECTOS CON PMBOK 5º EDICIÓN
GESTIÓN DE PROYECTOS CON PMBOK 5º EDICIÓN Curso oficial reconocido por PMI. Cibertec ha sido reconocido como Centro de Entrenamiento Oficial por PMI. 1. Qué es un Proveedor Registrado de Educación de PMI Más detalles La Oficina de Proyecto PMO aporta valor? Basado en el estudio el Valor de las PMO realizado por Deloitte y Universidad Santa María
La Oficina de Proyecto PMO aporta valor? Basado en el estudio el Valor de las PMO realizado por Deloitte y Universidad Santa María Conferenciante Ingeniero Informático, U de Chile, Diploma en Finanzas Más detalles Introducción. 1 No incluye los derechos del examen de certificación.
Introducción Curso de preparación para la acreditación como Project management professional (PMP) por el Project Management Institute (PMI). La certificación PMP (Project management professional) emitida Más detalles Sistemas de Aseguramiento de la calidad y Normas ISO 9000
Sistemas de Aseguramiento de la calidad y Normas ISO 9000 Métodos de Mejora de la Calidad Sumario Sistema de aseguramiento de la calidad ISO 9000:94, estandarización de SAC Diferencias TQM vs. ISO 9000:94 Más detalles Etapas y Áreas de Conocimiento en la Gestión de Proyectos
Etapas y Áreas de Conocimiento en la Gestión de Proyectos Curso 2009-2010 Etapas y Áreas de Conocimiento La metodología PMBOK consta de varios procesos, que se pueden agrupar por: Etapas: Indican orden Más detalles 4.- PM Curso de Certificación para obtener el Grado PMP-CAPM: Project Management Professional-Certified Associate in Project Management (36 Hrs)
4.- PM Curso de Certificación para obtener el Grado PMP-CAPM: Project Management Professional-Certified Associate in Project Management (36 Hrs) Introducción La gestión de proyectos se ha llevado a cabo, Más detalles Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas
Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción 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 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 UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS
UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERÍA DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS CARRERA DE INGENIERÍA DE SISTEMAS SISTEMA DE GESTION DE REQUERIMIENTOS DE SOFTWARE PROYECTO Más detalles ISO y la serie de Normas ISO 9000
ISO y la serie de Normas ISO 9000 La International Organization for Standardization (ISO) es la agencia internacional especializada para la estandarización, abarcando actualmente los cuerpos nacionales Más detalles LOS INDICADORES DE GESTIÓN
LOS INDICADORES DE GESTIÓN Autor: Carlos Mario Pérez Jaramillo Todas las actividades pueden medirse con parámetros que enfocados a la toma de decisiones son señales para monitorear la gestión, así se asegura Más detalles GESTIÓN DE LA CALIDAD EN PROYECTOS DE INVESTIGACIÓN Y DESARROLLO: Un estudio de caso.
GESTIÓN DE LA CALIDAD EN S DE INVESTIGACIÓN Y DESARROLLO: Un estudio de caso. Santa María, Delia Susana* 1, García, Beatriz 1,2 1 ITeDA-Mendoza. CNEA Cuyo Figueroa Alcorta 122, 5501 Godoy Cruz, Mendoza, Más detalles Plan de Implantación del Sistema de Gestión de Calidad para los Servicios de Información Aeronáutica -1-
Plan de Implantación del Sistema de Gestión de Calidad para los Servicios de Información Aeronáutica -1- Plan de Implantación del Sistema de Gestión de Calidad para los Servicios de Información Aeronáutica Más detalles CURSO INTENSIVO DE INTRODUCCÓN A LA DIRECCIÓN / GESTIÓN DE PROYECTOS y CURSO DE PREPARACION INTENSIVA EXAMEN PMP / CAPM (52 HORAS) PARTE 1
Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el Más detalles Curso de Preparación para la Certificación PMP -PMI
Certificación PMP -PMI - Incluye las guías actualizadas del PMBOK de la 4ª y 5ª edición - > Calidad en Contenidos y Metodología > Formación Online sin barreras > 100% Bonificable, Gestionamos todos los Más detalles GESTIÓN DE TIC. Gestión de Proyectos con Microsoft Project Professional 2013
Las Tecnologías de la Información y Comunicaciones (TIC) son actualmente un factor clave en las organizaciones que les permite mantener su competitividad en un mundo cada vez mas globalizado. En la actualidad Más detalles Gestión del Alcance del Proyecto
pm4dev, 2009 serie de gerencia para el desarrollo Gestión del Alcance del Proyecto GERENCIA DE PROYECTOS PARA ORGANIZACIONES DE DESARROLLO GERENCIA DE PROYECTOS PARA ORGANIZACIONES DE DESARROLLO Una metodología Más detalles 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 Sistemas de gestión de la calidad Requisitos
Sistemas de gestión de la calidad Requisitos 0 Introducción Generalidades La adopción de un sistema de gestión de la calidad debería ser una decisión estratégica de la organización. El diseño y la implementación Más detalles DESARROLLO DE UNA PROPUESTA PARA MEJORAR LA GESTION DEL TIEMPO DE LOS PROYECTOS DE DIGITALIZACION
UNIVERSIDAD CATOLICA ANDRES BELLO DIRECCION GENERAL DE LOS ESTUDIOS DE POSTGRADO AREA DE CIENCIAS ADMINISTRATIVAS Y DE GESTION POSTGRADO EN GERENCIA DE PROYECTOS DESARROLLO DE UNA PROPUESTA PARA MEJORAR Más detalles GESTIÓN DE TIC. Desarrollar tus competencias y habilidades en Gestión de Proyectos bajo los estándares del PMBOK 5ta.
Las Tecnologías de la Información y Comunicaciones (TIC) son actualmente un factor clave en las organizaciones que les permite mantener su competitividad en un mundo cada vez mas globalizado. En la actualidad Más detalles Fase de Planeación. Unidad
Fase de Planeación. Unidad 2 Una etapa primordial en la gestión de un proyecto es la Planeación. Durante ésta se realizan actividades para estimar costos y recursos asegurando que el proyecto satisfaga Más detalles Diplomado Administración de proyectos: Preparación para el examen de certificación PMP
Diplomado Administración de proyectos: Preparación para el examen de certificación PMP Duración 164 horas Objetivo general: Este diplomado proporciona los conocimientos, técnicas y herramientas necesarias Más detalles ISO 9000 ISO 9001 (2015) ISO 9001 (2015) Requisitos para los Sistemas de Gestión de la Calidad
«N o m b r e _ O r g a n i z a c i ó n _ C O M P L E T O» ISO 9001 (2015) ISO 9000 ISO 9001 (2015) Requisitos para los Sistemas de Gestión de la Calidad Interpretación libre de ISO/DIS 9001:2015 Tabla Más detalles Master en Gestion de la Calidad
Master en Gestion de la Calidad Implantacion Sistema de Gestion de Calidad Implantacion de Sistemas de Gestion de Calidad 1 / 14 OBJETIVOS Al finalizar esta unidad didáctica será capaz: Conocer los pasos Más detalles Grupo de procesos de Planificación
Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Cuarta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje Más detalles NORMA ISO 9001:2008 Sistemas de Gestión de la Calidad - ÍNDICE. 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación.
TEMA ÍNDICE PÁGINA 1 Objeto y campo de aplicación 3 1.1 Generalidades 3 1.2 Aplicación. 3 2 Referencias normativas. 3 3 Términos y definiciones.. 3 4 Sistema de gestión de la calidad. 4 4.1 Requisitos Más detalles PLANEAMIENTO ESTRATÉGICO E INDICADORES
PLANEAMIENTO ESTRATÉGICO E INDICADORES CASO CORPORACIÓN JOSE R. LINDLEY La Corporación José R. Lindley constituye uno de los casos más interesantes de planeamiento estratégico e implementación de indicadores Más detalles Proyectos Cuatrimestrales Multidisciplinares (PCM) TUVCH. Manual Básico. II.3.- Cómo participa el PCM en la calificación final de cada asignatura
Proyectos Cuatrimestrales Multidisciplinares (PCM) TUVCH Manual Básico I. Introducción Qué son y cuál es el propósito de los PCM. II. Operación y procedimiento de los PCM en el TUVCH II.1- Cómo operan Más detalles Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008
Sistemas de Gestión n de la Calidad - Requisitos UNE - EN ISO 9001:2008 ISO 9001 CUATRO CAPÍTULOS BÁSICOS RESPONSABILIDADES DE LA DIRECCIÓN P D GESTIÓN DE RECURSOS REALIZACIÓN DEL PRODUCTO A C MEDICIÓN Más detalles LA GESTIÓN DE PROYECTOS UNA NECESIDAD EN LOS PROGRAMAS ACADÉMICOS DE LAS INSTITUCIONES DE EDUCACIÓN SUPERIOR (IES) DEL NORTE DE SANTANDER
LA GESTIÓN DE PROYECTOS UNA NECESIDAD EN LOS PROGRAMAS ACADÉMICOS DE LAS INSTITUCIONES DE EDUCACIÓN SUPERIOR (IES) DEL NORTE DE SANTANDER Ing. María del Pilar Rojas Puentes MAP pilarrojas@ufps.edu.co Universidad Más detalles ELABORACION DE UN MODELO PARA LA PLANEACION DE LA EJECUCION DE CONTRATOS DE CONSTRUCCIÓN DE OBRAS PÚBLICAS BAJO LA GUIA METODOLÓGICA P.M.
ELABORACION DE UN MODELO PARA LA PLANEACION DE LA EJECUCION DE CONTRATOS DE CONSTRUCCIÓN DE OBRAS PÚBLICAS BAJO LA GUIA METODOLÓGICA P.M.I. (PROJECT MANAGEMENT INSTITUTE) JOSÉ LUIS GUZMÁN ARTEAGA UNIVERSIDAD Más detalles PROGRAMA DE PREPARACIÓN PARA LA CERTIFICACIÓN PMP DEL PROJECT MANAGEMENT INSTITUTE
Curso de gestión de proyectos PMI orientado a obtener la certificación PMP CONTENIDO TEMATICO Y DOCENTES JUSTIFICACION En el mundo moderno existen empresas que ejecutan sus actividades bajo el esquema Más detalles MANUAL DE REFERENCIA
Ejemplo Manual de la Calidad www.casproyectos.com ELABORADO POR: REPRESENTANTE DE LA DIRECCION APROBADO POR: GERENTE GENERAL 1. INTRODUCCIÓN Nuestra organización, nació en el año XXXXXXXXX, dedicada a Más detalles Presentada por: KENNY Carina & GRANIERI Marcelo
Presentada por: KENNY Carina & GRANIERI Marcelo IT PMO Molinos Rio de la Plata IT PMO ICBC Argentina Aclaración: Todos los derechos reservados. No está permitida la reproducción parcial o total del material Más detalles Gestión de Riesgos en Proyectos
GRUPO VISIÓN PROSPECTIVA MÉXICO 2030 Gestión de Riesgos en Proyectos Mauricio Jessurun Solomou mjess@unisolmexico.com Luis Miguel Arroyo lmarroyoi@emsi.com.mx Julio, 2015 Gestión de Riesgos en Proyectos Más detalles CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO. 6.1. Estructura Detallada del Trabajo (EDT)
CAPITULO VI: ADMINISTRACIÓN DEL PROYECTO 6.1. Estructura Detallada del Trabajo (EDT) Un EDT es la agrupación orientada a entregables de los elementos del proyecto que organiza y define el total de los Más detalles GUÍA METODOLÓGICA PARA LA ELABORACIÓN DE PROYECTOS DE CONSTRUCCIÓN BAJO EL ESTÁNDAR ISO 9001:2008 Y LOS FUNDAMENTOS DEL PMBOK.
GUÍA METODOLÓGICA PARA LA ELABORACIÓN DE PROYECTOS DE CONSTRUCCIÓN BAJO EL ESTÁNDAR ISO 9001:2008 Y LOS FUNDAMENTOS DEL PMBOK. LAURA STEPFANIE MARTÍNEZ ANAYA MARIA CAMILA ORTIZ NORIEGA UNIVERSIDAD INDUSTRIAL Más detalles MAESTRÍA EN GERENCIA DE PROYECTOS TEC-2016
MAESTRÍA EN GERENCIA DE PROYECTOS TEC-2016 INFORMACION GENERAL El programa se caracteriza por ser una Maestría Profesional en Gerencia de Proyectos, impartido por el Área Académica de Gerencia de Proyectos, Más detalles VENTAJAS DE ADOPTAR EL MODELO DE GERENCIAMIENTO DE PROYECTOS DEL PMI EN ISA
VENTAJAS DE ADOPTAR EL MODELO DE GERENCIAMIENTO DE PROYECTOS DEL PMI EN ISA Oswaldo Vélez Caballero Ejecutivo Clientes Dirección Gestión Integral del Negocio ISA - Colombia ojvelez@isa.com.co Categoría Más detalles ADMINISTRACIÓN ÁGIL DE PROYECTOS. 21 HORAS (21 horas de capacitación son las requeridas por el PMI para optar por la Certificación Ágil de Proyectos)
ADMINISTRACIÓN ÁGIL DE PROYECTOS 21 HORAS (21 horas de capacitación son las requeridas por el PMI para optar por la Certificación Ágil de Proyectos) Dictada en alianza con Alpha Consultoría (México). Este Más detalles PRINCE2 & TickIT. Jorge Armando Medina Morales. Código 1700321660. U n i v e r s i d a d D e C a l d a s. F a c u l t a d D e I n g e n i e r í a s
PRINCE2 & TickIT Jorge Armando Medina Morales Código 1700321660 U n i v e r s i d a d D e C a l d a s F a c u l t a d D e I n g e n i e r í a s I n g e n i e r í a D e S i s t e m a s O c t u b r e 2010 Más detalles UTILIZANDO BPM PARA IMPLEMENTAR METODOLOGIA DE GESTION DE PROYECTOS EN BASE AL PMBOK
UTILIZANDO BPM PARA IMPLEMENTAR METODOLOGIA DE GESTION DE PROYECTOS EN BASE AL PMBOK Ing. Juan Carlos Torres Vela, PMP, CBAP, ITIL Global Project Management Acerca del Autor Ing. Juan Carlos Torres Vela, Más detalles 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 PERFIL DEL LIDER DE PROYECTO
PERFIL DEL LIDER DE PROYECTO CONSULTORIA ESPECIALIZADA PARA INCUBAR LA IMPLEMENTACION DE UNA OFICINA DE GERENCIA DE PROYECTOS PROJECT MANAGEMENT OFFICE PMO EN EL INP RESUMEN Este documento describe cual Más detalles NORMA TÉCNICA NTC- ISO COLOMBIANA 9001
NORMA TÉCNICA NTC- ISO COLOMBIANA 9001 2008-11-14 SISTEMA DE GESTIÓN DE LA CALIDAD. REQUISITOS E: QUALITY MANAGEMENT SYSTEMS. REQUIREMENTS CORRESPONDENCIA: esta norma es idéntica (IDT) a la norma ISO 9001:2008 Más detalles GESTIÓN DE PROYECTOS DE SOFTWARE

References: in fine
 resolución 
 resolución 
in fine
in fine
in fine