Facultad de Ingeniería de Sistemas, Cómputo yTelecomunicaciones

SOFTWARE DE APLICACIÓNERICSON HUAMANÍ MANTILLA

RAÚL DÍAZ ROJAS

2011

ÍNDICEPresentación 4Introducción 5Orientación Metodológica 6

Primera Unidad1. Fundamentos en Gestión de Proyectos 81.1. Orientación y propósitos 81.2. Sumario 81.3. Contenido 8

Lección 1: Fundamentos básicos de gestión de proyectos 8

Lección 2: Ciclo de vida de un proyecto 15

1.4. Lectura: Project Manager vs. Team Leader 201.5. Actividades 211.6. Autoevaluación 221.7. Exploración online 231.8. Bibliografía 23

Segunda Unidad2. Proceso Unificado Abierto – Open UP 242.1. Orientación y propósitos 242.2. Sumario 242.3. Contenido 24

Lección 1: Fundamentos de Open UP 24

Lección 2: Ciclo de vida Open UP 38

2.4. Lectura: Metodologías tradicionales versus metodologías ágiles 422.5. Actividades 442.6. Autoevaluación 442.7. Exploración online 452.8. Bibliografía 45

Tercera Unidad

3. Eclipse Process Framework - EPF 463.1. Orientación y propósitos 463.2. Sumario 463.3. Contenido 46

Lección 1: Eclipse Process Framework – EPF 46

Lección 2: EPF Composer - EPFC 483.4. Lectura: La necesidad de nuevos métodos 803.5. Actividades 833.6. Autoevaluación 863.7. Exploración online 87

Bibliografía 87

Glosario 88

Introducción

Las exigencias actuales del mercado en un entorno cada vez más competitivo, tecnológico y globalizado, en continua evolución, donde la disponibilidad y tratamiento de la información resultan ser componentes fundamentales para la administración y gestión de los procesos de un negocio, conllevan a requerir aplicaciones informáticas cada vez más dinámicas y eficientes, capaces de ser implementados en el menor tiempo posible, sin sacrificar para ello las buenas prácticas requeridas para hacer más productivo todo el ciclo de desarrollo de software.

Dentro de este marco conceptual en el que se mueven los proyectos de software, nacen nuevos modelos y metodologías, que ayudan a la gestión de estos para cumplir con el tiempo, alcance y coste; satisfaciendo así las necesidades de las organizaciones que lo requieren; Open UP (Proceso Unificado Abierto) es uno de éstos modelo, el cual incluye su proceso Open UP/Basic, que es un método ágil que contiene un conjunto mínimo de buenas prácticas pudiendo ser adaptado y extendido según la necesidad de cada proyecto de desarrollo de software.

El presente libro constituye una guía para el estudiante y lo introduce en un entorno de desarrollo de sistemas informáticos basado en el trabajo colaborativo, involucrando para ello diferentes perspectivas de trabajo, desde los usuarios finales, pasando por los analistas, arquitectos, desarrolladores, revisores hasta el gerente a cargo de la realización del proyecto. El objetivo es proporcionar al alumno la capacidad de construir sistemas informáticos completos y extensibles, ajustándose a las nuevas necesidades de los usuarios, aplicando para ello Open UP/Basic.

Los autores

Orientación Metodológica

a. Descripción de las Unidades del Texto

Este libro está compuesto por tres unidades de acuerdo al contenido del sílabo, estas unidades se componen a su vez de lecciones, en cada lección se desarrolla la teoría fundamental para entender el tema, cada unidad además presenta un resumen, una lectura, una autoevaluación así como la bibliografía y los enlaces web correspondiente a la unidad.

La primera unidad contiene los conceptos y fundamentos de gestión de proyectos informáticos; indicando las consideraciones más importantes que deben evaluarse durante el ciclo de vida de desarrollo de un proyecto.

La segunda unidad presenta los conceptos básicos relacionados a la metodología Open UP y su aplicación mediante el framework Eclipse Process Framework, además de explicar su ciclo de vida. La tercera unidad enseña a utilizar la herramienta Eclipse Process Framework Composer, para construir y editar fragmentos de método y procesos a fin de generar automáticamente la documentación respectiva.

El libro puede ser consultado fácilmente por aquellas personas que han elaborado pequeñas aplicaciones y que desean adquirir un enfoque eficiente para maximizar su capacidad en la elaboración de aplicaciones informáticas.

En cada lección se explica detalladamente los conceptos necesarios para entender el tema y se desarrollan casos completos en el que el alumno podrá contrastar lo leído, al final de cada lección se presenta una lista de ejercicios propuestos que el alumno deberá resolver.

b. Sumilla

La parte teórica del curso se centra fundamentalmente en proporcionar las nociones básicas sobre los fundamentos teóricos de gestión de proyectos informáticos y de las tecnologías relacionadas para elaborar aplicaciones informáticas dinámicas y flexibles. La parte práctica proporciona una serie de actividades que van desde pequeñas aplicaciones hasta módulos completos e interactivos, todos ellos implementados usando la herramienta libre Eclipse Process Framework Composer (EPF Composer).

c. Objetivos del Curso

El objetivo es proporcionar al alumno la capacidad de aplicar un proceso de desarrollo de software que involucre los componentes necesarios para la construcción de un sistema informático completo y extensible, ajustándose a las nuevas necesidades los usuarios.

d. Estrategias de Aprendizaje

Por parte del docente, el método tendrá un carácter deductivo-inductivo, flexible y activo en materia de asesorías y de implementación de programas.

Por parte de los estudiantes, participarán activamente en las tutorías virtuales, realizando una serie de prácticas, implementar proyectos informáticos, así como demostrar su funcionamiento.

e. Evaluación

La evaluación comprende un examen parcial, un examen final y un examen sustitutorio, si se requiere, además de la presentación de una aplicación de software previa evaluación de los alcances del mismo.

La nota final sigue la siguiente fórmula:

PF=Promedio FinalEP=Examen Parcial EF=Examen FinalAS=Aplicación de Software

Primera Unidad1. Fundamentos en Gestión de Proyectos

1.1. Orientación y propósitos

Conocer y comprender los conceptos básicos relacionados a la gestión de proyectos informáticos y las buenas prácticas.

Conocer y aprender el ciclo de vida de la dirección de proyectos.

1.2. Sumario

La unidad comprende dos lecciones:Lección 1: Fundamentos básicos de gestión de proyectos Lección 2: Ciclo de vida de un proyecto

Lección 1

Fundamentos básicos de gestión de proyectos

A. Proyecto

Existen diferentes definiciones sobre el concepto de proyecto, entre los cuales destacan:

"Es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único". (PMI, 2006,5).

También, "Es una operación de envergadura y complejidad notables, de carácter no repetitivo, que se acomete para realizar una obra importante". (Pereña, 1996,2). Finalmente, "Es un conjunto o secuencia de actividades que desarrolla durante un tiempo un equipo de personas para obtener un resultado". (Rodríguez, 2007,32).

Como se puede apreciar de todas estas definiciones, podemos entender que todo proyecto presenta un ciclo de vida que empieza desde la aparición de una idea o necesidad, el cual, luego de los ajustes respectivos se formalizará y ejecutará hasta el logro de los objetivos o cumplimiento de las metas trazadas, ver figura 1-1; sin embargo, no necesariamente esto es así, ocurren diferentes factores que impactan directamente sobre la marcha del proyecto dificultando su avance, originando en algunos casos el cierre del mismo.

Dada la naturaleza temporal de un proyecto, al ser un conjunto limitado de actividades organizadas que se realizan por encargo o por contrato de alguien, llevadas a cabo por personal competente y dado que está encaminado para generar un resultado que impactará positivamente en la organización, incluso para la sociedad, es imprescindible que todo proyecto deba ser impulsado por la alta dirección, desde los requerimientos de financiamiento y particularmente de la participación de sus miembros, paralelamente a ello la designación de un gerente de proyectos para su conducción es necesario, dado que permitirá impulsar, comprometer y alinear a los interesados con los objetivos del proyecto.

Figura 1-1. Inicio de un proyecto (los autores)

Cuando empieza formalmente un proyecto, los objetivos deben estar bien definidos y no deben cambiar, sin embargo el presupuesto y fundamentalmente los tiempos de entrega

determinados inicialmente, pueden variar durante el proceso de desarrollo debido a los ajustes que se requieran hacer para mejorar los resultados, estos resultados pueden clasificarse en productos y servicios. Un producto es un elemento tangible que puede ser un componente o artefacto, en contraparte un servicio es un intangible que sólo se produce cuando participa directamente el usuario final. La tabla 1-1 muestra ejemplos de proyectos.

Productos Servicios

Un nuevo motor V6 para un

determinado tipo de automóvil.

Un nuevo procedimiento de atención al

cliente en un supermercado.

Una carretera interprovincial.Un programa de capacitación para el

personal docente de una universidad.

Un manual de usuario para el manejo de

un equipo de video.

Un mecanismo de asesoría

especializada contra ataques

informáticos.

Un nuevo microchip de aceleración de

video.

Un nuevo proceso de apoyo a la

producción automatizada de embases.

Una aplicación de software para la

gestión electrónica de documentos en

una empresa.

Una aplicación web libre para la

publicación de contenidos de

investigación.

Tabla 1-1. Ejemplos de proyectos de productos y servicios (los autores)

Podemos decir también que un proyecto es un conjunto de actividades interrelacionadas que deben ejecutarse siguiendo una secuencia organizada, basándose en las disponibilidad de la inversión y al tiempo para cada una de las actividades, para ello es necesario contar con elementos o recursos como: energía, capital, personal, información, tiempo, hardware, software, programas de aplicación, etc.

Los proyectos no son iguales y difieren fundamentalmente en el tamaño y la complejidad de su implementación así como del impacto o trascendencia que tienen para la entidad que lo ejecuta, incluso más aún para su entorno, tal situación, como es obvio, exige diferentes niveles de inversión, e incluso de financiamiento por parte de terceros. En consecuencia, gestionar un proyecto no es una tarea sencilla, por lo contrario, exige diferentes y cada vez mayores niveles de exigencia para optimizar los costos, tiempo y calidad del resultado, tal combinación se denomina comúnmente la triple restricción, término que resalta el equilibrio que debe existir en estas tres variables para conseguir culminar controlada y satisfactoriamente el alcance un proyecto.

En la práctica, gran cantidad de proyectos fallan frecuentemente, esto debido en gran parte a problemas de experiencia y habilidades durante de gestión y ocurre en mayor medida que aquellos que suceden por falta de conocimientos técnicos, basta con conocer algunas estadísticas "más del 50% de los proyectos informáticos no responden a los objetivos que tenían planeados o han tenido desviaciones significativas de tiempo o de coste. Según algunos autores, esta cifra llega al 70% o al 80%. De acuerdo con un estudio del Standish Group sobre proyectos informáticos en todo el mundo, de los proyectos analizados un 31% fueron cancelados antes de su finalización; en un 88% de los casos, se superó el periodo acordado. Y, lo que es más importante, el volumen económico de sobrecoste alcanzó el 222% de las estimaciones iniciales". (Rodríguez, 2007,29)

En conclusión, para tener éxito en el cumplimiento de nuestras metas es necesario llevar a cabo un proyecto formal, para ello tanto la experiencia como las habilidades del grupo responsable de la ejecución son necesarias, esto permitirá:

Mejorar el control financiero, físico y de los recursos humanos. Mejorar las relaciones con el cliente durante el ciclo de vida del proyecto. Organizar el proyecto en cortos tiempos de desarrollo. Minimizar los costos. Mejorar la calidad y la confiabilidad de los resultados. Proyectar nuestros márgenes financieros. Mejorar la productividad del personal especializado. Mejorar las coordinaciones internas. Mejorar el nivel de la moral del trabajador y de sus perspectivas de trabajo.

B. Dirección de Proyectos

Para dirigir un proyecto informático es necesario aplicar una diversidad de conocimientos especializados al área en cuestión, además de contar con habilidades, instrumentos, técnicas y métodos que permitan cumplir con los objetivos trazados inicialmente. Generalmente para un mejor entendimiento, todo proyecto debe ser descompuesto en procesos. Cada proceso a su vez está conformado por 3 componentes importantes: la estrada, la salida y las actividades, que son aplicados para transformar la entrada en valor, apoyado para este caso de las técnicas disponibles para dicho proceso.

El gerente de proyectos es la persona responsable de llevar a cabo un proyecto, más aún si se tratan de proyectos informáticos, dado que generalmente abarcan todos los procesos del negocio de una entidad, para ello es necesario que tenga dominio y experiencia en cinco áreas fundamentales las cuales convergen parcialmente para constituir las bases del cuerpo de conocimientos de la gestión de proyectos o Guía del PMBOK (Project Management Body of Knowledge). Ver figura 1-2.

Figura 1-2. Áreas de Experiencia y PMBOK (Rodriguez, 2007,13)

1. Conocimiento sobre dirección de proyectos. Debe tener el conocimiento técnico especializado para:

Integrar los diferentes procesos y actividades de las que está conformado un proyecto.

Definir los límites del proyecto, es decir saber exactamente lo que se va a implementar.

Controlar los tiempos proyectados de tal manera que no se extiendan. Gestionar los costos, para evitar que el proyecto se sobrevalore. Verificar la calidad del producto o servicio a fin de que cumplan con las expectativas de

los interesados. Controlar el esfuerzo del personal que tienen participación directa e indirecta en el

proyecto, logrando maximizar su producción. Definir los protocolos de comunicación entre todos los interesados, así como definir

los mecanismos adecuados y oportunos para garantizar la generación, recopilación, distribución, almacenamiento, recuperación y disposición de la información del proyecto.

Planificar los riesgos, la respuesta a ellos, así como su control y monitoreo durante todo el proyecto, evitando con ello minimizar los efectos negativos que pudieran colapsar su normal desarrollo.

Gestionar las compras o adquisiciones de los productos y/o servicios necesarios de las cuales dependan todos los procesos involucrados en el proyecto.

2. Conocimientos y habilidades sobre dirección general. Debe tener conocimientos sobre diferentes áreas de gestión, permitiéndole liderar e integrar el grupo bajo su mando. Involucra:

Aspectos sobre actividades de las diferentes áreas operativas y de la cadena de valor como: ventas, marketing, contabilidad, finanzas, recursos humanos, investigación, desarrollo, manufactura y distribución.

Fundamentos sobre planeamiento estratégico, táctico y operacional. Nociones sobre aspectos de la organización como su estructura, administración, visión

y misión, cultura. Aspectos laborales, para maximizar el trabajo en grupo. Habilidades individuales para la organización de su tiempo, de sus conflictos

emocionales así como la capacidad de superación ante situaciones de estrés.

3. Habilidades interpersonales. Que incluye:

Liderazgo y motivación al grupo. Capacidad de comunicarse eficientemente de forma: escrita, oral, corporal,

tecnológica, formal e informalmente. Negociación y gestión de conflictos en todo momento, a todo nivel, de manera directa

con mediación e incluso con arbitraje. Capacidad para solucionar problemas técnicos, administrativos e interpersonales. Capacidad para influir directamente en la toma de decisiones de la alta dirección y en

los organismos que dependen directa e indirectamente del proyecto.

4. Nociones sobre los lineamientos, normas y/o regulación anexos al proyecto. Que corresponde a las directivas de carácter legal, que sirven de sustento para su puesta en operación, comprende:

Conocimiento de las normas de la entidad mediante resoluciones, decretos, directivas, etc.

Conocimiento de las regulaciones dictadas por el gobierno que especifica las características de un producto, proceso o servicio.

5. Comprensión del entorno del proyecto. Que revisa el contexto externo del proyecto, en cuyo caso se ve afectado por su ejecución. Comprende:

Aspecto cultural y social, referente a los aspectos económicos, demográficos, educativos, éticos, étnicos y religiosos de las personas a quienes afecta el proyecto.

Aspecto internacional y político, que comprende el conocimiento de las leyes y costumbres internacionales, regionales y locales tales como diferencias horarias, días no laborales, alcance de licenciamiento, cobertura de las telecomunicaciones, etc.

Por lo tanto, el éxito de una buena dirección dependerá por un lado del cumplimiento de los requisitos del interesado teniendo en cuenta las restricciones de alcance, tiempo, costo, recursos, calidad y riesgos, y por otro lado, la adecuada selección y organización de los procesos que conformarán el proyecto, más aún si éstas se basan en una metodología preexistente, adaptable y eficiente en la práctica.

C. Proyecto Informático

"Un proyecto informático es una secuencia de actividades que desarrolla durante un tiempo predeterminado y con unos recursos limitados un equipo de personas, informáticos y no informáticos, para obtener unos resultados sobre la organización y los procesos de trabajo. Una parte sustancial de estas actividades requieren conocimientos y habilidades en las materias de sistemas y tecnologías de la información" (Rodríguez, 2007,35).

En este escenario, podemos decir que un proyecto informático es una clase de proyecto que centra sus objetivos en la construcción de entregables como: productos, aplicaciones, documentación, soluciones tecnológicas, etc, que deben cumplir ciertos estándares de calidad (satisfacción del cliente por el producto o servicio recibido) y rendimiento (capacidad del producto o servicio de funcionar eficientemente), los cuales tendrán como fin optimizar los procesos de negocio de una entidad, por tanto, es necesario ejecutar acciones simultáneas y/o secuenciales que incluyen personas, equipamiento de hardware, software y comunicaciones.

En los proyectos informáticos de gran alcance, el equipo de proyecto está constituido usualmente por especialistas informáticos que se encargarán concretamente en desarrollar el producto o servicio informático, para ello es conveniente que laboren a tiempo completo y bajo responsabilidad, destacándose entre los diferentes perfiles: analistas, arquitectos, diseñadores, programadores, administradores de sistemas operativos, gestor de procesos, administradores de base de datos, administradores de seguridad, especialistas de soporte y mantenimientos, revisores de rendimiento, todos ellos reportando al gerente o director de proyectos, quien es responsable entre muchas tareas de asignar los recursos, por tanto de él depende el éxito o fracaso del proyecto desde el punto de vista técnico y económico.

Un proyecto informático generalmente se inicia con el planteamiento de las necesidades y requerimientos de los usuarios, los cuales pueden abarcar desde problemas que ocurren dentro de la cadena de valor de un negocio (sistemas transaccionales), hasta contextos más estratégicos y de alto nivel de complejidad (sistemas para la toma de decisiones y sistemas expertos).

Son ejemplos de proyectos informáticos:

Un sistema de comunicación de voz sobre ip utilizando software libre Un nuevo dispositivo móvil de comunicación satelital. Un sistema experto para el reconocimiento de tumores óseos Un sistema para la gestión electrónica de documentos.

Lección 2

Ciclo de vida de un proyecto

Desde que se concibe un proyecto hasta que culmina con la obtención de los resultados, necesariamente debe pasar por ciertas fases o etapas que deben revisarse constantemente y que varían generalmente en función del tamaño y la complejidad del proyecto, estas etapas pueden ser: pre inversión, ejecución y operación [4], las cuales en la práctica no se ejecutan una tras otra. La figura 1-3 muestra las etapas de un proyecto.

Figura 1-3. Etapas de un Proyecto (Miranda, 2005,5).

Pre inversión

Conocida también por algunos autores como planificación. Corresponde a todas las actividades que tienen que ver con el estudio previo necesario para tomar la decisión de iniciar un proyecto. Aquí se determina y se evalúa la idea, la necesidad, se identifica el problema, se interpreta y se conceptualiza, dándole forma de proyecto preliminar, se evalúa las ventajas y desventajas, se determina la factibilidad técnica económica, los riesgos, así como la proyección de tiempos estimados, para finalmente llegar a un acuerdo definitivo si el proyecto se aplicará o no. Es bastante frecuente que durante todas estas actividades no sólo se revise una propuesta, sino un grupo que apuntan al mismo objetivo, por lo tanto esta etapa se caracteriza además por realizarse en ella actividades de selección y priorización de las propuestas más factibles, es decir que maximicen los beneficios, principalmente en términos de costos, tiempos y calidad del producto o servicio ofrecido, según claro está de las prioridad de la entidad que solicitó el producto o servicio. Esta etapa determina el éxito o fracaso de un proyecto.

Inversión

Denominada también Ejecución. En esta etapa, es necesario tener aprobado la propuesta y contar con todos los requisitos de personal, logístico y financiero. La Ejecución es la etapa de implementación del proyecto, es decir de la elaboración del producto o servicio, para ello se debe gestionar adecuadamente los recursos asignados

para cada especialista o unidad de trabajo y dado su complejidad por las actividades especializadas que se realizan se requiere la participación activa del gerente de proyectos para organizar éstas actividades manteniendo un equilibrio entre los tiempos programados y los costos asociados sin sacrificar la calidad y los alcances del proyecto. En conclusión, la inversión es la traducción de la pre inversión o planeación a los hechos concretos, por lo tanto es la etapa en la que se mueve la mayor cantidad de recursos tanto humanos como logísticos y económicos.

Operación

También llamado fase de entrega o puesta en marcha. Una vez finalizado el producto o servicio, este se pone en marcha siguiendo previamente un período de prueba para que, luego de haber efectuado los ajustes, este se ponga en producción permanente, por lo tanto en esta etapa se logra el objetivo propuesto del proyecto.

Otro definición es la que se revisa en la guía PMBOK, menciona que "El ciclo de vida del proyecto es un conjunto de fases del mismo, generalmente secuenciales y en ocasiones superpuestas, cuyo nombre y número se determinan por las necesidades de gestión y control de la organización u organizaciones que participan en el proyecto, la naturaleza propia del proyecto y su área de aplicación", en efecto, cuando se menciona el término superpuestas, se refiere a que no necesariamente debe culminar una fase para empezar la otra.[1]. Ver figura 1-4. Los procesos que conforman el ciclo de vida son: Iniciación, planeación, ejecución, control y cierre.

Figura 1-4. Procesos para la Dirección de un Proyecto. (PMI, 2004,68).

A. Iniciación

La iniciación es la primera etapa de un proyecto en la que se confirma que existe un problema u oportunidad de negocio, así mismo se determina si un proyecto puede ser creado para resolver el problema, es decir, se determina la viabilidad de un proyecto y se demuestra a la alta dirección a través de un documento formal denominado estudio de factibilidad. Entre los diferentes criterios que se evalúan aquí es: verificar si se pueden reducir los costos asociados a un proceso, evaluar si es factible incrementar los ingresos asociados a un servicio directa o indirectamente, analizar si las actividades de producción y eficiencia pueden mejorarse e

incrementarse, resolver problemas de negocios o funcionales, maximizar las capacidades de competencia tomando ventajas de las oportunidades de negocio que se presenten.

Dentro de la etapa de iniciación, es necesario en primera instancia identificar a los interesados del proyecto, dado que su participación ya sea a través del aporte de conocimiento, reglas, lineamientos e inversión, en el caso de los patrocinadores o inversionistas externos, influye directamente en la culminación positiva de un proyecto, luego a partir de ello se determina una propuesta del alcance que responde a ¿qué es lo que se va a construir, desarrollar, fabricar?, ¿quiénes o qué áreas se verán beneficiados directa e indirectamente?, ¿cuál es la extensión geográfica que abarcará el proyecto?, tal situación exige proyectar un calendario de trabajo inicial, el cual será propuesto en base a la disponibilidad de la capacidad de producción del grupo de trabajo a cargo de la implementación del proyecto así como de las facilidades de los interesado para participar activamente en el proyecto; ambas variables: alcance y tiempo constituyen las bases para proyectar el financiamiento necesario para cubrir la propuesta inicial.

En esta fase se identifican las necesidades del negocio en todos los niveles de la organización: operacional, táctico y estratégico, por lo tanto para alcanzar estos máximos niveles de la organización, es necesario que, el jefe de proyecto ya contratado defina claramente los objetivos, organice a las personas, los recursos e inicie la elaboración del enunciado del trabajo SOW (Statement of work), llamado también Check List, el cual servirá de entrada para el documento principal denominado Acta de constitución del proyecto (Project charter), todo ello con el apoyo del personal especializado bajo su cargo.

El SOW es un documento que determina el inicio del proyecto, contiene los lineamientos generales del proyecto con el fin de informar a los involucrados sobre el alcance del mismo. La estructura de este documento es la siguiente:

1. Datos generales 2. Objetivos3. Resumen del requerimiento 4. Beneficios del negocio5. Entregables y requerimientos 6. No es parte del alcance 7. Enfoque a utilizar8. Entregables y tareas principales 9. Cronograma resumen e hitos 10. Organización - Organigrama11. Asignación de roles y responsabilidades 12. Método de control y seguimiento 13. Supuestos, riesgos y restricciones 14. Procedimiento de aceptación15. Procedimiento de cambios16. Estimación de costos

El acta de constitución del proyecto, es un documento que autoriza formalmente que un proyecto se lleve a cabo, además le confiere al gerente de proyecto la autoridad para emplear los recursos que estime necesario. Ver figura 1-5.

La estructura de este documento es bastante parecida a la estructura del SOW, sin embargo es más elaborada y detallada.

Figura 1-5. Proceso para la generación del acta de constitución del proyecto (PMI, 2004,45)

B. Planificación

La planificación determina los procesos necesarios para determinar la forma en que se llevaran a cabo cada una de las actividades que conforman un proyecto, por lo tanto se debe tener cuidado sobre la información que será procesada, la buena utilización de las herramientas y métodos relacionados así como las salidas que servirán de entrada para otro proceso, todo ello siguiendo ciclos de retroalimentación, que permitirán ajustar el plan, haciéndolo cada vez más eficiente. Todo este mecanismo de autoajuste en esta fase se conoce con el nombre de planificación gradual.

Para iniciar esta etapa es necesario tomar como información de entrada el acta de constitución del proyecto, así como información actualizada referente a los factores ambientales de la empresa, nuevas restricciones o cambios en los procesos del negocio, hecho esto el gerente de proyecto elaborará el entregable: plan para la gestión del proyecto, el cual deberá ser aprobado formalmente. Así mismo el gerente de proyectos buscará el compromiso compartido entre el grupo de desarrollo y los interesados, reconociéndoles el valor de su trabajo y de su tiempo, por lo tanto asegura que los entregables estén alineados con las expectativas.

En esta etapa se planifica el alcance, se definen las actividades y su secuencia, se estiman los recursos de las actividades, su duración, se prepara un cronograma (calendario), se estiman los costos y el presupuesto, se analiza la calidad, se determina el personal y su contratación, se identifican y evalúan los riesgos, se resuelven los temas de adquisiciones, así como las capacidades de comunicación e integración.

Por lo tanto "La planificación es una relación entre objetivos y recursos, relación normalmente inestable, por lo que debe tener agilidad y dinamismo para ir efectuando ajustes periódicos con el fin de acercar las previsiones a la realidad." (Publicaciones Vérice, 2008,39).

C. Ejecución

Es el proceso que está conformado por todas las acciones llevadas a cabo por el grupo responsable de la implementación del proyecto así como la participación de los interesados para cumplir todas las actividades definidas en la panificación, para esto, se hace uso intensivo

de los recursos asignados bajo responsabilidad del gerente de proyectos, quien a su vez controla que dichas acciones se lleven a cabo dentro del tiempo señalado de manera organizada e integradora. Finalmente en esta etapa se determina la calidad del resultado.

D. Seguimiento y Control

En esta etapa se monitorea, analiza y regula el trabajo del proyecto. Para ello es necesario realizar las siguientes acciones:

Controlar permanentemente los cambios que pudieran aparecer a lo largo de la ejecución.

Verificar y controlar el alcance del proyecto, con el fin de determinar y proveer de nuevos recursos.

Controlar el cronograma, haciendo los ajustes necesarios para minimizar la ampliación de los tiempos.

Controlar los costos asignados, evitando el mal uso de ellos. Realizar control de calidad. Gestionar la performance operativa del grupo encargado de la implementación Mantener informado a los interesados del avance y rendimiento de los resultados. Monitorear los riesgos minimizando el impacto de los imprevistos. Revisar y aplicar las cláusulas del contrato.

E. Cierre

En esta etapa se realizan todas las actividades que pondrán fin formalmente a un proyecto, para ello se ha tenido que haber cumplido con los objetivos y de acuerdo a las especificaciones estipuladas en el contrato. Las actividades que se realizan son:

Auditar los documentos de adquisiciones. Completar la verificación del alcance. Cerrar contratos con contratistas. Cerrar asuntos administrativos. Emitir reportes finales. Archivar registros del proyecto. Reasignar a los miembros del equipo.

1.3. Lectura

Project Manager vs. Team Leader

¿Te ha tocado ver cuando el administrador del proyecto deja su equipo de trabajo y el jefe se ve obligado a poner a otra persona? Normalmente el jefe elige al mejor miembro del equipo para administrar el proyecto, después de todo este individuo se merece el ascenso. Cuando eso sucede, normalmente decimos que el equipo perdió a un buen técnico y ganó a un mal administrador.En México sucede que el crecimiento económico de un profesionista está muy ligado con el crecimiento de puesto o de responsabilidad, de tal forma que cuando una persona desea ganar más dinero es necesario que ascienda de puesto, porque en el puesto en el que se encuentra estará sujeto a un fabulador menor.

En el proceso, las compañías asignan puestos administrativos a técnicos sin una preparación administrativa previa ni un proceso de "ramp-up" para el nuevo puesto, y el resultado no se deja esperar.

Un técnico está acostumbrado a "meter las manos" en el momento de implementación, mientras el administrador observa desde afuera. Un técnico "delegará" responsabilidad diciendo a su equipo Qué y Cómo hacer las cosas, un administrador solo dirá Qué hacer y esperará los resultados. Un técnico estará más preocupado por el tipo de implementación mientras un administrador estará preocupado por entregar dentro de los límites acordados de tiempo, costo y calidad. Un técnico fácilmente caerá en la tentación del gold plating (funcionalidad extendida y mejorada) mientras un administrador se preocupa por entregar solamente lo solicitado por el cliente. Un técnico dejará pasar nuevos requerimientos del cliente a costa de su fecha de entrega mientras un administrador filtra los requerimientos por su proceso de change management establecido desde el principio.

Algunos técnicos solo quieren la posición de liderazgo y el sueldo relacionado con esa posición, pero no las responsabilidades, así que se convierten en "técnicos bien pagados" dado que hacen lo posible por continuar metiendo su nariz en las decisiones y acciones técnicas y desacreditando la documentación, planeación, coordinación y comunicación del proyecto.

Lo más grave de todo es cuando escuchamos a un técnico quejándose porque "tuvo" que dejar aquello que lo motivaba, aquello "para lo que fue hecho", para adoptar una posición administrativa que a sus ojos no agrega valor al proyecto.

1. Cuida a tus técnicos y desarrolla un plan de carrera para ellos.2. Si "subiste" en el organigrama para ganar más dinero pero detestas las actividades administrativas, piensa que en algún otro lugar pudieran estar premiando tus habilidades técnicas sin necesidad de tenerte haciendo todos esos reportes y hablando con toda esa gente.3. Cuando busques trabajo, revisa el anuncio primero: si piden un "Administrador de Proyectos" con muchas habilidades técnicas, probablemente lo que quieran es un Team Leader. Si les interesa que conozcas metodologías de PM, que generes reportes para la PMO, que manejes los conflictos, que reportes avances, que administres la calidad, que salga el proyecto a tiempo, que administres el presupuesto del proyecto, etc., entonces quieren a un PM.

Conclusión:

En todo el mundo, las compañías deben aprender a remunerar la especialización de sus técnicos para que tengan una ruta de crecimiento laboral y económico. Esto les permitirá

seguir motivados haciendo lo que más les gusta hacer y dejar los puestos administrativos para aquellos que encuentran una pasión en eso. Por otro lado, para aquellos que quieren cambiar de profesión avanzando a puestos administrativos, las compañías deben considerar el desarrollar a sus empleados para que estos tengan una transición adecuada con el fin de que tengan éxito en su nuevo puesto administrativo. Esta transición requiere tiempo, requiere uno o más mentores y mucha capacitación. Todo esto requiere inversión, pero el retorno es en fidelidad del empleado y de mejores técnicos y mejores administradores dentro de la compañía.

http://leccionesaprenclidas.blogspot.eom/2007/09/project-manager-vs-team-leacler.html

1.4. Actividades

Elabore el documento Estructura Desglosable de Trabajo (EDT) para descomponer en actividades cada vez más pequeñas un requerimiento de implementación de un sistema de comunicación por voz basado en la tecnología Asterisk.

1.5. Autoevaluación

a. Responda verdadero [V] o falso [F] según corresponda.

[ ] Un proyecto es un esfuerzo permanente que se lleva a cabo para crear un producto, servicio o resultado único

[ ] La restricción por la limitación de los recursos es una característica común de los proyectos y trabajos operativos.

[ ] El director del proyecto es la persona responsable de alcanzar los objetivos del proyecto.

[ ] Los procesos de iniciación, por lo general, se realizan fuera del ámbito de control del proyecto por la organización.

[ ] En la fase de planificación se refina la descripción del alcance inicial y los recursos que la organización está dispuesta a invertir.

b. Describa la participación de los interesados clave de un proyecto.

c. Que entendemos por triple restricción y cuál es su importancia.

d. Explique la importancia y alcances de los siguientes documentos (plantillas) que se utilizan durante la fase de Planificación:

Enunciado de trabajo (SOW) Acta de constitución del proyecto (Project charter) Enunciado del alcance del proyecto Plan de gestión del proyecto

e. Establezca las diferencias entre proceso y operación.

f. Utilizando la guía del PMBOK interprete y comente el gráfico que se muestra en la Figura 1-6.

Figura 1-6. Interesados del proyecto (PMI, 2004,25)

g. Que es análisis de requerimientos, diferencias entre requerimientos funcionales y no funcionales. Mencione 5 ejemplos por cada uno de ellos.

h. Explique los factores por las que un proyecto de tecnologías de información tiende a fracasar.

i. Explique el proceso de "Gestionar el Equipo de un Proyecto", e indique sus entradas y salidas.

j. Indique todas las actividades que se deben realizar durante el Cierre de un Proyecto.

1.6. Exploración oniine

http://www.pmi.org http://www.degerencia.com http://www.gestionproyectostic.com http://www.liderdeproyecto.com

1.7. Bibliografía

Project Management Institute, Inc (2004), Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK®). 3ra Edición. Pennsylvania, PMI Publications.

Pereña B., Jaime (1996). Dirección y Gestión de Proyectos. 2da Edición, Madrid, Ediciones Díaz de Santos.

Rodríguez J, Minguez J, Orozco 1.(2007). Gestión de proyectos informáticos: métodos, herramientas y casos. Barcelona, Editorial OUC.

Miranda M., Juan (2005). Gestión de Proyectos: Formulación - Identificación y Evaluación Financiera-Económica-Social-Ambiental. 5ta Edición. Bogotá. MM editores.

Publicaciones Vértice (2008). Gestión de Proyectos. Málaga. Editorial Vértice.

Segunda Unidad1. Proceso Unificado Abierto - Open UP

1.1. Orientación y propósitos

Conocer y comprender los conceptos básicos relacionados a la metodología Open UP, la cual servirá de base para aplicar EPF (Eclipse Process Framework).

Aprender el ciclo de vida de Open UP, para entender las diferentes fases y las consideraciones que debemos seguir para implementar eficientemente un proyecto de software.

1.2. Sumario

La unidad comprende 2 lecciones: Lección 1: Fundamentos de Open UP Lección 2: Ciclo de vida Open UP

Lección 1

Fundamentos de Open UP

A. Open UP

"Open UP es una metodología lanzada en el año 2006 por la compañía IBM, que posteriormente fue donado a la fundación eclipse bajo licencia libre de uso" (Open UP,2008,2), el cual busca brindar al mundo una nueva forma de gestionar proyectos pequeños y medianos mediante un nuevo enfoque ágil sobre el proceso de desarrollo de software, teniendo como uno de sus principales características la sincronización del conocimiento (fomentar el intercambio de información entre todo el equipo de trabajo y mantener una visión común del proyecto, objetivos, avances y alcances) y el enfoque hacia una arquitectura de desarrollo de software (ayuda a minimizar la incertidumbre, si el proyecto va a ser exitoso o no). Este modelo involucra un conjunto mínimo de buenas prácticas que ayudan a los equipos de trabajo a ser más productivos en el desarrollo de sistemas informáticos.Open UP introduce una filosofía colaborativa y ágil de trabajo, es decir integra en su interior procesos abiertos de gestión de desarrollo software; en cuanto a herramientas (Interfaces de gestión, lenguajes de programación, procesos de gestión) que puede ser tomado desde la fundación Eclipse, de donde nace el Open UP, y que puede ser expandido o adaptado de acuerdo a la envergadura de cada proyecto.

Se puede decir que este modelo es mínimo, completo y extensible por lo que se puede utilizar tal cual o ampliarlo y modificado para requisitos particulares en fines específicos.

Una buena manera de entender Open UP es pensar en él como una visión global a nivel de equipo de desarrollo que tienen los siguientes objetivos:

Aplicar el proceso mínimamente necesario que aporte valor. Evitar estar sobrecargado de trabajo formal (documentación improductiva y extensa)

que hace que el proceso de desarrollo de software se vuelva lento. Usar un proceso que puede ser adaptado y ampliado para satisfacer las necesidades

que puedan surgir durante el ciclo de vida de desarrollo de software.

Open UP/Basic es el nombre del proceso de la metodología Open UP, el cual tiene las siguientes características:

Mínimo.Aquí sólo se incluye solamente contenido fundamental para el proceso de desarrollo de software, siendo sus principales actividades esenciales:

Programación iterativa. Colaboración de equipo. Integración continua y ejecución de pruebas. Entregables frecuentes de software. Adaptación a los cambios, etc.

Completo.

Open UP se considera un proceso completo ya que abarca las disciplinas esenciales en un ciclo de vida de desarrollo de software, guiando al equipo en las siguientes actividades de alto nivel:

Las necesidades del cliente y los requisitos son identificados y capturados, con la participación continua de ellos.

Desarrollar una arquitectura robusta para el sistema, frente a los riesgos técnicos y la difusión de la organización del equipo.

Para cada necesidad, se diseña una solución técnica, implementada y probada, que se ajusta a las decisiones de arquitectura.

Todo sistema es evaluado por pruebas que se validan con los requisitos del cliente. Todo defecto y mejora retroalimentan el desarrollo. La prioridad es trabajar, las iteraciones se planifican y evalúan, y los miembros del

equipo trabajan sobre el proyecto.

Extensible.Diferentes proyectos pueden tener necesidades diferentes. Las organizaciones pueden estar interesadas en la personalización de algunos aspectos de Open UP / Basic para adaptarla a sus proyectos. Estos son algunos ejemplos de personalización posible:

Añade nuevas funciones existentes o cambia su estándar de nombramiento. Añade las medidas necesarias para las tareas existentes. Crea nuevas directrices sobre una determinada técnica Quitar un área de determinado contenido Modificar o añadir nuevas plantillas existentes a los artefactos. Modificar o crear un ciclo de vida de un nuevo proceso. Agregar o quitar contenido de un proceso. Añadir orientaciones sobre cómo lograr el cumplimiento de los objetivos. Añadir una orientación específica a una tecnología que se utiliza actualmente. Reemplazar o aumentar una de las capas con el nuevo contenido (por ejemplo,

cambiar o añadir material a la forma de gestión se lleva a cabo), etc.

B. Capas de Gestión de Desarrollo

Open UP, define como capas de gestión de desarrollo, 3 enfoques. Ver figura 2-1.

1. Enfoque de Participantes.

Define el ciclo de vida del proyecto, el cual proporciona a los stakeholders los lineamientos del proyecto, en otras palabras define puntos de decisiones importantes, así como también el tiempo en que deben de ser ejecutadas.Los objetivos específicos del equipo de trabajo puede variar radicalmente a lo largo del proyecto, entonces es necesario dividir el proyecto en fases, cada fase tiene un conjunto definido de objetivos, un estilo particular, iteración, tareas personalizadas y work products para abordar las necesidades específicas del proyecto en un punto definido. Este enfoque se ve en todo el proceso de desarrollo de software pasando desde la fase de la Incepción hasta fase de Transición. La finalidad principal de este enfoque es reducir el riesgo y aumentar el valor de ejecución del proyecto.

Figura 2-1. Capas del Open UP

http://www.eclipse.org/epf/general/An_lntroduction_to_EPF.Zip

Al principio en todo proyecto, al momento de la concepción del mismo el riesgo y la incertidumbre de no salir exitoso es alto y conforme el ciclo de vida del desarrollo de software va en aumento esta va disminuyendo a lo que el valor y la probabilidad de éxito va en crecimiento, esto se ve definido bajo un enfoque grupal, en la cual, las decisiones y lineamientos son tomadas en un tiempo dado dentro de la fase en la que se encuentre. Ver figura 2-2.

Figura 2-1 .Riesgo y Valor de un proyecto en las fases de desarrollo de software

http://www.eclipse.org/epf/general/An_lntroduction_to_EPF.zip

2. Enfoque de Equipo

La finalidad del enfoque de equipo es entregar valor incremental al cliente cada semana mediante la entrega de un proceso de prueba, demostrable o un entregable (incremento del producto). Esto crea un enfoque saludable y asegura que todo lo que se trabaja es de valor

para las partes interesadas. La toma de decisiones debe ocurrir más rápido que en un proceso sin repeticiones, porque no hay tiempo para el debate sin fin el cual llevaría a reuniones de poco valor para el proyecto. El desarrollo iterativo se centra en la producción de código, reduciendo el riesgo de no avanzar con un análisis detallado del sistema que se quiere desarrollar.Estos incrementos producidos por el equipo de trabajo tienen que ser planificados y ejecutados durante todo el proceso de desarrollo, para ello es necesario iterar cada incremento o entregable lo que hace necesario planificarlo.Planificar la iteración, estimarla y evaluar los avances se centran en ítems de trabajo. El plan de iteración se crea mediante la selección de los ítems de trabajo de alta prioridad. Para ello se usan técnicas de estimación ágiles para comprender cómo varios ítems de trabajo de forma segura pueden caber dentro de una iteración en el tiempo. Los avances se evalúan mediante la realización continua de muchos ítems de pequeños trabajos (microincrementos).Así como un proyecto pasa por un ciclo de vida, las iteraciones también lo hacen, pero con un enfoque diferente para el equipo, dependiendo de si está en la primera o la última semana de la iteración. Una iteración comienza con una reunión de planificación de iteración que es un par de horas generalmente. En los primeros dos días suele ser centrado en la planificación y la arquitectura, entre otras cosas, entender las dependencias y el orden lógico de los elementos de trabajo, y el impacto arquitectónico del trabajo a realizar. La mayor parte del tiempo durante una iteración se ve reflejada en la ejecución de los incrementos de los microentregables. Cada microincremento debe ofrecer pruebas a un código de construcción, así como la validación de los artefactos. Se dedica más atención a estas formaciones para asegurarse de que la calidad no está disminuyendo, por lo tanto el éxito de la iteración no se ve amenazado. La última semana o los últimos días de la iteración suelen tener un mayor énfasis en el pulido y corrección de errores de semanas anteriores, aunque se añaden nuevas funciones, según corresponda. El objetivo es no permitir que disminuya la calidad. La iteración termina con una evaluación (con los stackeholder) de lo que fue construido, y una retrospectiva para poder entender cómo mejorar el proceso para la siguiente iteración. Ver Figura 2-3.

Figura 2-3. Proceso de iteraciones de trabajo grupal y personal

"Diseño Propio"

3. Enfoque Personal

El enfoque personal busca crear microincrementos mesurables hacia el lineamiento de los objetivos de una iteración. Una persona del equipo de trabajo en un corto lapso de tiempo puede tener un incremento del sistema (avance o solución a una problema) terminado, este enfoque alinea este lapso de tiempo de trabajo en tareas individuales en las cuales pueden terminarse un lapso de horas o días y que alimentan a una iteración mayor. A este incremento mínimo funcional se le denomina microincremento.Un micro incremento representa el resultado de unas pocas horas a unos días de trabajo para un miembro del equipo (normalmente una o pocas personas colaborando) para alcanzar los objetivos de la iteración. El concepto de un microincremento ayuda a los miembros individuales del equipo a la partición de su trabajo en pequeñas unidades, cada una de ellas ofrece algo de valor medible para el equipo. Los microincrementos proporcionan una muy corta retroalimentación que impulsa las decisiones de adaptación dentro de cada iteración del proyecto.

C. Principios de Open UP

Open UP se basa en cuatro principios básicos, el cual crean todas las bases para este modelo sobre la gestión de los proyectos.

1. Balance de las prioridades para maximizar el valor de los stakeholders.

Este principio nos dice que se debe desarrollar una solución que maximice los beneficios de los interesados conforme a las limitaciones impuestas en el proyecto.Para tener éxito, las partes interesadas y el equipo del proyecto deben converger en un claro entendimiento y el acuerdo de estos tres factores:

1. El problema a ser solucionado.2. Restricciones puestas al equipo de desarrollo (costos, plazos, recursos, normas, etc.). 3. Restricciones puestas hacia la solución (producto o servicio).

El reto para todos los participantes en el proyecto es crear una solución que maximice el valor dado a los interesados, sin perjuicio de las limitaciones. El balance es hacer la observación de costo y beneficio así como el equilibrio entre las características deseadas y las decisiones de diseño posteriores que definen la arquitectura del sistema.

Descubrir el punto de equilibrio es un reto difícil de alcanzar, debido a que el punto de equilibrio es dinámico. A medida que el sistema evoluciona, los interesados que cambian las necesidades, hacen que aparezcan nuevas oportunidades; los riesgos se resuelven y aparecen nuevos riesgos, y el equipo de desarrollo descubre nuevas realidades sobre el sistema. El cambio ocurre en todo el ciclo de desarrollo. Las partes interesadas y los miembros del equipo deben estar preparados para volver a evaluar los compromisos, las expectativas de reajuste, ajustar los planes y cronograma lo que hace que el sistema evolucione.

Entonces, ¿Cómo priorizar los beneficios de los stakeholders? Conozca a los stakeholders:

No se puede saber cómo hacer efectivo un análisis previo si no se conoce quienes son ni que es lo que quieren.

Separar el problema de la solución:

Con demasiada frecuencia, nos encontramos de cabeza en una solución sin la comprensión del problema. Después de todo, se nos enseña cómo resolver problemas, más no la forma de definir los problemas, por lo que es más fácil. Sin embargo el no saber analizar un problema, limita su comprensión, imponiendo barreras artificiales y no permitiendo cubrir lo que realmente significa.

Asegúrese de que usted entiende el problema antes de definir la solución. Al separar claramente el problema (las necesidades del cliente) de la solución (lo que el sistema debe hacer), es más fácil mantener el enfoque adecuado y más fácil de adaptarse a formas alternativas de solucionar el problema.

Crear una visión compartida del dominio del problema:

Los expertos del dominio a menudo se han limitado los conocimientos técnicos, desarrolladores, arquitectos y testers a menudo tienen conocimientos limitados de dominio, los encuestados y otras partes interesadas a menudo tienen poco tiempo para comprometerse con el proyecto y aprender el dominio del problema. Como resultado, las personas a menudo tienen una comprensión inconsistente o pobre del dominio del problema, lo que provoca deficiencias de comunicación y aumenta la probabilidad de que la entrega sea de poco valor para las partes interesadas.

Mejorar y compartir la comprensión de todas las partes del dominio.

Un entendimiento conciso y compartido del dominio del problema aumenta la efectividad de la comunicación y el proyecto. Comience por definir el problema en el documento Visión. A medida que aumenta su comprensión, capture los conceptos clave del dominio y la terminología en un Glosario de Términos para garantizar un uso coherente y compartido de lo que se quiere decir en el dominio del problema.

Use escenarios casos de uso para capturar requisitos:

Hacer uso de escenarios y casos de uso para capturar los requisitos funcionales de tal forma que sea fácil para las partes interesadas de comprender. Los requisitos no funcionales, tales como el rendimiento, la estabilidad, o los requisitos de usabilidad, son importantes y pueden ser documentados como los requisitos de todo el sistema, utilizando técnicas tradicionales.

Establecer y mantener un acuerdo sobre las prioridades:

Tomar decisiones para decidir qué es lo siguiente que se va a desarrollar puede resultar ineficiente, o la identificación de problemas al final del proyecto puede provocar retrasos en el proyecto o incluso el fracaso de este.Priorizar los requisitos para la implementación y trabajando regularmente con los actores durante la evolución del software. Tomar decisiones que aportan valor (factores claves para la evolución y ejecución del proceso de desarrollo de software) y reducen riesgos, mientras se construye el sistema que puede evolucionar en el tiempo.

Realizar un listado de ventajas y desventajas para maximizar el valor:

El costo-beneficio no debe ser independiente de la arquitectura. Establecer beneficios de los requerimientos del sistema a los interesados del sistema, mientras se establece el costo de la implementación de la arquitectura del proyecto. El costo de una prestación puede influir en el valor percibido de las partes interesadas de los beneficios que puede ofrecer el sistema.

Trabajar con las partes interesadas y los miembros del equipo para dar prioridad a las necesidades y desarrollar arquitecturas candidatas para poner en práctica soluciones que ayuden en todo los procesos de desarrollo de software.

Use una arquitectura para evaluar el costo de los beneficios. Posibles soluciones se pueden considerar de alto nivel para determinar la viabilidad arquitectónica del sistema. Diferentes perspectivas arquitectónicas puede hacer que las evaluaciones de costo / beneficio varíen con el tiempo.

Administrar el alcance:

El cambio es inevitable. Aunque el cambio presenta oportunidades para mejorar el valor de los interesados, un cambio sin restricciones resultará en un sistema inflado (lleno de opciones y con posibles errores en la programación), deficiente y las necesidades de las partes interesadas no serán satisfechas.Gestionar el cambio, manteniendo los acuerdos con las partes interesadas. Los procesos modernos siempre gestionan el cambio, adaptando continuamente a estos en el medio ambiente y hacia las necesidades de los interesados. Las expectativas de las partes interesadas y del desarrollador deben ser realistas y alineadas a lo largo del ciclo de vida de desarrollo.

Conozca cuando parar:

El exceso de ingeniería de un sistema no sólo desperdicia recursos, sino también conduce a un sistema demasiado complejo.Un proceso de desarrollo de software termina, cuando este llega a la calidad deseada, o cumple con el alcance planteado. Recuerde que "La calidad es la conformidad con los requisitos". (Haumer, 2007,22).Esto es lo que da un sentido de cierre. Separar el problema de la solución, asegurándose de que la solución, en efecto, resuelve el problema. Después de que los requisitos críticos son implementados y validados.

2. Definir la capacidad de trabajo colaborativo para alinear intereses y compartir conocimiento.

Todo software es creado por personas con diferentes intereses y habilidades que deben trabajar juntos para crear un software eficaz.Desarrollar prácticas que promuevan un entorno de equipo saludable. Un entorno de equipo saludable permite la colaboración eficaz, que alinea los intereses de los participantes en el proyecto (equipo de desarrollo, garantía de calidad, las partes interesadas de productos y clientes) y ayuda a los participantes del proyecto desarrollar una comprensión compartida del proyecto.Dentro de las buenas prácticas para el trabajo colaborativo se tiene:

Mantener un entendimiento común

Todos los participantes en el proyecto requerirán una comprensión común del proyecto para cooperar eficazmente. De lo contrario, los miembros del equipo no podrían alinear su comprensión e intereses, haciendo que estos puedan trabajar con propósitos diferentes. Ser proactivo comunicarse y compartir información con los participantes del proyecto es clave. No dé por sentado que todo el mundo acaba de encontrar lo que necesitan saber, o que cada persona tiene la misma comprensión del proyecto. Usar artefactos (por ejemplo, la Visión, la lista de elementos de trabajo, y requisitos) para alinear el entendimiento entre las partes

interesadas y los desarrolladores. Utilizar la arquitectura para enfocar y alinear los intereses de los desarrolladores. Al final de cada iteración, llegar a un acuerdo sobre si los objetivos de la iteración se han alcanzado y, si no, ¿qué acciones se deben de tomar?

Fomentar un alto nivel de confianza en el ambiente de trabajo

Las personas que no se sienten seguros, no comunican sus ideas, no toman la iniciativa, o admiten su ignorancia. En estos ambientes de trabajo de baja confianza, las actividades deben ser laboriosamente planeadas en detalle, supervisado cuidadosamente, y ampliamente comprobadas. Un equipo de trabajo en un entorno de baja confianza no puede ser capaz de mantenerse al día con los cambios rápidos.Algunas medidas para adoptar una confianza significativa entre el equipo del proyecto pueden ser:Crear un ambiente donde los equipos deben proponerse a sí mismo el cumplimiento de los objetivos de cada iteración, y los administradores servir como mentores de los equipos para ayudarles a completar esos objetivos.Trabajar para eliminar las barreras físicas y mentales que impiden el desarrollo de un entendimiento común entre los participantes del proyecto.Respetar y tratar de entender las perspectivas de los demás antes de criticar sus ideas y responder a sus críticas.La gente, especialmente los técnicos, a menudo responden con el argumento o el desacuerdo, lo que lleva a la rivalidad y establece un orden jerárquico en el que sólo unas cuantas personas contribuyen a la discusión. Desarrollar y fomentar un comportamiento que valora la curiosidad y el interés sobre el argumento y el desacuerdo.Entender que cada uno tiene una perspectiva que es prácticamente invisible para el uno mismo (aunque a menudo se obvia para todos los demás). Desarrollar el hábito de la identificación de los supuestos y los prejuicios en su interior que conducen a la discusión o la falta de comunicación. Aprender a superar estos en el momento de la conversación. Esto requiere práctica. Hay momentos en que otros pueden ser difíciles, pero a menudo el problema puede ser abordado por la lucha libre con su propia perspectiva.Algunas organizaciones operan de una manera que permite a las personas a reconocer sus errores. Algunas organizaciones limitan estas expresiones, pero puede cambiar con el tiempo y esfuerzo. Algunas organizaciones no tienen la tolerancia para el error, y sus trabajadores se ponen en peligro si admiten errores. Entender que las organizaciones de baja confianza tienen más problemas en el logro de sus objetivos y proporcionar un ambiente menos satisfactorio.

Compartir Responsabilidad

Puede haber inconvenientes para los miembros del equipo cuando trabajan solos. La comunicación con el equipo puede llegar a ser esporádicos, o hasta deteniéndose. La gente puede meterse en problemas y no pedir ayuda, o no darse cuenta de que el equipo está en problemas y necesita su ayuda. Su comprensión del proyecto puede llegar a ser desalineados con el resto del equipo. En las peores situaciones, la confianza se rompe como personas del equipo al ver a su mismo equipo de trabajando en fines diferentes a sus intereses.La responsabilidad de los productos de trabajo es compartido. Nada es responsabilidad de otra persona. Esto puede significar tomar con holgura y trabajar con alguien que se está quedando por alguna razón, o pedir ayuda. El personal con experiencia debe ser muy vigilante y velar por los que menos experiencia tienen, animándoles a pedir ayuda si es necesario.

Aprende Continuamente

Continuamente desarrollar habilidades técnicas interpersonales. Aprender de los ejemplos de sus compañeros de equipo. Aproveche la oportunidad de ser a la vez un estudiante de sus compañeros, así como un maestro para ellos. Siempre aumentar su capacidad personal para superar el antagonismo para con otros miembros del equipo.

Organizarse en torno a la arquitectura dada

Dado que los proyectos crecen en tamaño, la comunicación entre los miembros del equipo se vuelve cada vez más complejo. Mientras todos los miembros del equipo entiendan el sistema global, pueden enfocarse principalmente en uno o varios subsistemas que son responsables. Organizarse en torno a la arquitectura también ayuda con la comunicación al proporcionar el equipo con un vocabulario común y un modelo mental compartido del sistema. La comunicación entre los miembros del equipo se vuelve cada vez a un nivel más complejo.

Organizar el equipo en torno a la arquitectura, el vocabulario y un modelo mental compartido del sistema.

3. Centrarse tempranamente en la arquitectura para minimizar los riesgos y organizar el desarrollo

La evolución de la arquitectura ayuda al equipo para hacer frente a la complejidad del proyecto, la mitigación de riesgo, y organizar el desarrollo.La arquitectura de un sistema de software es la organización o estructura de los componentes importantes del sistema que interactúan a través de interfaces, con los componentes cada vez más pequeños y las interfaces del sistema.Sin una base arquitectónica, un sistema va a evolucionar de una manera ineficiente y desordenada. Este sistema resulta a menudo difícil de ampliar, la reutilización, o integrar sin reproceso sustancial. También es difícil de organizar el equipo, o para comunicar ideas sin el enfoque común de técnicas que proporciona la arquitectura.Centrarse en tempranamente en la arquitectura minimiza los riesgos y organiza el desarrollo.

Algunas prácticas para establecer una buena arquitectura son:

Crea la arquitectura de lo que se conoce hoy en día

Como dijo Albert Einstein, "que todo sea tan simple como sea posible, pero no tan simple". Los proyectos de software usan recursos limitados, y el deseo de los desarrolladores es crear soluciones elegantes, que puede llevar a un sistema de mayor complejidad más de lo que las partes interesadas requieren.Cree arquitecturas que se ocupan de las necesidades reales de las partes interesadas, y proporcionar la flexibilidad apropiada y la velocidad de los requisitos como se les conoce hoy en día. Hay una distinción entre el exceso de la arquitectura y la construcción de una arquitectura flexible y extensible. Por ejemplo, puede que no haya una razón aparente para la creación de tres capas de arquitectura en un sistema, pero es probable que el sistema crezca de manera que no se puede predecir, por lo que debemos ver una arquitectura para ello.

Aproveche la arquitectura como una herramienta de colaboración.

La falta de un entendimiento común de los desarrolladores acerca de un sistema lleva a la indecisión y las opiniones contrarias entre los desarrolladores, y rápidamente se puede paralizar el proyecto. Los desarrolladores pueden tener diferentes modelos mentales del sistema y trabajar con propósitos cruzados entre sí.

Crear y desarrollar la arquitectura del sistema con la intención de usarlo para alinear los modelos de los desarrolladores de la competencia mental del sistema. Una buena arquitectura facilita la colaboración al proporcionar un vocabulario común para todas las negociaciones sobre el sistema en desarrollo.

Atacar la complejidad aumentando el nivel de abstracción.

El software es complejo, y la gente tiene una capacidad limitada para hacer frente a la complejidad. Cuando el sistema se hace más grande, es difícil para el equipo desarrollar una comprensión común del sistema, porque es difícil ver el cuadro más grande sobre su arquitectura.Usar modelos para elevar el nivel de abstracción para centrarse en las decisiones importantes de alto nivel, tales como las relaciones y los patrones, en lugar de perderse en los detalles. El modelado eleva el nivel de abstracción, y permite que el sistema sea más fácil de entender desde diferentes perspectivas.

Organizar la arquitectura en "bajo acoplamiento y alta cohesión" (Lyons, 2009,45).

El acoplamiento fuerte entre los componentes hace que un sistema sea frágil y difícil de entender. El software es difícil para crear, por lo que si los componentes existentes pueden ser reutilizados, que pueden reducir el esfuerzo necesario para crear un sistema. Organizar la arquitectura del sistema en componentes para maximizar la cohesión y minimizar el acoplamiento. Esto mejora la comprensión, y aumenta la flexibilidad y oportunidades para su reutilización. Ver figura 2-4.

■ Reutilizar la información existente.

Haga todo lo posible para reutilizar información existente. Los desarrolladores a menudo son reacios a reutilizar algo ya hecho, ya que no satisfacen exactamente sus necesidades, o que simplemente son de mala calidad.

Figura 2-4. Arquitectura de un sistema

"Diseño Propio"

4. Evolucionar continuamente para obtener retroalimentación y mejorar continuamente.

Promover las prácticas que permiten al equipo obtener retroalimentación temprana y continua de los interesados, y demostrar valor incremental a ellos balanceando y priorizando las necesidades de estos para llegar a un acuerdo común entre el interesado y el equipo de trabajo.

Normalmente no es posible conocer las necesidades de todos los interesados, ser consciente de todos los riesgos del proyecto, comprende todas las tecnologías del proyecto, o saber cómo trabajar con sus colegas. Incluso si se pudiera saber todas estas cosas, es probable que cambie durante la vida útil del proyecto. Promover prácticas que permiten al equipo demostrar el valor incremental, obtener retroalimentación temprana y continua de los interesados.La intención detrás de este principio es obtener retroalimentación continua, para mejorar el producto y el proceso del equipo del proyecto. Al proporcionar una estructura y crear una mentalidad de retroalimentación y mejora continua, los cambios se alojan con mayor facilidad. Además, la retroalimentación es capturada pronto y con frecuencia, y los riesgos de alta prioridad se enfrentan al principio del proyecto. Constantemente identificar y atacar a los riesgos, hay más confianza en el progreso del proyecto y la calidad.No sólo el producto debe evolucionar, sino también el equipo para colaborar y participar con las partes interesadas. El proceso seguido por el equipo puede ser ajustado en consecuencia para aprovechar las lecciones aprendidas y ajustar el ritmo de proyectos y necesidades.

Alguna practicas a Considerar:

Desarrolle el proyecto por iteraciones.

El desarrollo de un sistema en un solo paso lineal es difícil, porque hace que sea costoso para incorporar nuevos cambios y conocimientos. Peor aún, puede retrasar el descubrimiento y la mitigación de los riesgos, debido a los esfuerzos de desarrollo que se han programado más adelante en el ciclo de vida del proyecto.Divida su proyecto en una serie de iteraciones en el tiempo, y el plan de su proyecto de forma iterativa. Esta estrategia iterativa le permite entregar gradualmente las capacidades (como un subconjunto ejecutable, utilización de los requisitos implementado y probado) que pueden ser evaluados por los actores al final de cada iteración. Esto proporciona retroalimentación rápida y oportuna, para que los temas puedan ser abordados y las mejoras realizadas a un costo menor. Además, esto se logra, mientras que todavía tenga suficiente presupuesto y tiempo para hacerlo. El desarrollo iterativo permite a los equipos una mejora continua de software en todo el ciclo de desarrollo.

Enfoque iteraciones en el cumplimiento de los hitos.

Un proyecto puede parecer que avanza al mismo tiempo que los riesgos y problemas sin resolver se acumulan. Concentrarse en llevar el cierre de temas importantes del proyecto (tales como la concurrencia de las partes interesadas sobre el alcance y probar la arquitectura propuesta).Divida el proyecto en fases (por ejemplo, Concepción, Elaboración, Construcción y Transición), en cada fase que tiene un hito de gestión claramente visible. El enfoque de cada iteración dentro de una fase es la consecución de ese hito.

Gestione los riesgos.

Aplazar temas difíciles y arriesgadas hasta finales de un proyecto aumenta significativamente el riesgo de fracaso del proyecto. El aplazamiento puede dar lugar a la inversión en malas tecnologías, un mal diseño, o un conjunto de requisitos que no pueden atender las necesidades de los interesados.Los riesgos de ataque temprano, o que te ataque. Continuamente identificar y priorizar los riesgos, luego diseñar estrategias para mitigarlos. Determinar el foco de iteraciones sobre la base de los riesgos. Por ejemplo, los riesgos de gran importancia arquitectónica deben abordarse al comienzo del proyecto, a más tardar al final de la fase de elaboración, cuando la arquitectura ha sido probada y tiene su línea base.

Gestione el cambio.

Para satisfacer las necesidades del cliente, normalmente existe la necesidad de introducir cambios en el proyecto, pero el cliente debe ser consciente del impacto que esos cambios tienen en el costo del proyecto y en el cumplimiento del cronograma. Si es necesario, documente los cambios. Para los proyectos informales, un debate con las partes interesadas puede ser suficiente.

Medir el progreso objetivamente

Si no sabe cómo medir objetivamente el progreso del proyecto, no sabría si está incurriendo en omisiones presentes o futura del proyecto en el que se encuentra. La incertidumbre y el avance de un proyecto de software es difícil de medir objetivamente, y la gente es propensa a hacer una evaluación objetiva de la información subjetiva. Obtener una imagen clara del estado del proyecto, es decir medir objetivamente el progreso. La mejor medida de progreso es la entrega de programas de trabajo (entregables del proyecto), que es algo que se hace mediante la adopción de un enfoque evolutivo. También puede definir un conjunto de métricas objetivas para recoger en una iteración (por ejemplo, los requisitos que se han implementado y validado, el número de defectos emitidos en comparación con el número fijo encontrado anteriormente) y la revisión como parte de la evaluación de la iteración.

Reevaluar continuamente que es lo que se está haciendo.

Hacer preguntas y verificar hipótesis sobre el estado del proyecto siempre sobre una base regular. Reunirse regularmente con el equipo para el seguimiento del estado e identificar los riesgos y problemas. Esto se puede hacer todos los días cuando el equipo se reúne para compartir el estado de las responsabilidades individuales e identificar y abordar ciertos temas. Al final de las iteraciones, evaluar el estado de lo que se ha hecho y buscar áreas de mejora que se pueden abordar en la siguiente iteración. Tener una revisión retrospectiva en el final de las lecciones aprendidas del proyecto y la captura para ejecutar proyectos futuros de una manera más eficiente. Si nosotros siempre cuestionamos lo que hacemos y buscamos nuevas formas e innovadoras de desarrollar software, podemos mejorar nuestra forma de trabajar. Esto lleva a mejorar los resultados del proyecto.

Lección 2: Ciclo de Vida del Open UP

Open UP tiene un proceso para el desarrollo iterativo a lo largo de cuatro fases. Los patrones del modelo de iteraciones se aplican tantas veces como sea necesario, dependiendo de cuántas iteraciones el equipo decide ejecutar en cada fase. Los proyectos con diferentes necesidades pueden crear instancias de modelos de iteración diferentes. Por ejemplo, un proyecto sobre una tecnología desconocida o arquitectura compleja puede necesitar más iteraciones en la fase de elaboración de un proyecto sobre una tecnología conocida o una arquitectura preexistente. Ver figura 2-5.

Figura 2-5. Ciclo de vida del OpenUP

http://www.eclipse.org/epf/general/EPF_lnstallation_Tutorial_User_Manual.pclf

Comprende:

A. Fase de Incepción

La fase de incepción es la comprensión del alcance y objetivos del proyecto y obtener la información suficiente para confirmar que el proyecto debe continuar o para definir que no es conveniente para el proyecto a realizar.El objetivo en esta fase es lograr la concurrencia entre todas las partes interesadas sobre los objetivos del ciclo de vida del proyecto.Hay cuatro objetivos de la fase de incepción que aclarar en el alcance, los objetivos del proyecto y la viabilidad de la solución previsto:

Entender qué construir. Determinar una visión global, incluyendo el ámbito de aplicación del sistema y de sus límites. Identificar los actores: ¿quién está interesado en este sistema y cuáles son sus criterios de éxito?

Identificar las principales funcionalidades del sistema. Decida qué requisitos son los más críticos.

Determinar por lo menos una posible solución. Evaluar si la visión es técnicamente factible. Esto puede implicar la identificación de una arquitectura de alto nivel o haciendo prototipos técnicos, o ambas cosas.

Entender la estimación de alto nivel sobre el costo, horario, y los riesgos asociados con el proyecto.

Puntos a considerar para esta fase:

Dependiendo del ámbito del proyecto, estas pueden tener una o más iteraciones, estas van a depender de lo siguiente:

Si el proyecto es grande, y es difícil de definir su ámbito de aplicación. Dependiendo del alcance del proyecto, si el alcance es muy amplio y cuesta trabajo definir el análisis para el inicio del mismo, como por ejemplo Visión, Plan de Proyecto, etc., es recomendable establecer iteraciones para el desarrollo de estas tareas dentro del ciclo de vida del proceso de desarrollo del software.

Sistema sin precedentesCuando no existen información alguna sobre sistemas realizados anteriormente del mismo tipo o afinidad sobre el cual se va a desarrollar.

Demasiada partes interesadas con las necesidades de la competencia y las complejas relaciones.Dentro de un proyecto, en algunos existirán varias partes interesadas dentro del proyecto que tengan diferentes puntos de visión sobre las funcionalidades, objetivos o la visión del sistema, entonces para ello es recomendable ver y evaluar estos requerimientos y llegara un punto común entre las partes interesadas (stakeholders).

Riesgos técnicos importantes demanda la creación de un prototipo o prueba de concepto.Uno de los puntos a considerar muy tempranamente al momento de concebir la idea de un sistema, es definir la arquitectura, especificando como va a ser desarrollado, cuantas capas, que patrones se va a usar, que librerías, como va a ser su diagrama de red, etc. Ahora dependiendo de la complejidad y de la factibilidad del desarrollo de esto, es necesario realizar pruebas unitarias, así como también pruebas de factibilidad para poder verificar su correcta implementación y la minimización de riesgo de fracaso del proyecto.

B. Fase de Elaboración

Esta es la segunda de las cuatro fases del ciclo de vida del proyecto, cuando se abordan los riesgos de gran importancia arquitectónica.El propósito de esta fase es establecer la línea base de la arquitectura del sistema y proporcionar una base estable para la mayor parte de los esfuerzos de desarrollo en la siguiente fase.

Objetivos para esta fase:

Los objetivos para la fase de elaboración que ayudan a abordar los riesgos relacionados con los requisitos, la arquitectura, los costos y la programación:

Obtener una comprensión más detallada de los requisitos.

Tener una buena comprensión de la mayoría de los requisitos le permite crear un plan más detallado y para obtener la aceptación de los stakeholders. Asegurar de obtener una comprensión a fondo de los requisitos más importantes para ser validado por la arquitectura definida.

Diseñar, implementar, validar y establecer la línea base para la arquitectura. Diseñar, implementar y probar una estructura esquelética del sistema. Aunque la funcionalidad todavía no está completa, la mayoría de las interfaces entre los bloques de construcción están implementados y probados. Esto se refiere a una arquitectura ejecutable.Mitigar los riesgos esenciales, y producir programación precisa y estimaciones de costos. Muchos riesgos técnicos se tratan como resultado de detallar los requisitos y de diseño, implementación y pruebas de la arquitectura. Filtrar y detalle el plan de proyecto de alto nivel.

Puntos a considerar para esta fase:El número de iteraciones en la fase de elaboración depende, pero no limita a, factores tales como el desarrollo en comparación con el ciclo de mantenimiento, sistema sin precedentes en comparación con la tecnología conocida y la arquitectura, y así sucesivamente.

Por lo general, en la primera iteración, es mejor para diseñar, implementar y probar un pequeño número de escenarios críticos para identificar qué tipo de mecanismos de arquitectura necesita, para que pueda mitigar los riesgos más importantes. También detalle los requisitos de alto riesgo que deben abordarse al comienzo del proyecto.

Durante las iteraciones posteriores, corregir lo que no estaba bien de la iteración anterior. A diseñar, implementar y probar el resto de escenarios de gran importancia arquitectónica, para garantizar que se pueda revisar todas las áreas principales del sistema (cobertura de arquitectura), de modo que los riesgos potenciales son identificados lo más pronto posible.

C. Fase de Construcción

Esta fase se centra en el diseño, implementación y pruebas de las funciones a desarrollar en un sistema completo.El propósito de esta fase es completar todo el desarrollo del sistema basado en el lineamiento de la arquitectura definida en la fase anterior.Existen objetivos para esta fase que nos ayudan a tener un "desarrollo sostenible del producto completo, en otras palabras, una versión operativa de su sistema que se puede implementar en la comunidad de usuarios" {Cleland y King,1976,349)

Objetivos para esta fase:

Desarrollar iterativamente un sistema completo que está listo para la transición a su comunidad de usuarios.

Describir los requisitos restantes, completar los detalles del diseño, la aplicación completa, y probar el software.

Liberar la primera versión operativa (beta) del sistema y determinar si los usuarios están listos para la aplicación a desplegarse.

Consideraciones:

Usualmente, la fase de construcción tiene más de una sola iteración, generalmente de más de 2 iteraciones, esto va a depender del tipo de proyecto que se va a realizar, en otras palabras del alcance del sistema, el cual se puede tomar estas consideraciones al momento de establecer el número de iteraciones a desarrollar:

Si el sistema a desarrollar es simple, solo use una sola iteración para el desarrollo del producto, no es necesario más iteraciones, ya que incurriría a una extensión de tiempo innecesaria para la realización de la misma.

Para un sistema mediando, realice 2 iteraciones como base, una para mostrar el sistema de forma parcial y otra para mostrar el sistema Release a ser testeado por los usuarios.

Para proyectos grandes, establezca como base 3 o más iteraciones, dependiendo de la envergadura del proyecto.

D. Fase de Transición

Esta fase se centra en el diseño, implementación y pruebas de las funciones a desarrollar en un sistema completo.El propósito de esta fase es completar todo el desarrollo del sistema basado en el lineamiento de la arquitectura definida en la fase anterior.Existen objetivos para esta fase que nos ayudan a tener un "desarrollo sostenible del producto completo, en otras palabras, una versión operativa de su sistema que se puede implementar en la comunidad de usuar/os" (Crosby, 1979,87)

Esta fase se centra en el despliegue de software a los usuarios y asegurar que las expectativas de los suyos sobre el software se cumplieron satisfactoriamente.El propósito de esta fase es asegurarse que el software desarrollado esta listo para entregarse a los usuarios finales.Existen objetivos para la fase de transición que le ayudan a la "funcionalidad de afinar, el rendimiento y la calidad global del producto beta desde el final de la fase anterior" (Kroll P, 2003,136)

Objetivos para esta fase:

Pruebas "BETA" para verificar que se cumplan las expectativas de los usuarios finales. Este objetivo implica trabajar con la gestión de cambios dentro del sistema, es decir corregir errores de programación, funcionalidad; hacer mejoras y dar mayor facilidad de uso a los usuarios finales.

Lograr la aceptación de los stakeholders que el despliegue del sistema se ha completado con éxito. Lograr la aceptación puede implicar varios niveles de pruebas de aceptación que se le pueden realizar al sistema, esto incluye pruebas formales, como por ejemplo, pruebas de estrés, pruebas funcionales, etc., así como también pruebas informales y pruebas a la versión beta.

Mejorar el rendimiento futuro del proyecto a través de lecciones aprendidas. Documentar las lecciones aprendidas y mejorar el entorno del proceso así como también las herramientas para el proyecto.

Esta fase de transición puede ser parte dentro de su ejecución, el uso de sistemas antiguos y nuevos en paralelo, la migración de datos, formación de usuarios, así como también los ajustes del proceso de negocio.

El número de iteraciones en esta fase varía de una iteración de un sistema simple que requiere principalmente de errores mínimos que se puedan suscitar, para muchas iteraciones de un sistema complejo, que implica la adición de funciones y la realización de actividades para hacer la transición del negocio de utilizar el antiguo sistema a usar el nuevo sistema.Cuando los objetivos de la fase de transición se cumplen, el proyecto se puede finalizar. Para algunos proyectos de software, al final del ciclo de vida del proyecto actual puede coincidir con el inicio del ciclo de vida del mismo u otro proyecto, lo que lleva a la siguiente generación del mismo producto (el final del desarrollo de un producto puede estar definido como una primera fase, y el comienzo de una segunda fase se puede tomar como el inicio de otro proyecto).

1.3. Lectura

Metodologías tradicionales versus Metodologías Ágiles.

Las metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el objetivo de conseguir un software más eficiente y predecible.Para ello, se hace un especial hincapié en la planificación total de todo el trabajo a realizar y una vez que esta todo detallado, comienza el ciclo de desarrollo del producto software. Este planteamiento está basado en el resto de disciplinas de ingeniería, a pesar de que el software no pueda considerarse como la construcción de una obra clásica de ingeniería.Con estas metodologías se lleva trabajando desde hace tiempo y no ha habido en ningún caso ninguna experiencia traumática acerca de su uso. Pero aun así, han recibido diversas críticas, y la más común hace referencia a su carácter excesivamente burocrático, y como afirma Fowler (2001), este hecho ha llevado a identificarlas como metodologías monumentales.Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar. En contraposición a estas metodologías clásicas, en los últimos años ha aparecido un nuevo grupo de metodologías, que se identifica como metodologías ágiles. Aportan como novedad, nuevos métodos de trabajo que apuestan por una cantidad apropiada de proceso. Es decir, ni se pierden en una excesiva cantidad de cuestiones burocráticas ni defienden tampoco la falta total de proceso. Buscan el equilibrio en la relación proceso/esfuerzo. Las diferencias existentes entre ambos grupos de metodologías surgen por un enfoque y objetivos diferentes. Y como principales diferencias, Fowler (2001) identifica las siguientes:

Las metodologías ágiles son adaptativas más que predictivas. Las metodologías tradicionales potencian la planificación detallada de prácticamente todo el desarrollo software a largo plazo. Pero cuando se produce un cambio, toda esta planificación puede venirse abajo. Sin embargo, las metodologías ágiles proponen procesos que se adaptan y progresan con el cambio, llegando incluso hasta el punto de cambiar ellos mismos.

Las metodologías ágiles están orientadas al personal más que orientadas al proceso. Intentan trabajar con la naturaleza del personal asignado al desarrollo, más que contra ellos, de tal forma que permiten que la actividad de desarrollo software se convierta en una actividad grata e interesante. Existen diversas metodologías que coinciden en llamarse metodologías ágiles. Y aunque entre ellas comparten muchas características tienen también diferencias significativas. A continuación se presentan algunas de las metodologías ágiles más representativas.

Extreme Programming (XP) - La programación extrema (Beck, 1999; Me Breen, 2000) concede una gran importancia a las pruebas del software (testing). Aunque la mayoría de los procesos las tienen en cuenta, generalmente lo contemplan de una forma demasiado ligera y superficial. Sin embargo, XP lo toma como base para el desarrollo y cada programador que escribe código también escribe los casos de prueba. Estos

forman parte del proceso continuo de generación de código y se integra continuamente con ello, lo que garantiza una plataforma estable para el futuro desarrollo. Sobre dicha plataforma se genera un proceso de diseño evolutivo, que es la base del sistema y que se enriquece con cada iteración. Nunca se generan diseños futuros. Según afirma Fowler (2001), el resultado es un proceso de diseño que combina adecuadamente la disciplina con la adaptabilidad.

Open source - Open source apuesta por la distribución de trabajo entre diferentes equipos, al igual que ocurre con la mayoría de los procesos adaptativos. La mayoría de los proyectos open source cuentan con supervisores de código. Estos supervisores de código, son las únicas personas autorizadas para realizar un cambio en el repositorio del código fuente. Por otra parte, el resto del personal puede realizar cualquier cambio en el código base. Sin embargo, el supervisor del código es la persona responsable de coordinar y de mantener la consistencia del diseño del software. Una de las principales ventajas de los desarrollos open source es que la depuración es altamente paralelizable, aunque un gran número de personas puedan verse involucradas. Cuando se soluciona un error, se envía la solución al supervisor de código, lo que garantiza que alguien realiza la modificación de forma fiable mientras otra parte del personal se dedica a las tareas de depuración.

Paloma Cáceres, Esperanza Marcos (2010). Procesos Ágiles para el Desarrollo de Aplicaciones W. Madrid. Grupo Kybel. pp 2.

1.4. Actividades

Investigar las diferencias que existen entre métodos de programación ágiles y métodos de programación tradicionales, cual es el impacto al usar uno de ellos en un proyecto de desarrollo de software, que variables se verían afectados en cuanto al coste, alcance y tiempo, y en qué tipos de proyectos se podrían usar.

1.5. Autoevaluación

a. En la fase de Incepción, según el modelo planteado, ¿Se puede desarrollar pequeños módulos visuales para que el usuario pueda entender el alcance del proyecto?, ¿Porque?

b. Cuáles son las principales diferencias entre la fase de elaboración y la fase de construcción en cuanto al desarrollo de software.

c. Actividades como, capacitación a los usuarios, pruebas funcionales completas de software, pertenecen a la fase de:

a. Transiciónb. Construcciónc. Incepciónd. Elaboracióne. Todas, ya que es una actividad que permanece en todo el tiempo que dura la ejecución del proyecto.

d. Enuncie un ejemplo de cierre de proyecto y de inicio de proyecto, tomando en consideración que el cierre de este da paso a la consecución de un nuevo proyecto.

e. Cuando y como se debería iterar las acciones a tomar en la fase de Incepción, diga algunos ejemplos.

f. Defina usted, como afecta el entorno dentro de un proyecto y que tipos de estos pueden ser beneficiosos o no en la ejecución del mismo.

g. Defina las diferencias y similitudes existentes entre metodologías agües y tradicionales.

h. Dentro de la incepción se establecen ciertos documentos que pertenecen al control y ejecución de un proyecto, diga usted qué documento principal es una entrada para generar el Plan de Proyecto.

i. Cuál de estos artefactos no pertenecen a la gestión del proyecto.

a. Visiónb. Plan de Proyecto.c. Checkiistd. Items de Trabajoe. WBS.

j. Si usted fuera un Project Manager y tiene un proyecto valorizado en 240 k (240 mil dólares) para un plazo de 9 meses, dividido por 2 etapas. Diga usted qué modelo usaría y ¿Por qué?.

1.6. Exploración oniine

http://www.eclipse.org/epf/ http://www.eclipse.org/proposals/beacon/Who%20will%20benefit%20from%20Eclips

e%20Process%20Framework.pdf http://www.eclipse.org/epf/general/EPF_lnstallation_Tutorial_User_Manual.pdf http://dev.eclipse.org/newslists/news.eclipse.technology.epf/maillist.html

1.7. Referencias Bibliográficas

Cleland y King (1976), Systems Analysis and Project Management, Nueva York. McGraw-Hill.

Open UP, Fuente [Trabajo Iterativo], Imagen de licencia de libre uso, establecido por la Eclipse Public License, 2008

Lyons, B (2010). The Open Unified Process: A Brilliant, Collaborative March into Open,

Kroll, P. and Kruchten, P (2003). The Rational Unified Process Made Easy, Addison Wesley,

Crosby, Philip (1979). Quality is Free: The Art of Making Quality Certain, McGraw-Hill.

Haumer Peter (2007), Eclipse Process Framework Composer, Second Revisión

Tercera Unidad1. Eclipse Process Framework- EPF

1.1. Orientación y propósitos

Aprender y utilizar la herramienta EPFC (Eclipse Process Framework Composer) a fin de construir y editar fragmentos de método, procesos o metodologías, y generar automáticamente la documentación respectiva.

1.2. Sumario

La unidad comprende 2 lecciones:

Lección 1: Eclipse Process Framework- EPFLección 2: Eclipse Process Framework Composer- EPFC

Lección 1Eclipse Process Framework- EPF

A. ConceptoEPF es un proyecto de código abierto dentro de la Fundación Eclipse que tiene como objetivo proporcionar un marco extensible, que incluye varios procesos ya desarrollados y una herramienta para la ingeniería de procesos.

B. Elementos claveTodos los usuarios de un proceso de desarrollo de software deben estar familiarizados con 4 conceptos básicos.

Work Product:

Que es lo que se va a producir. Ejemplo:Los work products pueden tomar varias formas tales como:

Documentos como: Visión, Plan de Proyecto. Un modelo como: modelo de casos de uso. Base de Datos, hojas de cálculo, otros elementos de recolección de información. Código fuente y ejecutables. Prototipos del sistema, etc.

Rol:Un rol define el comportamiento y responsabilidades de un individuo o un conjunto de individuos que trabajan juntos como un equipo, en el contexto de una organización de ingeniería de software. Por ejemplo:

Analista - Representa a clientes y usuarios finales, reúne información de los interesados y define los requisitos.

Desarrollador - Desarrolla una parte del sistema, incluyendo el diseño, implementación, pruebas unitarias y de integración.

Tarea:Una tarea es el trabajo realizado por un rol. Por lo general se define como una serie de pasos que implican la creación o actualización de uno o más work products. Por ejemplo:

Desarrollar una visión, que comprende desarrollar una visión global del sistema, incluyendo la captura del problema a resolver, las principales partes interesadas, el alcance y los límites del sistema, las principales características del sistema, y las limitaciones de estas.

Plan de Iteración, que define el alcance y las responsabilidades de una sola iteración.

Proceso:

Define una estructura de trabajo o workflow. Ver Figura 3-1

Figura 3-1. Ejemplo de proceso del EPF Composer

"diseño propio"

Lección 2

Eclipse Process Framework Composer- EPFC

A. Concepto

EPF Composer es una herramienta que proporciona un entorno para la definición, adaptación, gestión y comunicación de los procesos de desarrollo. Un proceso de edición que puede definir quién hace qué, cuándo y cómo. Pueden proporcionar orientación, plantillas y otros materiales de apoyo y publicar la información como un sitio web en una intranet corporativa.

Lo que busca esta herramienta es la de compartir y alinear el trabajo colaborativo en cuanto a la gestión del desarrollo de software.

Al separar el contenido del método, que define los roles, los productos de trabajo (work products), tareas, y la orientación del proceso, que define las fases, iteraciones, actividades y tareas en el contexto de una estructura de división del trabajo, se puede reutilizar el contenido a través de proyectos, fases e iteraciones, adaptando el ciclo de vida para satisfacer las necesidades específicas del equipo del proyecto. Este enfoque apoya efectivamente la definición del proceso de arriba hacia abajo (fases, iteraciones, y actividades), la definición del proceso de abajo hacia arriba (papeles, productos de trabajo y tareas), o una combinación de los dos. La figura 1 muestra la interfaz de usuario EPF Composer. Ver Figura 3-2.

Entonces EPF Composer:

Sirve como base para una evolución de diferente software de código abierto dentro de los procesos de desarrollo de software.

Proporciona herramientas, un gran modelo unificado y contenido que se puede utilizar como base para una gran variedad de procesos para hacer frente a las necesidades de TI.

Utiliza la comunidad Eclipse para obtener una amplia aceptación del framework.

Figura 3-2. Interfaz de Usuario del Epf Composer

"diseño propio" - Eclipse IDE

Como se puede apreciar en la figura anterior, el EPF composer se divide en 4 partes importantes:

Visor de Librerías:A partir de esta área de la ventana se pueden agregar, extender, modificar, adaptar las librerías correspondientes al EPF, para poder definir roles, productos de trabajo, etc. y estos van a estar agrupados en dos grandes grupos, la parte de procesos, y la parte del método. Ver Figura 3-3.

Figura 3-3: Visor de Librerías

"diseño propio" - Eclipse IDE

Panel de Configuración:En esta parte de la ventana se podrá elegir entre varias metodologías o procesos que se tengan implementado en el EPF Composer, cada una de ellas tiene diferente paquetería en cuanto al orden de sus archivos, roles, productos de trabajo, etc. Ver Figura 3-4.

Figura 3-4. Panel de Selección de Configuración

"diseño propio" - Eclipse IDE

Visor de Configuración:Todo modelo que se extienda o adapte dentro del EPF Composer, se tiene que basara en una configuración previamente seleccionada en el panel de configuración, y este se va a poder visualizar en el Visor de Configuración del EPF. Ver Figura 3-5.

Figura 3-5. Visor de Configuración.

"diseño propio" - Eclipse IDE

Vistas del Modelo:Estas vistas permiten visualizar el modelo seleccionado en forma de solo exploración o también en forma de Autoría, esto implica que se va a poder adaptar, modificar y extender, si fuera necesario. Ver Figura 3-6.

Figura 3-6: Tipo de vistas del modelo dentro del EPF Composer

"diseño propio" - Eclipse IDE

B. Ecosistema EPF ComposerEPF Composer trabaja con un ecosistema amplio y variado de software para componer esta interfaz, que liace que sea extensible, adaptable y ligero. En la figura 3-7 se muestra el ecosistema general en la cual se construye EPF Composer.

Figura 3-7: Ecosistema de Software del EPF Composer

http://www.eclipse.org/downloads/download.php?file=/technology/epf/general/EPFC_10/Eclipse%20Process%20Framework%20Composer%201.0.html&r=1

Como se puede observar EPF Composer es una adaptación del software Eclipse, el cual es su base con la que trabaja este software y mantiene como componentes (plugins) las librerías que a este pueden ser añadidas, desde Open UP/Basic hasta otros modelos como Serum, Rup, XP, etc.

C. Instalando EPF ComposerPara poder instalar EPF Composer, primero se tiene que tener instalado el JDK, o el JRE, para su posterior ejecución del programa. Luego de ello ir al siguiente sitio web y descargar la

última versión del EPF Composer (1.5.1.1, actualizado al 30 de Setiembre del 2010). Ver figura 3-8.http://www.eclipse.org/epf/downloads/tool/tool_downloads.php

Figura 3-8: Pagina de descarga del EPF Composer

http://www.eclipse.ora/eDf/downloads/tool/tool _downloads.Php

Descargar las librerías necesarias para anexarlas al EPF Composer cuando este ejecutándose en el sistema, para ello ir a la siguiente página y descargar la última versión de la librería (1.5.1.1). Ver figura 3-9.

http://www.eclipse.org/epf/downloads/praclib/praclib_downloads.php

Figura 3-9: Página de descarga de librerías

http://www.eclÍDse.ora/eDf/downloads/Draclib/Draclib_downloads.php

Luego de descargado el EPF Composer y también la librería, descomprimir en una carpeta del ordenador, y luego después de ello ejecutar el archivo eclipse.exe. Ver figura 3-10.

Figura 3-10. Listado de archivos del EPF Composer

"diseño propio" - Eclipse IDE

Descomprimir también el archivo descargado de la librería en una carpeta del ordenador, y este al ser descomprimido tendrá el siguiente nombre: epf_practicesjibrary_1.5.1.1_20101130, correspondiente a la versión descargada.

inmediatamente después de ejecutar el archivo eclipse.exe, aparecerá la ventana inicial del EPF Composer, para poder anexar las librerías. Ver figura 3-11.

Figura 3-11. Pantalla Principal del EPF Composer

"diseño propio" - Eclipse IDE

Para adjuntar la librería donde se encuentra el proceso del Open UP/Basic, hacer click en File -> Open -> Method Library y aparecerá una ventana, seleccionar la ruta de la carpeta donde se descomprimió la librería. Ver figura 3-12.

Figura 3-12: Añadiendo librerías del EPF Composer.

"diseño propio" - Eclipse IDE

Luego de ello, dar clic en finish, luego de ello cerrar la ventana welcome y aparecerá en el visor de librerías el proceso definido por la librería. Ver figura 3- 13.

Figura 3-13. Ventana principal del EPF Composer con la librería anexada.

'diseño propio" - Eclipse IDE

EPF Composer ya se encuentra instalado.

D. Trabajando con Open UP/BasicOpen UP/Basic es el proceso que define el modelo Open Up, y que tiene como plataforma de implementación principal el EPF Composer, ya que este lo toma como configuración principal dentro del EPF Best Practices.Dentro del proceso Open UP/Basic, este no da como parte principal el desarrollo de los productos de trabajo iniciales que vendrían a ser el Documento de Visión y el Plan de Proyecto, el cual estos vienen a estar definidos dentro de un rol establecido.Trabajando con la gestión del proyecto dentro del EPF, vamos a configurar el modelo dentro de este proceso, para la creación de los roles con sus respectivas tareas y detallando cada una de ellas.

Definiendo Roles y Tareas dentro del EPF Composer.

a. Seleccionamos una configuración por defecto en primer lugar (openup). Ver figura 3-14.

Figura 3-14: Seleccionando Open UP dentro del EPF Composer

'diseño propio" - Eclipse IDE

b. Creamos una nueva plugin que extienda del Open UP/Basic. Ver figura 3-15.a. File New Method Plugin.

Figura 3-15: Creando un nuevo method-plugin

"diseño propio" - Eclipse IDE

c. Escribimos el nombre del método a crear, una breve descripción del método y quiénes son los autores del mismo, un factor importante es establecer a que plugins va a ser referencia nuestro método, ya que sin esa referencia no vamos a poder crear una organización de nuestro proyecto, para nuestro ejemplo y curso, utilizaremos el publish.openup.base. y luego daremos clic en finish. Ver figura 3-16.

Figura 3-16: Plantilla principal del método creado por el EPF Composer

"diseño propio" - Eclipse IDE

d. Se puede observar que en la plantilla general de la creación del plugin se agregan más opciones para poder completar, eso va a depender que tanto se desea tener documentado el plugin a crear, para nuestro ejemplo, solo hemos agregado información en "Presentation Name", "Versión" y en "Change Date".

e. Para crear roles dentro del Open UP/Basic, estos se tiene que definir dentro de un paquete de contenidos, para ello es necesario crear uno nuevo dentro de nuestro plugin.Click derecho sobre Content Package New Content Package.Escribimos el nombre del paquete de contenido, su nombre de presentación, así como también una pequeña descripción del mismo.Vemos en la parte derecha como se va creciendo el plugin creado de acuerdo a nuestras necesidades. Ver figura 3-17.

Figura 3-17: Creación de un nuevo Paquete de Contenido

"diseño propio" - Eclipse IDE

f. Luego de liaber creado el paquete de contenido, ya se puede crear lo roles sobre el cual se va a gestionar el proyecto, para nuestro caso, para la creación del primero documento (Visión), según UML y Open UP/Basic (Open Up/Basic se basa en UML) este tiene que ser definido por el analista como actor principal como rol secundario el Project Manager.Entonces pasamos a crear los roles correspondientes. Ver figura 3-18.Click derecho en roles new Role

Figura 3-18: Creación de un rol

"diseño propio" - Eclipse IDE

g. Se puede observar que la plantilla general de creación de un rol, es muy parecida al de la creación de plugin, definido anteriormente. EPF Composer trabaja bajo la misma estructura para todos sus componentes que son creados sobre él, lo que va a cambiar de acuerdo a que

componente es creado, es en la parte de Las PESTAÑAS que se pueden observar en la parte inferior de la ventana definido de la siguiente manera:

Description | Work Products | Guidance | Categories | Preview. Ver figura 3-19.

Figura 3-19: Acciones predefinidas para un Rol

"diseño propio" - Eclipse IDE

Description:Define una descripción detallada del componente que va a ser creado dentro del EPF, sobre esta plantilla se puede modificar todas las propiedades generales del componente.

Work Products:Son los productos que van a verse influenciados en la creación de un componente, en el caso del analista vendrían a ser los productos de trabajo que están bajo la responsabilidad de ese rol.

Guidance:Todo tipo de orientación que puede ser añadida para la mejor comprensión del componente creado, esta orientación puede ser, conceptos, paper, página web, etc.

Categories:Define la agrupación a un nivel superior del rol o producto de trabajo definido dentro del EPF Composer.

Preview:Es la pre visualización web del componente creado, y como este se va estructurando para poder ser accedido en la red mediante un navegador web cuando este sea exportado para su publicación. Ver figura 3-20.

Figura 3-20: Ejemplo de pre visualización web para el rol Analista

"diseño propio" - Eclipse IDE

h. Luego, para crear una tarea, es necesario hacerlo desde el panel de librerías, se sigue casi el mismo procedimiento anterior, con la diferencia que esta vez sería sobre tasks. Ver figura 3-21.Click derecho sobre tasks New Task

Figura 3-21. Plantilla para la creación de una tarea

"diseño propio" - Eclipse IDE

i. Si nos fijamos en las PESTAÑAS, vemos que están han aumentado en comparación cuando se creó un rol, esto se debe a que EPF Composer, reconoce por defecto el tipo de componente que es creado y organiza estas ventanas de acuerdo a la necesidad de cada componente, en este caso se detallarán Steps y Roles, ya que no se detallaron de forma genérica en las partes anteriores.

Steps:

Define los pasos debidamente ordenados en orden cronológico de realización para la creación de una tarea.Para añadir pasos a la tarea creada, solo basta con hacer clic en add. Ver figura 3-22.

Figura 3-22. Plantilla para la creación de una tarea

"diseño propio" - Eclipse IDE

Roles:Establece los roles asignados para una determinada tarea, este se puede definir como rol principal, o como rol secundario. Ver figura 3-23.

Figura 3-23. Plantilla para adjuntar roles

"diseño propio" - Eclipse IDE

Para adjuntar un rol, es necesario hacer clic en add, e inmediatamente después aparecerá una ventana para la búsqueda de los roles definidos anteriormente, procedemos a buscar nuestro rol "Analista". Ver figura 3-24.

Figura 3-24: Plantilla para la búsqueda de componentes.

'diseño propio" - Eclipse IDE

En cuanto a la búsqueda de componentes, sean estos, roles, productos de trabajo, orientación, tareas, etc. EPF trabaja con un plugin de apache que permite buscar sobre todo el proyecto con el cual se encuentra trabajando mediante patrones definidos de búsqueda, como podemos observar en la Figura 23, esta búsqueda soporta comodines como *, para definir uno o más caracteres de búsqueda sobre toda la gestión del modelo generado.Luego de haber seleccionado el rol, dar clic en Ok, y este se agregará por defecto a la plantilla anterior. Ver figura 3-25.

Figura 3-25. Rol añadido a la plantilla de roles de la creación de tareas.

'diseño propio" - Eclipse IDE

Definiendo Productos de Trabajo y Orientaciones dentro del EPF Composer.

a. Siguiendo con el ejemplo anterior y habiendo definido las actividades definidas anteriormente, ahora procederemos a crear los productos de trabajo y anexarlos a los roles

correspondientes para poder visualizar como iría quedando la gestión del software. Ver figura 3-26.Click derecho en Work Products New Artifact

Figura 3-26. Creación de un Work Product.

"diseño propio" - Eclipse IDE

b. Cuando se crea un work product, en la ventana principal del EPF Composer, aparece una nueva pestaña denominado State.

State:Define el estado de un producto de trabajo.Para definir un estado de trabajo, primero hay que administrar los estados del mismo. Para ello nos tenemos que ubicar en la pestaña State, luego inmediatamente después hacemos click en "Manage State". Nos aparecerá una ventana para administrar (crear, editar, eliminar) estados, procedemos a dar click en "Add". Ver figura 3-27.

Figura 3-27. Creación de un estado para un Producto de Trabajo.

"diseño propio" - Eclipse IDE

Luego escribimos en la opción "Name", Pendiente, y en Description, escribimos, documento pendiente de creación, presionamos OK y luego cerramos la ventana States. Vemos que la plantilla de Estados se actualiza con el estado creado, procedemos a seleccionar la opción creada y damos clic en Assign, para asignarlo al producto de trabajo. Ver figura 3-28.

Figura 3-28. Creación de estado pendiente al producto de trabajo creado.

"diseño propio" - Eclipse IDE

Hecho ya ese paso vamos a proceder a asignarle una guía de orientación (template) a nuestro producto de trabajo, para ello nos ubicamos en la pestaña Guidance y damos clic en Add, nos

aparecerá una ventana para la búsqueda de las guías de orientación, procedemos a escribir Visión y ubicamos la plantilla anexar. Ver figura 3-29.

Figura 3-29. Creación de estado pendiente al producto de trabajo creado.

"diseño propio" - Eclipse IDE

c. Damos click en OK, y luego pre visualizamos para ver cómo va quedando el componente creado. Ver figura 3-30.

Figura 3-30. Pre visualización del producto de trabajo creado.

"diseño propio" - Eclipse IDE

d. Nos ubicamos sobre el rol creado anteriormente y le añadimos el work product Visión. Damos doble clic sobre Analista y se mostrara la plantilla para la modificación de ese componente, inmediatamente después nos ubicamos en Work Products y en el área "Responible for", procedemos a añadir el work product. Ver figura 3-31.

Figura 3-31. Asignación del Work Product "Vision" al rol Analista

"diseño propio" - Eclipse IDE

Si pre visualizamos ahora el modelo web que se van generando, nos vamos a dar cuenta que esta va creciendo y que el mismo EPF lo va organizando de acuerdo a como vamos enlazando cada componente. Ver figura 3-32.

Figura 3-32. Pre visualización Web para el rol Analista

"diseño propio" - Eclipse IDE

e. Finamente completando la Tarea procedemos a seleccionar el producto de trabajo que va a ser creado al ejecutarse la tarea de "Crear Documento de Visión".Nos ubicamos y seleccionamos con doble clic sobre "Crear Documento de Vision", luego de ello en la opción Output procedemos a añadir el Producto de Trabajo "Vision". Ver figura 3-33.

Figura 3-33. Inserción de un Producto de trabajo como salida de una tarea

"diseño propio" - Eclipse IDE

Trabajando con Procesos, creando un Delivery ProcessDiagramas:EPF Composer provee 3 tipos de diagramas para el trabajo con Open Up/Basic. Diagrama de Actividades: Estos diagramas muestran las actividades subordinadas en una actividad de alto nivel. También muestran la secuencia de las relaciones entre esas actividades.Diagrama de Actividades Detallado: Estos diagramas muestran las tareas en una actividad con la realización de sus funciones junto con los productos de trabajo de entrada y salida. Son similares a los diagramas de flujo de trabajo detallado.Diagrama de dependencias de Productos de Trabajo: Estos diagramas muestran las dependencias de trabajo del producto en otros.

Creando un Delivery Process:Para crear un nuevo delivery process nos ubicamos en la paquetería de Procesos, dentro del visor de librerías, luego damos clic derecho en: Delivery Process New Delivery Process.Nos aparecerá una ventana para definir el nombre y la configuración por defecto a estructurar.En name escribimos "Mi Nuevo Proceso de Software" y en "default configuration" elegimos "openup". Ver figura 3-34.

Figura 3-34: Creación de un Delivery Process (Crear Plan de Proyecto)

"diseño propio" - Eclipse IDE

Ahora para comenzar a crear una estructura de nuestro proceso, sabemos que Open UP/Basic maneja 4 fases principales que vendrían a ser:

Incepción Elaboración Construcción Transición

Para definir estas fases dentro del EPF Composer, ubiquémonos dentro de la pestaña Work Breakdown Structure. Se verá una ventana como en la figura 3-35.

Figura 3-35. Creación de una WBS

"diseño propio" - Eclipse IDE

Una vez ubicados en esta ventana, damos clic derecho sobre el nombre del Delivery Process creado y elegimos la opción New Child Phase y procedemos a escribir el nombre de la primera fase "Incepción".Luego creamos una actividad llamada Requerimientos. Clic derecho sobre Incepción New Child Activity.Ingresamos como nombre "Requerimientos", quedando la ventana de la siguiente manera. Ver figura 3-36.

Figura 3-36. Creación de Fases y Actividades

"diseño propio" - Eclipse IDE

Procedemos ahora a realizar un drag and drop de nuestras tareas hacia la actividad creada (Requerimientos). Ver figura 3-37.

Figura 3-37. Definiendo tareas a la actividad creada

"diseño propio" - EcHpse iDE

Nos quedaría un WBS siguiente: Ver figura 3-38.

Figura 3-38. Definiendo tareas a la actividad creada

"diseño propio" - Eclipse IDE

Si podemos observar la parte inferior de la figura 3-38, vemos que existen 3 Pestañas más, ordenadas de la siguiente manera:Team Allocation | Work Product Usage | Consolidates View

Team Allocation:Indica los roles primarios que han sido asignados en las tareas definidas por la WBS, esto se genera automáticamente dependiendo de los enlaces definidos anteriormente. Ver figura 3-39.

Figura 3-39. Vista Team Allocation

"diseño propio" - Eclipse IDE

Work Product Usage:Lo productos de trabajo que son usados por esas actividades y que van a tener algún cambio o que nacen en alguna de esas actividades. Ver figura 3-40.

Figura 3-40. Vista Work Product Usage

"diseño propio" - Eclipse IDE

Consolidates View:Vista que une las dos vistas anteriores en una sola, mostrando tanto los roles como también los work products asociados a las actividades anexadas en la WBS. Ver figura 3-41.

Figura 3-41. Vista Consolidated View

"diseño propio" - Eclipse IDE

Creando un Diagrama de Procesos:Para crear un diagrama de procesos es necesario tener una WBS ya constituida para poder partir desde allí, la creación del diagrama, para ello se siguen los siguientes pasos:Nos vamos a la vista WBS de nuestro Delivery Process creado (Mi nuevo Proceso de Desarrollo)

Damos clic derecho sobre el nombre del Delivery Process Open Activity Diagram, si no se creó un diagrama anteriormente, nos mostrará un mensaje para crear un nuevo diagrama a partir del WBS obtenido. Ver figura 3-42.

Figura 3-42. Creando un Diagrama de Actividades

"diseño propio" - Eclipse IDE

Seleccionamos OK e inmediatamente nos aparecerá una ventana con la fase creada, adjuntemos otra fase de manera gráfica, para ello en la paleta de nodos damos un clic sobre el icono de fase y luego presionamos sobre cualquier parte blanca dentro del visor de propiedades. Se mostraría una ventana como la mostrada en la figura 3-43.

Figura 3-43: Creación de fases de manera declarativa.

"diseño propio" - Eclipse IDE

Defina una línea de flujo para el control de las dos fases y cree las dos restantes, quedando de la siguiente manera: Ver figura 3-44.

Figura 3-44. Creación de Fases y control de flujo.

"diseño propio" - Eclipse IDE

Para poder ver sobre el detalle de cada fase, se puede ingresar haciendo doble clic sobre la fase deseada. Por ejemplo. Veamos el detalle de la Incepción, mostraría solo una actividad que sería requerimientos. Ver figura 3-45.

Figura 3-45 Icono que corresponde a la actividad Requerimientos

"diseño propio" - Eclipse IDE

Y al ingresar a requerimientos, se vería las dos tareas definidas dentro de esa actividad. Ver figura 3-46.

Figura 3-46. Tareas asignadas dentro de la actividad Requerimientos.

"diseño propio" - Eclipse IDE

Creando un Diagrama de Procesos:Para crear un diagrama de actividades detallado es necesario tener generado la WBS dentro de nuestro Delivery Process, para ello igual que en el procedimiento anterior, nos ubicamos en la pestaña Work Breakdown Structure de nuestro Delivery Process, presionamos con el botón derecho del mouse sobre el nombre del proceso y elegimos la opción Diagrams Open Activity Detall Diagram, mostrando una estructura como la siguiente: Ver figura 3-47.

Figura 3-47. Diagrama detallado de actividades.

"diseño propio" - Eclipse IDE

Exportando y Publicando el proyecto: Exportar:Una de los principales características del EPF Composer es la portabilidad y el trabajo colaborativo, por tal motivo, esta herramienta permite la exportación de las librerías trabajadas, así como también de los modelos adaptados en una gestión de proyecto particular con el fin de que este pueda mejorado, adaptado, etc. es decir que se obtenga una retroalimentación de la gestión en todo el Proceso de Desarrollo de Software.Para exportar toda una librería completa es necesario ubicarnos en el menú File Export. Nos aparecerá una ventana indicándonos qué tipo de exportación deseamos realizar, dado que nosotros hemos implementado un plugin, seleccionamos la opción Method Plug-ins y presionamos Next. Ver figura 3-48.

Figura 3-48. Exportación de métodos y librerías.

'diseño propio" - Eclipse IDE

Luego de ello nos aparecerá todos los plugins que tiene nuestro modelo, buscamos el nuestro y lo seleccionamos y presionamos Next. Nos aparecerá una ventana de revisión de librerías, volvemos a presionar Next. Ver figura 3-49.

Figura 3-49. Revisión de librerías Open UP

"diseño propio" - Eclipse IDE

Nos aparecerá una ventana de confirmación, presionamos Next nuevamente, y luego nos solicitará el lugar donde se desea guardar la exportación, seleccionamos la ruta específica donde queremos que se guarde nuestra exportación y luego presionamos Finish. Ver figura 3-50.

Figura 3-50. Exportación de librerías, definiendo ruta de directorio.

"diseño propio" - Eclipse IDE

1.3. Lectura

La necesidad de nuevos métodos

En 1994, el grupo Standish Group, analizó más de 8.000 proyectos de software (el documento integro se encuentra en los anexos) y las conclusiones de The CHAOS Report (1994) fueron:

Sólo el 16.2% de los proyectos se completó a tiempo, cumpliendo el presupuesto y con las funcionalidades inicialmente propuestas.

EI 31.1% de los proyectos se canceló antes de acabar EI 52.7% de los proyectos no cumplió presupuesto, tiempo o funcionalidades iniciales

(o varios factores). Por ejemplo, costaron en media el 189% de su presupuesto inicial. Más del 25% se completó con un 25 a un 49% de las funciones y características

especificadas originalmente.

En el apartado 4.6 se ve la evolución de estos factores hasta 2004 que ha realizado el grupo Standish. También se dispone de una amplia encuesta realizada en 2006 por Scott Ambler.

Otros ejemplos destacados de fracasos en el desarrollo de software:

LONDON AMBULANCE DISPATCHING SYSTEM (1992) Sistema para gestionar las llamadas de emergencias. Inversión: 1.2 millones de libras. Pérdidas: se estiman 20 vidas. Problemas: El sistema no distinguía llamadas distintas. Retenía llamadas durante

horas. Usuarios sin formación. Implantación del sistema de manera apresurada.

AGENCIA ESPACIAL EUROPEA (1996)• Sistema de navegación del Ariane 5. Evolución del Ariane 4.• Inversión: 7 billones de dólares.• Pérdidas: 2 satélites se desintegraron.

• Problema: Overflow al operar con la velocidad (5 veces mayor que en el Ariane 4). No se controlaban las excepciones.

NIKE (2001) Sistema para automatizar la gestión, producción y venta. Inversión: 400 millones dólares. Pérdidas: 100 millones en ventas. Reducción de un tercio del valor de las acciones. Problema: El sistema intercambiaba órdenes de producción. Exceso de stock en

algunos productos y falta en otros.

FBI (2005) Sistema para aumentar la seguridad de las redes y modernizar las aplicaciones de

investigación. Inversión: 581 millones dólares. Pérdidas: 170 millones de dólares y 5 años de trabajo. Problema: Prisas tras el 11-S; Continuos cambios en los requisitos y en los

responsables: poca preparación de los directores de proyecto.

Tras analizar estos casos, las causas de los problemas que se repiten son:

1. Planificación pobre.2. Objetivos poco claros.3. Objetivos cambiantes durante el proyecto. 4. Previsiones poco realistas. 5. Falta de soporte "superior".6. Falta de implicación del usuario. 7. Falta de comunicación en el equipo.8. Uso de técnicas inadecuadas.

La alta y diversa demanda de software para Internet, con constantes actualizaciones, así como el software para terminales móviles pone de manifiesto la necesidad de optimizar desde el punto de vista económico y temporal los métodos que se emplean para diseñar software.

Métodos tradicionales

Proceso controlado, gestionado Proceso secuencial, lineal Proceso replicahle Proceso racional, determinado, orientado a proceso (goal-driven) Procesos y herramientas Documentación comprensible Negociación de contratos Seguir un plan Se basan en normas Mayor o menor resistencia a los cambios Se habla con el cliente sólo en reuniones Equipos grandes (>15-20 miembros) Procesos con muchas normas Mucha documentación

Mucho análisis y diseño Conceden mucha importancia a la arquitectura

Métodos ÁGILES

Aleatorio, oportunista, guiado por sucesos (accident-driven) Procesos simultáneos, solapados Ocurre de forma completamente única Negociado, comprometido y caprichoso Individuos e interacciones Software que funciona Colaboración con el cliente Responder al cambio Se basan en heurísticas para crear código Aceptan e incluso fomentan el cambio El cliente forma parte del equipo Equipos de trabajo pequeños o medianos Procesos con pocas reglas Poca documentación Poco análisis v diseño Conceden poca importancia a la arquitectura

Tabla 5. Diferencias entre métodos ágiles y tradicionales.

Uno de los problemas inherentes a los métodos orientados a proceso es que están completamente delimitados, congelados antes de empezar el diseño del software. Esta característica les hace inflexibles a la hora de realizar cambios en los requisitos.

Los métodos ágiles se oponen a los rígidos o pesados por varios motivos:

1. La recopilación completa de los requisitos es cara y requiere tiempo.2. Los requisitos suelen cambiar a lo largo de la realización de los proyectos, con lo que el

trabajo realizado puede ser inútil.3. No son métodos que puedan adaptarse fácilmente a los cambios, y menos aún a los

cambios rápidos.4. Carecen de realimentación entre clientes y desarrolladores.5. Aunque el sistema final cumpla los requisitos iniciales, el cliente puede no estar

satisfecho con los resultados finales ("Esto es lo que pedí, pero no es realmente lo que necesitaba").

Se considera como nacimiento público del "Agüe Movement" el momento en que el Agüe Software Development Manifestó, escrito por 17 programadores y consultores en un taller en Snowbird (Utah, Estados Unidos), vio la luz en 2001. También surgió la Alianza Ágil, una organización sin ánimo de lucro que tiene como fines el mejor entendimiento de los métodos ágiles y la creación de condiciones favorables para discutir e intercambiar opiniones sobre ellos. Las versiones originales en inglés del Manifiesto así como de los 12 principios se encuentran en los anexos. La reunión que se sintetizó en el Manifiesto, tuvo 4 puntos:

1. Se necesitan métodos que respondan a cambios durante el proyecto. El término "ágil" es más apropiado que "light" ya que proyectos con muchos programadores o de alta seguridad, no son precisamente light. 2. El segundo punto son las 4 declaraciones del Manifiesto.

3. El tercero, los 12 principios ágiles.4. Los métodos ágiles tienen la libertad de definirse ellos mismos.

Úbeda González, Raúl (2009). Métodos ágiles para el desarrollo de software. Madrid Árees temátiques. pp 36-39

1.4. Actividades

1. De acuerdo a lo estudiado en estos capítulos, realice usted las siguientes acciones dentro del mismo proyecto que se viene realizando.

a. Defina un Rol, llamado Project Manager con la siguiente información:

Name: Project ManagerPresentation Name: Project ManagerBrief Description: Persona que tiene la responsabilidad total del planeamiento y la ejecución acertada del proyecto de desarrollo de software.Versión: 0.1

b. Defina una tarea con la siguiente información:

Name: Crear Plan de ProyectoPresentation Name: Crear Plan de ProyectoBrief Description: Documento con información necesaria para gestionar el proyecto a nivel estratégico. Su parte principal consiste en un plan detallado, la identificación de las iteraciones del proyecto y sus objetivos.Versión: 0.1Pasos:

Identificar el equipo de trabajo. Estimar el tamaño del proyecto. Evaluar los riesgos.Pronosticar la duración y tamaño del proyecto. Esquematizar el ciclo de vida del proyecto. Establecer costos y valores. Desglosar el plan.

Rol Principal: Project ManagerRol Secundario: Analista

c. Al final se debería visualizar la siguiente pre visualización web. Ver figura 3-51 y 3-52.

Figura 3-51. Pre visualización del rol (Trabajo Practico)

"diseño propio" - Eclipse IDE

Figura 3-52. Pre visualización de la Tarea (Trabajo Practico)

"diseño propio" - Eclipse IDE

2. De acuerdo a lo estudiado en este capítulo, realice usted las siguientes acciones dentro del mismo proyecto que se viene realizando.

a. Defina un Work Product, llamado Plan de Proyecto con la siguiente información:Name: Plan de ProyectoPresentation Name: Plan de ProyectoBrief Description: Documento donde se definen los lineamientos que van a guiar el Proyecto de Desarrollo de Software.Versión: 0.1Guía de Orientación: Project plan Estado: pendiente.

b. Establecer a la tarea Crear Plan de Proyecto los siguientes cambios:

Rol Principal: Project ManagerRol Adicional: AnalistaWork Product de Entrada: VisionWork Product de Salida: Plan de Proyecto

c. Al final se debería visualizar la siguiente pre visualización web. Ver figura 3-53 y 3-54.

Figura 3-53. Pre visualización del Producto de Trabajo (Plan de Proyecto)

"diseño propio" - Eclipse IDE

Figura 3-54. Pre visualización de la Tarea (Crear Plan de Proyecto)

Diseño propio - Eclipse IDE

1.5. Autoevaluación

a. Según lo estudiado en este capítulo, defina usted, ¿Qué es una WBS, y cuál es su función principal en el proyecto?

b. Según UML, diga usted el Project Manager, qué documentos tiene como actividad primordial para su ejecución.

c. Del siguiente listado de documentos, diga usted cual no pertenece a la fase de Incepción. Documento de Visión Plan de Proyecto Plan de Pruebas Diagrama de Casos de Uso Glosario de Términos

d. Cuál es la diferencia principal entre rol y tarea, y cómo se pueden agrupar estos para definir una WBS.

e. Diga usted bajo sus propias palabras la diferencia entre Método y Proceso, y cómo éstos se complementan para la implementación y ejecución del desarrollo de un sistema.

f. La vista Team Allocation, ¿qué define dentro del proceso?

g. ¿Una tarea puede tener varios roles primarios?

h. Defina usted los pasos para realizar el Documento de Visión

i. El documento de Visión, ¿que otros documentos tiene como entrada para que este pueda ser creado por el analista?

j. ¿A qué fase pertenece el plan de pruebas? Explique.

1.6. Exploración oniine

http://www.eclipse.org/epf/http://www.eclipse.org/proposals/beacon/Who%20will%20benefit%20from%20Eclips e%20Process%20Framework.pdfhttp://www.eclipse.org/epf/general/EPF_lnstallation_Tutorial_User_Manual.pdf http://dev.eclipse.org/newslists/news.eclipse.technology.epf/maillist.html

Bibliografía

Casal O. Lorena (2006). Gestión de Proyectos. Elementos básicos a tener en cuenta como punto de partida para realizar efizcamente su proyecto. Madrid. Ideas Propias Editorial.

Harvard Business School Publishing Corporation (2004). Gestión de Proyectos. Una guía para directives ocupados. Enfoques y conceptos para avanzar. Barcelona. Ediciones Dusto.

Jack Gido, James P. Clements (2007). Administración Exitosa de Proyectos. Cengage Learning Latín America.

Glosario

Abstracción. Aislar un objeto dentro del contexto real en el que se encuentra y representarlo en modelos de software para su uso. (Eclipse Foundation IBM. Bajo licencia de uso EPL, http://www.eclipse.org/legal/epl-v10.html)

Arquitectura. Define una estructura sólida de software en cuanto al despliegue (administración del hardware) y a los componentes, metodologías, formas, modelos de software definidos para su realización. (G Booch, J Rumbaugh (1999). El Proceso Unificado de Desarrollo de Software. AddisonWesley, pp 202)

Componentes. Define cualquier nodo (Tarea, Rol, Work product, Guidance, etc.) que viene definido dentro del proceso de Open UP/Basic y que persiste en la librería dentro del EPF Composer. (B Meyer, MK Mora, RGB Fernández (1999). Construcción de software orientado a objetos, 1999, Prentice-Hall, pp 68)

Contrato. Es un acuerdo vinculante para las partes en virtud del cual el vendedor se obliga a proveer el producto, servicio o resultado especificado y el comprador a pagar por él. (PMI, 2004,356).

Dominio. Entorno sobre el cual se mueve un componente de software (artefacto o productos de trabajo), se refiere a la agrupación de dos o más grupos de trabajo. (http://www.gnu.org/licenses/lgpl.html)

EDT. (Estructura de Desglose del Trabajo). Un diccionario de la estructura detallada del trabajo. (PMI, 2004,360).

Iteración. Es una serie de repeticiones definidos por un grupo de pasos debidamente ordenados y en un número establecido de veces. (Treviño Esthela (2004). La iteración de "eventos". Universidad de La Rioja, ISSN 0185-3082, Vol. 25, N°. 2, pp. 120)

Librería. Framework predefinido por Open UP/Basic que define métodos y procesos para el proceso de desarrollo de software y que está compuesto en su interior por un orden de carpetas indicando donde debe ir cada componente y como usarlo y definirlo. (http://www.gnu.org/licenses/lgpl.html)

Microincremento. Avance mínimo significativo sobre un producto o servicio que en conjunto define un entregable funcional para una iteración. (Lyons, 2010,56).

Operación. Una función de la organización que se ocupa de la ejecución constante de actividades que generan el mismo producto o prestan un servicio reiterado. (PMI, 2004,374).

Paquete. Agrupación y organización de un conjunto de componentes dentro del EPF Composer. (B Meyer, MK Mora, RGB Fernández (1999). Construcción de software orientado a objetos, Prentice- Hall, pp68)

Patrocinador. (Sponsor). La persona o el grupo que ofrece recursos financieros, monetarios o en especie, para el proyecto. (PMI, 2004,374).

PMBOK. Expresión inclusiva que describe la suma de conocimientos de la profesión de dirección de proyectos. Al igual que otras profesiones, como la abogacía, la medicina, y las ciencias económicas, los fundamentos residen en los practicantes y los académicos que los

aplican y desarrollan. El conjunto de los fundamentos de la dirección de proyectos incluye prácticas tradicionales comprobadas y ampliamente utilizadas así como prácticas innovadoras emergentes para la profesión. (PMI, 2004,367).

Riesgo. Un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo en los objetivos de un proyecto. (PMI, 2004,380).

SOW. Enunciado del Trabajo. Es una descripción narrativa de los productos, servicios o resultados que deben suministrarse. También conocido como Definición del Trabajo o Descripción del Trabajo. (PMI, 2004,362)

Stakeholder. Personas y organizaciones como clientes, patrocinadores, organización ejecutante y el público, involucrados activamente en el proyecto, o cuyos intereses pueden verse afectados de manera positiva o negativa por la ejecución o conclusión del proyecto. También pueden influir sobre el proyecto y sus productos entregables. (PMI, 2004,371)

Template. Plantilla. Un documento parcialmente completo en un formato predefinido, que proporciona una estructura definida para recopilar, organizar y presentar información y datos. (PMI, 2004,377)

PMBOOK2008

Sección I

El Marco de Referencia para la Dirección de Proyectos

Capítulo 1 Introducción

Capítulo 2 Ciclo de Vida del Proyecto y Organización

Capítulo 1

Introducción

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 abogada, 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.

Los primeros dos capítulos de la Guía del PMBOK presentan una introducción a conceptos clave en el ámbito de la dirección de proyectos. El Capítulo 3 presenta la norma para la dirección de proyectos. Resume los procesos, entradas y salidas que generalmente se consideran buenas prácticas en la mayoría de los proyectos. Los Capítulos 4 a 12 constituyen la Guía de los Fundamentos para la Dirección de Proyectos. Amplían la información contenida en la norma mediante la descripción de las entradas y salidas, así como de las herramientas y técnicas utilizadas para dirigir proyectos.

La Guía del PMBOK proporciona pautas para la dirección de proyectos tomados de forma individual. Define la dirección de proyectos y otros conceptos relacionados, y describe el ciclo de vida de la dirección de proyectos y los procesos conexos.

Este capítulo define varios términos clave e identifica los factores externos del entorno del proyecto así como los factores internos de la organización, que giran en tomo al éxito de un proyecto o tienen alguna influencia sobre el mismo. En las siguientes secciones se presenta un panorama general de la Guía del PMBOK:

1.1 Propósito de la Guía del PMBOK®1.2 ¿Qué es un proyecto?1.3 ¿Qué es la dirección de proyectos?1.4 Relaciones entre la dirección de proyectos, la dirección de programas y la gestión del portafolio1.5 Dirección de proyectos y gestión de las operaciones 1.6 Rol del director del proyecto1.7 Fundamentos para la dirección de proyectos 1.8 Factores ambientales de la empresa

1.1 Propósito de la Guía del PMBOK

La creciente aceptación de la dirección de proyectos indica que la aplicación de conocimientos, procesos, habilidades, herramientas y técnicas adecuados puede tener un impacto considerable en el éxito de un proyecto. La Guía del PMBOK 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.

La Guía del PMBOK también proporciona y promueve un vocabulario común en el ámbito de la profesión de la dirección de proyectos, para analizar, escribir y aplicar conceptos de la dirección de proyectos. Un vocabulario estándar es un elemento esencial en toda disciplina profesional.

El Project Management Institute (PMI) considera la norma como una referencia fundamental en el ámbito de la dirección de proyectos para sus certificaciones y programas de desarrollo profesional.

En su carácter de referencia fundamental, esta norma no está completa ni abarca todos los conocimientos. Se trata de una guía, más que de una metodología. Se pueden usar diferentes metodologías y herramientas para implementar el marco de referencia. El Anexo D presenta ampliaciones por área de aplicación y el Anexo E enumera fuentes de información adicional sobre la dirección de proyectos.

Además de las normas que establecen pautas para los procesos, herramientas y técnicas de la dirección de proyectos, el Code of Ethics and Professional Conduct del Project Management Institute sirve de guía a los profesionales de la dirección de proyectos y describe las expectativas que tienen de sí mismos y de los demás. El Code of Ethics and Professional Conduct del Project Management Institute precisa las obligaciones básicas de responsabilidad, respeto, imparcialidad y honestidad. Requiere que quienes se desempeñan en este ámbito demuestren compromiso con la conducta ética y profesional. Conlleva la obligación de cumplir con leyes, regulaciones y políticas profesionales, y de la organización. Puesto que los profesionales provienen de culturas y orígenes diversos, el Code of Ethics and Professional Conduct se aplica a nivel mundial. En el trato con los interesados, los profesionales deben comprometerse a realizar prácticas justas y honestas, y a mantener relaciones respetuosas. El Code of Ethics and Professional Conduct del Project Management Institute está publicado en el sitio Web del PMI (http://www.pmi.org). La aceptación del código es requisito para la certificación PMP del PMI.

1.2 ¿Qué es un proyecto?

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los proyectos indica un principio y un final definidos. El final se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto. Temporal no necesariamente significa de corta duración. En general, esta cualidad no se aplica al producto, servicio o resultado creado por el proyecto; la mayor parte de los proyectos se emprenden para crear un resultado duradero. Por ejemplo, un proyecto para construir un monumento nacional creará un resultado que se espera que perdure durante siglos. Por otra parte, los proyectos pueden tener impactos sociales, económicos y ambientales que durarán mucho más que los propios proyectos.

Todo proyecto crea un producto, servicio o resultado único. Aunque puede haber elementos repetitivos en algunos entregables del proyecto, esta repetición no altera la unicidad fundamental del trabajo del proyecto. Por ejemplo, los edificios de oficinas son construidos con materiales idénticos o similares, o por el mismo equipo, pero cada ubicación es única: con un diseño diferente, en circunstancias diferentes, por contratistas diferentes, etcétera.

Un esfuerzo de trabajo permanente es por lo general un proceso repetitivo, puesto que sigue los procedimientos existentes de una organización. En contraposición, debido a la naturaleza única de los proyectos, puede existir incertidumbre respecto de los productos, servicios o resultados que el proyecto genera. Las tareas del proyecto pueden ser nuevas para el equipo del proyecto, lo que hace necesario planificar con mayor dedicación que si se tratara de un trabajo de rutina. Además, los proyectos se llevan a cabo en todos los niveles de una organización. Un proyecto puede involucrar a una sola persona, una sola unidad o múltiples unidades dentro de la organización.

Un proyecto puede generar:

• un producto que puede ser un componente de otro elemento o un elemento final en sí mismo,

• La capacidad de realizar un servicio (por ej., una función comercial que brinda apoyo a la producción o distribución), o

• un resultado tal como un producto o un documento (por ej., un proyecto de investigación que desarrolla conocimientos que se pueden emplear para determinar si existe una tendencia o si un nuevo proceso beneficiará a la sociedad).

Entre los ejemplos de proyectos, se incluye: • desarrollar un nuevo producto o servicio,• implementar un cambio en la estructura, el personal o el estilo de una organización,• desarrollar o adquirir un sistema de información nuevo o modificado, • construir un edificio o una infraestructura, o• implementar un nuevo proceso o procedimiento de negocio.

1.3 ¿Qué es 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 mismo. Se logra mediante la aplicación e integración adecuadas de los 42 procesos de la dirección de proyectos, agrupados lógicamente, que conforman los 5 grupos de procesos. Estos 5 grupos de procesos son:

• Iniciación,• Planificación, • Ejecución,• Seguimiento y Control, y• Cierre.

Dirigir un proyecto por lo general implica:

• identificar requisitos,• abordar las diversas necesidades, inquietudes y expectativas de los interesados según

se planifica y efectúa el proyecto,• equilibrar las restricciones contrapuestas del proyecto que se relacionan, entre otros

aspectos, con:

o el alcance, o la calidad,o el cronograma,

o el presupuesto, o los recursos yo el riesgo.

El proyecto específico influirá sobre las restricciones en las que el director del proyecto necesita concentrarse.

La relación entre estos factores es tal que si alguno de ellos cambia, es probable que al menos otro se vea afectado. Por ejemplo, un adelanto en el cronograma a menudo implica aumentar el presupuesto, a fin de añadir recursos adicionales para completar la misma cantidad de trabajo en menos tiempo. Si no es posible aumentar el presupuesto, se puede reducir el alcance o la calidad, para entregar un producto en menos tiempo por el mismo presupuesto. Los interesados en el proyecto pueden tener opiniones diferentes sobre cuáles son los factores más importantes, lo que crea un desafío aún mayor. Cambiar los requisitos del proyecto puede generar riesgos adicionales. El equipo del proyecto debe ser capaz de evaluar la situación y equilibrar las demandas a fin de entregar un proyecto exitoso.

Dada la posibilidad de sufrir cambios, el plan para la dirección del proyecto es iterativo y su elaboración es gradual a lo largo del ciclo de vida del proyecto. La elaboración gradual implica mejorar y detallar constantemente un plan, a medida que se cuenta con información más detallada y específica, y con estimados más precisos. La elaboración gradual permite a un equipo de dirección del proyecto dirigir el proyecto con un mayor nivel de detalle a medida que éste avanza.

1.4 Relaciones entre la dirección de proyectos, la dirección de programas y la gestión del portafolio

En organizaciones maduras en dirección de proyectos, la dirección existe en un contexto más amplio regido por la dirección de programas y la gestión del portafolio. Como se ilustra en el Gráfico 1-1, las estrategias y prioridades de una organización se vinculan, y se establecen relaciones entre portafolios y programas, y entre programas y proyectos individuales. La planificación de la organización ejerce un impacto en los proyectos, a través del establecimiento de prioridades basadas en los riesgos, el financiamiento y el plan estratégico de la organización. La planificación de la organización puede guiar el financiamiento y el apoyo a los proyectos que componen el portafolio basándose en categorías de riesgo, líneas de negocio específicas o tipos generales de proyectos como infraestructura y mejora de los procesos internos.

Gráfico 1-1. Interacciones entre la dirección de proyectos, la dirección de programas y la gestión del portafolio

Los proyectos, programas y portafolios tienen diferentes enfoques. El Cuadro 1-1 presenta una comparación entre las perspectivas de los proyectos, programas y portafolios según diferentes aspectos, entre ellos, el cambio, el liderazgo y la gestión.

1.4.1 Gestión del portafolio

El término portafolio se refiere a un conjunto de proyectos o programas y otros trabajos que se agrupan para facilitar la dirección eficaz de ese trabajo para cumplir con los objetivos estratégicos del negocio. Los proyectos o programas del portafolio no son necesariamente interdependientes ni están directamente relacionados. Por ejemplo, una compañía de infraestructura que tiene el objetivo estratégico de "maximizar el rendimiento de su capital invertido" puede incluir en un portafolio una combinación de proyectos en el ámbito del petróleo y gas, la energía, el agua, los caminos, ferrocarriles y aeropuertos. A partir de esta combinación, la compañía puede optar por gestionar como un solo programa los proyectos relacionados. Todos los proyectos energéticos pueden ser agrupados como un programa de energía. Del mismo modo, todos los proyectos hídricos pueden ser agrupados como un programa hídrico.

La gestión del portafolio se refiere a la gestión centralizada de uno o más portafolios, que incluye identificar, establecer prioridades, autorizar, dirigir y controlar proyectos, programas y otros trabajos relacionados para alcanzar los objetivos específicos y estratégicos del negocio. La gestión del portafolio se centra en asegurar que los proyectos y programas se revisen a fin

de establecer prioridades para la asignación de recursos, y en que la gestión del portafolio sea consistente con las estrategias de la organización y esté alineada con ellas.

Cuadro 1-1. Presentación comparativa de la dirección de proyectos, la dirección de programas y la gestión del portafolio

1.4.2 Dirección de programas

Un programa se define como un grupo de proyectos relacionados administrados de forma coordinada para obtener beneficios y control, que no se obtendrían si se gestionaran en forma individual. Los programas pueden incluir elementos de trabajo relacionados que están fuera del alcance de los proyectos específicos del programa. Un proyecto puede o no formar parte de un programa, pero un programa incluye siempre proyectos.

La dirección de programas se define como la dirección coordinada y centralizada de un conjunto de proyectos para lograr los objetivos y beneficios estratégicos de la organización. Dentro de un programa, los proyectos se relacionan mediante el resultado común o la capacidad colectiva. Si la relación entre los proyectos está dada únicamente por un cliente, vendedor, tecnología o recurso en común, el esfuerzo se debería gestionar como un portafolio de proyectos, en lugar de hacerlo como un programa.

La dirección de programas se centra en las interdependencias entre los proyectos y ayuda a determinar el enfoque óptimo para gestionarlas. Entre las acciones relacionadas con estas interdependencias, se puede incluir:

• resolver restricciones de los recursos y/o conflictos que afectan a múltiples proyectos dentro del sistema;

• ajustar la dirección estratégica de la organización que afecta las metas y los objetivos de los proyectos y del programa, y

• resolver problemas y cambiar la gestión dentro de una estructura de gobernabilidad compartida.

Un ejemplo de un programa sería un nuevo sistema de comunicaciones vía satélite con proyectos para el diseño y construcción del satélite y las estaciones terrestres, la integración del sistema y el lanzamiento del satélite.

1.4.3 Proyectos y planificación estratégica

A menudo, los proyectos se utilizan como el medio para cumplir con el plan estratégico de una organización. Por lo general, los proyectos se autorizan como resultado de una o más de las siguientes consideraciones estratégicas:

• Demanda del mercado (por ej., una compañía automotriz que autoriza un proyecto para construir más automóviles de bajo consumo en respuesta a la escasez de combustible),

• Oportunidad estratégica/necesidad comercial (por ej., un centro de capacitación que autoriza un proyecto de creación de un curso nuevo, para aumentar sus ganancias),

• Solicitud de un cliente (por ej., una empresa eléctrica que autoriza un proyecto para construir una nueva subestación a fin de abastecer un nuevo parque industrial),

• Adelantos tecnológicos (por ej., una compañía de productos electrónicos que autoriza un proyecto nuevo para desarrollar una computadora portátil más pequeña, más económica y más veloz, a partir de adelantos en materia de memorias de computadoras y tecnología electrónica), y

• Requisitos legales (por ej., un fabricante de productos químicos autoriza un proyecto para sentar las pautas para la manipulación de un nuevo material tóxico).

Dentro de programas o portafolios, los proyectos resultan un medio para alcanzar las metas y los objetivos de la organización, a menudo en el contexto de un plan estratégico. Si bien, dentro de un programa, un grupo de proyectos puede tener beneficios específicos, estos proyectos también pueden contribuir a los beneficios del programa, a los objetivos del portafolio y al plan estratégico de la organización.

Las organizaciones gestionan los portafolios basándose en su plan estratégico, lo que puede dictar una jerarquía al portafolio, programa o proyectos implicados. Uno de los objetivos de la gestión del portafolio consiste en maximizar el valor del portafolio mediante un examen cuidadoso de sus componentes: los programas, proyectos y otros trabajos relacionados que lo constituyen. Los componentes cuya contribución a los objetivos estratégicos del portafolio es mínima, pueden ser excluidos. De esta manera, el plan estratégico de una organización se convierte en el principal factor que guía las inversiones en los proyectos. Al mismo tiempo, los proyectos retroalimentan los programas y portafolios mediante informes de estado y solicitudes de cambio que pueden ejercer un impacto sobre otros proyectos, programas o

portafolios. Se acumulan necesidades de proyectos, incluso de recursos, y se comunican nuevamente a nivel del portafolio, lo que marca a su vez la dirección para la planificación de la organización.

1.4.4 Oficina de dirección de proyectos

Una oficina de dirección de proyectos es un cuerpo o entidad dentro de una organización que tiene varias responsabilidades asignadas con relación a la dirección centralizada y coordinada de aquellos proyectos que se encuentran bajo su jurisdicción. Las responsabilidades de una oficina de gestión de proyectos pueden abarcar desde proveer funciones de apoyo para la dirección de proyectos hasta la responsabilidad de dirigir proyectos directamente.

Los proyectos a los que esta oficina brinda apoyo o dirige pueden no estar relacionados, salvo por el hecho de ser dirigidos en conjunto. La forma, función y estructura específicas de una oficina de dirección de proyectos dependen de las necesidades de la organización que ésta apoya.

Puede delegársele la autoridad necesaria para actuar como un interesado integral y tomar decisiones clave en el comienzo de cada proyecto, para hacer sugerencias o para terminar proyectos o tomar otras medidas, según se requiera, a fin de mantener la coherencia con los objetivos de negocio. Asimismo, la oficina de dirección de proyectos puede participar en la selección, gestión e implementación de recursos de proyectos compartidos o dedicados.

Una función fundamental de esta oficina es brindar apoyo a los directores del proyecto de diferentes formas, entre ellas:

• gestionar recursos compartidos por todos los proyectos dirigidos por la oficina de dirección de proyectos;

• identificar y desarrollar una metodología, mejores prácticas y normas para la dirección de proyectos;

• instruir, orientar, capacitar y supervisar;

• vigilar el cumplimiento de las políticas de normas, procedimientos y plantillas de la dirección de proyectos mediante auditorias del proyecto;

• desarrollar y gestionar políticas, procedimientos, plantillas y otra documentación compartida del proyecto (activos de los procesos de la organización), y

• coordinar la comunicación entre proyectos.

Los directores del proyecto y las oficinas de gestión de proyectos persiguen objetivos diferentes y, por lo tanto, responden a necesidades diferentes. Sin embargo, todos estos esfuerzos deben estar alineados con las necesidades estratégicas de la organización. Las diferencias entre el rol de los directores del proyecto y una oficina de dirección de proyectos pueden incluir lo siguiente:

• El director del proyecto se concentra en los objetivos específicos del proyecto, mientras que esta oficina gestiona cambios importantes relativos al alcance del programa que pueden considerarse oportunidades potenciales de alcanzar mejor los objetivos de negocio.

• El director del proyecto controla los recursos asignados al proyecto a fin de cumplir mejor con los objetivos; por su parte, la oficina de dirección de proyectos optimiza el uso de los recursos de la organización que son compartidos entre todos los proyectos.

• El director del proyecto gestiona las restricciones (alcance, cronograma, costo y calidad, entre otras) de los proyectos individuales, mientras que la oficina de dirección de proyectos gestiona las metodologías, normas, oportunidad/riesgo global e interdependencias entre proyectos a nivel empresarial.

1.5 Dirección de proyectos y gestión de las operaciones

Las operaciones son una función de la organización que se efectúa permanentemente, con actividades que generan un mismo producto o proveen un servicio. Por ejemplo: operaciones de producción, operaciones de fabricación y operaciones de contabilidad. A pesar de su naturaleza temporal, los proyectos pueden colaborar en el logro de los objetivos de la organización cuando están alineados con su estrategia. Las organizaciones cambian a veces sus operaciones, productos o sistemas mediante la creación de iniciativas de negocio estratégicas. Los proyectos requieren la dirección de proyectos, mientras que las operaciones necesitan la gestión de procesos de negocio o la gestión de operaciones. Los proyectos pueden entrecruzarse con operaciones en varios puntos durante el ciclo de vida del producto, por ejemplo:

• al cierre de cada fase;• cuando se desarrolla un producto nuevo, se mejora un producto existente o se

expanden las salidas;• en la mejora de operaciones o del proceso de desarrollo del producto, o • hasta la desinversión de las operaciones al final del ciclo de vida del producto.

En cada punto, se transfieren entregables y conocimientos entre el proyecto y las operaciones a fin de implementar el trabajo entregado. Esto sucede mediante la transferencia de recursos del proyecto a las operaciones hacia el final del proyecto, o bien mediante la transferencia de recursos de las operaciones al proyecto al inicio del proyecto.

Las operaciones son esfuerzos permanentes que producen salidas repetitivas, con recursos asignados para realizar básicamente el mismo conjunto de tareas, según las normas institucionalizadas, en un ciclo de vida de producto. A diferencia de la naturaleza permanente de las operaciones, los proyectos son esfuerzos temporales.

1.6 Rol del director del proyecto

El director del proyecto es la persona asignada por la organización ejecutante para alcanzar los objetivos del proyecto. El rol del director del proyecto es diferente del de un gerente funcional o del de un gerente de operaciones. Por lo general, el gerente funcional se dedica a la supervisión gerencial de un área técnica o administrativa, mientras que los gerentes de operaciones son responsables de una faceta del negocio básico.

Según la estructura de la organización, el director del proyecto puede estar bajo la supervisión de un gerente funcional. En otros casos, el director del proyecto puede formar parte de un grupo de varios directores de proyecto que rinden cuentas a un director del programa o del portafolio, quien en última instancia es el responsable de los proyectos de toda la empresa. En este tipo de estructura, el director del proyecto trabaja estrechamente con el director del

programa o del portafolio para cumplir con los objetivos del proyecto y para asegurar que el plan del proyecto esté alineado con el plan global del programa.

Varias de las herramientas y técnicas para dirigir proyectos son específicas a la dirección de proyectos. Sin embargo, comprender y aplicar los conocimientos, herramientas y técnicas que se reconocen como buenas prácticas no es suficiente para gestionar los proyectos de un modo eficaz. Además de las habilidades especificas a un área y de las competencias generales en materia de gestión requeridas para el proyecto, la dirección de proyectos efectiva requiere que el director del proyecto cuente con las siguientes características:

1. Conocimiento. Se refiere a lo que director del proyecto sabe sobre la dirección de proyectos.

2. Desempeño, Se refiere a lo que el director del proyecto puede hacer o lograr si aplica los conocimientos en dirección de proyectos.

3. Personal, Se refiere a la manera en que el director del proyecto se comporta cuando ejecuta el proyecto o actividades relacionadas. La capacidad personal abarca actitudes, características básicas de la personalidad y liderazgo (la capacidad de guiar al equipo de un proyecto mientras se cumplen los objetivos del proyecto y se equilibran las restricciones del mismo).

1.7 Fundamentos para la dirección de proyectos

La Guía del PMBOK es la norma para dirigir la mayoría de los proyectos, la mayor parte del tiempo, en diversos tipos de industrias. Esta norma describe los procesos, herramientas y técnicas de la dirección de proyectos utilizados para dirigir un proyecto con miras a un resultado exitoso.

Esta norma es específica para el ámbito de la dirección de proyectos y se interrelaciona con otras disciplinas de la dirección de proyectos como la dirección de programas y la gestión del portafolio.

Las normas de dirección de proyectos no abordan todos los detalles de todos los temas. Esta norma se limita a proyectos individuales y a los procesos de dirección de proyectos generalmente reconocidos como buenas prácticas. Se pueden consultar otras normas para obtener información adicional sobre el contexto más amplio en el que se llevan a cabo los proyectos. La dirección de programas se trata en La Norma para la Dirección de Programas (The Standard for Program Management) mientras que la gestión de porfolios se aborda en La Norma para la Gestión del Portafolio (The Standard for Portfolio Management). El examen de las capacidades de los procesos de la dirección de proyectos de una empresa se aborda en el Organizational Project Management Maturity Model (OPM3) (Modelo de Madurez para la Dirección de Proyectos de una Organización).

1.8 Factores ambientales de la empresa

Los factores ambientales de la empresa se refieren a elementos tangibles e intangibles, tanto internos como externos que rodean el éxito de un proyecto o influyen en él. Estos factores pueden provenir de cualquiera de las empresas implicadas en el proyecto. Los factores ambientales de la empresa pueden aumentar o restringir las opciones de la dirección de proyectos, y pueden influir de manera positiva o negativa sobre el resultado. Se consideran entradas para la mayoría de los procesos de planificación.

Entre los factores ambientales de la empresa, se incluyen: • procesos, estructura y cultura de la organización;• normas de la industria o gubernamentales (por ej., regulaciones del organismo de

control, códigos de conducta, normas de producto, normas de calidad y normas de fabricación);

• infraestructura (por ej., instalaciones existentes y bienes de capital);• recursos humanos existentes (por ej., habilidades, disciplinas y conocimientos como

los relacionados con el diseño, el desarrollo, las leyes, las contrataciones y las compras);

• administración de personal (por ej., pautas de retención y manejo de personal, revisión del desempeño de los empleados y registros de capacitación, política de horas extras y registro de horas trabajadas);

• sistemas de autorización de trabajos de la compañía; • condiciones del mercado;• tolerancia al riesgo por parte de los interesados; • clima político;• canales de comunicación establecidos en la organización;• bases de datos comerciales (por ej., datos para estimación estandarizada de costos;

información de estudio de los riesgos de la industria y bases de datos de riesgos), y• sistemas de información para la dirección de proyectos (por ej., herramientas

automáticas, como una herramienta de software para definir cronogramas, un sistema de gestión de la configuración, un sistema de recopilación y distribución de información o interfaces Web a otros sistemas automáticos en línea).

Capítulo 2

Ciclo de vida del proyecto y organización

Los proyectos y la dirección de proyectos se llevan a cabo en un ambiente más amplio que el proyecto mismo. Entender este contexto contribuye a asegurar que el trabajo se lleve a cabo de acuerdo con los objetivos de la empresa y se gestione de conformidad con las metodologías de prácticas establecidas de la organización. Este capítulo describe la estructura básica de un proyecto, así como otras consideraciones importantes de alto nivel, que incluyen la manera en que el proyecto afecta el trabajo operativo continuo, la influencia de los interesados más allá del equipo inmediato del proyecto y el modo en que la estructura de la organización afecta el proyecto en cuanto a la asignación de personal, la dirección y la ejecución. Las secciones que aquí se tratan son:

2,1 El ciclo de vida del proyecto—Panorama general 2,2 Proyectos vs. Trabajo operativo2,3 Interesados2,4 Influencias de la organización en la dirección de proyectos

2.1 El ciclo de vida del proyecto—Panorama general

El ciclo de vida del proyecto es un conjunto de fases del mismo, generalmente secuenciales y en ocasiones superpuestas, cuyo nombre y número se determinan por las necesidades de gestión y control de la organización u organizaciones que participan en el proyecto, la naturaleza propia del proyecto y su área de aplicación. Un ciclo de vida puede documentarse con ayuda de una metodología. El ciclo de vida del proyecto puede ser determinado o conformado por los aspectos únicos de la organización, de la industria o de la tecnología empleada. Mientras que cada proyecto tiene un inicio y un final definidos, los entregables específicos y las actividades que se llevan a cabo entre éstos variarán ampliamente de acuerdo con el proyecto. El ciclo de vida proporciona el marco de referencia básico para dirigir el proyecto, independientemente del trabajo específico involucrado.

2.1.1 Características del ciclo de vida del proyecto

Los proyectos varían en tamaño y complejidad. Todos los proyectos, sin importar cuán pequeños o grandes, o cuán sencillos o complejos sean, pueden configurarse dentro de la siguiente estructura del ciclo de vida (véase el Gráfico 2-1):

• inicio,• organización y preparación, • ejecución del trabajo y• cierre.

A menudo se hace referencia a esta estructura genérica del ciclo de vida durante las comunicaciones con la alta dirección u otras entidades menos familiarizadas con los detalles del proyecto. Esta perspectiva general puede proporcionar un marco de referencia común para comparar proyectos, incluso si son de naturaleza diferente.

Gráfico 2-1. Niveles típicos de costo y dotación de personal durante el ciclo de vida del proyecto

La estructura genérica del ciclo de vida presenta por lo general las siguientes características:

• Los niveles de costo y dotación de personal son bajos al inicio del proyecto, alcanzan su punto máximo según se desarrolla el trabajo y caen rápidamente cuando el proyecto se acerca al cierre. Este patrón típico está representado en el Gráfico 2-1 por la línea punteada.

• La influencia de los interesados, al igual que los riesgos y la incertidumbre (según ilustrado en el Gráfico 2-2) son mayores al inicio del proyecto. Estos factores disminuyen durante la vida del proyecto.

• La capacidad de influir en las características finales del producto del proyecto, sin afectar significativamente el costo, es más alta al inicio del proyecto y va disminuyendo a medida que el proyecto avanza hacia su conclusión. El Gráfico 2-2 ilustra la idea de que el costo de los cambios y de corregir errores suele aumentar sustancialmente según el proyecto se acerca a su fin.

Gráfico 2-2. Impacto de la variable en función del tiempo del proyecto

Dentro del contexto de la estructura genérica del ciclo de vida, un director del proyecto puede determinar la necesidad de un control más efectivo sobre ciertos entregables. En particular, los proyectos grandes y complejos pueden requerir este nivel adicional de control. En tales casos, el trabajo desarrollado para cumplir con los objetivos del proyecto puede verse beneficiado por la división formal en fases.

2.1.2 Relaciones entre el ciclo de vida del producto y del proyecto

El ciclo de vida del producto consta de fases del producto generalmente secuenciales y no superpuestas, y que se determinan en función de las necesidades de fabricación y control de la organización. La última fase del ciclo de vida del producto, para el producto mismo, es por lo general su retiro. Normalmente, el ciclo de vida del proyecto está contenido dentro de uno o más ciclos de vida del producto. Debe tenerse cuidado en diferenciar el ciclo de vida del proyecto del ciclo de vida del producto. Todos los proyectos tienen un propósito u objetivo, pero en aquellos casos donde el objetivo es un servicio o resultado, puede haber un ciclo de vida para el servicio o resultado, pero no un ciclo de vida del producto.

Cuando el resultado de un proyecto está relacionado con un producto, existen muchas relaciones posibles entre ambos. Por ejemplo, el desarrollo de un nuevo producto podría ser un proyecto en si mismo. Por otro lado, un producto existente puede verse beneficiado por un proyecto para agregarle nuevas funciones o características, o puede crearse un proyecto para desarrollar un nuevo modelo. Muchas facetas del ciclo de vida del producto se prestan para ser tratadas como proyectos; por ejemplo, llevar a cabo un estudio de viabilidad, realizar una investigación de mercado, poner en marcha una campaña publicitaria, instalar un producto, organizar grupos de opinión, llevar a cabo la evaluación de un producto en un mercado de prueba, etc. En todos estos ejemplos, el ciclo de vida del proyecto es diferente del ciclo de vida del producto.

Puesto que un producto puede tener muchos proyectos asociados, es posible alcanzar una mayor eficiencia si todos los proyectos relacionados se dirigen colectivamente. Por ejemplo, un cierto número de proyectos individuales pueden estar relacionados con el desarrollo de un nuevo automóvil. Todos los proyectos pueden ser distintos, pero aun asi aportan un entregable clave necesario para sacar el automóvil al mercado. La supervisión de todos los

proyectos por parte de una autoridad de mayor jerarquía podria incrementar significativamente la probabilidad de éxito.

2.1.3 Fases del proyecto

Las fases del proyecto son divisiones dentro del mismo proyecto, donde es necesario ejercer un control adicional para gestionar eficazmente la conclusión de un entregable mayor. Las fases del proyecto suelen completarse de manera secuencial, pero en determinadas situaciones de un proyecto pueden superponerse. Por su naturaleza de alto nivel, las fases del proyecto constituyen un elemento del ciclo de vida del proyecto. Una fase del proyecto no es un grupo de procesos de dirección de proyectos.

La estructuración en fases permite la división del proyecto en subconjuntos lógicos para facilitar su dirección, planificación y control. El número de fases, la necesidad de establecer fases y el grado de control aplicado dependen del tamaño, la complejidad y el impacto potencial del proyecto. Independientemente de la cantidad de fases que compongan un proyecto, todas ellas poseen características similares:

• Cuando las fases son secuenciales, el cierre de una fase termina con cierta forma de transferencia o entrega del trabajo producido como el entregable de la fase. La terminación de esta fase representa un punto natural para re-evaluar el esfuerzo en curso y, en caso de ser necesario, para cambiar o terminar el proyecto. Estos puntos se conocen como salidas de fase, hitos, puertas de fase, puntos de decisión, puertas de etapa o puntos de cancelación.

• El trabajo tiene un enfoque único que difiere del de cualquier otra fase. Esto involucra a menudo diferentes organizaciones y conjuntos de habilidades.

• Para alcanzar con éxito el objetivo o entregable principal de la fase, se requiere un grado adicional de control. Como se describe en el Capítulo 3, la repetición de procesos a través de los cinco grupos de procesos proporciona ese grado adicional de control y define los límites de la fase.

Aunque muchos proyectos pueden tener fases con nombres y entregables similares, pocos son idénticos. Como se muestra en el Gráfico 2-3, algunos proyectos tendrán una sola fase. Otros, en cambio, pueden constar de muchas. El Gráfico 2-4 muestra un ejemplo de proyecto de tres fases. Normalmente, las diferentes fases tienen una duración o longitud diferente.

Gráfico 2-3. Ejemplo de proyecto de una sola fase

No existe una manera única de definir la estructura ideal de un proyecto. Aunque las prácticas comunes de la industria conduzcan con frecuencia a utilizar una estructura preferida, los proyectos en la misma industria, o incluso dentro de la misma organización, pueden presentar variaciones significativas. Algunas organizaciones han establecido políticas de estandarización de todos los proyectos, mientras que otras permiten que el equipo de dirección del proyecto escoja la más apropiada para su proyecto individual. Por ejemplo, una organización puede considerar un estudio de viabilidad como un anteproyecto de rutina, otra puede considerarlo como la primera fase de un proyecto, y una tercera puede considerar el estudio de viabilidad como un proyecto separado e independiente. De la misma manera, un equipo del proyecto podrá dividir el proyecto en dos fases, mientras que otro equipo podrá optar por la gestión de todo el trabajo en una sola fase. Mucho depende de la naturaleza del proyecto específico y del estilo del equipo del proyecto o de la organización.

1 Gobernabilidad del proyecto a lo largo del ciclo de vida

La gobernabilidad del proyecto proporciona un método integral y coherente de controlar el proyecto y asegurar el éxito. El enfoque de la gobernabilidad del proyecto debe describirse en el plan para la dirección del proyecto. La gobernabilidad de un proyecto debe integrarse al contexto más amplio del programa o de la organización que lo patrocina.

Dentro de esas restricciones, así como también de las limitaciones adicionales de tiempo y presupuesto, es función del director del proyecto y del equipo de dirección del proyecto seleccionar el método más idóneo para llevar a cabo el proyecto. Deben tomarse decisiones con respecto a quiénes participarán, qué recursos se necesitan y el enfoque general para completar el trabajo. Otro aspecto importante a considerar es si se requiere más de una fase y, de ser así, cuál será la estructura especifica de las fases para el proyecto individual.

La estructuración en fases proporciona una base formal para el control. Cada fase se inicia formalmente con la especificación de lo que se permite y se espera de la misma. A menudo se efectúa una revisión gerencial para decidir el inicio de las actividades de una fase. Esto es particularmente cierto cuando aún no se ha terminado una fase previa. Un ejemplo seria cuando una organización elige un ciclo de vida en el que más de una fase avanza simultáneamente. El inicio de una fase es un momento oportuno para revalidar los supuestos hechos previamente, revisar los riesgos y definir de manera más detallada los procesos necesarios para completar el entregable o los entregables de la fase. Por ejemplo, si una fase en particular no requiere la compra de materiales o equipos nuevos, no habría necesidad de llevar a cabo las actividades o procesos asociados con adquisiciones.

Por lo general, una fase se concluye y se cierra formalmente con una revisión de los entregables, para determinar su compleción y aceptación. La revisión al final de una fase puede permitir alcanzar el objetivo combinado de obtener la autorización para cerrar la fase actual e iniciar la fase siguiente. La terminación de una fase representa un punto natural para re-evaluar el esfuerzo en curso y, en caso de ser necesario, para cambiar o terminar el proyecto. Deben considerarse una buena práctica la revisión de los entregables clave y el desempeño del proyecto a la fecha, para: a) determinar si el proyecto debe avanzar hacia la siguiente fase y b) detectar y corregir errores de una manera económica. La terminación formal de una fase no implica necesariamente la autorización para continuar con la siguiente fase. Por ejemplo, si el riesgo se considera demasiado grande para continuar el proyecto, o si los objetivos ya no son necesarios, una fase puede cerrarse, con la decisión de no continuar con ninguna otra.

2 Relaciones entre fases

Cuando los proyectos constan de varias fases, las fases son parte de un proceso que generalmente es secuencial, diseñado para asegurar el control apropiado del proyecto y obtener el producto, servicio o resultado deseado. Sin embargo, en determinadas situaciones, un proyecto puede beneficiarse mediante la implementación de fases superpuestas o simultáneas.

Existen tres tipos básicos de relaciones entre fases:

• Una relación secuencial, donde una fase sólo puede iniciarse una vez que se completa la fase anterior. El Gráfico 2-4 muestra un ejemplo de un proyecto compuesto únicamente por fases secuenciales. La naturaleza paso a paso de este enfoque reduce la incertidumbre, pero puede eliminar las opciones de acortar el cronograma.

• Una relación de superposición, donde una fase se inicia antes de que finalice la anterior (véase el Gráfico 2-5). Esto puede aplicarse algunas veces como un ejemplo de la técnica de compresión del cronograma, conocida como ejecución rápida. La superposición puede aumentar el riesgo y causar un reproceso, si la fase siguiente avanza antes de que la información precisa generada en la fase previa esté disponible.

Grafico 2-4. Ejemplo de proyecto de tres fases

Grafico 2-5. Ejemplo de proyecto con fases superpuestas

• Una relación iterativa, donde en un momento dado sólo se planifica una fase y la planificación de la siguiente se efectúa conforme avanzan el trabajo y los entregables de la fase actual. Este enfoque es útil en ambientes muy poco definidos, inciertos o que cambian rápidamente, tales como el de una investigación, pero pueden reducir la

posibilidad de proporcionar una planificación a largo plazo. Así pues, el alcance se gestiona mediante la entrega continua de elementos adicionales del producto y la determinación de prioridades en cuanto a los requisitos, para reducir los riesgos del proyecto e incrementar el valor comercial del producto. También puede implicar contar con la disponibilidad de todos los miembros del equipo del proyecto (por ejemplo, diseñadores, desarrolladores, etc.) durante todo el proyecto, o por lo menos durante dos fases consecutivas.

En el caso de proyectos de fases múltiples, es posible que se presente más de un tipo de relación entre fases durante el ciclo de vida del proyecto. La relación entre las fases es definida en base a aspectos tales como el nivel de control requerido, la efectividad y el grado de incertidumbre. En función de estas consideraciones, los tres tipos de relaciones pueden presentarse entre las diferentes fases de un solo proyecto.

2,2 Proyectos vs. Trabajo operativo

Las organizaciones realizan trabajos con el propósito de alcanzar una serie de objetivos. En muchas organizaciones, el trabajo puede clasificarse como proyecto u operaciones.

Estos dos tipos de trabajo comparten determinadas características: • son realizados por individuos,• están limitados por restricciones, incluso restricciones de recursos, • son planificados, ejecutados, supervisados y controlados, y• son realizados con el fin de alcanzar los objetivos de la organización o los planes

estratégicos.

Los proyectos y las operaciones difieren principalmente en que las operaciones son continuas y producen servicios, resultados o productos repetitivos. Los proyectos (junto con los miembros del equipo y a menudo las oportunidades) son temporales y tienen un final. Por el contrario, las operaciones son continuas y sostienen la organización a lo largo del tiempo. Las operaciones no terminan cuando alcanzan sus objetivos actuales sino que, por el contrario, siguen nuevas direcciones para apoyar los planes estratégicos de la organización.

Las operaciones apoyan el ambiente del negocio donde se ejecutan los proyectos. Como consecuencia, por lo general existe una cantidad significativa de interacciones entre los departamentos operativos y el equipo del proyecto, dado que trabajan juntos para alcanzar los objetivos del proyecto. Un ejemplo de esto es la creación de un proyecto para rediseñar un producto. El director del proyecto puede trabajar con varios directores operativos para investigar las preferencias de los consumidores, elaborar especificaciones técnicas, construir un prototipo, probarlo e iniciar la fabricación del producto. El equipo de proyectos interactuará con los departamentos operativos para determinar la capacidad de producción del equipo actual o para establecer el momento más propicio para transferir las líneas de producción a la fabricación del nuevo producto.

La cantidad de recursos proporcionados por los departamentos operativos varía de un proyecto a otro. Un ejemplo de esta interacción es cuando se asigna personal de operaciones como recursos dedicados al proyecto. Su experiencia en materia operativa se utiliza para desarrollar y completar los entregables del proyecto, a través de su trabajo con el resto del equipo para completar el proyecto.

En función de la naturaleza del proyecto, los entregables pueden modificar o realizar contribuciones a las operaciones existentes. En este caso, el departamento operativo integrará

los entregables en prácticas futuras del negocio. Algunos ejemplos de este tipo de proyectos incluyen:

• el desarrollo de un nuevo producto o servicio que se añade a la línea de productos de una organización para su comercialización y venta,

• la instalación de productos o servicios que requerirán apoyo continuo,• proyectos internos que afectarán la estructura, los niveles de personal o la cultura de

una organización, o• el desarrollo, adquisición o mejora del sistema de información de un departamento

operativo.

2.3 Interesados

Los interesados son personas u organizaciones (por ejemplo, clientes, patrocinadores, la organización ejecutante o el público), que participan activamente en el proyecto, o cuyos intereses pueden verse afectados positiva o negativamente por la ejecución o terminación del proyecto. Los interesados también pueden ejercer influencia sobre el proyecto, los entregables y los miembros del equipo. El equipo de dirección del proyecto debe identificar tanto a los interesados internos como extemos, con objeto de determinar los requisitos del proyecto y las expectativas de todas las partes involucradas. Más aún, el director del proyecto debe gestionar la influencia de los diversos interesados con relación a los requisitos del proyecto, para asegurar un resultado exitoso. El Gráflco 2-6 muestra la relación entre el proyecto, el equipo del proyecto y otros interesados habituales.

Gráfico 2-6. Relación entre los interesados y el proyecto

Los interesados tienen diferentes niveles de responsabilidad y autoridad cuando participan en un proyecto y éstos pueden cambiar durante el ciclo de vida del mismo. Su responsabilidad y autoridad pueden variar desde una participación ocasional en encuestas y grupos de opinión, hasta el patrocinio total del proyecto, lo cual incluye proporcionar apoyo financiero y político. Los interesados pueden tener un impacto adverso en los objetivos del proyecto.

La identificación de los interesados es un proceso continuo y puede resultar difícil. Por ejemplo, se puede argumentar que un operario de una línea de montaje cuyo empleo futuro

depende del resultado de un proyecto de diseño de un nuevo producto, es un interesado. Resulta crucial identificar a los interesados y comprender su grado relativo de influencia en un proyecto. No hacerlo puede prolongar la duración y elevar sustancialmente los costos del proyecto. Un ejemplo es el reconocimiento tardío de que el departamento legal es un interesado significativo, lo cual trae como resultado retrasos y un incremento en los gastos, debido a los requisitos legales.

Para los interesados, un proyecto puede tener resultados tanto positivos como negativos. Algunos interesados se benefician con el éxito de un proyecto, mientras que otros perciben resultados negativos como consecuencia del éxito del proyecto. Por ejemplo, los líderes empresariales de una comunidad que se beneficiarán con un proyecto de expansión industrial a raíz de los beneficios económicos para la comunidad. Para los interesados con expectativas positivas en el proyecto, sus intereses serán mejor atendidos si contribuyen al éxito del proyecto. Los intereses de los interesados negativos se verán mejor atendidos si impiden el avance del proyecto. Ignorar a los interesados negativos puede traer como consecuencia un aumento en la probabilidad de fi-acaso del proyecto. Una de las importantes responsabilidades del director del proyecto consiste en gestionar las expectativas de los interesados. Esto puede ser difícil, ya que a menudo los objetivos de los interesados son muy diferentes o contradictorios. Parte de las responsabilidades del director del proyecto es balancear estos intereses y asegurarse de que el equipo del proyecto interactúe con los interesados de una manera profesional y cooperativa. A continuación se presentan algunos ejemplos de interesados:

• Clientes/Usuarios. Los clientes/usuarios son las personas u organizaciones que usarán el producto, servicio o resultado del proyecto. Los clientes/usuarios pueden ser internos o externos a la organización ejecutante. Incluso puede haber diferentes niveles de clientes. Por ejemplo, los clientes de un nuevo producto farmacéutico pueden incluir a los doctores que lo recetan, a los pacientes que lo consumen y a las aseguradoras que pagan por él. En algunas áreas de aplicación, clientes y usuarios son sinónimos, mientras que en otras, clientes se refiere a la entidad que adquiere el producto del proyecto y usuarios hace referencia a aquéllos que usan el producto del proyecto directamente.

• Patrocinador. Un patrocinador es la persona o grupo que proporciona los recursos financieros, en efectivo o en especie, para el proyecto. Cuando se concibe inicialmente un proyecto, el patrocinador es quien lo defiende. Esto incluye servir de portavoz frente a los altos niveles de dirección, para reunir el apoyo de la organización y promover los beneficios que aportará el proyecto. El patrocinador guía el proyecto a través del proceso de contratación o selección hasta que está formalmente autorizado y cumple un rol significativo en el desarrollo inicial del alcance y del acta de constitución del proyecto.

El patrocinador sirve como vía de escalamiento para los asuntos que están fuera del alcance del director del proyecto. También puede participar en otros asuntos importantes, como la autorización de cambios en el alcance, revisiones al final de una fase y, cuando los riesgos son particularmente altos, decidir si el proyecto debe continuar o no.

• Directores del portafolio/Comité de revisión del portafolio. Los directores del portafolio son responsables de la gobernabilidad de alto nivel de un conjunto de proyectos o programas, que pueden o no ser interdependientes. Los comités de revisión del portafolio están conformados normalmente por ejecutivos de la

organización que actúan como un panel de selección de proyectos. Tienen a su cargo la revisión de cada proyecto desde el punto de vista del retorno de la inversión, el valor del proyecto, los riesgos asociados con su ejecución y otros atributos del proyecto.

• Directores del programa. Los directores del programa son responsables de la gestión coordinada de proyectos relacionados, para obtener beneficios y un control que no serían posibles si los proyectos se gestionaran individualmente. Los directores del programa interactúan con los directores de cada proyecto, proporcionándoles apoyo y guía en proyectos individuales.

• Oficina de dirección de proyectos (PMO). Una oficina de dirección de proyectos es un cuerpo o entidad dentro de una organización que tiene varias responsabilidades asignadas con relación a la dirección centralizada y coordinada de aquellos proyectos que se encuentran bajo su jurisdicción. Las responsabilidades de una oficina de dirección de proyectos pueden abarcar desde el suministro de funciones de soporte para la dirección de proyectos hasta la responsabilidad de la dirección directa de un proyecto. La PMO puede ser un interesado si tiene alguna responsabilidad directa o indirecta en el resultado del proyecto. Entre sus funciones, la PMO puede proporcionar:

o servicios de apoyo administrativo, tales como políticas, metodologías y plantillas;

o capacitación, mentoría y asesoría a los directores del proyecto;

o apoyo al proyecto, lineamientos y capacitación sobre la dirección de proyectos y el uso de herramientas;

o alineación de los recursos de personal del proyecto, y/o

o centralización de la comunicación entre directores del proyecto, patrocinadores, directores y otros interesados.

• Directores del proyecto. Los directores del proyecto son designados por la organización ejecutante para alcanzar los objetivos del proyecto. Se trata de un rol prestigioso, lleno de desafíos, con una responsabilidad significativa y prioridades cambiantes. Requiere de flexibilidad, buen juicio, fuerte liderazgo y habilidades para la negociación, así como de un conocimiento sólido de las prácticas de dirección de proyectos. Un director de proyecto debe ser capaz de comprender los detalles del proyecto, pero debe dirigirlo desde una perspectiva global. Como responsable del éxito del proyecto, el director del proyecto tiene a su cargo todos los aspectos del proyecto, que abarcan, entre otros:

o desarrollar el plan para la dirección del proyecto, así como todos los planes complementarios relacionados,

o mantener el proyecto encaminado en términos de cronograma y presupuesto, o identificar, dar seguimiento y responder a los riesgos, y

o proporcionar informes precisos y oportunos sobre las métricas del proyecto. El director del proyecto es la persona líder responsable de la comunicación con todos los interesados, en particular con el patrocinador del proyecto, el equipo del proyecto y otros interesados clave. El director del proyecto ocupa el centro de las interacciones entre los interesados y el proyecto mismo.

• Equipo del proyecto. El equipo del proyecto está conformado por el director del proyecto, el equipo de dirección del proyecto y otros miembros del equipo que desarrollan el trabajo, pero que no necesariamente participan en la dirección del proyecto. Este equipo está compuesto por quienes llevan a cabo el trabajo del proyecto: individuos procedentes de diferentes grupos, con conocimientos en una materia específica o con un conjunto de habilidades específicas.

• Gerentes funcionales. Los gerentes funcionales son personas clave que desempeñan el rol de gestores dentro de un área administrativa o funcional de una empresa, tal como recursos humanos, finanzas, contabilidad o adquisiciones. Cuentan con personal permanente propio asignado para la realización del trabajo en curso y tienen la clara misión de gestionar todas las tareas dentro de su área funcional de responsabilidad. El gerente funcional puede aportar su experiencia en la materia, o bien su función puede proporcionar servicios al proyecto.

• Gerentes de operaciones. Los gerentes de operaciones desempeñan una función de gestión en un área medular de la empresa, tal como la de investigación y desarrollo, diseño, fabricación, aprovisionamiento, pruebas o mantenimiento. A diferencia de los gerentes funcionales, estos gerentes tienen que ver directamente con la producción y el mantenimiento de los productos o servicios que vende la empresa. En función del tipo de proyecto, una vez que éste se termina, se realiza una entrega formal de la documentación técnica del proyecto y de otros registros permanentes al grupo de gerentes de operaciones correspondiente. La gestión de operaciones incorpora el proyecto entregado dentro de las operaciones normales y proporciona el apoyo a largo plazo.

• Vendedores/Socios de negocios. Los vendedores, también llamados proveedores o contratistas, son compañías externas que celebran un contrato para proporcionar componentes o servicios para el proyecto. Los socios de negocios también son compañías externas, pero que tienen una relación especial con la empresa, lograda algunas veces mediante un proceso de certificación. Los socios de negocios proporcionan experiencia especializada o desempeñan una función específica, como una instalación, adecuación, capacitación o apoyo.

2.4 Influencias de la organización en la dirección de proyectos

La cultura, estilo y estructura de la organización influyen en la forma en la que los proyectos son ejecutados. El grado de madurez de la dirección de proyectos de una organización, así como sus sistemas de dirección de proyectos, también puede influenciar el proyecto. Cuando en el proyecto participan entidades externas, como resultado de una unión temporal de empresas o de un convenio para un proyecto determinado, el proyecto recibirá la influencia de más de una empresa. En las siguientes secciones, se describen características y estructuras de la organización dentro de una empresa, capaces de influenciar el proyecto.

2.4.1 Culturas y estilos de la organización

Las culturas y estilos pueden tener una fuerte influencia en la capacidad del proyecto de alcanzar sus objetivos. Las culturas y estilos se conocen habitualmente como "normas culturales". Las "normas" incluyen un conocimiento común sobre qué enfoque abordar para la realización del trabajo, qué medios se consideran aceptables para este fin y quién tiene influencia para facilitarlo.

Muchas organizaciones han desarrollado culturas únicas que se manifiestan de diferentes maneras, entre las que se incluyen:

• visiones, valores, normas, creencias y expectativas compartidas, • políticas, métodos y procedimientos,• percepción de las relaciones de autoridad, y • ética laboral y horario de trabajo.

La cultura de la organización es un factor ambiental de la empresa, como se describe en la Sección 1.8. Por lo tanto, un director del proyecto debe comprender las diferentes culturas y estilos de la organización que pueden influenciar un proyecto. Por ejemplo, en algunos casos la persona que aparece encabezando un organigrama puede ser sólo una figura decorativa y no estar a cargo realmente. El director del proyecto debe conocer quiénes toman las decisiones dentro de la organización y trabajar con ellos para influir en el éxito del proyecto.

2.4.2 Estructura de la organización

La estructura de la organización es un factor ambiental de la empresa que puede afectar la disponibilidad de recursos e influir en el modo de dirigir los proyectos. Las estructuras abarcan desde una estructura funcional hasta una estructura orientada a proyectos, con una variedad de estructuras matriciales entre ellas. El Cuadro 2-1 muestra las características clave de los principales tipos de estructuras de la organización relacionadas con los proyectos.

Cuadro 2-1. Influencias de la organización en los proyectos

La organización funcional clásica, como se muestra en el Gráfico 2-7, es una jerarquía donde cada empleado tiene un superior claramente definido. En el nivel superior, los miembros del personal están agrupados por especialidades, tales como: producción, comercialización, ingeniería y contabilidad. A su vez, las especialidades pueden subdividirse en organizaciones funcionales, como la ingeniería mecánica y la ingeniería eléctrica. Cada departamento de una

organización funcional realizará el trabajo del proyecto de forma independiente de los demás departamentos.

Gráfico 2-7. Organización funcional

Las organizaciones matriciales, como se muestra en los Gráficos 2-8 a 2-10, presentan una mezcla de características de las organizaciones funcionales y de las orientadas a proyectos. Las matriciales débiles mantienen muchas de las características de una organización funcional, y el rol del director del proyecto es más bien el de un coordinador o expedidor, que el de un verdadero director del proyecto. Las matriciales fLiertes tienen muchas de las características de la organización orientada a proyectos: pueden tener directores del proyecto dedicados de tiempo completo y una autoridad considerable, y personal administrativo dedicado de tiempo completo. Si bien la organización matricial equilibrada reconoce la necesidad de contar con un director del proyecto, no le confiere autoridad plena sobre el proyecto ni su financiamiento. El Cuadro 2-1 proporciona detalles adicionales sobre las diferentes estructuras matriciales de la organización.

Gráfico 2-8. Organización matricial débil

Gráfico 2-9. Organización matricial equilibrada

Gráfico 2-10. Organización matricial fuerte

En el extremo opuesto de la organización funcional, se encuentra la organización orientada a proyectos, como se muestra en el Gráfico 2-11. En una organización orientada a proyectos, los miembros del equipo están a menudo colocados en un mismo lugar, la mayor parte de los recursos de la organización participa en el trabajo de los proyectos y los directores del proyecto tienen mucha más independencia y autoridad. Las organizaciones orientadas a proyectos suelen contar con unidades organizacionales denominadas departamentos, pero estos grupos dependen directamente del director del proyecto, o bien prestan sus servicios a varios proyectos.

Gráfico 2-11. Organización orientada a proyectos

Gráfico 2-12. Organización combinada

Muchas organizaciones presentan todas estas estructuras a diferentes niveles, como se muestra en el Gráfico 2-12 (Organización combinada). Por ejemplo, incluso una organización fundamentalmente funcional puede crear un equipo del proyecto especial para gestionar un proyecto crítico. Dicho equipo puede tener muchas de las características de un equipo del proyecto de una organización orientada a proyectos. El equipo puede incluir personal dedicado de tiempo completo procedente de diferentes departamentos funcionales, desarrollar su propio conjunto de procedimientos operativos y funcionar fuera de la estructura estándar formalizada de reporte.

2.4.3 Activos de los procesos de la organización

Los activos de los procesos de la organización abarcan alguno o todos los activos relativos a procesos de alguna o todas las organizaciones participantes en el proyecto que pueden usarse para influir en el éxito del proyecto. Estos activos de procesos abarcan planes, políticas, procedimientos y lineamientos, ya sean formales o informales. Los activos de procesos también abarcan las bases de conocimiento de la organización, como las lecciones aprendidas y la información histórica. Los activos de los procesos de la organización pueden incluir cronogramas completados, datos sobre riesgos y datos sobre el valor ganado. Las actualizaciones y adiciones que sea necesario efectuar a lo largo del proyecto con relación a los activos de los procesos de la organización, son por lo general responsabilidad de los miembros del equipo del proyecto. Los activos de los procesos de la organización pueden agruparse en dos categorías:

1 Procesos y procedimientos

Los procesos y procedimientos de la organización para realizar el trabajo incluyen, entre otros:

• procesos estándar de la organización, tales como: normas, políticas (por ejemplo, políticas de seguridad y salud, política de ética, y política de dirección de proyectos), ciclos estándar de vida del producto y del proyecto, políticas y procedimientos de calidad (por ejemplo, auditorias de procesos, objetivos de mejora, listas de control y definiciones estandarizadas de procesos para usarse en la organización);

• lineamientos, instrucciones de trabajo, criterios para la evaluación de propuestas y criterios estandarizados para la medición del desempeño;

• plantillas (por ejemplo, plantillas de riesgos, de estructura de desglose del trabajo, de diagrama de red del cronograma del proyecto y de contratos);

• lineamientos y criterios para adaptar el conjunto de procesos estándar de la organización para que satisfagan las necesidades específicas del proyecto;

• requisitos de comunicación de la organización (por ejemplo, tecnología especifica de comunicación disponible, medios de comunicación permitidos, políticas de retención de registros y requisitos de seguridad);

• lineamientos o requisitos de cierre del proyecto (por ejemplo, auditorias finales del proyecto, evaluaciones del proyecto, validaciones del producto y criterios de aceptación);

• procedimientos de control financiero (por ejemplo, informes de tiempo, revisiones requeridas de gastos y desembolsos, códigos contables y provisiones contractuales estándar);

• procedimientos para la gestión de problemas y defectos que definen los controles para problemas y defectos, la identificación y la solución de problemas y defectos, así como el seguimiento de los elementos de acción;

• procedimientos de control de cambios, incluyendo las etapas por las cuales se modificarán las normas, políticas, planes y procedimientos oficiales de la compañía (o cualquier otro documento del proyecto), y cómo se aprobará y validará cualquier cambio;

• procedimientos de control de riesgos, que incluyen categorías de riesgos, definición de la probabilidad e impacto y la matriz de la probabilidad e impacto; y

• procedimientos para priorizar, aprobar y emitir autorizaciones de trabajo.

2 Base corporativa de conocimiento

La base corporativa de conocimiento de la organización para almacenar y recuperar información abarca, entre otros elementos:

• bases de datos para la medición de procesos, que se utiliza para recopilar y tener disponibles los datos de mediciones de procesos y productos,

• archivos del proyecto (por ejemplo, líneas base de alcance, costo, cronograma y calidad, líneas base para la medición del desempeño, calendarios del proyecto, diagramas de red del cronograma del proyecto, registros de riesgos, acciones planificadas de respuesta e impacto definido del riesgo),

• información histórica y bases de conocimiento de lecciones aprendidas (por ejemplo, registros y documentos del proyecto, toda la información y documentación de cierre del proyecto, información sobre los resultados de las decisiones de selección y sobre el desempeño de proyectos previos, e información sobre el esfuerzo de gestión de riesgos),

• bases de datos sobre la gestión de problemas y defectos que contiene el estado de los problemas y defectos, información del control, resolución de los problemas y defectos, y los resultados de los elementos de acción,

• base del conocimiento de la gestión de configuración, que contiene las versiones y líneas base de todas las normas, políticas y procedimientos oficiales de la compañía, y cualquier otro documento del proyecto, y

• bases de datos financieras que contienen informaciones tales como horas de trabajo, costos incurridos, presupuestos y cualquier déficit presupuestario del proyecto.

Sección II

La Norma para la Dirección de Proyectos de un Proyecto

Capítulo 3 Procesos de la Dirección de Proyectos para un Proyecto

Capítulo 3 Procesos de la Dirección deProyectos para un Proyecto

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. Como se explica en los Capítulos 1 y 2, el director del proyecto debe considerar los activos de los procesos de la organización y los factores ambientales de la empresa. Éstos se deben tener en cuenta para cada proceso, incluso si no están enumerados de manera explícita como entradas en las especificaciones del proceso. Los activos de los procesos de la organización proporcionan pautas y criterios para adaptar dichos procesos a las necesidades específicas del proyecto. Los factores ambientales de la empresa pueden restringir las opciones de la dirección de proyectos.

Para que un proyecto tenga éxito, el equipo del proyecto debe:

• seleccionar los procesos adecuados requeridos para alcanzar los objetivos del proyecto,

• utilizar un enfoque definido que pueda adoptarse para cumplir con los requisitos,• cumplir con los requisitos a fin de satisfacer las necesidades y expectativas de los

interesados, y• equilibrar las demandas contrapuestas relativas al alcance, tiempo, costo, calidad,

recursos y riesgo para producir el producto, servicio o resultado especificado.

Los procesos del proyecto son ejecutados por el equipo del proyecto y generalmente se enmarcan en una de las siguientes dos 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 (Capítulos 4 a 12).

• Los procesos orientados al producto especifican y crean el producto del proyecto. Estos procesos normalmente son definidos por el ciclo de vida del proyecto (como se analiza en la Sección 2.1.2) 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.

Los procesos de dirección de proyectos se aplican globalmente y a todos los grupos de industrias. Buenas prácticas significa que existe un acuerdo general en cuanto a que se ha demostrado que la aplicación de los procesos de dirección de proyectos aumenta las posibilidades de éxito de una amplia variedad de proyectos.

Esto no significa que los conocimientos, habilidades y procesos descritos deban aplicarse siempre de la misma manera en todos los proyectos. Para un proyecto determinado, el director del proyecto, en colaboración con el equipo del proyecto, siempre tiene la responsabilidad de determinar cuáles son los procesos apropiados, así como el grado de rigor adecuado para cada proceso.

Los directores del proyecto y sus equipos deben abordar cuidadosamente cada proceso, así como las entradas y salidas que lo constituyen. Este capítulo debe servirles de guía para aquellos procesos que deben considerar en la dirección de su proyecto. Este esfuerzo se conoce como adaptación.

La dirección de proyectos es una tarea integradora que requiere que cada proceso del producto y del proyecto esté alineado y conectado de manera adecuada con los demás procesos, a fin de facilitar la coordinación. Normalmente, las acciones tomadas durante un proceso afectan a ese proceso y a otros procesos relacionados. Por ejemplo, un cambio de alcance afecta generalmente al costo del proyecto, pero puede no afectar al plan de comunicación o a la calidad del producto. A menudo, estas interacciones entre procesos requieren efectuar concesiones entre requisitos y objetivos del proyecto, y las concesiones específicas de desempeño variarán de un proyecto a otro y de una organización a otra. Una dirección de proyectos exitosa incluye dirigir activamente estas interacciones a fin de cumplir con los requisitos del patrocinador, el cliente y los demás interesados. En determinadas circunstancias, será necesario repetir varias veces un proceso o conjunto de procesos para alcanzar el resultado requerido.

Los proyectos existen en el marco de referencia de una organización y no pueden operar como un sistema cerrado. Requieren datos de entrada procedentes de la organización y del exterior, y producen capacidades que vuelven a la organización.Los procesos del proyecto pueden generar información para mejorar la dirección de futuros proyectos.

Esta norma describe la naturaleza de los procesos de dirección de proyectos en términos de la integración entre los procesos, sus interacciones y los propósitos a los cuales sirven. Los procesos de dirección de proyectos se agrupan en cinco categorías conocidas como Grupos de Procesos de la Dirección de Proyectos (o grupos de procesos):

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

Este capítulo también proporciona información para la dirección de proyectos de un proyecto individual organizado como una red de procesos interrelacionados, detallando los procesos, e incluye las siguientes secciones principales:

3.1 Interacciones comunes entre procesos de dirección de proyectos3.2 Grupos de procesos de la dirección de proyectos3.3 Grupo del Proceso de Iniciación3.4 Grupo del Proceso de Planificación3.5 Grupo del Proceso de Ejecución3.6 Grupo del Proceso de Seguimiento y Control3.7 Grupo del Proceso de Cierre

3.1 interacciones comunes entre procesos de la dirección de proyectos

Los procesos de dirección de proyectos se presentan como elementos diferenciados con interfaces bien definidas. Sin embargo, en la práctica se superponen e interactúan en formas que aquí no se detallan totalmente. La mayoría de los profesionales con experiencia en este ámbito reconocen que existe más de una forma de dirigir un proyecto. Los grupos de procesos requeridos y los procesos que los constituyen sirven de guía para aplicar conocimientos y habilidades apropiados en materia de dirección de proyectos durante el proyecto. La aplicación de los procesos de dirección de proyectos es iterativa y 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, como se muestra en el Gráfico 3-1. 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.

Gráfico 3-1. Grupos de Procesos de la Dirección de Proyectos

Los Grupos de Procesos de la Dirección de Proyectos se vinculan entre sí a través de los resultados que producen. Los grupos de procesos rara vez son eventos diferenciados o únicos; son actividades superpuestas que tienen lugar a lo largo de todo el proyecto. La salida de un proceso normalmente se convierte en la entrada para otro proceso o es un entregable del proyecto. El Grupo del Proceso de Planificación suministra al Grupo del Proceso de Ejecución el Plan para la Dirección del Proyecto y los documentos del proyecto y, conforme el proyecto avanza, a menudo exige actualizar el plan para la dirección del proyecto y dichos documentos. El Gráfico 3-2 ilustra cómo interactúan los grupos de procesos y muestra el nivel de superposición en distintas etapas. Cuando el proyecto está dividido en fases, los grupos de procesos interactúan dentro de cada fase.

Gráfico 3-2. Los grupos de procesos interactúan en una fase o proyecto

Un ejemplo de esto sería la salida de una fase de diseño, que requiere la aceptación del documento de diseño por parte del cliente. El documento de diseño proporciona, una vez que está disponible, la descripción del producto para los grupos de procesos de planificación y de ejecución en una o más fases subsiguientes. Cuando un proyecto se divide en fases, los grupos de procesos se activan según resulte apropiado a fin de conducir eficazmente el proyecto hacia

su cierre de una manera controlada. En proyectos de fases múltiples, los procesos se repiten dentro de cada fase hasta que se cumplan los criterios para concluir la fase. El Capítulo 2 proporciona información adicional sobre los ciclos de vida del proyecto y las fases del proyecto.

3.2 Grupos de Procesos de la Dirección de Proyectos

Las siguientes secciones identifican y describen los cinco grupos de procesos de la dirección de proyectos necesarios en todo proyecto. Estos cinco grupos de procesos cuentan con dependencias bien definidas y normalmente se los ejecuta en la misma secuencia en cada proyecto. Son independientes de las áreas de aplicación y del enfoque de las industrias. Los grupos de procesos individuales y los procesos individuales que los constituyen a menudo se repiten antes de concluir el proyecto. Los procesos constitutivos pueden presentar interacciones dentro de un grupo de procesos y entre grupos de procesos. Estas interacciones, cuya naturaleza varía de un proyecto a otro, pueden realizarse o no en un orden determinado.

El diagrama de flujo de procesos, Gráfico 3-3, proporciona un resumen global del flujo básico y de las interacciones entre los grupos de procesos y los interesados específicos. Un grupo de procesos incluye los procesos constitutivos de la dirección de proyectos que están vinculados por las entradas y salidas respectivas; de este modo el resultado de un proceso se convierte en la entrada de otro. Los grupos de procesos no son fases del proyecto. Cuando proyectos complejos o de gran tamaño son separados en subproyectos o fases diferenciadas, como por ejemplo estudio de viabilidad, desarrollo conceptual, diseño, prototipo, construcción, prueba, etc., por lo general, todos los grupos de procesos se repetirán en cada fase o subproyecto.

El Cuadro 3-1 refleja la correspondencia entre los 42 procesos de dirección de proyectos con los 5 grupos de procesos de dirección de proyectos y las 9 Áreas de Conocimiento de la Dirección de Proyectos. Los procesos de la dirección de proyectos se muestran en el grupo de procesos en el cual ocurre la mayor parte de la actividad. Por ejemplo, cuando un proceso que normalmente ocurre en el Grupo del Proceso de Planificación se actualiza en el Grupo del Proceso de Ejecución, no se considera como un proceso nuevo.

Gráfico 3-3. Interacciones entre procesos de la dirección de proyectosCuadro 3-1. Correspondencia entre grupos de procesos y áreas de conocimiento de la

dirección de proyectos

3.3 Grupo del Proceso de Iniciación

El Grupo del Proceso de Iniciación está compuesto por 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. Dentro de los procesos de

iniciación, se define el alcance inicial y se comprometen los recursos financieros iniciales. Se identifican los interesados internos y externos que van a interactuar y ejercer alguna influencia sobre el resultado global del proyecto. 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 (Gráfico 3-4).

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.

En general, involucrar a los clientes y a otros interesados durante la iniciación mejora la probabilidad de contar con propiedad compartida, con la aceptación de los entregables y con la satisfacción del cliente y demás interesados.

Gráfico 3-4. Límites del proyecto

Los procesos de iniciación pueden ser realizados por procesos de la organización, del programa o del portafolio que son ajenos al alcance de control del proyecto. Por ejemplo, antes de iniciar un proyecto, la necesidad de requisitos de alto nivel puede documentarse como parte de una iniciativa más amplia de la organización. La viabilidad de la nueva tarea puede establecerse mediante un proceso de evaluación de alternativas. Los objetivos del proyecto se describen con claridad, y entre ellos, las razones por las que un proyecto específico resulta la mejor alternativa para cumplir los requisitos. La documentación que respalda esta decisión también puede contener la declaración inicial del alcance del proyecto, los entregables, la duración del proyecto y una proyección de los recursos para el análisis de inversión de la organización. Como parte de los procesos de iniciación, se otorga autoridad al director del proyecto para que utilice recursos de la organización en las actividades posteriores del proyecto.

Gráfico 3-5. Grupo del Proceso de Iniciación

El Grupo del Proceso de Iniciación (Gráfico 3-5) incluye los siguientes procesos de dirección de proyectos (Gráficos 3-6 y 3-7):

3.3.1 Desarrollar el Acta de Constitución del Proyecto

Desarrollar el Acta de Constitución del Proyecto es el proceso que consiste en desarrollar un documento que autoriza formalmente un proyecto o una fase, y en documentar los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados. En proyectos de fases múltiples, este proceso se utiliza para validar o refinar las decisiones tomadas durante la repetición anterior del proceso Desarrollar el Acta de Constitución del Proyecto.

Gráfico 3-6. Desarrollar el Acta de Constitución del Proyecto: Entradas y Salidas

3.3.2 Identificar a los Interesados

Identificar a los Interesados es el proceso que consiste en identificar a todas las personas u organizaciones que reciben el impacto del proyecto, y en documentar información relevante relativa a sus intereses, participación e impacto en el éxito del proyecto.

Figura 3-7. Identificar a los Interesados: Entradas y Salidas3.4 Grupo del Proceso de Planificación

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. Los procesos de planificación desarrollan el plan para la dirección del proyecto y los documentos del proyecto que se utilizarán para llevarlo a cabo. La naturaleza multidimensional de la dirección de proyectos genera bucles de retroalimentación repetidos que permiten un análisis adicional. 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. Esta incorporación progresiva de detalles al plan para la dirección del proyecto recibe generalmente el nombre de “planificación gradual”, para indicar que la planificación y la documentación son procesos repetitivos y continuos.

Gráfico 3-8. Grupo del Proceso de Planificación

El plan para la dirección del proyecto y los documentos del proyecto desarrollados como salidas del grupo de procesos de planificación, explorarán todos los aspectos del alcance, tiempo, costos, calidad, comunicación, riesgos y adquisiciones. Las actualizaciones que surgen de los cambios aprobados durante el proyecto pueden tener un impacto considerable en partes del plan para la dirección del proyecto y en los documentos del proyecto. Estas actualizaciones a los documentos aportan mayor precisión en torno al cronograma, costos y requisitos de recursos a fin de cumplir con el alcance definido del proyecto.

El equipo del proyecto debe estimular la participación de todos los interesados pertinentes durante la planificación del proyecto y en el desarrollo del plan para la dirección y documentos del proyecto. Debido a que el proceso de retroalimentación y mejora no puede continuar de manera indefinida, 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.

Otras interacciones entre los procesos dentro del grupo de procesos de planificación dependen de la naturaleza del proyecto. Por ejemplo, en algunos proyectos, el riesgo será mínimo o no identificable hasta que se haya realizado la mayor parte de la planificación. En ese momento, el equipo puede reconocer que las metas con respecto al cronograma y los costos resultan demasiado agresivas, es decir, implican un mayor riesgo que el contemplado previamente. Los resultados de las iteraciones se documentan como actualizaciones al plan para la dirección del proyecto o a los documentos del proyecto.

El Grupo del Proceso de Planificación (Gráfico 3-8) incluye los procesos de dirección de proyectos identificados en los Gráficos 3-9 a 3-28 (véanse las Secciones 3.4.1 a 3.4.20).

3.4.1 Desarrollar el Plan para la Dirección del Proyecto

Desarrollar el Plan para la Dirección del Proyecto es el proceso que consiste endocumentar las acciones necesarias para definir, preparar, integrar y coordinar todos losplanes subsidiarios. El plan para la dirección del proyecto se convierte en la fuenteprimaria de información para determinar la manera en que se planificará, ejecutará,supervisará y controlará, y cerrará el proyecto.

Gráfico 3-9. Desarrollar el Plan para la Dirección del Proyecto: Entradas y Salidas

3.4.2 Recopilar Requisitos

Recopilar Requisitos es el proceso que consiste en definir y documentar las necesidades de los interesados a fin de cumplir con los objetivos del proyecto.

Gráfico 3-10. Recopilar Requisitos: Entradas y Salidas

3.4.3 Definir el Alcance

Definir el Alcance es el proceso que consiste en desarrollar una descripción detallada del proyecto y del producto.

Gráfico 3-11. Definir el Alcance: Entradas y Salidas

3.4.4 Crear la EDT (Estructura de Desglose del Trabajo)Crear la Estructura de Desglose del Trabajo es el proceso que consiste en subdividir los entregables y el trabajo del proyecto en componentes más pequeños y más fáciles de dirigir.

Gráfico 3-12. Crear la EDT: Entradas y Salidas

3.4.5 Definir las ActividadesDefinir las Actividades es el proceso que consiste en identificar las acciones específicas a ser realizadas para elaborar los entregables del proyecto.

Gráfico 3-13. Definir las Actividades: Entradas y Salidas

3.4.6 Secuenciar las ActividadesSecuenciar las Actividades es el proceso que consiste en identificar y documentar las relaciones entre las actividades del proyecto.

Gráfico 3-14. Secuenciar las Actividades: Entradas y Salidas

3.4.7 Estimar los Recursos de las ActividadesEstimar los Recursos de las Actividades es el proceso que consiste en estimar el tipo y las cantidades de materiales, personas, equipos o suministros requeridos para ejecutar cada actividad.

Gráfico 3-15. Estimar los Recursos de las Actividades: Entradas y Salidas

3.4.8 Estimar la Duración de las ActividadesEstimar la Duración de las Actividades es el proceso que consiste en establecer aproximadamente la cantidad de períodos de trabajo necesarios para finalizar cada actividad con los recursos estimados.

Gráfico 3-16. Estimar la Duración de las Actividades: Entradas y Salidas

3.4.9 Desarrollar el CronogramaDesarrollar 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.

Gráfico 3-17. Desarrollar el Cronograma: Entradas y Salidas

3.4.10 Estimar CostosEstimar Costos es el proceso que consiste en desarrollar una aproximación de los recursos monetarios necesarios para completar las actividades del proyecto.

Gráfico 3-18. Estimar Costos: Entradas y Salidas

3.4.11 Determinar el PresupuestoDeterminar el Presupuesto es el proceso que consiste en sumar los costos estimados de actividades individuales o paquetes de trabajo para establecer una línea base de costos autorizados.

Gráfico 3-19. Determinar el Presupuesto: Entradas y Salidas

3.4.12 Planificar la CalidadPlanificar 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.

Gráfico 3-20. Planificar la Calidad: Entradas y Salidas

3.4.13 Desarrollar el Plan de Recursos HumanosDesarrollar 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.

Gráfico 3-21. Desarrollar el Plan de Recursos Humanos: Entradas y Salidas

3.4.14 Planificar las ComunicacionesPlanificar las Comunicaciones es el proceso para determinar las necesidades de información de los interesados en el proyecto y para definir cómo abordar las comunicaciones.

Gráfico 3-22. Planificar las Comunicaciones: Entradas y Salidas

3.4.15 Planificar la Gestión de RiesgosPlanificar la Gestión de Riesgos es el proceso por el cual se define cómo realizar las actividades de gestión de riesgos para un proyecto.

Gráfico 3-23. Planificar la Gestión de Riesgos: Entradas y Salidas

3.4.16 Identificar Riesgos

Identificar Riesgos es el proceso por el cual se determinan los riesgos que pueden afectar el proyecto y se documentan sus características.

Figura 3-24. Identificar Riesgos: Entradas y Salidas

3.4.17 Realizar Análisis Cualitativo de RiesgosRealizar 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.

Gráfico 3-25. Realizar Análisis Cualitativo de Riesgos: Entradas y Salidas

3.4.18 Realizar Análisis Cuantitativo de RiesgosRealizar Análisis Cuantitativo de Riesgos es el proceso que consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto.

Gráfico 3-26. Realizar Análisis Cuantitativo de Riesgos: Entradas y Salidas

3.4.19 Planificar la Respuesta a los RiesgosPlanificar 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.

Gráfico 3-27. Planificar la Respuesta a los Riesgos: Entradas y Salidas

3.4.20 Planificar las AdquisicionesPlanificar las Adquisiciones es el proceso que consiste en documentar las decisiones de compra para el proyecto, especificar el enfoque e identificar posibles vendedores.

Gráfico 3-28. Planificar las Adquisiciones: Entradas y Salidas

3.5 Grupo del Proceso de EjecuciónEl Grupo del Proceso de Ejecución está compuesto por 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. Este grupo de proceso implica coordinar personas y recursos, así como integrar y realizar las actividades del proyecto de conformidad con el plan para la dirección del proyecto (Gráfico 3-29).

Gráfico 3-29. Grupo del Proceso de Ejecución

Durante la ejecución del proyecto, los resultados pueden requerir que se actualice la planificación y que se vuelva a establecer la línea base. 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. El grupo de procesos de ejecución incluye los siguientes procesos de dirección de proyectos (Gráficos 3-30 a 3-37):

3.5.1 Dirigir y Gestionar la Ejecución del ProyectoDirigir 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.

Gráfico 3-30. Dirigir y Gestionar la Ejecución del Proyecto: Entradas y Salidas

3.5.2 Realizar Aseguramiento de CalidadRealizar Aseguramiento de Calidad es el proceso que consiste en auditar los requisitos de calidad y los resultados obtenidos a partir de medidas de control de calidad, a fin de garantizar que se utilicen definiciones operacionales y normas de calidad adecuadas.

Gráfico 3-31. Realizar Aseguramiento de Calidad: Entradas y Salidas

3.5.3 Adquirir el Equipo del ProyectoAdquirir el Equipo del Proyecto es el proceso para confirmar los recursos humanos disponibles y a formar el equipo necesario para completar las asignaciones del proyecto.

Gráfico 3-32. Adquirir el Equipo del Proyecto: Entradas y Salidas

3.5.4 Desarrollar el Equipo del ProyectoDesarrollar el Equipo del Proyecto es el proceso que consiste en mejorar las competencias, la interacción de los miembros del equipo y el ambiente general del equipo para lograr un mejor desempeño en el proyecto.

Gráfico 3-33. Desarrollar el Equipo del Proyecto: Entradas y Salidas

3.5.5 Dirigir el Equipo del ProyectoDirigir el equipo del proyecto es el proceso que consiste en dar seguimiento al desempeño de los miembros del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto.

Gráfico 3-34. Dirigir el Equipo del Proyecto: Entradas y Salidas

3.5.6 Distribuir la InformaciónDistribuir la Información es el proceso para poner la información relevante a la disposición de los interesados en el proyecto de acuerdo al plan establecido.

Gráfico 3-35. Distribuir la Información: Entradas y Salidas

3.5.7 Gestionar las Expectativas de los InteresadosGestionar las Expectativas de los Interesados es el proceso que consiste en comunicarse y trabajar en conjunto con los interesados para satisfacer sus necesidades y abordar los problemas conforme se presentan.

Gráfico 3-36. Gestionar las Expectativas de los Interesados: Entradas y Salidas

3.5.8 Efectuar AdquisicionesEfectuar Adquisiciones es el proceso que consiste en obtener respuestas de los vendedores, seleccionar un vendedor y adjudicar un contrato.

Gráfico 3-37. Efectuar Adquisiciones: Entradas y Salidas

3.6 Grupo del Proceso de Seguimiento y Control

El grupo del Proceso de Seguimiento y Control está compuesto por aquellos procesos requeridos para supervisar, 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. El beneficio clave de este grupo de procesos radica en que el desempeño del proyecto se observa y se mide de manera sistemática y regular, a fin de identificar variaciones respecto del plan para la dirección del proyecto. El grupo de procesos de seguimiento y control también incluye:

• controlar cambios y recomendar acciones preventivas para anticipar posibles problemas,

• dar seguimiento a las actividades del proyecto, comparándolas con el plan para la dirección del proyecto y la línea base desempeño de ejecución del proyecto

• influir en los factores que podrían eludir el control integrado de cambios, de modo que únicamente se implementen cambios aprobados.

Este seguimiento continuo proporciona al equipo del proyecto conocimientos sobre la salud del proyecto y permite identificar las áreas que requieren más atención. Además de dar seguimiento y controlar el trabajo que se está realizando dentro de un grupo de proceso, este grupo de proceso da seguimiento y controla la totalidad del esfuerzo del proyecto. 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.

Gráfico 3-38. Grupo del Proceso de Seguimiento y Control

El Grupo del Proceso de Seguimiento y Control (Gráfico 3-38) incluye los siguientes procesos de dirección de proyectos (Gráficos 3-39 a 3-48):

3.6.1 Dar Seguimiento y Controlar el Trabajo del ProyectoDar Seguimiento y Controlar el Trabajo del Proyecto es el proceso que consiste en revisar, analizar y regular el avance a fin de cumplir con los objetivos de desempeño definidos en el plan para la dirección del proyecto. Dar Seguimiento implica realizar informes de estado, mediciones del avance y proyecciones. Los informes de desempeño suministran información sobre el desempeño del proyecto en lo relativo al alcance, cronograma, costos, recursos, calidad y riesgos, que puede utilizarse como entrada para otros procesos.

Gráfico 3-39. Dar Seguimiento y Controlar el Trabajo del Proyecto: Entradas y Salidas

3.6.2 Realizar Control Integrado de CambiosRealizar Control Integrado de cambios es el proceso que consiste en revisar todas las solicitudes de cambios, aprobar los cambios 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.

Gráfico 3-40. Realizar Control Integrado de Cambios: Entradas y Salidas

3.6.3 Verificar el AlcanceVerificar el Alcance es el proceso que consiste en formalizar la aceptación de los entregables del proyecto que se han completado.

Gráfico 3-41. Verificar el Alcance: Entradas y Salidas

3.6.4 Controlar el AlcanceControlar el Alcance es el proceso por el que se da seguimiento el estado del alcance del proyecto y del producto, y se gestionan cambios a la línea base del alcance.

Gráfico 3-42. Controlar el Alcance: Entradas y Salidas

3.6.5 Controlar el CronogramaControlar el Cronograma es el proceso por el que se da seguimiento a la situación del proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma.

Gráfico 3-43. Controlar el Cronograma: Entradas y Salidas

3.6.6 Controlar CostosControlar costos es el proceso por el que se da seguimiento a la situación del proyecto para actualizar el presupuesto del mismo y gestionar cambios a la línea base de costo.

Gráfico 3-44. Controlar Costos: Entradas y Salidas

3.6.7 Realizar Control de CalidadRealizar Control de Calidad es el proceso por el que se da seguimiento y se registran los resultados de la ejecución de actividades de control de calidad, a fin de evaluar el desempeño y recomendar cambios necesarios.

Gráfico 3-45. Realizar Control de Calidad: Entradas y Salidas

3.6.8 Informar el DesempeñoInformar el Desempeño es el proceso de recopilación y distribución de información sobre el desempeño, incluidos informes de estado, mediciones del avance y proyecciones.

Gráfico 3-46. Informar el Desempeño: Entradas y Salidas

3.6.9 Dar Seguimiento y Controlar los RiesgosDar Seguimiento r y Controlar los Riesgos es el proceso por el cual se implementan planes de respuesta a los riesgos, se da seguimiento a los riesgos identificados, se da seguimiento a los riesgos residuales, se identifican nuevos riesgos y se evalúa la efectividad del proceso contra riesgos a través del proyecto.

Gráfico 3-47. Dar Seguimiento y Controlar los Riesgos: Entradas y Salidas

3.6.10 Administrar las AdquisicionesAdministrar las Adquisiciones es el proceso que consiste en gestionar las relaciones de adquisiciones, supervisar el desempeño del contrato y efectuar cambios y correcciones según sea necesario.

Gráfico 3-48. Administrar las Adquisiciones: Entradas y Salidas

3.7 Grupo del Proceso de Cierre

El Grupo del Proceso del Cierre está compuesto por aquellos procesos realizados para finalizar todas las actividades a través de todos los grupos de procesos de la dirección de proyectos, a fin de completar formalmente el proyecto, una fase del mismo u otras obligaciones contractuales.Este grupo de procesos, una vez completado, verifica que los procesos definidos se hayan completado dentro de todos los grupos de procesos a fin de cerrar el proyecto o una fase del

mismo, según corresponda, y establece formalmente que el proyecto o fase del mismo ha finalizado. En el cierre del proyecto o fase, 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.

Figura 3-49. Grupo del Proceso de cierre

El Grupo del Proceso de Cierre (Gráfico 3-49) incluye los siguientes procesos de dirección de proyectos (Gráficos 3-50 y 3-51):

3.7.1 Cerrar el Proyecto o FaseCerrar el Proyecto o Fase es el proceso que consisten en finalizar todas las actividades a través de todos los grupos de procesos de dirección de proyectos para completar formalmente el proyecto o una fase del mismo.

Gráfico 3-50. Cerrar el Proyecto o Fase: Entradas y Salidas

3.7.2 Cerrar las AdquisicionesCerrar las Adquisiciones es el proceso de finalización de cada adquisición del proyecto.

Gráfico 3-51. Cerrar las Adquisiciones: Entradas y Salidas