Uso del PMBOK del PMI en Proyectos de Software

(1)

Uso del PMBOK del PMI en Proyectos de Software

Finalidad: Proponer el uso generalizado y mostrar las ventajas de la “Guía del Cuerpo de Conocimiento para la

Gestión de Proyectos” del “Instituto de Gestión de Proyectos” (Guide to “Project Management Body of

Knowledge” – PMBOK; “Project Management Institute” - PMI) en la Gestión de Proyectos de Software.

Contenidos

• Desarrollo de Software: Planos conceptuales

• Considerando la complejidad del proyecto de software

• “Proceso de Software” y “Proyecto de Software”

• Modelos de “Proceso de Software”

• “Proceso de Software” y “Modelo de Ciclo de Vida”

• Dos referencias: “Proceso de Software” según el RUP (IBM) y según el CMMI del SEI

• Desde los “Fujos de Trabajo” a la Programación (cronograma del proyecto).

• Desde la Programación al Presupuesto

• El PMBOK del PMI

– La Matriz “Grupo de Procesos” / “Áreas de Conocimiento”

– La “instanciación” de la Matriz “Grupo de Procesos” / “Áreas de Conocimiento”

– Definición de las Tareas de un Proyecto a partir del PMBOK del PMI

• Síntesis

(2)

13/05/2012 Doctor Roberto Uzal 3

Desarrollo de Software: cuatro capas

Las Herramientas

Lenguajes gráficos / visuales (Lenguaje de Modelado Unificado) Ambientes / Lenguajes de Programación

Bibliotecas de componentes Herramientas CASE Gerenciamiento:

Administración de la CalidadTotal ISO 9001 (ISO 9000.3) CMMI del SEI - CMU PMBOK – PMI MSF (Microsoft) ALM (Borland) UP (IBM) Gestión de Proyectos Gestión de Cambios Gestión de Configuraciones Gestión del Riesgo

Proceso

La Administracióndel Ciclo de Vida Modelos de Ciclo de Vida

El Método

Métodos Formales vs. Métodos Semiformales Distintas corrientes metodológicas de los Métodos Semiformales

Distintas Metodologías (Semiformales) H

M P G

Nivel de Complejidad

Puede hacerla una sola persona o un pequeño grupo que trabaje informalmente Requiere:

Modelado mínimo Proceso simple Herramientas simples

Construida eficientemente y en un tiempo razonable por un equipo

Requiere:

Modelado Proceso bien definido Herramientas más sofisticadas

(3)

Proceso y Proyecto

• Un Proyecto es una instancia en el tiempo y en recursos de un Proceso

•El Proceso dice “que” y “como”

•El Proyecto dice “quien” y “cuando”

ID T ask Name

1 2

3 Modelado de Negocio

4 Moelar Casos de Uso de Negocio

5 Modelar Objetos de Negocio

6 Modelado de Negocio Completado

7 Captura Requisitos

8 Derivar Casos de Uso de Sistema

9 Requisitos Completos

10 Analisis y Diseño

11 Analizar Casos de Uso Sistema

12 Derivar Entidades

13 Diseñar Clases

14 Definir Componentes

15 Definir Despliegue

16 Arquitectura Definida 17 Implentación y Despliegue

18 Implementar Componentes

19 Desplegar Componentes

20 Versión Sistema 1.0

Mortadelo Mortadelo 10/15

Filemon[50% ] 10/17

Filemon[50% ] Mortadelo,Filemon[50% ]

Bacterio Bacterio

Bacterio 10/28

Zipi,Zape[50% ] Zape[50% ] 11/3 WTFSSMOct 12, '03TWTFSOct 19, '03SMTWTFSOct 26, '03SMTWTFSSNov 2, '03MTWTFSSNov 9, '03 Arquit ec to Sist ema

Analis ta del Negocio ( Domini o)

Mod ela r Casos de uso de Neg ocio

Use Case Model Bu ssin ess Use Cas e Mod el

Bu ssin es Ob ject Mod el (Wo rke rs , Entida des y Pro cesos)

Ana lysis Mo de l (es tru ctura y com p oratm ien to)

Des ign Model Analis ta Sist em a

Mo de lar Obje tos de Neo gcio Deriva r Casos de Uso Sis tem a

An aliza r Ca sos de Uso

Deriva r En tida des Dis eña r Classes (e structu ra y co m po rtam in en to)

Impleme nta r Com p onn etes Defin ir Com p on en tes

Im pleme nta tion Mod el

De plo ym e nt Mod el De fin ir Des pliegu e

Developer

Des ple ga r Com p onn etes Com p on en tes

Programación de un proyecto Proceso

tiempo

El Proceso del Software

• Conjunto estructurado de actividades requeridas para desarrollar un sistema de software.

l Especificación- que debe hacer el software y cuales son sus especificaciones de desarrollo.

l Desarrollo – producción del sistema de software.

l Validación – verificar que el software hace lo que el cliente pide.

l Evolución – cambiar/adaptar el software a las demandas.

• Las actividades varían dependiendo de la

organización y del tipo de sistema a desarrollarse.

• Debe estar explícitamente modelado para posibilitar

un adecuado gerenciamiento.

(4)

Modelos de Proceso “Producto Comercial”

Arquitecto Sistema Analista del Neg ocio (Dominio)

Modelar Cas os de us o de Negoci o

Use Cas e Model Bussiness Use Cas e Model

Bussines Object Model (Wo rkers , Enti dad es y Procesos )

Analys is Model (es tructura y com poratm iento )

Design Mo del Analista Sistema

Model ar Objetos de Ne ogcio

De ri var Cas os de Uso Sis tem a

Anal izar Cas os de Us o

Derivar Enti dades

Dis eñar Classes (es tructura y com portam inento )

Im plem entar Com ponn etes Defini r Com pon entes

Im plem entatio n Model

Deployme nt Model Defini r Des pliegue

De veloper

Des plegar Com ponnetes Com ponentes

Existen numerosos modelos de “procesos de software”

(este es un ejemplo para desarrollos de alta complejidad de sistemas de tiempo real del área defensa)

Requirement Specs

Real Real--timetime execution execution

Behavior Requirements at lower levels

levels of System Specification

Model Structures at higher levels of

System Specification

Verification and Validation Simulation

execution

Test Models/

Federations

Model Continuity

Experimental Frames System

Theory

(5)

Proceso de Software y Modelo de Ciclo de Vida

• Modelo de Ciclo de Vida

– Fases por las que pasa un producto de software a lo largo de su “vida” (estudio de viabilidad, análisis, diseño, construcción, pruebas, implantación, mantenimiento, etc) – Forma en la que relacionan dichas fases

entre sí.

Modelo de Ciclo de Vida Lineal Secuencial

Programación Pruebas Implantación Diseño

Análisis Viabilidad

Ventajas:

- Es muy fácil de comprender

- Es útil para introducir el concepto de “Ciclo de Vida”

Desventajas

- Ineficiencias por “esperas”

- Los usuarios “ven” el producto al final del “Ciclo de Vida”

(6)

Modelo de Ciclo de Vida “en Cascada”

Programación

Pruebas

Implantación Diseño

Análisis Viabilidad

Ventajas:

- Introduce el concepto de interactividad - Introduce el concepto de iteractividad Desventajas

- Casi todos los reciclos propuestos son inviables

Modelo Lineal Incremental

Tiempo

Análisis

Ventajas

- Introduce el concepto de Incrementalidad - Más flexible que el Lineal Secuencial Desventajas

- Su capacidad para absorber el concepto de Prototipo es escasa - Al igual que el Lineal Secuencial evidencia cierta ineficiencia en la utilización de los recursos (aunque en menor medida)

(7)

Modelo RAD

^Ventajas:- Incremento significativo de la productividad

- Compatible con Métodos más sofisticados y potentes que los Métodos Estructurados Desventajas

- Tentación de no alcanzar niveles de robustez y confiabilidad aceptables

La disponibilidad de Tecnología de Bases de Datos induce su utilización

Prototipo de Aplicaciones

Desarroll de Aplicaciones

Implantación y Pruebas Modelado

de Aplicaciones Modelado

de Datos Modelado

del Negocio

Equipo 1

Equipo 2

Equipo 3

Equipo n

del Negocio

Modelo de Ciclo de Vida en Espiral

6.

SW OOA- Dynamic View

7.

SW OOD- Process

View 7.

SW OOD- Vista de los

Procesos

9.

SW OOD- DynamicView

9.

SW OOD- Vista Dinámica 11.

SW OOD- Method Design

11.

SW OOD- Diseño (Métodos)

10.

SW OOD- Language Representation

10.

SW OOD- Language Representation 12.

Class Implementation/Test

12.

Clases Test de Implementación

13.

Category Test 13.

Agregación Test

Trace 16.

Requerimientos (Traza) 4.

HW/SW Split

4.

HW/SW Split 3.

System OOA- Dynamic View

15.

System Test 15.

Prueba del Sistema

8.

SW OOD- Static View

8.

SW OOD- Vista Estática

17.

Maintenance 17.

Mantenimiento 2.

System OOA- Static View

2.

System OOA- Static View

Requerimientos1.

SW OOA-5.

Static View

14.

BIT 14.

Prueba de Integración

(8)

Otro modelo de Ciclo de Vida: RUP

(es más que un Modelo de Ciclo de Vida: contempla “dos dimensiones”)

Flujos de Trabajo de Ingeniería Aspectos de la Capa 3

Organización a lo largo del tiempo

Fases Flujos de trabajo principales

Flujos de trabajo de apoyo Organización

según la naturaleza de

las tareas

Aspectos de la Capa 2

Flujos de Trabajo de Apoyo (Environment incluye

“Risk Management”) Aspectos de la Capa 1

TODAS ITERACCIONES SUBSECUENTES

PLAN DEL PROYECTO PLAN DEL

PROYECTO ¿CERRAR

PROYECTO?

CERRAR FASE EVALUACIÓN DEL ALCANCE Y RIESGOS

DEL PROYECTO GESTION DE LA ITERACIÓN PLAN PARA

LA PRIMERA ITERACIÓN

PROYECTO CANCELADO

PROYECTO CANCELADO ITERACIÓN

EXITOSA

FIN DE ITERACIÓN FIN DEL

PROYECTO

FIN DEL PROYECTO

FIN DE ITERACIÓN

FIN DE FASE

FASE COMPLETA PROYECTO

COMPLETO PLAN DE PROYECTO APROBADO CONCEBIR

NUEVO PROYECTO

EVALUACION DEL PROYECTO DEL ALCANCE

Y DE LOS RIESGOS

No

MONITOTEO Y CONTROL DEL PROYECTO

RUP

ARRANQUE DEL PROYECTO UNICAMENTE

(OPIONAL, DEPENDIENDO DEL GRADO DE CAMBIO) PLAN PRÓXIMA

ITERACIÓN CIERRE NO ACEPTADO

(9)

Considerando el Modelo de Ciclo de Vida y la Iteraciones necesarias se llega a algo así:

(sólo estamos considerando el RUP como ejemplo)

Asignación de Recursos

Recurso Rol Actividad

Pablo Diseñador Diseño de Objetos

María Autor de Casos de Uso Detallar un Caso de Uso José Diseñador de Casos de Uso Diseñar un Caso de Uso Silvia Revisor de Diseño Revisar el Diseño

Eduardo Arquitecto Análisis de Arquitectura

Diseño de Arquitectura

(10)

El CMMI

Maturity Level 5 OID, CAR Maturity Level 4

OPP, QPM

Maturity Level 3 REQD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR

Overview Introduction Structure of the Model Model Terminology

Maturity Levels, Common Features, and Generic Practices Understanding the Model

Using the Model Maturity Level 2

REQM, PP, PMC, SAM, MA, PPQA, CM

Appendixes

Engineering REQM, REQD, TS, PI, VER, VAL

Project Management PP, PMC, SAM IPM, RSKM, QPM

Process Management OPF, OPD, OT, OPP, OID

Process Management PAs - Goals - Practices

Support CM, PPQA, MA, CAR, DAR

Appendixes

CMMI-SE/SW Staged

Overview Introduction Structure of the Model Model Terminology

Capability Levels and Generic Model Components Understanding the Model

Using the Model

CMMI-SE/SW Continuous

Proyectos según el CMMI

CMMI

Gestión del Proceso

Gestión de

Proyectos Ingeniería Soporte

- Enfoque Proceso Organizacional - Definición Proceso Organizacional - Formación Organizacional - Rendimiento - Innovación y Distribución Organizacional

- Planificación del Proyecto - Monitorización y Control de Proyectos - Gestión del Acuerdo con el Suministrador - Gestión Integrada de Proyectos - Gestión de Riesgos - Gestión Cuantitativa de Proyectos

- Gestión de Requisitos - Desarrollo de Requisitos - Solución Técnica - Integración del Producto - Verificación - Validación

- Gestión de Configuración - Aseguramiento de la Calidad del Proceso y Producto - Medición y Análisis

- Análisis de Decisiones y Resolución - Análisis Causal y Resolución

IPPD Adquisición

- Entorno Organizacional para la Integración - Equipo Integrado

- Selección y Monitorización del Suministrador - Gestión Integrada del Suministrador - Gestión Cuantitativa del Suministrador

(11)

CMMI: Gestión de Proyectos

Estudio de Viabilidad

Inicial Estimación

preliminar

Planeamiento del proyecto

Cierre del

proyecto Planear y organizar el

trabajo

Monitorear y controlar el trabajo

Administrar los recursos del proyecto

Comunicar el estado del proyecto

Ejecución del proyecto

CMMI: Planeamiento del proyecto

Iniciar proyecto

Preparar el proyecto dentro

del grupo de desarrollo

Determinar y organizar los recursos del proyecto

Definir los procesos y metodología

Adaptar los soportes administrativos

Realizar reunión de kick

off

(12)

CMMI: Control de la Ejecución

Coordinar revisiones QA

Ejecutar soporte en los proyectos de gestión Medir

rendimiento Asignar

tareas

Analizar estado de la

perfomance

Determinar alternativas y acciones correctivas

Comunicar Acciones correctivas

Tomar Acciones correctivas

Actualizar Plan de proyecto Desviaciones

Afecta programa o costos?

No Sí Sí

Control y monitoreo

No

CMMI: Gestión de la ejecución

Ejecutar el proyecto

Administrar los recursos del proyecto Comunicar el status del proyecto

Preparar informe de status Comunicar informe de status

(13)

CMMI: Gestión del cierre

Completar y cerrar el proyecto

Capitalizar los Activos del

Proyecto

Completar Cerrar el Proyecto

A partir de Flujos de Trabajo

(adecuadamente instanciados ...)

• Una lista de actividades, trabajadores (roles) y artefactos constituye un proceso.

• Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso.

• “Instanciando” el “Proceso” y los “Flujos de Trabajo”

podemos llegar a un Programa de Trabajo

Análisis de

Arquitectura Diseño de

Arquitectura Describir

Concurrencia Describir Distribución

Análisis de

Casos de Uso Diseño de Casos de Uso

Análisis de

Objetos Diseño de Objetos

Revisar el

Análisis Revisar el

Diseño Revisar la Arquitectura Revisor de

Diseño Diseñador Diseñador de Casos de Uso Arquitecto

(14)

Hay que llegar a la Programación

(para lo cual necesitamos el listado de actividades y su secuencia)

Tareas

Tiempo

Diagramas Gantt

Diagramas PERT / CPM

T1

T2

T3

T4

T5 T6

T7

Asignado recursos a las Tareas

(previo al presupuesto necesitamos el programa)

(15)

Proyecto según el PMBOK del PMI

Iniciación

Planeamiento

Control Ejecución

Cierre

Proyecto según el PMBOK del PMI

(otra visión)

(16)

PMBOK: Iniciación

Hacia los procesos de planeamiento

PROCESOS DE INICIACION

Iniciación

Se ejecuta cuando el proyecto o fase debe comenzar. Ejecutar el proceso de iniciación al comienzo de cada fase ayuda a mantener el proyecto enfocado.

PMBOK: Planeamiento

Planeamiento del alcance

Definición del alcance Definición

de actividades Secuencias

de actividades

Estimación de las actividades

Planeación de recursos

Estimación de costos

Planeamiento de riesgos Presupuesto

de costos Desarrollo

del programa

Desarrollo del proyecto

Proceso de Planeamiento: Procesos de Apoyo Proceso de Planeamiento: Procesos Esenciales

(17)

PMBOK: Planeamiento

Planeamiento: Procesos de soporte

Planeamiento de calidad

Planeamiento

organizacional Obtención de staff

Planeamiento de adquisiciones

Planeamiento de solicitud de propuestas

Planeamiento de la comunicación

Identificación del riesgo

Análisis cualitativo del riesgo

Análisis cuantitativo

del riesgo

Planeamiento de respuesta al

riesgo

Planeamiento: Procesos esenciales

PMBOK: Ejecución

Desde los procesos de

control

A los procesos de control

Procesos de ejecución

Ejecución del plan del proyecto

Procesos de soporte

Solicitud de propuestas

Aseguramiento de calidad

Selección de proveedor

Desarrollo del personal

Distribución de la información

Administración del contrato

(18)

PMBOK: Control

Procesos de control

Reporte de desempeño

Procesos de soporte

Control integrado de cambios

Control de cambios del

alcance Verificación

del alcance

Control del programa

Control del costo

Control de calidad

Monitoreo y control de

riesgo Desde el

Proceso de Ejecución

Hacia el Proceso de Planeamiento

Hacia el Proceso de

Ejecución Hacia el Proceso de

Cierre

PMBOK: Cierre del proyecto

Procesos de cierre

Objetivo: formalizan la aceptación del proyecto o fase y los llevan a una terminación ordenada

Desde los procesos de

control

Cierre administrativo Cierre de

contrato

Generar, recoger, y diseminar información para formalizar el cierre de una fase o terminación del proyecto Completar y negociar un contrato,

incluyendo la resolución de cualquier ítem abierto

(19)

PMBOK

¿qué significa Gestionar un Proyecto?

Administración Administración de Proyectos de Proyectos

Integración Integración

Costo Costo

Comunicaciones Comunicaciones

Alcance Alcance

Calidad Calidad

Riesgo Riesgo

Tiempo Tiempo

Recursos Recursos Humanos Humanos

Adquisiciones Adquisiciones

Cómo llegar a un listado de Tareas

Procesos Areas de

Conocimiento Iniciación Planeamiento Ejecución Control Cierre

1.- Integración 2.- Alcance 3.- Tiempos 4.- Costos 5.- Calidad 6.- Recursos

Humanos 7.- Comuni-

cación 8.- Riesgos 9.- Aprovisiona-

miento

(20)

13/05/2012 Doctor Roberto Uzal 39 Comunicación

Comunicación

Riesgo Riesgo Recursos Recursos Humanos Humanos

Adquisiciones Adquisiciones Calidad Calidad Costo Costo Tiempo Tiempo Alcance Alcance Integración Integración

4 10.4 Cierre administrativo 10.3 Información del

desempeño 10.2 Dist. de la información

10.1 Planeación de las comunicaciones

6 11.6 Monitoreo y

control del riesgo 11.1 Plan. de la ad. del riesgo

11.2 Identificación del riesgo 11.3 An. cualitativo del riesgo 11.4 An. cuantitativo del riesgo 11.5 Plan. de la resp. al riesgo

3 9.3 Desarrollo del equipo

9.1 Planeamiento de la org.

9.2 Reclutamiento de personal

39 2

8 7

21

# Procesos 1

6 12.6 Cierre de contratos 12.3 Licitaciones y cotizaciones

12.4 Selección de proveedores 12.5 Admón de contratos 12.1 Plan. de las adquisiciones

12.2 Planeación de licitaciones y cotizaciones

3 8.3 Control de calidad

8.2 Aseguramiento de la calidad 8.1 Planeación de la calidad

4 7.4 Control de costo

7.1 Planeación de recursos 7.2 Estimación de costos 7.3 Presupuesto

5 6.5 Control del

cronograma 6.1 Definición de actividades

6.2 Secuencia de actividades 6.3 Estimación de la duración de las actividades

6.4 Desarrollo del cronograma

5 5.4 Verificación del

alcance 5.5 Ctrl. cambios de alcance 5.2 Planeamiento del alcance

5.3 Definición del alcance 5.1

Inicio

3 4.3 Control integral de

cambios 4.2 Ejec. del plan del proyecto

4.1 Desarrollo del plan del proyecto

#Procesos CIERRE CONTROL

EJECUCIÓN PLANEAMIENTO

INICIO Áreas de conocimiento

Grupos de procesos

Ejemplo de “Fila Adicional”

Inicio Planeamiento Ejecución Control Cierre

Gestión de las Configuracio nes en Proyectos de Software

Entrenamiento de los miembros del Equipo de Desarrollo y de otros grupos relacionados para encarar las actividades de SCM y también en el uso de las herramientas automatizadas de SCM.

Establecimiento de una biblioteca SCM a ser utilizada como repositorio de las “Líneas de Base” del Proyecto de Software.

Establecimiento de un equipo con autoridad para la Gestión de las “Líneas de Base” del Proyecto de Software.

Definición de las metas y tareas del área SCM.

Establecimiento de un programa detallado (calendario) asociado a las metas y tareas SCM.

Suministrar los recursos y presupuesto adecuados para encarar las tareas SCM

Ejecución de las actividade s SCM definidas de acuerdo con las definicion es programáti cas y presupuest arias.

Control de Cambios de las

“Líneas de Base” de acuerdo con un procesos documentado.

Actualización del Plan SCM del Proyecto tal que refleje la situación vigente en todo momento.

Informe de las actividades SCM realizadas durante el Proyecto.

(21)

Para cumplir con este esquema

Planeamiento Alcance

Definición Alcance

Definición Actividades

Planeamiento Recursos

Secuencia

Estimación Duraciones

Estimación Costos

Desarrollo Programación

Presupuesto Desarrollo Plan Proyecto

Necesitamos contemplar tres dimensiones

Fases (Grupos de Procesos del PMBOK)

“Areas de Conocimiento” PMBOK

Tarea x,y,z Considerando el espacio de problema y la herramienta de representación / modelado

(22)

Ventajas de la propuesta

• La mayoría de los Proyectos de Software relevantes lo son de carácter multidisciplinario. Pretender que profesionales de diversos orígenes adhieran a un estándar específico de Gestión de Proyectos de Software, tal como el RUP (Rational Unified Process) de IBM, MSF (Microsoft Solution Framework) de Microsoft, ALM (Application Lifecycle Management) de Borland y otras propuestas “comerciales” es casi imposible. La Guía del PMBOK, en cambio, es de carácter general para todo tipo de proyecto. Su uso en Proyectos de Software es posible, además de ser muy conveniente.

• El esquema propuesto ha revelado ser muy apto en el momento en el cual, la Programación del Proyecto, debe ser volcada en un formato del tipo PERT / CPM.

• En Proyectos de Software del “mundo real”, el enfoque recomendado en este trabajo ha resultado ser muy conveniente en el momento de tener que elaborarse el Presupuesto del Proyecto.

• También, de acuerdo con la experiencia de los autores, el entrenamiento del equipo de proyecto es menos oneroso utilizando el enfoque de Gestión PMBOK comparado, por ejemplo, con el RUP de IBM.

• El esquema propuesto es claro, útil y efectivo (eficaz + eficiente)

Síntesis

• La proliferación de “metodologías producto comercial”, tales como el RUP (Rational Unified Process) de IBM, MSF (Microsoft Solution Framework) de Microsoft, ALM (Application Lifecycle Management) de Borland y otras ha causado un efecto “Torre de Babel” en el ámbito de la Gestión de Proyectos de Software. El uso del PMBOK es una interesante propuesta de “Lengua Franca” a ser considerada.

• En trabajos anteriores los autores han mostrado, mediante estudios comparativos, las ventajas del enfoque PMBOK, en Proyectos de Software, respecto de las alternativas “comerciales” que se han mencionado.

• Las actividades de formulación de una Matriz “Grupos de Proceso / Áreas de Conocimiento” específica para un Proyecto de Software puede ser incluida en el “Grupo de Procesos” denominado “Inicio” en el esquema de la Guía del PMBOK.

• El enfoque PMBOK brinda claras oportunidades para la estimación del esfuerzo de desarrollo en Proyectos de Software al ser utilizado en forma conjunta con técnicas como “Puntos de Casos de Uso” (Use Case Points) tal como los autores lo muestran en trabajos que se han presentados en otros eventos académico / profesionales.