uso del pmbok uzal

13/05/2012

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.

13/05/2012 Doctor Roberto Uzal 2

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

13/05/2012

2


Desarrollo de Software: cuatro capas

Las HerramientasLenguajes gráficos / visuales (Lenguaje de Modelado Unificado)Ambientes / Lenguajes de ProgramaciónBibliotecas de componentesHerramientas CASE

Gerenciamiento: Administración de la CalidadTotalISO 9001 (ISO 9000.3)CMMI del SEI - CMUPMBOK – PMIMSF (Microsoft)ALM (Borland)UP (IBM)Gestión de ProyectosGestión de CambiosGestión de ConfiguracionesGestión del Riesgo

ProcesoLa Administracióndel Ciclo de VidaModelos de Ciclo de Vida

El MétodoMétodos Formales vs. Métodos SemiformalesDistintas corrientes metodológicas de los Métodos SemiformalesDistintas Metodologías (Semiformales)

HMPG


Nivel de Complejidad

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

Modelado mínimoProceso simpleHerramientas simples

Construida eficientemente y en un tiempo razonable por un equipoRequiere:

ModeladoProceso bien definidoHerramientas más sofisticadas

13/05/2012

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 Task Name

12

3 Modelado de Negocio4 Moelar Casos de Uso de Negocio5 Modelar Objetos de Negocio

6 Modelado de Negocio Completado7 Captura Requisitos8 Derivar Casos de Uso de Sistema9 Requisitos Completos

10 Analisis y Diseño11 Analizar Casos de Uso Sistema12 Derivar Entidades

13 Diseñar Clases14 Definir Componentes15 Definir Despliegue

16 Arquitectura Definida17 Implentación y Despliegue18 Implementar Componentes19 Desplegar Componentes

20 Versión Sistema 1.0

MortadeloMortadelo

10/15

Filemon[50% ]10/17

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

Bacterio

BacterioBacterio

10/28

Zipi,Zape[50% ]Zape[50% ]

11/3

W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S SOct 12, '03 Oct 19, '03 Oct 26, '03 Nov 2, '03 Nov 9, '03

Arquitecto SistemaAnalista del Negocio ( Domini o)

Modelar Casos de uso de Negocio

Use Case Model

Bussiness Use Cas e Model

Bussines Object Model(Workers , Entidades y Procesos)

Analysis Model(es tructura y comporatmiento)

Design Model

Analista Sistema

Modelar Objetos de Neogcio

Derivar Casos de Uso Sis tema

Analizar Casos de Uso

Derivar Entidades

Dis eñar Classes(estructura y comportaminento)

Implementar Componnetes

Definir Componentes

Im plementation Model

Deployment Model

Definir Des pliegue

Developer

Des plegar Componnetes

Componentes

Programación de un proyectoProceso

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.

13/05/2012

4


Modelos de Proceso “Producto Comercial”

Arquitecto SistemaAnalista del Negocio (Dominio)

Modelar Casos de uso de Negocio

Use Case Model

Bussiness Use Case Model

Bussines Object Model(Workers, Entidades y Procesos)

Analys is Model(estructura y comporatmiento)

Design Model

Analista Sistema

Modelar Objetos de Neogcio

Derivar Casos de Uso Sistema

Analizar Casos de Uso

Derivar Entidades

Diseñar Classes(estructura y comportaminento)

Implementar Componnetes

Definir Componentes

Implementation Model

Deployment Model

Definir Despliegue

Developer

Desplegar Componnetes

Componentes


Existen numerosos modelos de “procesos de software”(este es un ejemplo para desarrollos de alta complejidad de sistemas de tiempo real del área defensa)

RequirementSpecs

RealReal--timetimeexecutionexecution

BehaviorRequirements at lower levels

levels of System

Specification

Model Structures at

higher levels ofSystem

Specification

Verification and

Validation

Simulationexecution

Test Models/Federations

Model Continuity

Experimental Frames

SystemTheory

13/05/2012

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ónDiseñoAnálisisViabilidad

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”

13/05/2012

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

Programación Pruebas ImplantaciónDiseñoAnálisis



Ventajas- Introduce el concepto de Incrementalidad- Más flexible que el Lineal SecuencialDesventajas- Su capacidad para absorber el concepto de Prototipo es escasa- Al igual que el Lineal Secuencial evidencia cierta ineficiencia enla utilización de los recursos (aunque en menor medida)

13/05/2012

7


Modelo RAD Ventajas:- Incremento significativo de la productividad- Compatible con Métodos más sofisticados ypotentes que los Métodos Estructurados Desventajas- Tentación de no alcanzar niveles de robustezy confiabilidad aceptables

La disponibilidad de Tecnologíade Bases de Datos induce suutilización

Prototipode Aplicaciones

Desarrollde Aplicaciones

Implantacióny Pruebas

Modelado de Aplicaciones

Modeladode Datos

Modeladodel Negocio

Equipo 1

Equipo 2

Equipo 3

Equipo n





Modeladode Datos

Modeladodel Negocio





Modeladode Datos

Modeladodel 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/SWSplit

4.HW/SWSplit

3.System OOA-Dynamic View

15.SystemTest

15.Prueba delSistema

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.

5.SW OOA-

Static View

14.BIT14.

Prueba deIntegración

13/05/2012

8


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

Flujos de Trabajode Ingeniería

Aspectos de la Capa 3

Organización a lo largo del tiempo

FasesFlujos de trabajo principales

Flujos de trabajo de apoyo

Organizaciónsegún la

naturaleza delas tareas

Aspectos de laCapa 2

Flujos de Trabajode Apoyo

(Environment incluye “Risk Management”)

Aspectos de la Capa 1


TODAS ITERACCIONES SUBSECUENTES

PLAN DELPROYECTO

PLAN DELPROYECTO

¿CERRAR PROYECTO?

CERRAR FASE

EVALUACIÓN DELALCANCE Y RIESGOS

DEL PROYECTO

GESTION DELA ITERACIÓN

PLAN PARALA PRIMERAITERACIÓN

PROYECTOCANCELADO

PROYECTOCANCELADO

ITERACIÓNEXITOSA

FIN DE ITERACIÓN

FIN DEL PROYECTO

FIN DEL PROYECTO

FIN DE ITERACIÓN

FIN DE FASE

FASE COMPLETA

PROYECTO COMPLETO

PLAN DEPROYECTOAPROBADO

CONCEBIRNUEVO

PROYECTO

EVALUACION DELPROYECTO DEL ALCANCE

Y DE LOS RIESGOS

No

MONITOTEO YCONTROL DEL

PROYECTO

RUPARRANQUE DEL PROYECTO UNICAMENTE

(OPIONAL, DEPENDIENDODEL GRADO DE CAMBIO)

PLAN PRÓXIMAITERACIÓN

CIERRE NO ACEPTADO

13/05/2012

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 ArquitecturaDiseño de Arquitectura

13/05/2012

10


El CMMIMaturity Level 5

OID, CAR

Maturity Level 4OPP, QPM

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

OverviewIntroductionStructure of the ModelModel TerminologyMaturity Levels, Common Features, and Generic PracticesUnderstanding the ModelUsing the Model

Maturity Level 2REQM, PP, PMC,SAM, MA, PPQA, CM

Appendixes

EngineeringREQM, REQD, TS,PI, VER, VAL

Project ManagementPP, PMC, SAMIPM, RSKM, QPM

Process ManagementOPF, OPD, OT,OPP, OID

Process ManagementPAs- Goals- Practices

SupportCM, PPQA, MA, CAR, DAR

Appendixes

CMMI-SE/SWStaged

OverviewIntroductionStructure of the ModelModel TerminologyCapability Levels and Generic Model ComponentsUnderstanding the ModelUsing the Model

CMMI-SE/SWContinuous


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

13/05/2012

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

13/05/2012

12


CMMI: Control de la Ejecución

Coordinar revisiones QA

Ejecutar soporte en los proyectos de gestión

Medirrendimiento

Asignartareas

Analizar estado de la perfomance

Determinaralternativas y

acciones correctivas

Comunicar Acciones

correctivas

Tomar Acciones

correctivas

Actualizar Plan de proyecto

Desviaciones

Afecta programao 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/05/2012

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 deArquitectura

Diseño deArquitectura

DescribirConcurrencia

DescribirDistribución

Análisis deCasos de Uso

Diseño deCasos de Uso

Análisis deObjetos Diseño de

Objetos

Revisar elAnálisis

Revisar elDiseño

Revisar laArquitecturaRevisor de

Diseño

Diseñador

Diseñador deCasos de Uso

Arquitecto

13/05/2012

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)

13/05/2012

15


Proyecto según el PMBOK del PMI

IniciaciónPlaneamiento

Control Ejecución

Cierre


Proyecto según el PMBOK del PMI(otra visión)

13/05/2012

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: PlaneamientoPlaneamientodel alcance

Definicióndel alcance

Definiciónde actividades

Secuenciasde actividades

Estimación de las actividades

Planeaciónde recursos

Estimaciónde costos

Planeamientode riesgos

Presupuestode costos

Desarrollodel programa

Desarrollodel proyecto

Proceso de Planeamiento: Procesos de Apoyo

Proceso de Planeamiento: Procesos Esenciales

13/05/2012

17


PMBOK: Planeamiento

Planeamiento: Procesos de soporte

Planeamiento

de calidadPlaneamiento 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

13/05/2012

18


PMBOK: ControlProcesos 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 elProceso deEjecución

Hacia elProceso de

PlaneamientoHacia el

Proceso deEjecuciónHacia el

Proceso deCierre


PMBOK: Cierre del proyecto

Procesos de cierreObjetivo: 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

13/05/2012

19


PMBOK¿qué significa Gestionar un Proyecto?

Administración Administración de Proyectosde Proyectos

IntegraciónIntegración

CostoCosto

ComunicacionesComunicaciones

AlcanceAlcance

CalidadCalidad

RiesgoRiesgo

TiempoTiempo

Recursos Recursos HumanosHumanos

AdquisicionesAdquisiciones


Cómo llegar a un listado de TareasProcesos

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

13/05/2012

20


ComunicaciónComunicación

RiesgoRiesgo

Recursos Recursos HumanosHumanos

AdquisicionesAdquisiciones

CalidadCalidad

CostoCosto

TiempoTiempo

AlcanceAlcance

IntegraciónIntegración

410.4 Cierre administrativo

10.3 Información del desempeño

10.2 Dist. de la información10.1 Planeación de las comunicaciones

611.6 Monitoreo y control del riesgo

11.1 Plan. de la ad. del riesgo11.2 Identificación del riesgo11.3 An. cualitativo del riesgo11.4 An. cuantitativo del riesgo11.5 Plan. de la resp. al riesgo

39.3 Desarrollo del equipo9.1 Planeamiento de la org.9.2 Reclutamiento de personal

39287211# Procesos

612.6 Cierre de contratos

12.3 Licitaciones y cotizaciones12.4 Selección de proveedores12.5 Admón de contratos

12.1 Plan. de las adquisiciones12.2 Planeación de licitaciones y cotizaciones

38.3 Control de calidad8.2 Aseguramiento de la calidad8.1 Planeación de la calidad

47.4 Control de costo7.1 Planeación de recursos7.2 Estimación de costos7.3 Presupuesto

56.5 Control del cronograma

6.1 Definición de actividades6.2 Secuencia de actividades6.3 Estimación de la duración delas actividades6.4 Desarrollo del cronograma

55.4 Verificación del alcance5.5 Ctrl. cambios de alcance

5.2 Planeamiento del alcance5.3 Definición del alcance

5.1 Inicio

34.3 Control integral de cambios

4.2 Ejec. del plan del proyecto4.1 Desarrollo del plan del proyecto

#ProcesosCIERRECONTROLEJECUCIÓNPLANEAMIENTOINICIOÁreas de

conocimiento

Grupos de procesos


Ejemplo de “Fila Adicional”Inicio Planeamiento Ejecución Control Cierre

Gestión de las Configuraciones 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 actividades SCM definidas de acuerdo con las definiciones programáticas y presupuestarias.

Control de Cambios de las “Líneas de Base” de acuerdo con un procesos documentado. Actualización del Plan SCMdel Proyecto tal que refleje la situación vigente en todo momento.

Informe de las actividades SCMrealizadas durante el Proyecto.

13/05/2012

21


Para cumplir con este esquema

PlaneamientoAlcance

DefiniciónAlcance

DefiniciónActividades

PlaneamientoRecursos

Secuencia

EstimaciónDuraciones

Estimación Costos

DesarrolloProgramación

Presupuesto DesarrolloPlan Proyecto


Necesitamos contemplar tres dimensiones

Fases (Grupos de Procesos del PMBOK)

“Are

as d

e C

onoc

imie

nto”

PM

BOK

Tarea x,y,zConsiderando el espacio de problema y

la herramienta de representación / modelado

13/05/2012

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.

uso del pmbok uzal

Documents

t f s soct

proceso de software

casos de uso sistema12

uso generalizado

negocio4 moelar casos

comoel proyecto

procesoel proceso

proyectos guide