Estándares para gestión de proyectos

En la actualidad la gerencia de proyectos constituye uno de los pilares fundamentales en las cuales se soporta la operación de las organizaciones. La correcta organización de actividades, recursos, objetivos y demás que constituyen un proyecto requieren contar con una metodología de apoyo que permita a los profesionales dedicados a la gerencia del proyecto seguir una hoja de ruta clara y concisa para implementar el proyecto con resultados positivos.

Debido a la necesidad de contar con unos lineamientos claros de gestión de proyectos nacen los estándares, un estándar es un documento que es generado de forma consensuada y aprobado por un grupo reconocido, que provee un grupo de lineamientos, características de las actividades y reglas que se aplican de forma repetida y común. En este caso el estándar de gestión de proyectos permite conocer las diferentes actividades, con sus características, que deben ser llevadas a cabo para gestionar un proyecto de forma exitosa, sin importar la naturaleza del proyecto en si.

      1. PMI

El Project Management Institute es una institución fundada en 1969, con sede en Estados Unidos. Fue creado por directores de proyecto y su objetivo es definir estándares de gestión de proyectos que sirvan para apoyar la labor de los directores de proyecto en las organizaciones.

El PMI promueve la definición de estándares, fomentar la formación de gerentes de proyecto certificados y la investigación en gestión de proyectos

• El PMBOK

El PMBOK constituye el estándar para la dirección de proyectos, se divide en dos grandes partes que abordan en primera parte sobre los procesos de un proyecto y seguidamente sobre las diferentes áreas de conocimiento especificas de la gestión de proyectos.

Según el estándar durante el desarrollo del proyecto se debe usar herramientas y desarrollar un grupo de actividades definidas, para tal fin se especifican un grupo de Procesos que se enmarcan dentro de los Macro-Procesos que constituyen el ciclo de vida del proyecto, dichos Macro-Procesos son:

MACRO PROCESO	NÚMERO DE PROCESOS
Inicio	2
Planificación	24
Ejecución	8
Seguimiento y control	11
Cierre	2

•  Certificación en PMI

El PMI ofrece la posibilidad a los profesionales en proyectos de obtener una certificación que les permita asegurar su conocimiento y experiencia en gestión de proyectos, la certificación apoya el desarrollo profesional de los directores de proyecto, a continuación se presentan las diferentes certificaciones ofrecidas por el PMI:

§  Certified Associate in Project Management (CAPM)®

§  Project Management Professional (PMP)®

§  Program Management Professional (PgMP)®

§  Portfolio Management Professional (PfMP)SM

§  PMI Agile Certified Practitioner (PMI-ACP)®

§  PMI Risk Management Professional (PMI-RMP)®

§  PMI Scheduling Professional (PMI-SP)®

§  OPM3® Professional Certification

En los siguientes vídeos se presentan experiencias a tener en cuenta para la certificación en PMI y algunas generalidades sobre el estándar.

    2. PRINCE2

Constituye una metodología de gestión de proyectos, aplicable a cualquier tipo de proyecto. Se encuentra enfocado en los “productos” y divide el proyecto en fases que deben ser controladas de forma eficiente para asegurar el avance del proyecto.

• Elementos

PRINCE cuenta con tres elementos principales:

a)      7 procesos

§  Dirigir el proyecto

§  Comenzar el proyecto

§  Iniciar el proyecto

§  Manejar los límites de las etapas

§  Controlar las etapas

§  Manejar la entrega del producto

§  Cerrar el proyecto

§  Planear

b)      7 principios

§  Justificación comercial continua

§  Aprender de la experiencia

§  Roles y responsabilidades definidos

§  Gestión por fases

§  Gestión por excepción

§  Orientación a productos

§  Adaptación

c)       7 temáticas

§  Caso de negocio

§  Organización

§  Planes

§  Progreso

§  Riesgo

§  Calidad

§  Cambio

• Certificaciones

El marco de certificaciones para PRINCE se divide en dos niveles:

§  Foundation

Constituye el nivel de entrada, busca verificar que el profesional cuenta con la suficiente experiencia y conocimiento para integrar equipos de proyecto que apliquen PRINCE.

§  Practitioner

Permite verificar que el profesional puede aplicar y ajustar la metodología PRINCE a un proyecto de acuerdo a su contexto y características.

A continuación se presenta un video que introduce la metodología de PRINCE.

Como se puede ver, la gestión de proyectos ha llegado a un nivel de profesionalización que es común encontrar múltiples metodologías o estándares disponibles para guiar la dirección del proyecto. El uso de estándares facilita un marco estructurado, claro y conciso para guiar el desarrollo de un proyecto reduciendo la incertidumbre.

Adicionalmente las certificaciones constituyen un medio para que los profesionales puedan incrementar su conocimiento y experiencia en determinado estándar, y una manera para que las organizaciones puedan conseguir colaboradores con conocimientos fuertes en la metodología adoptada al interior de la organización.


REFERENCIAS

http://www.pmi-valencia.org/index.php/que-es-el-pmimenu

http://calidad.pucp.edu.pe/el-asesor/que-es-el-pmbok#sthash.52RIaXjn.dpbs

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

http://www.hilogic.com.my/prince2_learnmore-themes.php

http://es.wikipedia.org/wiki/PRINCE2

http://www.qrpinternational.es/index/prince-2/what-is-prince2

http://www.prince2.com/rest-world/training

http://www.prince-officialsite.com/Accreditation/AccreditationScheme.aspx

Escenarios

La técnica de escenarios permite describir una interacción puntual con el sistema, específicamente la ocurrencia de dicha interacción para un actor determinado, en un momento determinado y con unos datos específicos.

Los escenarios son instancias puntuales de un caso de uso, un caso de uso puede contener múltiples escenarios.

Generalmente los escenarios se describen en un lenguaje no formal, narrativo, lo anterior permite que el actor describa con mayor facilidad las interacciones que va teniendo con el sistema al avanzar a través del escenario descrito. De tal manera que permiten describir la forma como un actor especifico utiliza una determinada funcionalidad de un sistema para llevar a cabo una tarea.

Los escenarios se pueden categorizar en: 

•        Primarios 

Describen el flujo normal y esperado de eventos que el sigue actor para llevar a cabo su tarea, u objetivo, utilizando el sistema. 

•        Secundarios 

Corresponden a posibles variaciones del flujo definido por el escenario primario:

o   Alternativos

En este caso se lleva a cabo la tarea original, pero el flujo de pasos se ejecuta en una secuencia diferente a la definida en el escenario primario.

o   Excepcionales

Corresponde a los casos que difieren de las condiciones establecidas en el escenario primario.

Un caso de uso debe contar con un escenario primario, y puede tener o no, uno o varios escenarios secundarios, dependiendo de sus características puntuales.

Los tipos de escenarios son: 

•        Como es (As is) 

Se utiliza para describir el estado y funcionamiento actual del sistema, permite recopilar las interacciones de los usuarios actuales cuando hacen uso de funcionalidades del sistema disponible. 

•        Visionario 

Permite describir un sistema futuro, que no ha sido desarrollado. Los actores especifican como desean interactuar con el sistema. 

•        De evaluación 

Permite evaluar el estado y desempeño actual del sistema, frente a las tareas específicas que determinados actores requieren ejecutar. 

•       De entrenamiento 

Se utiliza para especificar el flujo de pasos que un usuario nuevo o novato debe seguir con el objetivo de realizar una determinada tarea haciendo uso del sistema.

Existen diversos métodos para registrar y documentar los escenarios generados para un determinado sistema: 

•        Texto, ya sea informal o utilizando formatos estandarizados.
•        Diagramas
•        Videos
•       Animaciones
•        Diagrama en UML 

El uso de escenarios presenta multiples beneficios para el levantamiento de requerimientos, dado que prioriza una comunicación directa con el actor involucrado. A partir de lo anterior es más sencillo que los requerimientos obtenidos correspondan a las necesidades, expectativas y situaciones reales de cada actor, adicionalmente permite comparar la visión que se tiene del sistema desde los puntos de vista de diferentes involucrados.

El uso de escenarios promueve la expresión de la experticia del actor involucrado, dado que le permite demostrar, con un lenguaje que le resulta familiar, sus conocimientos y necesidades.

A continuación se encuentra un video que introduce el tema de escenarios y su relación con los casos de uso:

Referencias:

[1] http://www.iai.uni-bonn.de/III/lehre/vorlesungen/SWT/RE05/slides/05_Requirements%20Elicitation%201-2.pdf

[2] http://www.pm.inf.ethz.ch/education/courses/kse/archive/2011/lectures/02_-_requirements_elicitation_6up.pdf

[3] http://www.site.uottawa.ca/~bochmann/SEG3101/Notes/SEG3101-ch2-3%20-%20ElicitationTechniques.pdf

Encuesta de Estándares en Gestión de Proyectos

Estándares en Gestión de Proyectos

Reuniones JAD - Prototipo

Reuniones JAD

JAD es una técnica de definición de requisitos y de diseño de la interfaz de usuario, basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha reunión los temas a tratar se centran más en el negocio que en el asunto técnico. Está orientado a proyectos de cliente (o bien sistemas a medida, como también se les conoce), y permite recolectar requisitos eficientemente. Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una falsa realidad en cuanto al progreso del proyecto o la productividad. 

Además, hay que prestar especial cuidado con las estimaciones tempranas, aquellas que entrañan un mayor riesgo por el mayor desconocimiento del sistema y que deben ofrecer una amplitud de rango mayor entre mejor estimación y estimación pesimista. Esta técnica sale beneficiada si se utiliza en modelos incrementales, ya que permite pulir poco a poco el sistema en función de las necesidades del cliente. Para su buen funcionamiento es fundamental que cada grupo o rol que participa en las reuniones se implique al máximo. Bien utilizada, esta técnica permite ver conflictos entre requisitos y eliminar aquellos menos útiles (costosos, poco beneficio o rendimiento logrado, etc.).

Para estas reuniones hay unos perfiles:

1. Moderador: Es un especialista en metodología de trabajo
2. Promotor: Es un impulsor del desarrollo  es  el impulsor del proyecto
3. Jefe de Proyecto: El Encargado de administrar y ejecutar el poryecto
4. Especialista en Modelización: Es el responsable de los modelos
5. Desarrolladores: Aseguran que los modelos están correctamente diseñados.
6. Usuarios: Responsables de definir los requisitos del sistema y validarlo

Actividades:

Inicio: se define la estructura del proyecto

Desarrollo: Se definen las salidas del proyecto

Finalización: Se valida la información se genera el proyecto

Productos: 

Se generan dos tipos de productos  la preparación del proyecto y el resultado que es el diseño del proyecto.

PROTOTIPOS

Los prototipos son una herramienta valiosa para clarificar requerimientos confusos. Pueden actuar de manera similar a los escenarios, proveyendo el contexto de los usuarios en el cual se puede entender mejor la información.

En la ingeniería de software, un prototipo es programa de computador que implementa algunos de los requerimientos de un sistema. Este prototipo puede ser usado para colaborar con la definición de los requerimientos, o para facilitar la evaluación de alternativas de implementación de un sistema

Existen dos grandes tipos de prototipos. Los prototipos no funcionales o desechables (Throw away), que sirven para entender la dificultad y aclarar los requerimientos; y los prototipos funcionales o evolutivos (Evolutionary) que permiten construir una aproximación del sistema de manera que se pueda proveer cierta funcionalidad del sistema final y usualmente se convierten en parte del mismo.

En general, los prototipos se consideran herramientas muy valiosas para clarificar los requerimientos que son confusos durante el desarrollo de un sistema. Los prototipos actúan de manera similar a los escenarios, debido a que proveen un contexto en el cual los usuarios pueden entender mejor la información que ellos deben proveer a los desarrolladores para que se pueda construir el sistema.

 

Encuesta de Sistemas de Información

Encuesta levantamiento de requerimientos

Casos de uso

Es una técnica de levantamiento de requerimientos donde se busca describir las diferentes interacciones que tienen los múltiples actores con un sistema determinado, el caso de usuario muestra las acciones que un actor efectúa frente al sistema con el objetivo de cumplir una determinada tarea.

El caso de uso permite recopilar los requerimientos del sistema partiendo de las acciones que el usuario debe ejecutar con el sistema con el fin de alcanzar un determinado objetivo, el enfoque se centra en una descripción funcional del comportamiento del sistema.

Por lo general los casos de uso deben ser independientes de las tecnologías específicas de implementación.

Los casos de uso son descripciones textuales que describen las interacciones de los actores y el sistema de una forma concisa, precisa y clara. El lenguaje utilizado debe ser común para los diferentes involucrados en el proceso de levantamiento de requerimientos. El uso de diagramas en UML es también común en la descripción de casos de uso.

Figura 1. Diagrama UML de un caso de uso

Fuente: http://blog.feabhas.com/tag/use-case/

Componentes del caso de uso:

• Actores 

Los actores corresponden a los roles externos: Usuarios, dispositivos externos, otros sistemas; que interactúan con el sistema con el fin de alcanzar un determinado objetivo. El caso de uso no se limita a un único actor, se deben incluir todos los actores que interactúan con el sistema.

Los actores se pueden categorizar en:

• Actores primarios 

Un actor que tiene un objetivo con el sistema, es decir que se beneficia del sistema para completar una tarea.

• Actores secundarios 

Son los actores con los cuales el sistema tiene un objetivo, permiten generar valor para otros actores del sistema.

• Límites del sistema 

Define claramente la separación del sistema y el entorno que lo rodea, es de vital importancia especificar con claridad los límites dado que su modificación puede tener fuertes implicaciones sobre la solución a desarrollar.

• Precondiciones 

Describen el estado del sistema antes de iniciar el caso de uso, se requiere que todas las condiciones sean cumplidas para que el caso de uso pueda iniciar su desarrollo.

• Postcondiciones 

Describen el estado del sistema después de terminar el caso de uso; independientemente del flujo seguido dentro del caso de uso, alguna de las postcondiciones debe ser cumplida al terminar el caso de uso.

• Alternativas 

Cuando se presenta un evento que interrumpe el flujo normal seguido por el caso de uso se crea una alternativa, las alternativas corresponden a errores o excepciones de los eventos del flujo normal. Las alternativas generan nuevas interacciones dentro del caso de uso, pero las alternativas no tienen sentido fuera del caso de uso principal dentro del cual se generan.

Los casos de uso presentan una representación familiar que permite a los interesados involucrarse de forma activa en la especificación de los requerimientos, al enfatizar la descripción de la interacción del sistema con los diferentes actores se logra identificar con mayor claridad las expectativas de los actores. La utilización de casos de uso permiten identificar los diferentes flujos normales y alternativos para el sistema bajo definición, lo anterior le facilita a los desarrollos priorizar las interacciones criticas del sistema y las respuestas que los actores esperan por parte del mismo en dichas situaciones.

El nivel de abstracción propio de los casos de uso le ofrece libertad a los involucrados para definir los requerimientos del sistema sin ser restringidos por limitaciones o soluciones tecnológicas específicas.

El siguiente video hace una sencilla introducción a los casos de uso: 

Referencias:

[1]http://www.site.uottawa.ca/~bochmann/SEG3101/Notes/SEG3101-ch2-3%20-%20ElicitationTechniques.pdf

[2]http://rfidlab.iecs.fcu.edu.tw/~cyt/cyt/data/slide/Requirements_Elicitation_with_Use_Cases_2005_05_22.pdf

[3]www.csee.umbc.edu/~mgrass2/.../useCases_F08.ppt‎

[4]http://www.cs.fsu.edu/~baker/swe1/restricted/templates/rr631gv1_stuwrk_uc_modeling_guidelines.pdf

[5]http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf