Saltar al contenido

Métrica V3

Fuente: http://es.wikipedia.org/wiki/M%C3%89TRICA

Fuente: http://administracionelectronica.gob.es/?_nfpb=true&_pageLabel=P60085901274201580632&langPae=se

MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistemas de información. Promovida por el Ministerio de Administraciones Públicas del Gobierno de España para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology – Software Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination).

Elementos fundamentales

  • Procesos
  • Interfaces
  • Técnicas y Prácticas
  • Roles o Perfiles

Procesos principales de MÉTRICA

Al igual que ISO/IEC 12207, MÉTRICA está orientada al proceso y, en su versión 3, estos procesos son:

  • Planificación de Sistemas de Información (PSI).
  • Desarrollo de Sistemas de Información (DSI). Debido a su complejidad, está a su vez dividido en cinco procesos:
    • Estudio de Viabilidad del Sistema (EVS).
    • Análisis del Sistema de Información (ASI).
    • Diseño del Sistema de Información (DSI).
    • Construcción del Sistema de Información (CSI).
    • Implantación y Aceptación del Sistema (IAS).
  • Mantenimiento de Sistemas de Información (MSI).

Interfaces de MÉTRICA

MÉTRICA, en su versión 3, proporciona también cuatro interfaces que definen actividades orientadas a la mejora y perfeccionamiento de los procesos principales para garantizar la consecución del objetivo del desarrollo.

  • Gestión de proyectos (GP).
  • Seguridad (SEG).
  • Aseguramiento de la Calidad (CAL).
  • Gestión de la Configuración (GC).

Técnicas de MÉTRICA

MÉTRICA, en su versión 3, distingue entre:

Perfiles de MÉTRICA

MÉTRICA establece los siguientes perfiles para los participantes en el proceso de desarrollo de un sistema de información:

  • Directivo (Comité de Dirección, Directores de Usuarios,…).
  • Jefe de Proyecto (Responsable de Implantación, Responsable de Seguridad,…).
  • Consultor (Consultor Informático, Técnico de Sistemas).
  • Analista (Analista, Administrador de Bases de Datos,…).
  • Programador.

ITIL

  • admin 

Fundamentos de la Gestión de TI

fuente: http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

fuente: http://itil.osiatis.es/Curso_ITIL/

fuente: http://www.itil-officialsite.com/

Las tecnologías de la información son tan antiguas como la historia misma y han jugado un importante papel en la misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestión se han convertido en una herramienta imprescindible y clave para empresas e instituciones.

La información es probablemente la fuente principal de negocio en el primer mundo y ese negocio a su vez genera ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debe considerarse como una herramienta más entre muchas otras.

Hasta hace poco las infraestructuras informáticas se limitaban a dar servicios de soporte y de alguna forma eran equiparables con el otro material de oficina: algo importante e indispensable para el correcto funcionamiento de la organización pero poco más.

Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan generalmente una parte sustancial de los procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuas redes de información: sirva de ejemplo la Banca Electrónica.

Los objetivos de una buena gestión de servicios TI han de ser:

  • Proporcionar una adecuada gestión de la calidad
  • Aumentar la eficiencia
  • Alinear los procesos de negocio y la infraestructura TI
  • Reducir los riesgos asociados a los Servicios TI
  • Generar negocio

ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas mediante:

  • Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos
  • El establecimiento de estrategias para la gestión operativa de la infraestructura TI

¿Qué es ITIL

Information Technology Infraestructure Library.

Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la Información (ITIL) se ha convertido en el estándar mundial de de facto en la Gestión de Servicios Informáticos. Iniciado como una guía para el gobierno de UK, la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización.

ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de la Informática para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos de mantenimiento y operaciones.

A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del 70-80% del total del tiempo y del coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados, con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.

ITIL fue producido originalmente a finales de 1980 y constaba de 10 libros centrales cubriendo las dos principales áreas de Soporte del Servicio y Prestación del Servicio. Estos libros centrales fueron más tarde soportados por 30 libros complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del negocio. A partir del año 2000, se acometió una revisión de la biblioteca. En esta revisión, ITIL ha sido reestructurado para hacer más simple el acceder a la información necesaria para administrar sus servicios. Los libros centrales se han agrupado en dos, cubriendo las áreas de Soporte del Servicio y Prestación del Servicio, en aras de eliminar la duplicidad y mejorar la navegación. El material ha sido también actualizado y revisado para un enfoque conciso y claro.

Críticas a ITIL

ITIL ha recibido críticas de varios frentes. Entre ellas:

  • El hecho de que muchos defensores de ITIL parecen creer que es un marco holístico y completo para el gobierno de TI.
  • Su tendencia a convertirla en una religión.

Como señala Jan van Bon (autor y editor de muchas publicaciones de Gestión de Servicios de TI):

Hay mucha confusión sobre ITIL, procedente de todo tipo de malentendidos sobre su naturaleza. ITIL, como afirma la OGC, es un conjunto de buenas prácticas. La OGC no afirma que dichas mejores prácticas describan procesos puros, ni tampoco que ITIL sea un marco diseñado como un modelo coherente. Eso es lo que la mayoría de sus usuarios hacen de ella, probablemente porque tienen una gran necesidad de dicho modelo.6

El columnista CIO Magazine Dean Meyer también ha expuesto algunos puntos de vista cautelosos sobre ITIL,7 incluyendo cinco trampas típicas tales como «convertirse en esclavo de definiciones desactualizadas» y «dejar que ITIL se convierta en religión». Como Meyer señala, ITIL «no describe el abanico completo de procesos necesarios para ser líderes. Se centra en […] gestionar servicios actuales.»

La calidad de los volúmenes de la biblioteca se considera desigual. Por ejemplo, van Herwaarden y Grift señalan que «la consistencia que caracterizaba los procesos de soporte al servicio […] se pierde en gran medida en los libros de entrega de servicio.»8

Todas estas manifestaciones acerca de ITIL provienen de compañias que en un momento dado han logrado entender que `para alcanzar objetivos de manera clara es necesario practicar ciertas practicas que cumplan con ese objetivo y los resultados demostrados son beneficos para quien los desarrolla y para quien hace uso de este entorno.

Visión general de la Biblioteca de Infraestructura de TI version 2 (ITIL v2)

La biblioteca de infraestructura de TI (ITIL) toma este nombre por tener su origen en un conjunto de libros, cada uno dedicado a una práctica específica dentro de la gestión de TI. Tras la publicación inicial de estos libros, su número creció rápidamente (dentro la versión 1) hasta unos 30 libros. Para hacer a ITIL más accesible (y menos costosa) a aquellos que deseen explorarla, uno de los objetivos del proyecto de actualización ITIL versión 2 fue agrupar los libros según unos conjuntos lógicos destinados a tratar los procesos de administración que cada uno cubre. De esta forma, diversos aspectos de los sistemas de TIC, de las aplicaciones y del servicio se presentan en conjuntos temáticos. Actualmente existe la nueva versión ITIL v3 que fue publicada en mayo de 2007.

Aunque el tema de Gestión de Servicios (Soporte de Servicio y Provisión de Servicio) es el más ampliamente difundido e implementado, el conjunto de mejores prácticas ITIL provee un conjunto completo de prácticas que abarca no sólo los procesos y requerimientos técnicos y operacionales, sino que se relaciona con la gestión estratégica, la gestión de operaciones y la gestión financiera de una organización moderna.

Los ocho libros de ITIL y sus temas son:

Gestión de Servicios de TI,

1. Mejores prácticas para la Provisión de Servicio
2. Mejores prácticas para el Soporte de Servicio
Otras guías operativas

3. Gestión de la infraestructura de TI
4. Gestión de la seguridad
5. Perspectiva de negocio
6. Gestión de aplicaciones
7. Gestión de activos de software

Para asistir en la implementación de prácticas ITIL, se publicó un libro adicional con guías de implementación (principalmente de la Gestión de Servicios):

8. Planeando implementar la Gestión de Servicios

Adicional a los ocho libros originales, más recientemente se añadió una guía con recomendaciones para departamentos de TIC más pequeños:

9. Implementación de ITIL a pequeña escala

  • Soporte de Servicio

El libro de Soporte de Servicio se ocupa de asegurar que el Usuario tenga acceso a los servicios apropiados que soporten las funciones de negocio. Los temas que se tratan en el libro son:

Centro de Servicio al Usuario
Gestión del Incidente
Gestión del Problema
Gestión de Configuración
Gestión del Cambio
Gestión de la Entrega
  • Provisión de Servicio

El libro de Provisión de Servicio analiza qué servicio requiere el negocio del proveedor (entendiendo como proveedor la organización interna o externa que provee el servicio de TI), para ofrecer un soporte adecuado a los Usuarios y/o Clientes de negocio. El libro cubre los siguientes temas:

Gestión del Nivel de Servicio
Gestión Financiera de Servicios TI
Gestión de la Capacidad
Gestión de la Continuidad del Servicio de TI
Gestión de la Disponibilidad

ITIL v3

En ITIL v3 reestructura el manejo de los temas para consolidar el modelo de «ciclo de vida del servicio» separando y ampliando algunos subprocesos hasta convertirlos en procesos especializados. Esta modificación responde a un enfoque empresarial para grandes corporaciones que utilizan ampliamente ITIL en sus operaciones y aspira a consolidar el modelo para conseguir aún mejores resultados. Es por ello que los especialistas recomiendan que empresas emergentes o medianas no utilicen ITIL v3 si no cuentan con un modelo ITIL consolidado y aspiran a una expansión a muy largo plazo. ITIL v3 consta de 5 libros basados en el ciclo de vida del servicio:

1. Estrategia del Servicio
2. Diseño del Servicio
3. Transición del Servicio
4. Operación del Servicio
5. Mejora Continua del Servicio
  • Estrategia del Servicio

Se enfoca en el estudio de mercado y posibilidades mediante la búsqueda de servicios innovadores que satisfagan al cliente tomando en cuenta la real factibilidad de su puesta en marcha. Asi mismo se analizan posibles mejoras para servicios ya existentes. Se verifican los contratos con base en las nuevas ofertas de proveedores antiguos y posibles nuevos proveedores, lo que incluye la renovación o revocación de los contratos vigentes.

Procesos

  1. Gestión Financiera
  2. Gestión del Portafolio
  3. Gestión de la Demanda

Cambios en la versión 2011

Los conceptos dentro de la publicación se han aclarado, sin necesidad de cambiar el mensaje general. La publicación actualizada incluye una orientación más práctica y con más ejemplos.

  • Financial Management for IT services (Gestión Financiera de TI)

La gestión financiera de TI ha ampliado para incluir algunos de los elementos clave de la ITIL publicaciones anteriores que habían sido excluidos en la edición 2007 de la Estrategia del Servicio – tales como contabilidad, elaboración de presupuestos y de cargos.

  • Business Relationship Management (Gestión de Relaciones del Negocio)

Este es un nuevo proceso que se asemeja al existente en la ISO 20.000. Se hace una diferenciación para los distintos proveedores de servicio: tipo I, II y III . Se brinda una explicación diferente para cada tipo de proveedor.

  • Governance (Gobierno)

Ahora hay más detalles sobre el concepto de Gobierno, incluida una definición más completa de su significado, la diferencia entre el gobierno y gestión, un marco de gobierno, y cómo la gestión del servicio se relaciona con el gobierno.

  • Cloud Computing (Computación en la nube)

Se ha incluído en qué forma la gestión de servicios se ve afectada por la aparición de la computación en la nube. Se agregó un nuevo apéndice que cubre específicamente la estrategia de servicio y la nube: características, tipos, tipos de servicio, y los componentes de la arquitectura de nube.

Federico, Ricardo. «Actualizacion ITIL V3 2011: Estrategia del Servicio» (en español). BITCompany. Consultado el 09/10/2011.

  • Diseño del Servicio

Una vez identificado un posible servicio el siguiente paso consiste en analizar su viabilidad. Para ello se toman factores tales como infraestructura disponible, capacitación del personal y se planifican aspectos como seguridad y prevención ante desastres. Para la puesta en marcha se toman en consideración la reasignación de cargos (contratación, despidos, ascensos, jubilaciones, etc), la infraestructura y software a implementar.

Procesos

  1. Gestión del Catálogo de Servicios
  2. Gestión de Niveles de Servicio
  3. Gestión de la Disponibilidad
  4. Gestión de la Capacidad
  5. Gestión de la Continuidad de los Servicios de TI
  6. Gestión de Proveedores
  7. Gestión de la Seguridad de Información
  8. Coordinación del Diseño (nuevo en la versión 2011)

Cambios en la versión 2011

Las principales modificaciones del libro de ITIL V3 Diseño del Servicio en su versión 2011 incluye: un cambio a los denominados 5 aspectos del diseño y primordialmente la inclusión de un nuevo proceso de Coordinación del Diseño. De esta manera esta fase incluye ahora 8 procesos, en lugar de 7.

Nuevo Proceso ITIL V3 2011: Coordinación del Diseño (Design Coordination Process)

Se adicionó este proceso para hacer más claro el flujo de actividades en el ciclo de vida del diseño. El propósito del proceso de Coordinación del Diseño es garantizar que las metas y los objetivos de la etapa de diseño del servicio entregando y manteniendo un punto único de coordinación y control de todas las actividades y procesos dentro de esta etapa del ciclo de vida de servicio. Las salidas del proceso de coordinación del diseño son potencialmente:

  • Diseño de servicios integrado y consistente a través del SDP (paquete de diseño del servicio)
  • Revisión de la arquitectura empresarial
  • Revisión del sistema de gestión
  • Revisión de las métricas y métodos de medición
  • Revisión de procesos
  • Actualización del Portafolio de Servicios
  • Actualización de los registros de cambios

Federico, Ricardo. «Actualización ITIL V3 2011: Diseño del Servicio» (en español). BITCompany. Consultado el 28/10/2011.

  • Transición del Servicio

Antes de poner en marcha el servicio se deben realizar pruebas. Para ello se analiza la información disponible acerca del nivel real de capacitación de los usuarios, estado de la infraestructura, recursos IT disponibles, entre otros. Luego se prepara un escenario para realizar pruebas; se replican las bases de datos, se preparan planes de rollback (reversión) y se realizan las pruebas. Luego de ello se limpia el escenario hasta el punto de partida y se analizan los resultados, de los cuales dependerá la implementación del servicio. En la evaluación se comparan las expectativas con los resultados reales.

Procesos

  1. Gestión de la Configuración y Activos
  2. Gestión del Cambio
  3. Gestión del Conocimiento
  4. Planificación y Apoyo a la Transición
  5. Gestión de Release y Despliegue
  6. Gestión Validación y Pruebas
  7. Evaluación (Evaluación del cambio)

Cambios en la versión 2011

En la edición ITIL V3 2011 del libro de Transición del Servicio, se realizaron modificaciones y aclaraciones, a efectos de mejorar el entendimiento de los conceptos.
Se aclaró la estructura , el contenido y las relaciones entre el Sistema de Gestión de Configuraciones (CMS) y el Sistema de Gestión del Conocimiento del Servicio (SKMS) para hacer más entendibles los conceptos.

Se incorporó un nuevo contenido relacionado con la forma que que debe ser usado un Requerimiento de Cambio (RFC).

El proceso de Evaluación (que no se ve en fundamentos sino en el Intermediate RCV) fue renombrado como Evaluación del cambio. Se modificó su propósito y alcance, a efectos de clarificar cuando debe ser usado.

El proceso de Gestión de Activos y Configuraciones del Servicio tiene información adicional y se mejoraron los flujos de interacción con otros procesos, incluidos Gestión de Cambio, Gestión de Versiones y Entrega, y Evaluación del Cambio.

Por último se mejoraron las descripciones de los Elementos de Configuración (CI) , Sistema de Gestión de Configuraciones (CMS) y el Sistema de Gestión del Conocimiento del Servicio (SKMS)

Federico, Ricardo. «Actualización ITIL V3 2011: Transición del Servicio» (en español). BITCompany.

  • Operación del Servicio

En este punto se monitoriza activa y pasivamente el funcionamiento del servicio, se registran eventos, incidencias, problemas, peticiones y accesos al servicio.

Procesos

  1. Gestión de Incidentes
  2. Gestión de Problemas
  3. Cumplimiento de Solicitudes
  4. Gestión de Eventos
  5. Gestión de Accesos
  • Mejora Continua del Servicio

Se utilizan herramientas de medición y feedback para documentar la información referente al funcionamiento del servicio, los resultados obtenidos, problemas ocasionados, soluciones implementadas, etc. Para ello se debe verificar el nivel de conocimiento de los usuarios respecto al nuevo servicio, fomentar el registro e investigación referentes al servicio y disponer de la información al resto de los usuarios.

Scrum

  • admin 

Scrum es una metodología de gestión de proyectos de software y es por eso que se percibe más cercana al desarrollo de la solución que la metología sugerida en el PMBOK, que es más genérica.

Roles

Roles en Scrum

– Dueño del Producto mantiene la orientación del equipo hacia los requerimientos del cliente. El Product Backlog está a su cargo.
– Scrum Master es quién mantiene la correcta aplicación de las prácticas Scrum al interior del equipo.
– Equipo Scrum, dentro del cual están los desarrolladores.
– Los Usuarios y Clientes también son roles considerados en la metodología Scrum.

Artefactos

Artefactos en Scrum

Los artefactos principales son:
– Product Backlog: Es una lista con las funcionalidades del sistema con sus correspondientes niveles de prioridad. Nuevas funcionalidades pueden ser adicionadas a esta lista.
– Sprint Backlog: Es un documento detallado que indica la forma en la que se van a cubrir los requerimientos. Las tareas no deben ser demasiado extensas por lo que sí se admite que sean numerosas.

http://www.scrumalliance.org/welcome_to_scrum_alliance

http://www.navegapolis.net/files/Flexibilidad_con_Scrum.pdf

 

PMBOK vs Scrum

  • admin 

Fuente http://blog.pucp.edu.pe/item/42262/pmbok-vs-scrum

Expondré el porqué de Scrum como metodología adecuada para un proyecto de fin de carrera como es una tesis universitaria. Específicamente para uno que incluye un desarrollo en el área de Tecnologías de la Información.

En principio la metodología sugerida por el PMBOK supone:
– Especialización: Miembros de equipo y roles bien delimitados y casi independientes lo que no considera una interacción cercana entre roles.
– Fases: Delimitadas y rígidamente definidas, por lo que las tareas se concluyen en una fase y la acción de los roles se encuentra encasillada en una o más fases.
– Requisitos detallados: Los requerimientos llegan al equipo de desarrollo a través de un artefacto. El cliente no interactúa estrechamente con el producto durante su desarrollo.
– Seguimiento del plan: No se experimenta con opciones atractivas que se puedan presentar durante el transcurso del proyecto sino que se controla rígidamente el plan establecido.

En contraposición Scrum conssidera:

Solapamiento de actividades

Scrum establece ciclos en los que las fases se solapan de forma muy amplia lo que permite actualizar los requerimientos del proyecto, ajustar la planificación e incluso poder reformular el alcance. De esta forma, más que fases que se realizan de forma secuencial, se tienen actividades que se ejecutan en el momento en que se requieren. Educción de requisitos, análisis, codificación, pruebas e integración se
van realizando en cada momento según las necesidades en la evolución del proyecto. Todo esto está guiado por la gestión del alcance que otorga principalmente la exploración medida de actividades. Si se presenta la oportunidad de avanzar algún aspecto del proyecto sin correr riesgos pues este avance se realiza hasta que se vea la dimensión real del aspecto referido y plantear la planificación más adecuada en el contexto correspondiente y tratando de aprovechar los avances completados.

Visión del producto

Queda claro que se busca obtener un producto. La afirmación del concepto del producto tiene mucho más peso que los requisitos específicos del sistema. Se hace necesaria la dirección estratégica ante la ausencia de un plan detallado.

Roles

Para Scrum se considera su compatibilidad con un equipo multidisciplinar. Para el caso de una tesis, el tesista es el único encargado de los roles al interior del proyecto.
Otros roles pertenecen al asesor, asesores que realizarán correcciones al borrador del documento de tesis y el jurado.
– El asesor es cliente del documento de tesis y del producto del proyecto.
– El jurado es cliente del proyecto en su conjunto.
– Los otros asesores que realizarán una corrección al borrador del documento es un cliente no del proyecto sino de su propia apreciación del documento de tesis. Se debe atender sus apreciaciones en la medida que su posición es tan externa como lo es la de los miembros del jurado del proyecto de tesis.
El equipo de desarrollo es auto-organizado y en el caso particular de este proyecto es la unidad auto-organizada representada por el tesista.

Adaptación a los cambios

Pueden ser modificados, dejados de lado o cambiados:
– La elaboración del documento por su correspondencia con el producto a desarrollar.
– La selección de herramientas de desarrollo del producto y de gestión del proyecto.
– El software de terceros.
– El alcance hasta una etapa temprana y fijada del proyecto.

La modificación de un requisito no existe como tal ya que no ha existido la fase de requisitos tradicional sino que se ve enriquecida para concretar la visión del producto.
La incertidumbre es observada constantemente y por eso se permite el descubrimiento paulatino durante el desarrollo y se tiene cuidado con las circunstancias que se van produciendo.
El principal motivo para la elección de Scrum es que el margen de libertad amplio es propicio para que los encargados del proyecto aporten con su ingenio y compromiso.

Por ser un proyecto unipersonal son importantes las disciplinas de
– Autocontrol: Se genera un ambiente de responsabilidad y de gusto por el trabajo que se realiza.
– Autosuperación: Se desarrollan soluciones que son evaluadas, analizadas y mejoradas.

Por ser un proyecto único se considera:
– Muchos proyectos, como una tesis, no son parte de procesos industriales y no es el plan producir muchos sino un único producto, es un proyecto particular.

De acuerdo al Manifiesto Ágil se reconoce valor en los procesos formales que sugiere el PMBOK pero que considera preferibles otros aspectos:

Individuos y su interacción frente a Procesos y herramientas

Software que funciona frente a Documentación exhaustiva

Colaboración con el cliente frente a Negociación contractual

Respuesta al cambio frente a Seguimiento de un plan

Metodos Generalistas de Gestión de Proyectos PMBOK

  • admin 

Fuente: http://es.wikipedia.org/wiki/Project_Management_Body_of_Knowledge

Project Management Body of Knowledge

La Guía del PMBOK® es un estándar en la Administración de proyectos desarrollado por el Project Management Institute (PMI). La misma comprende dos grandes secciones, la primera sobre los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento específico para la gestión de un proyecto.

En 1987, el PMI publicó la primera edición del PMBOK® en un intento por documentar y estandarizar información y prácticas generalmente aceptadas en la gestión de proyectos. La edición actual, la cuarta, provee de referencias básicas a cualquiera que esté interesado en la gestión de proyectos. Posee un léxico común y una estructura consistente para el campo de la gestión de proyectos

La Guía del PMBOK es ampliamente aceptada por ser el estándar en la gestión de proyectos, sin embargo existen algunas críticas: La mayor viene de los seguidores de la Cadena Crítica (en oposición al Método de la ruta crítica). EL PMBOK se encuentra disponible en 11 idiomas: inglés, español, chino simplificado, ruso, coreano, japonés, italiano, alemán, francés, portugués de Brasil y árabe.

PMBOK®

El PMBOK es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. El PMBOK es un estándar reconocido internacionalmente (IEEE Std 1490-2003) que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcciónsoftwareingeniería, etc.

El ‘PMBOK’ reconoce 5 grupos de procesos básicos y 9 áreas de conocimiento comunes a casi todos los proyectos.

Los procesos se traslapan e interactúan a través de un proyecto o fase y son descritos en términos de:

  • Entradas (documentos, planes, diseños, etc.)
  • Herramientas y Técnicas (mecanismos aplicados a las entradas)
  • Salidas (documentos, productos, etc.).

Grupos básicos de Procesos

Los 5 grupos básicos de procesos son:

1. Iniciación:

Define y autoriza el proyecto o una fase del mismo. Está formado por dos procesos.

2. Planificación:

Define, refina los objetivos y planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto. Está formado por veinte procesos.

3. Ejecución:

Compuesto por aquellos procesos realizados para completar el trabajo definido en el plan a fin de cumplir con las especificaciones del mismo. Implica coordinar personas y recursos, así como integrar y realizar actividades del proyecto en conformidad con el plan para la dirección del proyecto. Está formado por ocho procesos.

4. Seguimiento y Control:

Mide, supervisa y regula el progreso y desempeño del proyecto, para identificar áreas en las que el plan requiera cambios. Está formado por diez procesos.

5. Cierre:

Formaliza la aceptación del producto, servicio o resultado, y termina ordenadamente el proyecto o una fase del mismo. Está formado por dos procesos.

Áreas de Conocimiento

Las nueve áreas del conocimiento mencionadas en el PMBOK son:

1. Gestión de la Integración del Proyecto:

Incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los diversos procesos y actividades de la dirección de proyectos dentro de los grupos de procesos de dirección de proyectos.

2. Gestión del Alcance del Proyecto:

Incluye los procesos necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarla con éxito.

3. Gestión del Tiempo del Proyecto:

Incluye los procesos requeridos para administrar la finalización del proyecto a tiempo.

4. Gestión de los Costos del Proyecto:

Incluye los procesos involucrados en estimar, presupuestar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado.

5. Gestión de la Calidad del Proyecto:

Incluye los procesos y actividades de la organización ejecutante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por la cuales fue emprendido.

6. Gestión de los Recursos Humanos del Proyecto:

Incluye los procesos que organizan, gestionan y conducen el equipo del proyecto.

7. Gestión de las Comunicaciones del Proyecto:

Incluye los procesos requeridos para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto sean adecuados, oportunos y entregada a quien corresponda (interesados del proyecto o stakeholders).

8. Gestión de los Riesgos del Proyecto:

Incluye los procesos relacionados con llevar a cabo la planificación de la gestión, identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitoreo y control en un proyecto.

9. Gestión de las Adquisiciones del Proyecto:

Incluye los procesos de compra o adquisición de los productos, servicios o resultados que es necesario obtener fuera del equipo del proyecto.

Relación entre Áreas de Conocimiento y Procesos

El siguiente cuadro muestra la relación entre los 42 procesos y las 9 áreas de conocimiento de la Dirección de Proyectos

Grupo de Procesos de Iniciación Grupo de Procesos de Planificación Grupo de Procesos de Ejecución Grupo de Procesos de Seguimiento y Control Grupo de Procesos de Cierre
1. Gestión de la Integración del Proyecto 1.1 Desarrollar el Acta de Constitución del Proyecto 1.2 Desarrollar el Plan para la Dirección del Proyecto 1.3 Dirigir y Gestionar la ejecución del Proyecto 1.4 Monitorizar y Controlar el trabajo del Proyecto1.5 Realizar el Control Integrado de Cambios 1.6 Cerrar Proyecto o Fase
2. Gestión del Alcance del Proyecto 2.1 Recopilar requisitos2.2 Definir el Alcance2.3 Crear EDT 2.4 Verificar el Alcance2.5 Controlar el Alcance
3. Gestión del Tiempo del Proyecto 3.1 Definir las actividades3.2 Secuenciar las actividades3.3 Estimar los Recursos de las Actividades3.4 Estimar la Duración de las Actividades3.5 Desarrollar el Cronograma 3.6 Controlar el Cronograma
4. Gestión de los Costos del Proyecto 4.1 Estimar los Costos4.2 Determinar el Presupuesto 4.3 Controlar los Costos
5. Gestión de la Calidad del Proyecto 5.1 Planificar la Calidad 5.2 Realizar el Aseguramiento de Calidad 5.3 Realizar el Control de Calidad
6. Gestión de los Recursos Humanos del Proyecto 6.1 Desarrollar el Plan de Recursos Humanos 6.2 Adquirir el Equipo del Proyecto6.3 Desarrollar el Equipo del Proyecto6.4 Dirigir el Equipo del Proyecto
7. Gestión de las Comunicaciones del Proyecto 7.1 Identificar a los Interesados (Stakeholders) 7.2 Planificar las Comunicaciones 7.3 Distribuir la Información7.4 Gestionar las expectativas de los interesados 7.5 Informar el Desempeño
8. Gestión de los Riesgos del Proyecto 8.1 Planificar la Gestión de Riesgos8.2 Identificar los Riesgos8.3 Realizar el Análisis Cualitativo de Riesgos8.4 Realizar el Análisis Cuantitativo de Riesgos8.5 Planificar la Respuesta a los riesgos 8.6 Monitorizar y Controlar los Riesgos
9. Gestión de las Adquisiciones del Proyecto 9.1 Planificar las Adquisiciones 9.2 Efectuar las Adquisiciones 9.3 Administrar las Adquisiciones 9.4 Cerrar las Adquisiciones

PMBOK ® 5

A mediados del 2012, el PMI lanzó la 5 ª edición del PMBOK®.

Novedades PMBOK ® 5

En primer lugar, los grupos de procesos de Iniciación, Planificación, Ejecución, Monitoreo y Control, y Cierre de los proyectos no han sufrido cambios. Este sigue siendo el contexto para el flujo de los procesos y actividades, y significa un gran alivio que no haya sido modificado.

En segundo lugar, es importante mencionar el hecho de que las áreas de conocimiento se han ampliado para incluir la gestión de stakeholders. Cada día se torna más evidente que una correcta gestión de proyectos no sólo requiere prestar atención al exterior sino también una mirada introspectiva de los grupos involucrados en el proyecto y su comunicación.

En la actualidad, el nuevo PMBOK® 5 cuenta con 47 procesos, un aumento del 12% con respecto a la 4ta. edición de la guía. La idea de que cada área debe tener su propio “plan maestro” está de vuelta. Este concepto se incluyó en la 3ra. edición, pero fue abandonado (por alguna razón) en PMBOK® 4. Ahora ha hecho su retorno y con nuevos procesos, tales como “Plan de Gestión del Alcance” y “Plan de Gestión de Recursos Humanos.”

Finalmente, la Guía del PMBOK® en general es mucho más extensa y completa, y puede que estos cambios incomoden a algún profesional en un principio, pero a la larga se notarán los beneficios. De hecho, esto no es tanto una novedad ya que, si miramos hacia atrás en el tiempo, podemos percibir que el tamaño de los contenidos de las guías del PMBOK® ha ido creciendo.

Fuente de información: PMI: La nueva Guía PMBOK 5 está lista! – Blog BITCompany.biz

####################################################################################

Fuente: http://www.crisoltic.com/2011/08/introduccion-la-direccion-de-proyectos.html

Introducción a la dirección de Proyectos con PMBOK

Introducción

La Dirección de Proyectos es una disciplina que cabalga entre la ciencia y el arte. Tiene un componente metodológico que facilita  conocer qué debe hacerse (en qué orden) para gestionar correctamente un proyecto, un componente de conocimiento de diferentes disciplinas (organización, gestión de recursos, gestión de riesgos, gestión financiera, etc), pero el componente más difícil de adquirir depende de las habilidades personales, experiencia y capacidad de orquestrar todo lo anterior hacia la consecución del fín último que es el conseguir que los objetivos del proyecto se consigan en plazo y forma dentro de los límites económicos establecidos.En este primer post dedicado a la Gestión de Proyectos haremos una revisión general de la metodología o mejores prácticas de gestión de proyectos, tal y como se define en la Guía del PMBOK.
Un poco de historia
La Guía del PMBOK es un estándar en la gestión de proyectos desarrollado por el Project Management Institute (PMI).La primera versión de PMBOK fue publicada en 1987. Esta versión consta de 37 procesos.
La segunda versión  fue publicada el 2000, basado en los comentarios recibidos de parte de los miembros. PMBOK fue reconocido como estándar por el American Nacional Standards Institute (ANSI) en 1998, y más adelante por el Instituto de los Ingenieros Electrónicos Eléctricos (IEEE).  Esta versión constaba de 39 procesos.
La tercera versión fue publicada en 2004, con mejoras importantes en la estructura del documento, adiciones a los procesos, términos y dominios del programa y de porfolios. Esta versión constaba de 44 procesos.
La cuarta versión fue publicada en 2008. No introdujo cambios mayores, pero sí se organizó de manera más precisa, clara y fácil de entender. Esta versión consta de 42 procesosy es la versión vigente en la actualidad, aunque ya se está trabajando en la siguiente versión.
PMI pretende definir, mantener y difundir un cuerpo de conocimiento con dos objetivos principales:
  • Mejorar el desarrollo de proyectos en diferentes industrias mediante el uso de buenas prácticas.
  • Definir procesos de gestión de proyectos estándares y homogéneos para todo tipo de proyectos

 Pero ¿qué es un proyecto?

Según PMBOK, 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, bien porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto.
Esta es el ciclo de vida más sencillo en la que el proyecto consta de una única fase. Es común encontrar proyectos con varias fases, secuenciales o incluso superpuestas.

Áreas de conocimiento

Si, en vez de en la dimensión temporal, nos fijamos ahora en la dimensión funcional, podemos agrupar los procesos de la dirección de proyectos de acuerdo a las siguientes áreas de conocimiento:
La administración de la Integración del Proyecto, describe los procesos y actividades que sirven  para integrar los diversos elementos de la dirección de proyectos, lo que incluye:
•       Desarrollar el Acta de Constitución del Proyecto
•       Desarrollar el Plan para la Dirección del Proyecto
•       Dirigir y Gestionar la Ejecución del Proyecto
•       Monitorear y Controlar el Trabajo del Proyecto
•       Realizar Control Integrado de Cambios
•       Cerrar el Proyecto o la Fase
La gestión del Alcance del Proyecto, con los procesos involucrados en garantizar que el proyecto incluya todo (y únicamente) el trabajo requerido para completarlo exitosamente, lo que incluye:
•       Recopilar los Requisitos
•       Definir el Alcance
•       Crear la Estructura de Desglose del Trabajo (EDT)
•       Verificar el Alcance
•       Controlar el Alcance
La gestión del Tiempo del Proyecto, se centra en los procesos que se utilizan para garantizar la conclusión a tiempo del proyecto. Incluye:
•       Definir las Actividades
•       Secuenciar las Actividades
•       Estimar los Recursos para las Actividades
•       Estimar la Duración de las Actividades
•       Desarrollar el Cronograma
•       Controlar el Cronograma
La gestión de los Costos del Proyecto, describe los procesos involucrados en planificar, estimar, presupuestar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado. Para ello, es necesaria la realización de las siguientes actividades:
•       Estimar los Costos
•       Determinar el Presupuesto
•       Controlar los Costos
La gestión de la Calidad del Proyecto, describe los procesos involucrados en planificar, dar seguimiento, controlar y garantizar que se cumpla con los requisitos de calidad del proyecto, lo que incluye:
•       Planificar la Calidad
•       Realizar el Aseguramiento de Calidad
•       Realizar el Control de Calidad.
La gestión de los Recursos Humanos del Proyecto, los procesos involucrados en la planificación, adquisición, desarrollo y gestión del equipo del proyecto. Para ello es necesario:
•       Desarrollar el Plan de Recursos Humanos
•       Adquirir el Equipo del Proyecto
•       Desarrollar el Equipo del Proyecto
•       Gestionar el Equipo del Proyecto.
La gestión de la Comunicación, identifica los procesos involucrados en garantizar que la generación, recopilación, distribución, almacenamiento y disposición final de la información del proyecto sean adecuados y oportunos. Esto incluye la necesidad de:
•       Identificar a los Interesados
•       Planificar las Comunicaciones
•       Distribuir la Información
•       Gestionar las Expectativas de los Interesados
•       Informar el Desempeño
La gestión del Riesgo del Proyecto, describe los procesos involucrados en la identificación, análisis y control de los riesgos para el proyecto, a saber:
•       Planificar la Gestión de Riesgos
•       Identificar los Riesgos
•       Realizar Análisis Cualitativo de Riesgos
•       Realizar Análisis Cuantitativo de Riesgos
•       Planificar la Respuesta a los Riesgos
•       Dar seguimiento y Controlar los Riesgos.
La gestión de Adquisiciones, describe los procesos involucrados en la compra o adquisición de productos, servicios o resultados para el proyecto. Esto incluye:
•       Planificar las Adquisiciones
•       Efectuar las Adquisiciones
•       Administrar las Adquisiciones
•       Cerrar las Adquisiciones
Esta división es probablemente más intuitiva y conocida que la dimensión temporal. Hay que tener en cuenta que los procesos no se ejecutan de manera secuencial. Incluso es posible que algunos procesos no se ejecuten en algún proyecto dado que PMBOK es un conjunto estructurado de buenas prácticas que deben adaptarse en cada organización y a cada proyecto en función de la naturaleza de este, de la cultura de la organización y otras variables.
En la siguiente figura se muestran las dos dimensiones de un proyecto.

Despliegue de procesos en un proyecto

Una vez entendido el carácter dual de un proyecto en la dimensiones temporal y funcional, es necesario atender a cómo encajan los procesos definidos por el PMI en un proyecto tipo.
Ya hemos indicado que los procesos no siguen una progresión secuencial pero sí es cierto que las actividades de cada proceso se intensifican en unas etapas temporales concretas.
Así, por ejemplo, el proceso de Estimación de costos del proyecto se realiza por lo general en la etapa de Planificación del proyecto.
También es cierto que unos procesos se realizan antes que otros; No es posible realizar el proceso anterior sin haber realizado el proceso Estimación de recursos.
Sin embargo, el proceso de planificación es iterativo ya que la planificación de cada aspecto del proyecto (inversiones, recursos humanos, plazos, etc) se establecen por medio de refinaciones sucesivas hasta el cierre de la baseline o planificación base del proyecto.
Incluso en la propia ejecución del proyecto se establecen mecanismos de control que pueden impactar en
la planificación inicial, teniendo que recalcular los plazos, costes u otros parámetros  del proyecto.
De una manera gráfica, representamos en la siguiente figura la correspondencia de cada uno de los procesos definidos en PMBOK con su marco temporal y con su área de conocimiento:
Todo proyecto debe crear un resultado único, lo que lo distingue de tareas repetitivas realizadas en trabajos permanentes. Por ejemplo, una tarea de oficina realizada todos los días no es un proyecto, aunque requiera alguna planificación.
Un proyecto suele ser algo más complejo. Dirigir un proyecto por lo general implica:
  • Identificar requisitos,
  • Abordar las diversas necesidades, inquietudes y expectativas de los interesados (stakeholders en Inglés) según se planifica y ejecuta el proyecto,
  • Equilibrar las restricciones contrapuestas del proyecto (ej. tiempo, presupuesto, recursos, etc)
Para dirigir un proyecto, PMBOK ha identificado 42 procesos que permiten transformar la ejecución de un proyecto en una serie de procesos concatenados que se ejecutan de manera secuencial y o recursiva.
Para cada proceso se consideran:
  • Entradas
  • Herramientas y técnicas
  • Salidas
Asimismo, la dirección de proyectos implica un equilibrio entre diferentes variables. Tradicionalmente, se ha hablado de una triple dependencia del proyecto respecto al coste,alcance y tiempo en el sentido de que  es posible realizar un cambio en uno de estos aspectos sin alterar los otros dos.
Realmente, la dependencia es más amplia en el sentido de que los factores que se afectan mutuamente en el desarrollo de un proyecto son, además de los mencionados, la calidad, losriesgos del proyecto y  la satisfacción del cliente.
Asimismo, PMBOK  distingue dos dimensiones o formas de clasificar los distintos procesos y actividades del proyecto:

  • La dimensión temporal en la que se considera el ciclo de vida de un proyecto y
  • la dimensión funcional, que hace referencia a las diferentes áreas de conocimiento que se ponen en juego para alcanzar los objetivos del proyecto.
Vamos a ver cada una de estas dos dimensiones a continuación:

Ciclo de vida y fases del proyecto 

Empezando con la dimensión temporal, cada proyecto sigue una evolución desde su inicio hasta que finaliza. 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, la naturaleza propia del proyecto y su área de aplicación.
En general, cualquier proyecto, por simple que sea, se estructura de acuerdo a la siguiente estructura del ciclo de vida:
·         Inicio
·         Ejecución de los trabajos del proyecto
·         Cierre del proyecto
Vemos en la figura que en cada fase se obtienen unos resultados concretos (acta de constitución del proyecto, Plan del proyecto, entregables, etc) y que los niveles de costo  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.
Desde el punto de vista de los procesos y del ciclo de vida, PMBOK establece cinco grupos de procesos que se corresponden con las distintas etapas del proyecto indicadas en la figura anterior, más un sexto grupo de procesos de control:

  • Procesos de Iniciación.- Autorización del proyecto o de una fase.
  • Proceso de Planificación.- Definición y redefinición de objetivos, selección de la mejor alternativa entre posibles cursos de acción
  • Proceso de Ejecución.- Coordinación de las personas y de otros recursos necesarios
  • proceso de Control.- Aseguramiento de que se cumplan los objetivos del proyecto, mediante la supervisión y la medición regular de avances.
  • Proceso de Cierre.- Formalización de la aceptación del proyecto o de una fase.
Conclusiones 

Ya hemos indicado que la dirección de proyectos no es algo que se aprenda estudiando un libro. Sin embargo, sí que es necesario tener en cuenta todos los aspectos que influyen en la consecución de los objetivos del proyecto y, para esto, es necesario conocer las partes de metodologia y de conocimiento de disciplinas que indicabamos en la introducción.

En este sentido, PMBOK conforma un cuerpo de conocimiento amplio basado en buenas prácticas aceptadas a nivel internacional. Recomiendo la lectura del estandar, pero para una introducción menos dolorosa, es mejor empezar por alguno de los excelentes libros dedicados a la materia. En particular, eligiría el de Rita Mulcahy, PMP Exam Prep, que aúnque está escrito en perfecto inglés, merece la pena por la experiencia que esta gran comunicadora plasmaba en todos sus libros y artículos.

El aprendizaje del resto requiere «saltar al ruedo», esto es, adquirir experiencia participando en proyectos, equivocarnos en alguna decisión, que es la mejor manera de aprender (siempre y cuando se reconozcan los errores) y tener en cuenta algunos consejos acerca de errores comunes en la dirección de proyectos.