Sei sulla pagina 1di 61

Administracin y Control de Proyectos I Proyectos Informticos

Gua de TP
2 Cuatrimestre de 2007 Trabajos Prcticos

Agosto de 2007
Versin 9.0

ndice
Introduccin ....................................................................................................4 1 Equipos de Trabajo .................................................................................10
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 Diseo Diseo Diseo Diseo Diseo Diseo Diseo Diseo de de de de de de de de Equipo Equipo Equipo Equipo Equipo Equipo Equipo Equipo de de de de de de de de Trabajo Trabajo Trabajo Trabajo Trabajo Trabajo Trabajo Trabajo para para para para para para para para el el el el el el el el Proyecto Proyecto Proyecto Proyecto Proyecto Proyecto Proyecto Proyecto APPITEL 2.0 ..................................... 10 DATATEL ......................................... 11 DWH LOPEC..................................... 13 DRUG 1 ........................................... 14 BETA ............................................... 15 Comisiones II ................................... 16 Certificacin ISO............................... 18 Cine & Video .................................... 18

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 4.1 4.2

Etapa 1: Inicio (Alcance) .........................................................................20

WBS para el Proyecto APPITEL 2.0......................................................................... 20 Versiones y Entregas Incrementales para el Proyecto APPITEL 2.0........................... 21 Planificacin de Recursos para el Proyecto APPITEL 1.0........................................... 22 Propuesta para el Proyecto Help Desk .................................................................... 24 Riesgos para el Proyecto Help Desk ....................................................................... 27 Alcance para el Proyecto Help Desk........................................................................ 27 Planificacin de Recursos para el Proyecto CPP 1.0 ................................................. 28 WBS para el Proyecto Cine & Video ........................................................................ 28 Entregas Incrementales para el Proyecto Cine & Video ............................................ 30 WBS para el Proyecto DRUG 1 ............................................................................... 30 Planificacin de Recursos para el Proyecto ALFA ..................................................... 30 Planificacin de Recursos para el Proyecto Comisiones ............................................ 31 WBS para el Proyecto BETA ................................................................................... 32 Planificacin de recursos para el Proyecto 25 de Mayo Delivery................................ 32 WBS para el Proyecto K......................................................................................... 33 WBS para el Proyecto Certificacin ISO .................................................................. 34 Planificacin de Recursos para el Proyecto Cine & Video.......................................... 34 Calendario Cliente / Distribucin de Presupuesto para el Proyecto APPITEL 1.0......... 35 Calendario Cliente para el Proyecto DATATEL ......................................................... 36 Calendario Cliente para el Proyecto APPITEL 2.0 ..................................................... 37 Calendario Build Diario para el Proyecto APPITEL 1.0 .............................................. 37 Diseo de Indicador de Funcionalidad Completa para el Proyecto APPITEL 1.0 ......... 38 Calendario Build Diario e Indicador de FC para el Proyecto APPITEL 2.0 ................... 40 WBS de Calidad para el Proyecto APPITEL 2.0 ........................................................ 40 Plan de Proyecto para el Proyecto APPITEL 1.0 ....................................................... 41 Plan de Adm. de Cambios para el Proyecto APPITEL 2.0.......................................... 41 Plan de Calidad para el Proyecto APPITEL 2.0 ......................................................... 41 Calendario Cliente para el Proyecto Cine & Video .................................................... 42 Calendario Build Diario para el Proyecto Cine & Video ............................................. 42 Calendario Build Diario para el Proyecto ADP .......................................................... 43 Calendario Cliente para el Proyecto BETA ............................................................... 44 Versiones, Entregas Incrementales y Calendario Cliente para el Proyecto DRUG 1..... 44 Calendario Cliente para el Proyecto K ..................................................................... 45 Anlisis de Indicadores para el Proyecto CE-EME..................................................... 46 Anlisis de Indicadores de FC y Esfuerzo para el Proyecto GENERIC1 ....................... 48
Administracin y Control de Proyectos I

Etapa 2: Organizacin .............................................................................35

Etapa 3: Ejecucin y Control ....................................................................46

Agosto/2007 (versin 9.0)

Pgina 2 de 61

4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13

Re-planificacin del Proyecto GENERIC1 ................................................................. 50 Esquema de reuniones de avance para el Proyecto DATATEL .................................. 50 Estabilizacin de Liberacin a Produccin para el Proyecto APPITEL 1.0 ................... 51 Estabilizacin de Liberacin a Aceptacin para el Proyecto APPITEL 1.0 ................... 51 Tratamiento de Riesgos para el Proyecto DATATEL ................................................. 52 Esquema de reuniones de avance para el Proyecto APPITEL 2.0 .............................. 53 Earned Value para el Proyecto IDC 1...................................................................... 54 Priorizacin de defectos para el Proyecto CPP 1.0 ................................................... 55 Earned Value (terico) ............................................................................................. 56 Anlisis de Indicadores para el Proyecto INDI 1 ...................................................... 56 Anlisis de Indicadores para el Proyecto INDI 2 ...................................................... 60

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 3 de 61

Introduccin
Filosofa de los ejercicios:
En general los ejercicios plantean situaciones y escenarios a ser analizados por un jefe de Proyecto. En base a ese anlisis se debe disear una solucin al problema planteado. El xito en la resolucin del ejercicio est dado por la capacidad de analizar el problema y plantear una solucin y no por el uso de frmulas mgicas. Es por eso que se recomienda no copiar resoluciones, ya que el parcial plantear el mismo tipo de ejercicios en donde la prctica de haber estado en situaciones similares ser clave para resolverlos.

Dedicacin de los alumnos:


Para un correcto aprovechamiento de las clases y una buena preparacin para los parciales recomendamos: Tomar las clases tericas como base para la resolucin de los ejercicios. Resolver los ejercicios con calidad de presentacin. Resolver un ejercicio en forma parcial puede hacer que el alumno no obtenga las conclusiones del mismo. Si hay dudas ante la resolucin de un ejercicio, avanzar tomando hiptesis y justificando las decisiones tomadas. La mayora de las dudas sern resueltas por el mismo alumno. Volver a resolver en forma completa todos los ejercicios luego de cada clase prctica para aplicar los conocimientos adquiridos. Ampliar la prctica con los ejercicios recomendados. Dedicar un mnimo de 20 horas semanales a la materia.

Frmula para estar bien preparado:


Clase Terica + Pautas para resolucin de Ejercicios + Resolucin ejercicios obligatorios (1 y 2 ver calendario) y recomendados antes de la clase + Verificacin de solucin en Clase Prctica + Resolucin ejercicios obligatorios y recomendados despus de la clase = 20 HH semanales

Diagrama de Secuencia de Ejercicios:


La idea del siguiente diagrama es mostrar a los alumnos cmo se relacionan entre s los ejercicios correspondientes a los distintos Proyectos, de forma tal que puedan comprender la importancia de resolverlos antes de la clase y corregirlos luego de la misma, a fin de poder seguir resolviendo los que son correlativos a medida que avanza el cuatrimestre.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 4 de 61

Proyecto APPITEL 2.0


2.1 WBS Semana 5 Obligatorio Semana 6 - Obligatorio Semana 7 - Obligatorio

1.1 Diseo de Equipo de Trabajo

2.2 Versiones y Entregas Incrementales 3.3 Calendario Cliente

Semana 7 - Obligatorio Semana 9 - Recomendado Semana 12 - Obligatorio

3.6 Calendario Build Diario / IFC

4.8 Esquema de Reuniones de Trabajo 3.7 WBS Calidad Semana 15 - Obligatorio

3.9 Plan de Administracin de Cambios 3.10 Plan de Calidad

Semana 15 - Obligatorio

Semana 15 - Recomendado

Proyecto DATATEL

1.2 Diseo de Equipo de Trabajo

Semana 6 - Recomendado Semana 7 - Recomendado Semana 12 - Obligatorio

3.2 Calendario Cliente

4.4 Esquema de Reuniones de Avance 4.7 Tratamiento de Riesgos

Semana 12 - Obligatorio

Proyecto DRUG 1
2.10 WBS Semana 5 Recomendado

1.4 Diseo de Equipo de Trabajo

Semana 6 Recomendado Semana 7 Recomendado

3.15 Versiones, Ent. Inc. y Calendario Cliente

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 5 de 61

Proyecto DWH LOPEC

1.3 Diseo de Equipo de Trabajo

Semana 6 - Recomendado

Proyecto BETA
2.13 WBS Semana 5 - Recomendado Semana 6 - Recomendado Semana 7 - Recomendado

1.5 Diseo de Equipo de Trabajo 3.14 Calendario Cliente

Proyecto Comisiones II
1.6 Diseo de Equipo de Trabajo Semana 6 - Recomendado

Proyecto K
2.15 WBS Semana 5 - Recomendado Semana 7 - Recomendado

3.16 Calendario Cliente

Proyecto CINE & VIDEO


2.8 WBS Semana 5 - Obligatorio Semana 6 - Obligatorio

1.8 Diseo de Equipo de Trabajo

2.9 Entregas Incrementales 3.11 Calendario Cliente

Semana 7 - Obligatorio

Semana 7 - Obligatorio Semana 8 - Recomendado

3.12 Calendario Build Diario 2.17 Diseo Equipo de Trabajo

Semana 8 - Obligatorio

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 6 de 61

Proyecto APPITEL 1.0

3.1 Calendario Cliente / Distribucin Presupuesto 2.3 Planificacin de Recursos 3.4 Calendario Build Diario

Semana 7 - Recomendado

Semana 8 - Obligatorio Semana 8 - Recomendado Semana 9 - Obligatorio

3.5 Indicador Funcionalidad Completa 3.8 Plan de Proyecto

Semana 15 - Obligatorio Semana 10 - Recomendado Semana 10 - Recomendado

4.5 Estabilizacin Lib. a Produccin 4.6 Estabilizacin Lib. a Aceptacin

Proyecto Comisiones
2.12 Planificacin de Recursos Semana 8 - Obligatorio

Proyecto 25 de Mayo Delivery


2.14 Planificacin de Recursos Semana 8 - Recomendado

Proyecto CPP 1.0


2.7 Planificacin de Recursos

Semana 8 - Recomendado Semana 10 - Obligatorio

4.10 Priorizacin de Defectos

Proyecto ALFA
2.11 Planificacin de Recursos Semana 8 - Recomendado

Proyecto ADP
3.13 Calendario Build Diario Semana 8 - Recomendado

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 7 de 61

Proyecto CE-EME
4.1 Anlisis de Indicadores Semana 9 - Obligatorio

Proyecto HELP DESK


2.4 Propuesta de Proyecto Semana 9 - Recomendado Semana 12 - Recomendado

2.5 Riesgos del Proyecto 2.6 Alcance del Proyecto

Semana 12 - Recomendado

Proyecto Certificacin ISO

2.16 WBS

Semana 5 - Obligatorio Semana 6 - Obligatorio

1.7 Diseo de Equipo de Trabajo

Proyecto GENERIC1
4.2 Anlisis IFC y Esfuerzo Semana 9 - Recomendado Semana 9 - Recomendado

4.3 Replanificacin de Proyecto

Proyecto INDI2
4.13 Anlisis de Indicadores Semana 9 - Recomendado

Proyecto IDC1
4.9 Earned Value Semana 10 - Obligatorio

Proyecto INDI1
4.12 Anlisis de Indicadores Semana 10 - Obligatorio

Ejercicio Terico
4.11 Earned Value Semana 10 - Recomendado

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 8 de 61

Historial de Versiones:
Fecha / Versin Agosto de 2007 / 9.0 Marzo de 2007 / 8.0 Agosto de 2006 / 7.0 Marzo de 2006 / 6.0 Agosto de 2005 / 5.0 Patricia Ins Bus Patricia Ins Bus Autor Patricia Ins Bus Anotaciones Modificacin del Diagrama de Secuencia de Ejercicios por cambios en el orden de resolucin y en el calendario. Nuevos ejercicios: 1.8 y 2.17 Modificacin del Diagrama de Secuencia de Ejercicios por cambios en el orden de resolucin y en el calendario. Nuevos ejercicios: 1.7 y 2.16 Correccin de etiquetas en grficos de los ejercicios 3.5, 4.2, 4.7 y 4.12 Modificacin del Diagrama de Secuencia de Ejercicios. Mariana Gmez Patricia Ins Bus Modificacin terminologa. Correccin defectos. Nuevos ejercicios: 1.5, 1.6, 2.12, 2.13, 2.14, 2.15, 3.14, 3.15, 3.16 Actualizacin del Diagrama de Secuencia de Ejercicios. Correccin del punto 5 del Ejercicio 4.7 (se cambi semana 8 por semana 5). Marzo de 2005 / 4.0 Patricia Ins Bus Incorporacin del Diagrama de Secuencia de Ejercicios (sobre una idea de Alejandro Sasn) Eliminacin de Organizacin de Clases Prcticas. Correccin de defectos de ortografa y redaccin. Agosto de 2004 / 3.0 Patricia Ins Bus Nuevos ejercicios: 1.4, 2.10, 2.11, 3.13, 4.12, 4.13 Modificacin en la Organizacin de Clases Prcticas. Eliminacin del Calendario de Ejercicios. Correccin de defectos de ortografa y redaccin. Marzo de 2004 / 2.0 Agosto de 2003 / 1.0 Juan Pablo Pussacq Laborde Juan Pablo Pussacq Laborde (Colaboracin de Ral Martnez y Mariana Gmez en algunos ejercicios y en revisiones) Nuevos ejercicios: 1.3, 2.7, 2.8, 2.9, 3.11, 3.12, 4.10 y 4.11 Versin inicial.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 9 de 61

1 Equipos de Trabajo 1.1 Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0
Escenario CIRCULO SA ha decidido renovar su aplicacin de Atencin de Pedidos Telefnicos en dos meses y medio. Se trata de una aplicacin crtica con los siguientes lineamientos de arquitectura: Aplicacin win32 en Visual Basic en una red NT con base de datos Access. Servidor central con base de datos SQL Server. Servicios del servidor central programados con arquitectura Web.

El rea de Sistemas de CIRCULO no puede afrontar este Proyecto, por lo cual decide tercerizarlo. Para ello contrata a los siguientes proveedores: FX SA para que trabaje en la parte de Visual Basic CEREBE SRL para modificar los servicios Web del servidor central. PI SA para realizar anlisis, diseo y QC. Adems tomar la direccin del Proyecto. Adems proveer uno o dos recursos de CIRCULO para el desarrollo de interfaces con otros sistemas.

El Proyecto ha sido aprobado y comienza la prxima semana. Usted pertenece a PI y ha sido designado como Jefe de Proyecto. La propuesta presentada por PI tiene las siguientes restricciones: Duracin: 2 meses y medio (incluye construccin y puesta en marcha) Presupuesto: o 218 HH de Consultor Senior

o 392 HH de Consultor Su primer paso es disear la estructura de trabajo. Cuenta con la siguiente informacin: PI PI asigna dos personas al Proyecto. o Alejo (usted): consultor senior que adems de dirigir el Proyecto, puede realizar tareas de o anlisis, diseo y prueba. Valentina: un consultor de PI que cuenta con experiencia en QC y algo de experiencia en

anlisis y diseo. Uno de los socios de PI (Adolfo) participar con algunas horas (31 HH aproximadamente) para seguimiento de alto nivel.

FX PI ya ha trabajado con FX anteriormente. FX proveer los recursos necesarios para terminar en fecha el Proyecto. An no saben si sern uno, dos o tres. Andrs, uno de ellos, participar seguro. FX cuenta con dos socios (Martn y Carlos). Uno de los dos o los dos estarn tambin participando en el Proyecto.

CEREBE PI no ha trabajado con CEREBE anteriormente. CEREBE proveer los recursos necesarios para terminar en fecha el Proyecto. A diferencia de FX, que trabaja por producto terminado, CEREBE trabaja por mano de obra. CEREBE ya posee 3 recursos asignados a otros trabajos en CIRCULO. En principio Silvio estar asignado, salvo que se complique el otro trabajo que est realizando en CIRCULO. De todas maneras, CEREBE asegur que hay otros recursos disponibles, que nunca trabajaron en CIRCULO. Uno de los socios de CEREBE (Cintia) estar disponible si se lo necesita.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 10 de 61

CIRCULO Juan y Alberto estarn asignados para trabajar en el tema de Interfaces. Juan conoce mucho mejor la problemtica por lo cual es el principal asignado. Aunque en la reunin de Kick Off manifest estar con demasiadas tareas. Norberto, el Gerente de Sistemas de CIRCULO, es quien decidi tercerizar y quin contrat a PI y FX. Norberto percibe que tanta gente involucrada puede generar un problema, por lo tanto asignar a dos de sus mejores recursos, Andrea y Ral. Andrea trabaja habitualmente con los usuarios y conoce claramente la problemtica desde el punto de vista funcional. Ral tambin conoce la problemtica, pero fundamentalmente es una persona tcnica con mucha experiencia en Visual Basic y arquitectura Web. Jos es el Gerente de Ventas. De l depende el Call Center que utiliza esta aplicacin. Norberto quiere que participen algunas de las supervisoras del Call Center ya que estn en el da a da y conocen claramente la problemtica. Alicia estar involucrada en sus ratos libres en el Call Center y probablemente participe adems alguna de las otras supervisoras. An no se tiene muy claro cul es la distribucin de trabajo entre los distintos proveedores de desarrollo, pero una primera aproximacin arroja los siguientes datos: FX: 65% del total del desarrollo CEREBE: 30% del total del desarrollo CIRCULO: 5% del total del desarrollo

Objetivo
Se pide que usted disee la estructura del equipo de trabajo para presentar en la prxima reunin y validar con los dems participantes. Debe incluir: Diagrama estilo organigrama con nombres de las personas y funciones. Debe involucrar a todos los participantes. Descripcin breve de responsabilidades de cada uno. Identificar riesgos principales del equipo planteado.

1.2 Diseo de Equipo de Trabajo para el Proyecto DATATEL


Escenario
CIRCULO SA ha decidido contratar nuevamente a PI para encarar un Tablero de Ventas. A diferencia del Proyecto APPITEL, CIRCULO no conoce en este caso nada acerca de la problemtica de Datawarehousing. De hecho, este ser el primer Proyecto con esta tecnologa en la empresa. CIRCULO decide encarar el Proyecto de la siguiente manera: El proveedor PI SA tomar el Proyecto en forma completa. CIRCULO proveer uno o dos recursos propios para el desarrollo de interfaces con otros sistemas que permitan poblar el datawarehouse.

El Proyecto ha sido aprobado y comienza la prxima semana. Usted pertenece a PI y ha sido designado como Jefe de Proyecto. La propuesta presentada por PI tiene las siguientes restricciones: Duracin: 2 meses y medio (incluye construccin y puesta en marcha)

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 11 de 61

Presupuesto: o o o o 150 HH de Consultor Senior especializado en Datawarehouse 400 HH de Desarrollador especializado en Datawarehouse 350 HH de QC 180 de Jefe de Proyecto

Su primer paso es disear la estructura de trabajo. Cuenta con la siguiente informacin: PI PI asigna las siguientes personas al Proyecto. o Alejo (usted): jefe de Proyecto con experiencia en administracin de Proyectos, sin experiencia en Proyectos de Datawarehouse. Adems tiene conocimiento del negocio por su participacin en el Proyecto anterior. Mariano: consultor senior. Ha trabajado como desarrollador o como analista en otros Proyectos de Datawarehouse. Posee mucha experiencia. Cecilia: consultor que ha trabajado como desarrollador en otros Proyectos de Datawarehouse. Federico: especialista en la customizacin del Front End. Tomar algunas horas de desarrollo (de las 400) para posibles customizaciones. Se estiman alrededor de 80. Sebastin: tester con experiencia en Proyectos de datawarehouse. Martn: tester junior. Colaborar con Sebastin en algunas tareas y es objetivo de PI que este Proyecto le sirva de capacitacin.

o o o o o

Uno de los socios de PI (Adolfo) participar con algunas horas (34 HH aproximadamente) para seguimiento de alto nivel. El Proyecto comienza en diciembre. Usted, Mariano, Cecilia y Sebastin tienen 15 das de vacaciones durante el Proyecto, a tomarse entre las semanas 4 y 10, exceptuando Cecilia que puede tomarlas a partir de la 2. Usted debe contemplar la estructura de reemplazos.

CIRCULO Juan y Alberto estarn asignados para trabajar en el tema de Interfaces. Juan conoce mucho mejor la problemtica por lo cual es el principal asignado. Aunque en la reunin de Kick Off manifest estar con demasiadas tareas. Norberto, el Gerente de Sistemas de CIRCULO, es quien decidi tercerizar y quin contrat a PI. Oscar, un gerente de alto nivel cuya funcin no le queda muy clara a PI, es quien espera obtener buenos resultados con este tablero. Desea involucrarse mucho en el Proyecto y estuvo de acuerdo con Norberto en que se contratara a PI. Jos es el Gerente de Ventas, y espera obtener buena informacin del Tablero. Omar, Jefe de Marketing, y Sal, uno se sus empleados, esperan obtener buena informacin tambin. Florencia trabaja habitualmente con informacin en Excel y espera tambin conseguir buena informacin. Muchos de sus informes son provistos directamente a Oscar y a Fernando, el CEO de la Compaa. El CEO espera obtener buena informacin tambin. Adrin, quien trabaja en los aspectos operativos del circuito de Delivery, tambin espera ser usuario de este Tablero. Estar involucrado en el Proyecto junto a Mara, una de sus empleadas. Osvaldo trabaja en Administracin y Finanzas. Norberto le pidi que se involucre en el Proyecto porque la informacin puede serle til a l tambin. Dada la experiencia exitosa de APPITEL, Norberto asigna nuevamente a dos de sus mejores recursos, Andrea y Ral. Andrea trabaja habitualmente con los usuarios y conoce claramente la problemtica desde el punto de vista funcional. Ral tambin conoce la problemtica, pero fundamentalmente es una persona tcnica con mucha experiencia en Visual Basic y arquitectura Web. Ral no tiene experiencia en Datawarehouse, pero est interesado en quedarse con algunos conocimientos de manera de poder resolver problemas de operacin en el futuro. Norberto decide involucrar a ms gente de su rea dado que se trata de tecnologa nueva: o Damin, un programador que colaborar con aspectos tcnicos. Administracin y Control de Proyectos I Pgina 12 de 61

Agosto/2007 (versin 9.0)

Martina, quien trabajar junto a Andrea.

No se sabe cundo ni quines, pero es posible que varios de los integrantes de CIRCULO tomen vacaciones en distintos momentos del Proyecto.

CIRCULO CENTRAL CIRCULO es una subsidiaria de CIRCULO CENTRAL. An no est muy claro, pero es posible que el tablero se instale en CIRCULO CENTRAL, ya que cuenta con los servidores necesarios y con algo de conocimiento en este tipo de Proyectos. Luca, quin maneja los aspectos de Datawarehouse en CIRCULO CENTRAL, ser el contacto. Luca involucrar a Antonio, especialista en Datawarehouse, para que valide que el Tablero de Ventas para CIRCULO cumplan con los estndares de la Organizacin Luca har participar tambin a las reas de Seguridad, Base de Datos, Software de Base y Comunicaciones de CIRCULO CENTRAL para los temas de Infraestructura.

Objetivo
Se pide que usted disee la estructura del equipo de trabajo para presentar en la prxima reunin y validar con los dems participantes. Debe incluir: Diagrama estilo organigrama con nombres de las personas y funciones. Debe involucrar a todos los participantes. Descripcin breve de responsabilidades de cada uno. Identificar riesgos principales del equipo planteado.

1.3 Diseo de Equipo de Trabajo para el Proyecto DWH LOPEC


Escenario
La empresa LOPEC SA ha decidido contratar a PI (la empresa a la que usted pertenece) para encarar un desarrollo de un nuevo sistema de gestin que incluye los siguientes mdulos: 1. 2. 3. 4. 5. Construccin de un Datawarehouse de Compras (a cargo de PI) Desarrollo de una interfaz con el Sistema de Compras (a cargo de LOPEC) Integracin con el actual Datawarehouse de Ventas (a cargo de PI) Desarrollo de un aplicativo que permita almacenar informacin que hoy no existe en el Sistema de Compras (a cargo de PI) Herramienta de explotacin de Datawarehouse (provista por el proveedor SUBOSCURO)

LOPEC encarg a PI la direccin total del Proyecto, pidiendo que coordine los 5 mdulos. La propuesta presentada por PI se basa en la siguiente estimacin y asignacin de recursos:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 13 de 61

Rol / Tiempo Analista (Laura) Desarrollador Datawarehouse 1 (Pedro) Desarrollador Datawarehouse 2 (Luis) Desarrollador Aplicativo 1 (Pablo) Desarrollador Aplicativo 2 (Andrs) Tester 1 (Mariana) Tester 2 (Juan Pablo) Jefe de Proyecto (Ral) 1 = Full Time 0,5 = Part Time

Q1 1 0,5

Q2 1 1 1 1

Q3 0,5 1 1 1 1 1 1 1

Q4 0,5 1 1 1 1 1 1 1

Q5 0,5 1 1 1 1 1 1 1

Q6 0,5 1 1 1 1 1 1 1

Q7 0,5 1 0,5 1 0,5 1 1 1

Hiptesis: El Analista trabaja tanto en el anlisis del Datwarehouse como en el del Aplicativo. El Analista instala, parametriza y capacita en la herramienta de explotacin. El Analista disea las interfaces. Son desarrolladas y probadas por LOPEC.

Los participantes de LOPEC en el Proyecto son: Samuel, Gerente de Compras, quien paga por el nuevo sistema Adolfo y Carlos, quienes trabajan en el rea de Compras y conocen todos los aspectos del Negocio. En particular Carlos posee muchos ms aos en la compaa. Silvia, personal de la Gerencia de Ventas que conoce en detalle el actual sistema de Gestin de Ventas. Antonio, Gerente de Sistemas, quien decidi subcontratar. Andrea, personal de Sistemas quien se har responsable de todos los aspectos funcionales y tcnicos que el Proyecto requiera a LOPEC. Martn, Sebastin y Marita se encargarn del desarrollo de las interfaces. Gabriela, responsable de Seguridad

Adems participan: Miguel, de SUBOSCURO, quien vendi a LOPEC las licencias de su producto de explotacin. Cristian, consultor de SUBOSCURO encargado de brindar consultora sobre la herramienta de explotacin a Laura (de PI). Enrique, socio de PI

Objetivo
Se pide que usted disee la estructura del equipo de trabajo para presentar en la prxima reunin y validar con los dems participantes. Debe incluir: Diagrama estilo organigrama con nombres de las personas y funciones. Debe involucrar a todos los participantes. Descripcin breve de responsabilidades de cada uno. Identificar riesgos principales del equipo planteado.

1.4 Diseo de Equipo de Trabajo para el Proyecto DRUG 1


Escenario
SPAZIO es una multinacional con origen en Estados Unidos, que provee productos y servicios de software y hardware. Usted, Alejo de PI SA, ha sido contratado por SPAZIO Argentina para trabajar como lder del Proyecto DRUG 1. En este momento se encuentra en la primera reunin con Adolfo, Gerente de Servicios de SPAZIO Argentina, quien le est describiendo de que se trata el Proyecto. Su objetivo es armar el equipo de trabajo del Proyecto para presentarlo en el Kick Off del prximo viernes, que ser conducido por usted.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 14 de 61

Descripcin brindada por Adolfo: En el ao 1999, IRC SA desarroll su producto / servicio IRC*SERVICE para operar con Obras Sociales, Farmacias y Mdicos. SPAZIO compr IRC SA en el 2001. As fue evolucionando IRC* SERVICE hasta la actualidad en que se encuentra en su versin 3.0. Hoy, el servicio IRC* SERVICE, se ejecuta en un servidor central en SPAZIO Argentina y es utilizado por 15 Obras Sociales, 300 Farmacias y 700 Mdicos. SPAZIO de Estados Unidos ha construido un servicio similar, aunque con menos funcionalidad por tratarse de la primera versin: DRUG 1. El servicio IRC*SERVICE ser dado de baja en 6 meses y ser reemplazado totalmente por DRUG 1 en todos los clientes que acepten el cambio. Los que no acepten el cambio, debern trabajar con la competencia o dejar de usar el servicio. El Proyecto que tens que liderar finaliza con las instalacin de DRUG 1 en todos los clientes y el cierre de IRC*SERVICE para siempre. Tu funcin es coordinar a las distintas partes involucradas. El Proyecto tiene un aspecto tecnolgico que consiste en la localizacin del servidor de DRUG 1 para Argentina y en la customizacin de los clientes de DRUG 1 para cada una de las Obras Sociales. Una vez resuelto esto, debern migrarse los clientes: Obras Sociales, Farmacias y Mdicos. Andrea, de SPAZIO Argentina liderar esta parte y trabajar con un partner de desarrollo (WSD SRL) y un partner de QC (DIM SA) para la localizacin, la customizacin y la instalacin de Clientes y Servidor. Otro aspecto muy importante es la parte comercial. Es necesario calcular los nuevos precios del servicio y vendrselo a los Clientes, en particular a las Obras sociales. Daniel de SPAZIO Argentina coordina todo este aspecto, aunque la parte de Farmacias y Obras Sociales est delegada en Cecilia de SPAZIO Argentina. Es posible que nos enfrentemos a juicios o temas complicados de contratos con los clientes. Es por eso que estar involucrado Alberto del rea Legales de SPAZIO Argentina. l ser el responsable de la parte Legal. Es importante tener en cuenta que el nuevo servicio no brinda mejoras a nuestros clientes, al contrario, se pierde funcionalidad. Esto generar muchos problemas. El aspecto de comunicacin es importante. Margarita, del rea de Comunicacin de SPAZIO, estar encargada de este punto, que incluye tanto la comunicacin interna dentro de SPAZIO Argentina como los comunicados de prensa, y comunicados a Obras Sociales, Farmacias y Mdicos. No queremos que se genere ningn tipo de ruido. Es decir, no queremos que DRUG 1 genere un problema de imagen a SPAZIO. A nivel SPAZIO de Estados Unidos, Tom es el responsable del presupuesto asignado al subProyecto de Argentina y constituye el nivel de decisin ms alto del Proyecto. Paul es el referente tecnolgico de DRUG 1 y nos podr dar asistencia en ese aspecto.

Objetivo
Se pide que disee la estructura del equipo de trabajo para presentar en la reunin de Kick Off y validar con los dems participantes. Debe incluir: Diagrama estilo organigrama con nombres de las personas y funciones. Debe involucrar a todos los participantes. Descripcin breve de responsabilidades de cada uno. Identificar riesgos principales del equipo planteado.

1.5 Diseo de Equipo de Trabajo para el Proyecto BETA


Agosto/2007 (versin 9.0) Administracin y Control de Proyectos I Pgina 15 de 61

Escenario
La empresa PI ha decidido lanzar un Proyecto para la construccin de un producto para el mercado financiero. An no sabe como ser el producto, por lo cual ha decidido que parte del trabajo de este Proyecto sea la definicin del mismo. El Proyecto debe arrancar con el desarrollo de la visin y finalizar con un entregable que incluya el CD y los manuales listos para la duplicacin. El Proyecto est financiado en un 70% por PI y en un 30% por el gobierno de la provincia de Crdoba, en el contexto de una iniciativa para promover la industria del software en la provincia. El gobierno de Crdoba aportar presupuesto para que PI compre los equipos de hardware para los ambientes de desarrollo y prueba. Adems aportar presupuesto para que el personal de PI afectado al Proyecto se capacite en la ltima tecnologa de bases de datos que deber utilizarse en dicho Proyecto. Es objetivo del Proyecto tanto el desarrollo del producto como las actividades comerciales alrededor de ste: desarrollar material de venta, lanzar una campaa de difusin y buscar posibles clientes mientras dure el desarrollo del producto. Adems debe definirse el precio del producto y el esquema de licenciamiento. Sobre el contenido del producto, se sabe poco. Tendr una base de datos con informacin financiera que ser consultada por una aplicacin web de reporting. No existe nadie en PI que conozca con mucho detalle el mercado financiero. Es por eso que se ha decidido buscar un cliente real se asocie con PI y participe en el Proyecto. El objetivo es que el cliente brinde los requerimientos y reciba a cambio determinados beneficios para el uso del producto en su empresa finalizado el Proyecto. An no estn definidos estos beneficios.

Objetivo
Identifique los roles necesarios para el Proyecto, diagramando la estructura del equipo de trabajo.

1.6 Diseo de Equipo de Trabajo para el Proyecto Comisiones II


Escenario
Dos compaas de seguros han resuelto fusionarse, por lo que necesitan unificar los sistemas de Comisiones de sus agentes de venta. Han solicitado a varios de sus proveedores que presenten sus propuestas para este Proyecto. Actualmente PI no cuenta con muchos recursos disponibles por estar trabajando en varios Proyectos, pero dado que tiene inters en el tema, decidi evaluar distintas alternativas para presentar la ms conveniente.

Objetivo
Disee 5 posibilidades de equipo de trabajo que tengan entre 2 y 3 recursos (los nicos disponibles son Juan, Pedro y Mara) cubriendo los 5 roles enumerados. En cada posibilidad identifique puntos a favor y riesgos. Marque la alternativa recomendada para presentar como propuesta. Equipo 1 Project Leader Analista QC (Anlisis) Desarrollo QC (Desarrollo) Juan Pedro Mara Puntos a Favor Riesgos e inconvenientes

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 16 de 61

Equipo 2 Project Leader Analista QC (Anlisis) Desarrollo QC (Desarrollo) Equipo 3 Project Leader Analista QC (Anlisis) Desarrollo QC (Desarrollo) Equipo 4 Project Leader Analista QC (Anlisis) Desarrollo QC (Desarrollo) Equipo 5 Project Leader Analista QC (Anlisis)

Juan

Pedro

Mara

Puntos a Favor

Riesgos e inconvenientes

Juan

Pedro

Mara

Puntos a Favor

Riesgos e inconvenientes

Juan

Pedro

Mara

Puntos a Favor

Riesgos e inconvenientes

Juan

Pedro

Mara

Puntos a Favor

Riesgos e inconvenientes

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 17 de 61

Desarrollo QC (Desarrollo)

1.7 Diseo de Equipo de Trabajo para el Proyecto Certificacin ISO


Escenario
La Organizacin SOLUCIONES IT S.R.L. est interesada en realizar una certificacin de Calidad, y se decidi por la Norma ISO 9001:2000. La fecha clave a cumplir es 01/12/2007. La Organizacin requiere certificar el 21/12/2007. Los Gerentes necesitan este proyecto para estar a la altura de sus competidores, adems estn interesados en definir los procesos que se requieran y la definicin e implementacin de un Sistema de Gestin de Calidad en su Organizacin. SOLUCIONES IT S.R.L. se dedica a proyectos de desarrollo, mantenimiento, Quality Control y Consutora (mejora de procesos, etc.) En la Organizacin existen Administradores de Cuentas de Clientes, Responsables de Ventas, Project Leaders, Responsables de Tecnologa, Consultores, y en el Centro de Desarrollo hay Analistas, Desarrolladores y Testers. Existe personal administrativo que se dedica a la administracin de los recursos de SOLUCIONES IT S.R.L., as como tambin a la facturacin y cobros a Clientes y pagos a Proveedores. La Gerencia est muy interesada en que se instaure en la Organizacin el nuevo Sistema de Calidad. La Organizacin tiene que seguir con los Proyectos en curso y a su vez se requerir un esfuerzo adicional del personal para trabajar en este Proyecto. Joaqun es un Consultor, l tendr a cargo la coordinacin y la confeccin de los procesos. La Gerencia est muy preocupada por lograr el consenso de todas las personas que conforman SOLUCIONES IT S.R.L. Para brindar apoyo a Joaqun se va a seleccionar y contratar un especialista en la Norma ISO 9001:2000. El xito del proyecto se mide en tener la certificacin en ISO el 21/12/2007.

Objetivo:
Se pide que disee un equipo de trabajo para poder dar solucin a la problemtica de SOLUCIONES IT S.R.L. 1. 2. Ayuda: Tenga en cuenta: Estos conceptos: Diagrama de una Organizacin IT, Administracin de Proyectos, Administracin de Riesgos, Administracin de Cambios, Administracin de Configuracin. El proceso de ventas, proceso de gestin de calidad, proceso de produccin, etc. El criterio definido para identificar el resto de los procesos. Seleccione la forma de representar el equipo de trabajo, tiene que ser la ms eficiente. Justifique su eleccin. Diagrame el equipo de trabajo, indicando: roles, responsables y funciones de los roles.

1.8 Diseo de Equipo de Trabajo para el Proyecto Cine & Video


Escenario
El mismo escenario de WBS para el Proyecto Cine & Video.

Objetivo
Agosto/2007 (versin 9.0) Administracin y Control de Proyectos I Pgina 18 de 61

Identifique los roles necesarios para el Proyecto, diagramando la estructura del equipo de trabajo. Describa brevemente las responsabilidades de cada uno. Identifique riesgos principales del equipo planteado.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 19 de 61

2 Etapa 1: Inicio (Alcance) 2.1 WBS para el Proyecto APPITEL 2.0


Escenario
CIRCULO SA ha decidido renovar su aplicacin de Atencin de Pedidos Telefnicos en dos meses y medio. El Proyecto ya arranc esta semana y los analistas de PI (la consultora que har el anlisis y el diseo) acaban de tener una reunin con los usuarios principales. A continuacin se reproduce la entrevista realizada: Analista (PI): por qu quieren re-escribir el sistema? Representante de IT (CIRCULO): porque est hecho con tecnologa obsoleta y nos resulta muy caro cada cambio que queremos hacer. Analista (PI): podra describirnos la funcionalidad del sistema a grandes rasgos? Usuario (CIRCULO): es un sistema para tomar pedidos telefnicos. Los clientes llaman, se dan de alta, hacen su pedido, informan el mtodo de pago, el horario y domicilio de entrega y all termina. Representante de IT (CIRCULO): hoy el sistema trabaja con una base local de artculos y clientes. La base de artculos requiere actualizacin manual. Queremos que se actualice automticamente desde nuestro servidor central. Analista (PI): y los clientes? Representante de IT (CIRCULO): lo mismo, queremos centralizarlos porque en el servidor central tienen una codificacin distinta. Esta seccin la desarrollar CEREBE. Usuario (CIRCULO): si, eso es muy importante, porque queremos cruzar la informacin de clientes que compran por distintas bocas de expendio. Es importante para ofrecer un servicio ms personalizado. Analista (PI): Qu otra funcionalidad tiene la aplicacin? Usuario (CIRCULO): nada ms, pero tenemos una lista importante de requerimientos. Por ejemplo queremos que se puedan modificar los pedidos cuando el cliente se haya equivocado y se entere un rato despus y llame nuevamente. Representante de IT (CIRCULO): tiene algunos reportes que desarrollamos nosotros. Analista (PI): Qu tipo de reportes? Representante de IT (CIRCULO): Por Locales, Por Vendedores (telemarketers). Usuario (CIRCULO): productos ms vendidos. Analista (PI): Cuntos reportes? Representante de IT (CIRCULO): 20. Usuario (CIRCULO): S, pero no los usamos. Slo usamos los dos de locales, tres de telemarketers y uno de productos. Necesitamos un par ms de Productos. Uno que agrupe por Familia y otro que agrupe por Fabricante. Analista (PI): Cules son los otros requerimientos que mencionaba? Usuario (CIRCULO): Te leo la lista que me pasaron los otros usuarios: 1. Que cuando se cuelgue la mquina no tengamos que cargar todo el pedido de nuevo. 2. 3. 4. 5. 6. 7. Que podamos buscar clientes por otros datos adems del telfono: Domicilio, nombre, DNI, Cdula, etc. Poder ver rpidamente cules son los productos que estn de oferta. Tener los precios de los productos actualizados. Poder modificar los pedidos y volverlos a enviar. Saber qu tipo de cliente est llamando. Me dijeron que se puede obtener este dato analizando la base central de pedidos de todos los locales. Bsqueda de artculos por categoras. A veces el cliente quiere buscar el mejor precio en

gaseosas, no importa la marca. Representante de IT (CIRCULO): te aclaro una cosa. Los pedidos tienen un promedio de 200 artculos. La carga de artculos tiene que se muy veloz para que los telemarketers sean productivos.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 20 de 61

Nada de mouse. Nada de buscar artculos en la base centralizada. Los tenemos que importan desde el central, pero deben residir localmente porque si no es muy lento. Usuario (CIRCULO): sigo 8. 9. Que permita pagar con pesos y tickets. Que permita modificar los datos del cliente.

Representante de IT (CIRCULO): tiene que tener seguridad integrada con Windows. Hoy no la tiene. Analista (PI): existen distintos perfiles de usuarios?. Representante de IT (CIRCULO): no () Analista (PI): de acuerdo. El objetivo principal ser entonces re-escribir todo el sistema. Luego, si estn de acuerdo, priorizaremos los nuevos requerimientos. () Analista (PI): muchas gracias a todos.

Objetivo
Se pide que usted disee la WBS del Proyecto. Debe incluir: Diagrama WBS. Debe involucrar todo el producto a construir y las actividades generales del Proyecto. Tenga en cuenta que el Proyecto arranca con el anlisis y termina con la instalacin en el Call Center habiendo reemplazado la versin anterior. Identifique un responsable de cada bloque de la WBS teniendo en cuenta el equipo de trabajo que arm en el ejercicio Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0 Efecte una propuesta de prioridades para las funcionalidades nuevas.

2.2 Versiones y Entregas Incrementales para el Proyecto APPITEL 2.0


Escenario
El mismo escenario de WBS para el Proyecto APPITEL 2.0.

Objetivo
Se pide que disee el plan de versiones y plan de entregas incrementales de la versin 1: Plan de Versiones: incluir por cada versin o o Alcance: qu incluye Objetivo principal de esa versin desde el punto de vista del usuario

Plan de Entregas: incluir por cada entrega: o Versin o o Contenido Objetivo de la entrega / Motivo del orden en que se ubica dicha entrega

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 21 de 61

2.3 Planificacin de Recursos para el Proyecto APPITEL 1.0


Escenario
CIRCULO SA ha decidido crear un sistema de Atencin de Pedidos Telefnicos en tres meses. Es un servicio nuevo para los clientes de CIRCULO. El objetivo es construir el producto en un mximo de 3 meses. Luego hay un perodo de 15 das planificado para la capacitacin e instalacin en produccin. Las campaas publicitarias ya estn lanzadas, motivo por el cual la fecha es inamovible. Es importante tomar todos los recaudos necesarios para que no haya ni una hora de retraso. CIRCULO se encuentra en etapa de Alcance y ya ha resuelto los siguientes pasos del proceso de planificacin: WBS (ver figura) Estimacin: 4 personas con diferentes perfiles estimaron las actividades principales: administracin del Proyecto, anlisis y diseo, desarrollo y prueba. Esto permite tener una primera estimacin construida por perfiles que conocen el tipo de trabajo a realizar (ver tabla) Hiptesis: Calendario requerido por el negocio: 3 meses. Alcance: el calendario a construir slo incluye la etapa de construccin (anlisis, desarrollo y prueba). Incluir todo lo necesario para dejar un producto con cero defectos listo para liberar. Mtricas: CIRCULO maneja mtricas histricas sobre los Proyectos. Las mismas arrojan la siguiente relacin entre roles para Proyectos de desarrollo de software: o Administracin y Seguimiento: 19% del esfuerzo en horas total o o Desarrollo: 40% del esfuerzo en horas total Anlisis y Diseo: 14% del esfuerzo en horas total

o Prueba: 27% del esfuerzo en horas total (incluye prueba del anlisis y el diseo) Mtodo de Trabajo: se requiere paralelismo entre tareas con el fin de integrar constantemente la solucin y acotar el calendario. Dicho de otra manera, comenzar a desarrollar cuando ya se tenga algo de diseo y probar desde el primer da.

Caractersticas de la estimacin: las estimacin ha sido realizada sin tener en cuenta restricciones de calendario o estructuras de equipo de trabajo. Las personas que hicieron la estimacin han asumido que las distintas tareas se harn con personal semi-senior.

Informacin disponible:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 22 de 61

Proyecto Pedidos Telefnicos

Construccin

Aceptacin

Puesta en Marcha

Cabecera de Pedido

Detalle del Pedido

Registro de Pago

Doc. de Usuario

Bsqueda de Cliente Alta de Cliente Modificacin de Cliente Seleccin de Local Seleccin de Banda Horaria

Bsqueda de Artculos ABM Lista de Artculos Bsqueda de Ofertas

Seleccin Forma de Pago Envo del Pedido

Manual de Usuario Manual de Instalacin

WBS

WBS 1

WBS 2

Jefe de Proyecto 30 25 12 25 30 50 87 37 12 57 5 4 375

Analista 24 20 10 20 24 40 70 30 10 46 4 3 301

Desarrollor 70 59 29 59 70 117 205 88 29 135 12 9 882

Bsqueda de cliente Alta de cliente Cabecera del Pedido Modificacin de cliente Seleccin de local Seleccin de banda horaria Bsqueda de artculos Detalle del Pedido ABM lista de artculos Bsqueda de ofertas Seleccin de forma de Pago Registro de Pago Envo del Pedido Manual de Usuario Documentacin de Usuario Manual de Instalacin Total
21% 17% Tester (aplicado a Anlisis)

Tester Tester (aplicado a (aplicado a Anlisis) desarrollo) 12 36 10 30 5 15 10 30 12 36 20 60 36 105 15 45 5 15 23 69 2 6 2 4 154 450

2.161

7%

14%

Tester (aplicado a desarrollo)

41% Jefe de Proyecto Analista Desarrollor Tester (aplicado a Anlisis) Tester (aplicado a desarrollo) Analista Desarrollor

50

100

150

200

250

300

350

200

400

600

800

1.000

Estimacin

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 23 de 61

Perfil Valor de Hora Project Leader Desarrollador Analista Tester Desarrollador Senior Analista Senior Tester Senior Tabla para clculo de costos

20 12 15 12 15 18 15

Objetivo
Definir: Equipo de Trabajo: estructura del equipo de trabajo, cantidad de personas por cada rol. Gantt de Recursos: mostrar en qu fecha del Proyecto se incorporan y se desvinculan los recursos. Identificar adems si tienen asignacin tiempo completo o tiempo parcial. Costo del Proyecto: de Recursos Humanos solamente. Se requiere un anlisis para fundamentar las diferencias entre el costo que se obtiene directamente de la estimacin versus el costo final que obtiene luego de disear el equipo de trabajo.

2.4 Propuesta para el Proyecto Help Desk


Escenario
La empresa BPF ha decido encarar un Proyecto para la construccin de una herramienta de Help Desk de uso interno. Es por ello que le ha pedido a PI S.A. que cotice este Proyecto. PI cuenta con el siguiente material para realizar la estimacin: Objetivo del Proyecto: documento adjunto generado por BPF Minuta de reunin de Relevamiento: PI ha realizado una reunin para obtener un poco ms de detalle con el fin de hacer una estimacin ms acertada. BPF necesita la propuesta para la semana prxima y parece difcil conseguir alguna otra reunin.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 24 de 61

Herramienta de Help Desk


BPF SA ha encarado un proceso de mejora interna dentro de la Gerencia de IT. Una de las mejoras a encarar es la unificacin del Help Desk. Actualmente recibimos llamados y pedidos por 5 canales: pedidos de hardware al rea de soporte, pedidos al rea de control de calidad, pedidos al rea de operaciones, pedidos directos a nuestros programadores y pedidos a la secretaria del gerente. En lneas generales, podemos decir que bsicamente se tratan de llamados por Software y por Hardware. La mejora que estamos encarando es crear un nico Help Desk que reciba todos los llamados y resuelva alguno de los problemas directamente. Si no los puede resolver, debe derivar el problema, pero es responsable de seguirlo hasta que se cierre y finalmente se le enve la respuesta al cliente interno. Para ello necesitamos una herramienta de Help Desk. La Gerencia ha decidido no adquirir ninguna por los elevados costos del mercado. Por el contrario, BPF desarrollar su propia herramienta especialmente adaptada a sus necesidades. El desarrollo podr ser encarado en etapas. Bsicamente debemos soportar de entrada el registro de los pedidos hasta que finalmente podamos hacer un anlisis estadstico y desarrollar nuestro SLA (acuerdo de nivel de servicio). Ms detalle: registro de incidentes, derivacin, administracin de estados, alarmas, etc.

Ing. Oscar Lpez Jefe de Soporte Tecnolgico Oscar.Lopez@bpf.com.ar BPF S.A.


Beneficios para la Farmacia

BPF

Objetivo del Proyecto

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 25 de 61

Herramienta de Help Desk


Fecha: 28/09/2003 Hora: de 10:30 a 11:30 Alcance: El cliente no tiene requerimientos claros. Desea que la herramienta cumpla las funcionalidades bsicas de cualquier herramienta de Help Desk. Nos ha pedido que incluyamos en la herramientas funcionalidades tpicas, pero l no las conoce. Nos ha pedido que investiguemos sobre el tema. Sin embargo ha recalcado las siguientes requerimientos: o Posibilidad de derivar incidentes cuando el Help Desk no puede resolverlos o o o o o Posibilidad de Anlisis estadstico histrico de incidentes Alarmas para los operadores de Help Desk Escritorio de incidentes que permita filtrar y priorizar de diferentes maneras Reportes e indicadores estndar Impresin de informes de tickets para el rea de soporte tcnico. El objetivo es que cada persona de soporte tenga su lista de tickets a atender en el da.

Ha aclarado que no est interesado en una base de conocimientos, al menos en una primera etapa.

Arquitectura: Puede ser Web o cliente Servidor Debe ser Red Windows Base de Datos Oracle o SQL Server. El cliente trabaja con las dos. Deseable arquitectura .NET sobre Windows 2003 y SQL Server 2000

Tiempos: No manifest un pedido especfico, pero le gustara que est operativa en Marzo de 2004.

Varios: La herramienta debe tener manuales Puede liberarse en etapas, pero debe cotizarse el Proyecto completo

Minuta de Reunin de Relevamiento

Objetivo
Definir: WBS: WBS del Proyecto. Este material ser presentado en la propuesta para marcar los lmites del Proyecto. Estimacin: planilla de estimacin en horas discriminada por rol y WBS. Es de uso interno. Las planillas de estimacin de PI poseen habitualmente el ltimo nivel de la WBS como fila y los distintos roles como columna. La estimacin se hace en horas hombre. Cotizacin: precio del Proyecto obtenido de la estimacin y otros gastos. El hardware y software de base no se incluye en la propuesta. Calendario: calendario de alto nivel del Proyecto a ser presentado en la propuesta. Debe incluir hitos y tareas principales. Hitos Facturables: identificacin de Hitos Facturables del Proyecto. Comnmente, PI factura cada 3 o 4 semanas.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 26 de 61

Equipo de Trabajo: definicin de roles a intervenir en el Proyecto por parte del cliente (BPF) y por parte de PI.

El resto de los puntos necesarios para la propuesta se completarn posteriormente, luego de cerrar los puntos mencionados.

2.5 Riesgos para el Proyecto Help Desk


Escenario
El mismo escenario de Propuesta para el Proyecto Help Desk.

Objetivo
Realizar el anlisis inicial de riesgos incluyendo exposicin, responsable, tratamiento y contingencia de cada uno. Cuantificar los riesgos que correspondan. Corregir la propuesta de acuerdo a este anlisis de riesgos.

2.6 Alcance para el Proyecto Help Desk


Escenario
El mismo escenario de Propuesta para el Proyecto Help Desk.

Objetivo
Completar el ejercicio Propuesta para el Proyecto Help Desk con el objetivo de generar el documento de Alcance del Proyecto. Agregar: Objetivo del Sistema: qu resuelve, cul es su funcin. Alcance del Sistema: qu incluye y qu no incluye. Organizacin Usuaria: quines sern los usuarios del sistema. Identificacin de Requerimientos: funcionales y no funcionales con prioridades. Contexto del Sistema: contexto del sistema con el exterior: Sectores, Usuarios, Sistemas y Entidades. Utilizar herramientas tipo Diagrama de Contexto, Casos de Uso de Alto nivel, etc. Segn crea conveniente. Principales entidades de informacin: modelo de datos o identificacin de entidades de alto nivel. Alternativas de Solucin: descripcin y comparacin de alternativas de solucin, identificando: o o Visin Funcional Visin Tcnica

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 27 de 61

2.7 Planificacin de Recursos para el Proyecto CPP 1.0


Escenario
PI ha encarado un Proyecto para la construccin de una herramienta de Control de Proyectos, CPP 1.0. Cuenta con una estimacin preliminar que no tiene en cuenta calendario ni skills del equipo de trabajo:

Entrega Incremental Creacin de WBS 1 Estimacin de HH en WBS 2 Carga de HH Reales Informe de % de avance en WBS Reporte Presupuestado vs Real 3 Reporte Earned Value ABM Recursos 4 ABM Valor de HH por Recurso

Analista 100 100 80 40

Desarrollador 600 600 480 240

Tester 300 300 240 120

Project Leader 200 200 160 80

Total 1.200 1.200 960 480 3.840

Hiptesis y Restricciones:

Se desea implementar entregas incrementales Se desea implementar Build Diario Se desea una etapa inicial de Alcance No incluye Deployment Se desea un calendario de 5 o 6 meses aproximadamente

Objetivo
Calcular el valor de horas final teniendo en cuenta la estructura de equipo de trabajo a utilizar, el calendario del Proyecto y la optimizacin del uso de recursos. Aclare en cada caso si utiliza recursos seniors o juniors.
Skill Mes 1 Q1 Q2 Mes 2 Q3 Q4 Mes 3 Q5 Q6 Mes 4 Q7 Q8 Mes 5 Q9 Q10 Mes 6 Q11 Q12

2.8 WBS para el Proyecto Cine & Video


Escenario
Cine & Video S.A. (CV) ha contratado a PI para desarrollar un nuevo sistema. El objetivo es comenzar a ofrecer nuevos servicios a sus clientes luego de la fusin de Video Global y Cinematic que dio como origen la empresa CV. Actualmente ambas empresas cuentan con sistemas propios de venta en los 10 complejos de cine de Cinematic y los 40 locales de Video Global, distribuidos en Capital, Buenos Aires y Crdoba. La direccin de CV ha creado la nueva tarjeta CV Plus, que permitir a los clientes obtener puntos que podrn canjear por premios: ofertas especiales y descuentos. La CV Plus identifica unvocamente al cliente,

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 28 de 61

permitiendo que el sistema haga sugerencias especialmente orientada a l. Es parte de una estrategia de segmentacin de clientes. El sistema de los Video Clubes se reconstruir por completo. El sistema de los cines ser modificado slo en las funcionalidades que sean necesarias. Ambos sistemas debern tener lectores pticos para leer el cdigo de barras de la CV Plus y reconocer automticamente al cliente. La CV Plus se obtendr al hacerse socio del Video Club. Los clientes deben poder ser reconocidos en todos los locales de cine y de video. Los sistemas trabajarn con BD locales que se actualizarn todas las noches con las novedades de los clientes. Para este proceso se contar con una BD de datos central. Las sucursales envan la informacin a la central y reciben luego la actualizacin. Mensualmente, cada cliente recibir en su domicilio un resumen de cuenta con el detalle de gastos, detalle de puntos acumulados y puntos usados, y posibles canjes (por ofertas de alquileres, ofertas de entradas o descuentos). El resumen indica adems propuestas orientadas al cliente: Preferencias de actores: si vio 3 veces pelculas del mismo actor, ofrece las novedades en cine y

video relacionadas. Preferencias por continuaciones. Por ejemplo, si el cliente alquil Matrix alguna vez, se le informa la fecha de estreno en cine de Matrix Revoluciones.

El sistema del Video Club deber adems realizar todas sus funciones habituales: registro del pedido, emisin del ticket de venta, actualizacin de stock local de la sucursal luego de la venta. Se desea agregar la posibilidad de leer (con un lector ptico) las devoluciones de pelculas. Debe emitir adems un informe de devoluciones pendientes, con el telfono del cliente para hacer reclamos. El proceso de actualizacin diaria, adems de actualizar la informacin de clientes, actualiza la informacin de precios de alquileres (el mismo precio para todas las sucursales) y la informacin de Stock: el ABM de pelculas de cada sucursal se maneja en forma centralizada tomando los datos de una interfaz del Sistema de Compras. Los datos de precios se manejan con una pantalla en la central que permite asignar precios. El desarrollo de esta interfaz deber tener en cuenta asignaciones mltiples de precios:

Todas las pelculas nuevas, estrenadas en determinada fecha Todas las pelculas viejas, anteriores a una fecha.

Asignaciones individuales. Aqu se cargan las ofertas y los descuentos por uso de puntos. Se debe permitir adems una pantalla simple que indique porcentaje de descuentos para una determinada

cantidad de puntos para las entradas de cine. Los precios de las entradas se manejan en el actual sistema de Cinematic, pero debe permitir asignar los descuentos que surjan de los puntos que posee el cliente. Nota: si el cliente olvid su tarjeta, el sistema debe permitir reconocimiento por DNI, telfono o nombre. Para acceder a las ofertas, debe presentar el DNI o la cdula. Nota sobre la infraestructura: no habr cambios en la infraestructura de las sucursales, salvo por la adquisicin de los lectores pticos. El servidor central ser reemplazado por uno nuevo.

Objetivo

Construya la WBS del Proyecto Por cada tem de la WBS asigne responsable y una descripcin. Considere que la WBS debe permitir hacer una estimacin

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 29 de 61

2.9 Entregas Incrementales para el Proyecto Cine & Video


Escenario
El mismo escenario de WBS para el Proyecto Cine & Video.

Objetivo
Asumiendo que el Proyecto tendr una duracin de 7 meses (implementacin incluida), defina las entregas incrementales, determinando el contenido de cada una y justificando el motivo de la entrega.

2.10 WBS para el Proyecto DRUG 1


Escenario
El mismo escenario de Diseo del Equipo de Trabajo para el Proyecto DRUG 1.

Objetivo

Construya la WBS del Proyecto Por cada tem de la WBS asigne responsable y una descripcin. Considere que la WBS debe permitir hacer una estimacin

2.11 Planificacin de Recursos para el Proyecto ALFA


Escenario
Su empresa, WSD, ha sido contratada para un desarrollo del Proyecto ALFA, por SPAZIO Argentina, una subsidiaria de la multinacional SPAZIO, proveedora de servicios y productos de hardware y software. El contrato es para el desarrollo de tres aplicaciones que utilizan distintos lenguajes de programacin. WSD no cuenta con desarrolladores que conozcan ms de un lenguaje de programacin. Usted debe definir el equipo de trabajo necesario para realizar el trabajo, teniendo en cuenta la siguiente lista de restricciones: a. b. El anlisis y diseo est siendo realizado por SPAZIO Argentina y estar completo para el momento en que comiencen los desarrollos: principios de Julio de 2004 La empresa DIM realizar el QC, el cual se divide en tres etapas: A. Prueba en paralelo mientras dure el desarrollo B. C. c. Estabilizacin de cada una de las aplicaciones Pruebas de integracin entres todas las aplicaciones (las 3 desarrolladas por WSD y otras

desarrolladas por otras consultoras) Todos los desarrollos debern terminar a ms tardar a fines de enero de 2005 debido a: A. Febrero est reservado como perodo de estabilizacin de cada una de las aplicaciones y se considera que el cdigo de las mismas est completo

d. e.

B. Marzo y Abril estn reservados para las pruebas de integracin WSD deber proveer recursos para el desarrollo de las aplicaciones y para las correcciones de defectos durante los perodos de estabilizacin y prueba integral Existen algunas restricciones de calendario preexistentes; A. Las aplicaciones 2 y 3 no pueden arrancar hasta principios de Octubre de 2004 por un tema de dependencias

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 30 de 61

B. f.

La aplicacin 1 debe terminar a ms tardar a fines de Noviembre de 2004 por un tema de

dependencias Personal de WSD ha realizado una estimacin atmica, que no considera estructura de equipo de trabajo, temas de calendario, etc. El resultado de esta estimacin es: A. Aplicacin 1: 2.500 horas B. C. D. E. F. Aplicacin 2: 2.500 horas Aplicacin 3: 3.000 horas Total: 8.000 horas Estas estimaciones no incluyen los tiempos de correccin de defectos para las etapas de estabilizacin y prueba de integracin Incluyen tiempos de correcciones de defectos durante la etapa inicial en que DIM realiza

las pruebas en paralelo con el desarrollo En su empresa se calcula el esfuerzo de administracin y seguimiento como un 20 % del esfuerzo total del Proyecto.

Objetivo
Calcular el valor de horas final y definir la estructura de equipo de trabajo que participar en el Proyecto. Asignacin de recursos

Rol / Nivel

2004 Jul Ago Set Oct Nov Dic Ene

2005 Feb Mar Abr

2.12 Planificacin de Recursos para el Proyecto Comisiones


Escenario
Su empresa, PI, ha sido contratada para el desarrollo de una aplicacin de software que calcular las comisiones a pagar a los vendedores de una compaa. Usted debe definir el equipo necesario para realizar el trabajo y as poder costear el Proyecto. La estimacin inicial de tareas es la siguiente: Mdulo 1: 400 HH de desarrollo, 200 de QC, 100 de anlisis Mdulo 2: 400 HH de desarrollo, 200 de QC, 100 de anlisis Administracin y seguimiento: 280 HH

Objetivo
Genere dos equipos de trabajo de acuerdo a estas alternativas, utilizando hiptesis y justificaciones: A) Minimizando el calendario Asignacin de recursos

Rol / Nivel

Meses Ene Feb Mar Abr May Jun Jul Ago Sep Oct

B)

Minimizando la cantidad de recursos

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 31 de 61

Asignacin de recursos

Rol / Nivel

Meses Ene Feb Mar Abr May Jun Jul Ago Sep Oct

2.13 WBS para el Proyecto BETA


Escenario
El mismo escenario de Diseo del Equipo de Trabajo para el Proyecto BETA.

Objetivo
Construya la WBS identificando el rol responsable de cada tem.

2.14 Planificacin de recursos para el Proyecto 25 de Mayo Delivery


Escenario
La librera mayorista 25 de Mayo ha contratado a su empresa, PI, para construir un software para la administracin de los pedidos telefnicos de sus clientes. Ya se realiz una estimacin inicial, donde se defini la WBS y el esfuerzo de cada rol necesario para llevar a cabo el Proyecto. Hiptesis: No se incluye instalacin en produccin de la aplicacin.

WBS 1

WBS 2

Jefe de Proyecto 30 25 12 25 30 50 87 37 12 57 5 4 375

Analista 24 20 10 20 24 40 70 30 10 46 4 3 301

Desarrollor 70 59 29 59 70 117 205 88 29 135 12 9 882

Bsqueda de cliente Alta de cliente Cabecera del Pedido Modificacin de cliente Seleccin de local Seleccin de banda horaria Bsqueda de artculos Detalle del Pedido ABM lista de artculos Bsqueda de ofertas Seleccin de forma de Pago Registro de Pago Envo del Pedido Manual de Usuario Documentacin de Usuario Manual de Instalacin Total
21% 17% Tester (aplicado a Anlisis)

Tester Tester (aplicado a (aplicado a Anlisis) desarrollo) 12 36 10 30 5 15 10 30 12 36 20 60 36 105 15 45 5 15 23 69 2 6 2 4 154 450

2.161

7%

14%

Tester (aplicado a desarrollo)

41% Jefe de Proyecto Analista Desarrollor Tester (aplicado a Anlisis) Tester (aplicado a desarrollo) Analista Desarrollor

50

100

150

200

250

300

350

200

400

600

800

1.000

Estimacin

Objetivo
Agosto/2007 (versin 9.0) Administracin y Control de Proyectos I Pgina 32 de 61

Efecte una planificacin de recursos cuyo objetivo sea minimizar el equipo de trabajo, logrando la menor cantidad posible de personas asignadas al Proyecto.

2.15 WBS para el Proyecto K


Escenario
CIRCULO SA ha decidido cambiar su sistema central de Facturacin y Contabilidad FOCUS por el sistema PARKING. Esta es una decisin corporativa, y por razones legales, el nuevo sistema PARKING debe estar en produccin dentro de 4 meses. La fecha es inamovible, el incumplimiento de la misma generara una multa impensable para CIRCULO SA. PI ha sido contratada por CIRCULO SA para que construya el SISTEMA K, cuyo objetivo es integrar la informacin de pagos proveniente de 7 aplicaciones y generar una nica salida que registre dichos pagos en el nuevo sistema PARKING. El Proyecto K incluye la construccin de los siguientes mdulos: Construccin del Sistema K que incluye: o Un mdulo de procesamiento para cada una de las 7 aplicaciones origen o Un mdulo para generar la salida para PARKING o Un mdulo de monitoreo en lnea del procesamiento o Un mdulo de reprocesamiento o Un mdulo de auditoria Extraccin: modificacin de las 7 aplicaciones origen para que puedan generar la informacin de pagos en el formato definido por el Sistema K El Proyecto K no incluye la construccin de los siguientes mdulos: Carga: Construccin del proceso que tome la salida del Sistema K para cargarla en el sistema PARKING. Este mdulo ser construido por SPAZIO, empresa que tiene a cargo todos los desarrollos sobre el Sistema PARKING.

Aplicacin Origen 1

Extraccin

Archivo

Proc. 1

(...)
Aplicacin Origen 7

Sistema K
Extraccin
Archivo

Archivo

Carga

PARKING

Proc. 7

PI

SPAZIO

Marcelo, el Jefe de Desarrollo de CIRCULO SA, ha contratado a PI para el Proyecto K, Proyecto que se integra dentro del Proyecto PARKING. Debido a que se trata de un sistema de integracin, no intervendrn usuarios finales, pero participar personal del rea de desarrollo de CIRCULO SA para ayudar a entender los requerimientos y las caractersticas de las 7 aplicaciones. El personal de CIRCULO SA no tiene conocimiento sobre PARKING, pero SPAZIO proveer toda la informacin que PI necesite. Para el Sistema K se utilizar tecnologa nueva, no usada antes en CIRCULO SA. Es por eso que intervendr en el Proyecto el Jefe de Infraestructura de CIRCULO y personal de su rea. El calendario del Proyecto K deber integrarse dentro del calendario del Proyecto PARKING. Este calendario es controlado por la Oficina de Proyectos de CIRCULO, rea de una gerencia distinta a la de Marcelo. Algunas fechas a tener en cuenta: Al finalizar el mes 4 se instalar en Produccin el Sistema K con las extraccin de las aplicaciones 1, 2 y 3 PI debe liberar al finalizar el mes 3 el Sistema K junto con las modificaciones a las aplicaciones 1, 2 y 3, ya que durante el mes 4 se har una prueba integral coordinada por la Oficina de Proyectos Al finalizar el mes 7 se instalar en Produccin el Sistema K con las extraccin de las aplicaciones 4, 5, 6 y 7 PI debe liberar al finalizar el mes 6 las modificaciones a las aplicaciones 4, 5, 6 y 7, ya que durante el mes 7 se har una prueba integral coordinada por la Oficina de Proyectos PI ha asignado a las siguientes personas al Proyecto:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 33 de 61

Antonio: desarrollador y arquitecto senior de mucha experiencia (part time) Lorena: analista desarrolladora senior (full time) Juan: desarrollador semi-senior (full time) Carlos: tester senior de mucha experiencia (2 horas por da) Pedro: tester junior (full time)

El estado actual del Proyecto es no iniciado. Slo se ha escrito el alcance. Debe iniciarse la etapa de anlisis y de arquitectura global del Sistema K. PI no controla a SPAZIO. El alcance de PI incluye slo el Sistema K, aunque obviamente debe relacionarse con el resto de los involucrados.

Objetivo:
Disee la WBS para el Proyecto K, identificando responsables para cada tem.

2.16 WBS para el Proyecto Certificacin ISO


Escenario
El mismo escenario de Diseo del Equipo de Trabajo para el Proyecto Certificacin ISO.

Objetivo
Construya la WBS identificando el rol responsable de cada tem.

2.17 Planificacin de Recursos para el Proyecto Cine & Video


Escenario
El mismo escenario de WBS para el Proyecto Cine & Video.

Objetivo
Planificar la asignacin de recursos que participarn en el Proyecto.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 34 de 61

3 Etapa 2: Organizacin 3.1 Calendario Cliente / Distribucin de Presupuesto para el Proyecto APPITEL 1.0
Escenario
El mismo escenario de Estimacin de Recursos para el Proyecto APPITEL 1.0. Se toma como hiptesis que la resolucin del ejercicio Estimacin de Recursos para el Proyecto APPITEL 1.0 ha sido aprobada y por lo tanto constituye la restriccin de horas, calendario y equipo de trabajo para llevar adelante el Proyecto. El proveedor que asumir todas las tareas es PI.

Objetivo
El objetivo principal es construir un calendario de alto nivel entendible por el cliente. Se debe generar: Calendario Cliente:
o o o o o

Calendario de alto nivel con hitos principales del Proyecto. Deben figurar los tres meses del Proyecto (que abarcan desde el inicio hasta la etapa de construccin finalizada) Deben ser hitos que tengan validez para el usuario. No incluye hitos internos. Por cada hito incluir responsable del hito. Este calendario ser utilizado como control durante las reuniones en que se informe el

avance del Proyecto al cliente Plan de Entregas: el calendario deber contener entregas incrementales al cliente. Por cada una de ellas, usted deber presentar: o Nmero de entrega
o o
Hito

Contenido Objetivo de la entrega para el cliente


Responsable Responsable Responsable Responsable Fecha Mes 1 S2 S3 x x Mes 2 S3 Mes 3 S2

Hito 1 Hito 2 Hito 3 ...

S1 x

S4

S1

S2

S4

S5

S1

S3

Formato sugerido para el calendario

Para poder armar este calendario, usted deber distribuir el presupuesto de horas hombres obtenido en el ejercicio Estimacin de Recursos para el Proyecto APPITEL 1.0. Para ello deber generar para uso interno la siguiente planilla: Distribucin de Esfuerzo:
o o o

Tareas y Fechas Recursos asignados Presupuesto asignado a cada recurso

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 35 de 61

Tarea Tarea 1 Tarea 1 Tarea 1 Tarea 1 Tarea 2 Tarea 2 Tarea Tarea

Recurso Total Tarea Recurso 1 asignado Recurso 2 asignado Recurso Total Tarea Recurso Total Tarea Recurso

Mes 1 Semana 1 Semana 2 Semana 3 30 25 10 5 20 20

Mes Semana

Total 55 15 40

Formato sugerido para distribucin de esfuerzo

3.2 Calendario Cliente para el Proyecto DATATEL


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto DATATEL. Se toman como restricciones el equipo de trabajo, la cantidad de horas y el calendario del ejercicio Diseo
de Equipo de Trabajo para el Proyecto DATATEL.

Objetivo
El objetivo principal es construir un calendario de alto nivel entendible por el cliente. Se debe generar: Calendario Cliente:
o o o o o

Calendario de alto nivel con hitos principales del Proyecto. Deben figurar los dos meses y medio del Proyecto (que abarcan desde el inicio hasta el final, incluyendo instalacin en produccin del producto) Deben ser hitos que tengan validez para el usuario. No incluye hitos internos. Por cada hito incluir responsable. Este calendario ser utilizado como control durante las reuniones en que se informe el avance del Proyecto al cliente

Hiptesis adicionales a las del escenario: Hay tres entregas incrementales. Surgieron de la distribucin de presupuesto que hizo PI:
o o

1. Prototipo: semana 3 (no requiere ambiente de aceptacin) 2. Datawarehouse construido: semana 5

o 3. Procesos de extraccin y carga / Interfaces: semana 7 (requiere interfaces) El producto trabajar con un volumen importante. Se requieren pruebas de performance a cargo de

PI que debern reflejarse en el calendario. CIRCULO proveer datos de 1 ao para realizar las pruebas una vez que haya terminado de construir las interfaces.

Existe un equipo de aceptacin que hay que instalar y configurar. Se utilizar en los ambientes de CIRCULO y la instalacin estar a cargo de ellos. Se debe adquirir el equipo para produccin. Esto es responsabilidad de CIRCULO GLOBAL. La compra lleva 1 mes aproximadamente y requiere una estimacin de volumen previa y dimensionamiento del equipo El Proyecto comienza el 1/9/2003 y termina el 7/11/2003 con el producto instalado en produccin.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 36 de 61

Hito Hito 1 Hito 2 Hito 3 ...

Responsable Responsable Responsable Responsable

Fecha

Mes 1
S1 S2 S3 S4 S1 S2

Mes 2
S3 S4 S5 S1

Mes 3
S2 S3

x x x

Formato sugerido para el calendario

3.3 Calendario Cliente para el Proyecto APPITEL 2.0


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0. Se toman como restricciones el equipo de trabajo, la cantidad de horas y el calendario del ejercicio Diseo
de Equipo de Trabajo para el Proyecto APPITEL 2.0.

Objetivo
El objetivo principal de este ejercicio es construir un calendario de alto nivel entendible por el cliente. Se debe generar:

Calendario Cliente: o Calendario de alto nivel con hitos principales del Proyecto.
o o o o

Deben figurar los dos meses y medio del Proyecto (que abarcan desde el inicio hasta el final, incluyendo instalacin en produccin del producto) Deben ser hitos que tengan validez para el usuario. No incluye hitos internos. Por cada hito incluir responsable del hito. Este calendario ser utilizado como control durante las reuniones en que se informe el avance del Proyecto al cliente

Hiptesis adicionales a las del escenario:


Este Proyecto incluye slo la versin 1 segn se defini en la resolucin del ejercicio Versiones y Entregas Incrementales para el Proyecto APPITEL 2.0 Existe un equipo de aceptacin que hay que instalar y configurar. Se utilizar en los ambientes de CIRCULO y la instalacin estar a cargo de ellos. Para Produccin se utilizar el actual equipo del Call Center. La instalacin no es en paralelo, se baja la versin 1.0 e inmediatamente despus se habilita la versin 2.0 El Proyecto comienza el 1/9/2003 y termina el 7/11/2003 con el producto instalado en produccin.
Hito Responsable Responsable Responsable Responsable Fecha Mes 1
S1 S2 S3 S4 S1 S2

Mes 2
S3 S4 S5 S1

Mes 3
S2 S3

Hito 1 Hito 2 Hito 3 ...

x x x

Formato sugerido para el calendario

3.4 Calendario Build Diario para el Proyecto APPITEL 1.0


Escenario

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 37 de 61

El mismo escenario de Planificacin de Recursos para el Proyecto APPITEL 1.0. Tomar como base el calendario de cliente y la distribucin de esfuerzo del ejercicio Calendario Cliente / Distribucin de
Presupuesto para el Proyecto APPITEL 1.0.

Objetivo
Dado que el Proyecto trabajar con esquema de Build Diario (desarrollo y prueba en paralelo) se pide realizar un calendario detallado en donde se indiquen pequeos (mini) hitos asociados al proceso de Build Diario con el objetivo de cumplir con las entregas incrementales. El Calendario debe incluir: Hitos con su correspondiente fecha. Cada hito debe estar vinculado con una porcin de cdigo a ser liberada por un recurso. o Cada recurso no debera pasar ms de 3 das sin un hito
o

No se requieren hitos diarios. Habr build diario, pero no todos los das se entregar funcionalidad nueva. A veces slo se entregarn correcciones de defectos.

o No incluir en este calendario la etapa de anlisis. Recurso responsable del hito.

Fecha.
Fecha Recurso 1 01/01/03 02/01/03 Hito 1 03/01/03 04/01/03 Da por examen 05/01/03 06/01/03 07/01/03 08/01/03 09/01/03 10/01/03 11/01/03 12/01/03 13/01/03 14/01/03 15/01/03 16/01/03 17/01/03 18/01/03 19/01/03 Recurso 2 Recurso 3

Estabilizacin

Liberacin Entrega 1

Formato sugerido para calendario de Build Diario

3.5 Diseo de Indicador de Funcionalidad Completa para el Proyecto APPITEL 1.0


Escenario
El mismo escenario de Planificacin de Recursos para el Proyecto APPITEL 1.0. Tomar como base el calendario de build diario del ejercicio Calendario Build Diario para el Proyecto APPITEL 1.0.

Objetivo
Se decide implementar un indicador que permita medir objetivamente el avance del Proyecto. Se utilizar un indicador del tipo funcionalidad completa. Se pide:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 38 de 61

1.

Indicador de Funcionalidad Completa: construya el indicador a travs de los siguientes pasos: Dividir al producto en partes. Estas partes podran ser las porciones de cdigo incluidas en el

calendario de Build Diario. Poner un peso a cada una de esas partes entre 1 y 3 de acuerdo a su complejidad. Estimar la fecha de liberacin de la funcionalidad por parte del equipo de desarrollo. Estimar la fecha de aprobacin de la funcionalidad por parte de QC Graficar el indicador con las fechas presupuestadas en donde: 1. El eje horizontal indique fechas 2. 3. El eje vertical indique puntos de funcionalidad acumulados. Los puntos de funcionalidad se obtienen de sumar la complejidad estimada a la fecha. Existan dos curvas: una de liberacin estimada de desarrollo y otra de liberacin estimada de QC. Ambas curvas deben llegar a la suma de puntos de funcionalidad.

45 40 35 30 25 20 15 10 5 0
m Se 1 Se m 2 m Se 3 Se m 4 Se m 5 m Se 6 Se m 7 m Se 8 Se m 9 m Se 10 m Se 11 m Se 12 m Se 13 m Se 14

FC Desa Estimado FC QC Estimado

Ejemplo de grfico de FC

2.

Anlisis preliminar del Indicador: analice el indicador con el objetivo de verificar si el calendario est correctamente armado.

Analice la separacin de las curvas y efecte correcciones Analice la pendiente de las curvas y efecte correcciones Analice otros puntos que considere convenientes Analice si este indicador le servir para controlar el Proyecto. Ventajas y desventajas.

3.

Comparacin entre FC y Esfuerzo: construya un grfico acumulado de esfuerzo y comprelo con el de funcionalidad entregada.

Grafique el esfuerzo acumulado en funcin del tiempo en donde: 1. El eje horizontal indique fechas 2. 3. 4. El eje vertical indique horas hombre acumuladas. Existan dos curvas: una de esfuerzo estimado de desarrollo y otra de esfuerzo estimado de QC. Mezcle este grfico con el anterior utilizando un eje secundario

4.

Analice Agregado de liberaciones al usuario en el grfico de FC: agrega las curvas de funcionalidad

liberada al usuario y aprobada por el usuario segn indica el calendario que arm para el Cliente Grafique las curvas nuevas

Analice
Administracin y Control de Proyectos I Pgina 39 de 61

Agosto/2007 (versin 9.0)

5.

Comparacin final con Esfuerzo total: analice finalmente las curvas principales de esfuerzo a lo largo del Proyecto Grafique el esfuerzo sin acumular en funcin del tiempo en donde: 1. 2. 3. El eje horizontal indique fechas El eje vertical indique horas hombre acumuladas. Existan cinco curvas: i. Administracin y Seguimiento ii. iii. iv. v. Anlisis Revisin de Anlisis Desarrollo QC

6.

Analice Analice para qu sirvi hacer todo esto

3.6 Calendario Build Diario e Indicador de FC para el Proyecto APPITEL 2.0


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0. Tomar como base el calendario de cliente del ejercicio Calendario Cliente para el Proyecto APPITEL 2.0.

Objetivo
Como se sabe PI ha tomado el liderazgo y el QC de este Proyecto. Se ha acordado al inicio del Proyecto trabajar con un esquema de build diario (desarrollo y prueba en paralelo). Se pide que PI cree un calendario detallado y un indicador de funcionalidad completa que le permita controlar el proceso de Build Diario y el cumplimiento de las entregas incrementales. Recuerde que PI no hace desarrollo en este Proyecto, hay tres proveedores involucrados. Por lo tanto PI no tiene control sobre las tareas individuales de los recursos de desarrollo. No podra hacer un calendario orientado a hitos de cada recurso de desarrollo. Por otro lado sabe que con el calendario de alto nivel orientado al cliente le ser imposible controlar el desarrollo y garantizar el cumplimiento en fecha de las entregas parciales. Teniendo en cuenta estas restricciones, construya el calendario y el indicador pedido.

3.7 WBS de Calidad para el Proyecto APPITEL 2.0


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0.

Objetivo
Construir la WBS del Proyecto orientado a los aspectos de aseguramiento de calidad del mismo. Se desea utilizar la herramienta WBS para identificar todo el trabajo que debe realizar el equipo de QC, tanto desde el punto de vista de pruebas funcionales como pruebas tcnicas.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 40 de 61

3.8 Plan de Proyecto para el Proyecto APPITEL 1.0


Escenario
El mismo escenario de Planificacin de Recursos para el Proyecto APPITEL 1.0.

Objetivo
Crear el documento de Plan de Proyecto para el Proyecto APPITEL 1.0 . Incluir:

Equipo de Trabajo: diagrama y responsabilidades Calendario: calendario y plan de entregas Costos: distribucin de costos Proceso: definicin del proceso que utilizar para construir el producto Plan de Calidad Plan de Comunicacin Proceso de Administracin de Cambios Proceso de Administracin de la Configuracin Proceso de Administracin de Riesgos Mtricas

Tip: un documento de este tipo ocupa entre 15 y 25 pginas aproximadamente.

3.9 Plan de Adm. de Cambios para el Proyecto APPITEL 2.0


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0.

Objetivo
Definir el Pan de Administracin de Cambios para el Proyecto APPITEL 2.0. Incluir:

Alcance: tems bajo control de cambios. Proceso: tareas, secuencia de tareas, roles, documentacin asociada. Responsables: asocie las personas del equipo de trabajo a las distintas tareas, indicando participantes, responsables y autoridad. Herramientas

Tenga en cuenta que el proceso debe estar preparado para ser utilizado en las distintas etapas del ciclo de vida, desde que se inicia el Proyecto hasta que finaliza la implementacin en produccin.

3.10 Plan de Calidad para el Proyecto APPITEL 2.0


Escenario

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 41 de 61

El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0.

Objetivo
Definir el Plan de Administracin de la Calidad para el Proyecto APPITEL 2.0. Incluir:

Alcance: qu incluye y qu no incluye el Proyecto. Tipos de prueba: funcional, tcnica, aceptacin, etc. Proceso: tareas, secuencia de tareas, roles, documentacin asociada. Responsables: asocie las personas del equipo de trabajo a las distintas tareas, indicando participantes y responsables Herramientas Ambientes / Pasajes de Ambientes Frecuencia de builds / Entrega de builds Criterios de Calidad Indicadores

Tenga en cuenta que el proceso debe estar preparado para ser utilizado en las distintas etapas del ciclo de vida, desde que se inicia el Proyecto hasta que finaliza la implementacin en produccin.

3.11 Calendario Cliente para el Proyecto Cine & Video


Escenario
El mismo escenario de Entregas incrementales para el Proyecto Cine & Video.

Objetivo
Construya un calendario orientado al Cliente que permita el seguimiento durante los 7 meses del Proyecto.

3.12 Calendario Build Diario para el Proyecto Cine & Video


Escenario
El mismo escenario de Entregas incrementales para el Proyecto Cine & Video. Usted se encuentra trabajando en la primera entrega incremental para el mdulo Video Club. Esta primera entrega del mdulo Video Club estar formada por:

tem Alta de Cliente

Descripcin Datos bsicos del cliente, domicilio y telfono, generacin automtica de un cdigo de barras que se pega en la tarjeta, informacin del servicio que present el cliente como garanta, datos que pueden servir para la segmentacin de clientes (edad, grupo familiar, sexo, barrio). Cantidad de tarjetas adicionales que solicita.

Reconocimiento del Cliente manual

Segn enunciado.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 42 de 61

Reconocimiento del Cliente ptico

Comunicacin (lectura) del dispositivo ptico, procesamiento del cdigo de barras para identificar el cliente en la base, apertura automtica de la pantalla de pedido con los datos del cliente reconocido. Modificacin adicionales Impresin del cdigo de barras en la cantidad de etiquetas solicitadas. Las etiquetas se pegan luego en una tarjeta de datos y posibilidad de pedir ms tarjetas

Modificacin de datos del Cliente Emisin de la CV Plus

Hiptesis:

El Anlisis y Diseo est completo Posee tres desarrolladores, un tester full time y un tester part time El modelo de datos para esta entrega no est creado. 1 mes de duracin desde el inicio de la construccin hasta la liberacin para aceptacin

Objetivo
Cree un calendario de tipo Build Diario para controlar esta primera entrega fundamentando los criterios utilizados.

3.13 Calendario Build Diario para el Proyecto ADP


Escenario
Usted el Lder del Proyecto de construccin de una herramienta para Administracin de Proyectos. La primera entrega incremental estar formada por las siguientes funcionalidades: tem Base de Datos Pantalla ABM Proyecto Pantalla Tareas Administracin de Descripcin Base de Datos para esta entrega: tablas Proyecto, Tarea, Recursos, Tipo de Tarea, Recursos x Tarea, Horas Cargadas Nombre, Descripcin, Fecha de Inicio y Fin Alta y Modificacin de Tareas de un Proyecto. Nombre, Descripcin, Fechas (*) de Inicio y Fin, Tipo de Tarea y Recursos (**) (*) Incluye validacin de que las fechas estn dentro de las fechas del Proyecto (**) Se pueden cargar varios recursos asociados a la tarea Pantalla Carga de Horas El Usuario carga una Fecha Luego elige un Proyecto y una Tarea y registra la cantidad de horas trabajadas (*). (*) Puede elegir varias combinaciones de Proyecto y Tarea para el mismo da. Nombre y Descripcin Nombre y Descripcin

Pantalla ABM Tipo de Tareas Pantalla ABM Recursos

Diseo de Pantalla Administracin de Tareas

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 43 de 61

Nombre: Descripcin:
Fecha: Proyecto / Tarea:
05/11/2004 Proyecto ALFA

Diseo Pantalla Carga de Horas

Anlisis

4,00

Eliminar Eliminar Eliminar

Proyecto ALFA
<seleccione>

Diseo
<seleccione>

5,00

Fecha Inicio: Fecha Fin: Tipo de Tarea: Recursos:

05/11/2004

Total:
Aceptar Cancelar

9,00

05/11/2004

<seleccione de la lista> Alejo Valentina


Eliminar

Eliminar Eliminar

Adolfo
<agregue un recurso>
Aceptar Cancelar

Objetivo
Cree un calendario de tipo Build Diario para controlar esta primera entrega fundamentando los criterios utilizados. Hiptesis: El Anlisis y Diseo est completo

Posee tres desarrolladores, un tester full time y un tester part time El modelo de datos para esta entrega no est creado, pero si est diseado. 3 semanas de duracin desde el inicio de la construccin hasta la liberacin para aceptacin

3.14 Calendario Cliente para el Proyecto BETA


Escenario
El mismo escenario de Equipo de Trabajo para el Proyecto BETA.

Objetivo
Construya un calendario orientado al Cliente que permita el seguimiento del Proyecto.

3.15 Versiones, Entregas Incrementales y Calendario Cliente para el Proyecto DRUG 1


Escenario
El mismo escenario de Equipo de Trabajo para el Proyecto DRUG 1.

Objetivo
Defina un plan de versiones y/o entregas incrementales, determinando el contenido de cada una y justificando el motivo de la entrega.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 44 de 61

Construya un calendario orientado al Cliente para presentar en la reunin de kick-off del Proyecto.

3.16 Calendario Cliente para el Proyecto K


Escenario:
El mismo escenario de WBS para el Proyecto K.

Objetivo:

Construya el calendario orientado al cliente para el Proyecto K. Este calendario ser utilizado para informar quincenalmente el avance a CIRCULO SA. Es importante que figuren los hitos externos, que aunque no sean responsabilidad de PI, impactan directamente en el Proyecto K. Enuncie qu acciones preventivas tomar para que el Proyecto finalice en fecha.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 45 de 61

4 Etapa 3: Ejecucin y Control 4.1 Anlisis de Indicadores para el Proyecto CE-EME


Escenario
La empresa ERMIA S.A. est construyendo un producto de software relacionado con una prctica de Project Management. Se trata de la primera versin del producto que ser instalada a modo de prueba en el cliente SANTE el 13 de diciembre de 2002. La etapa de construccin de esta primera versin se inici el 15 de octubre de 2002. Previamente hubo una etapa de anlisis y diseo global de 2 semanas aproximadamente. Hoy es 27 de noviembre y usted, Jefe del Proyecto CE-EME, est analizando los indicadores del Proyecto con el objetivo de entender como se encuentra posicionado para los prximos hitos. 29/11/2002: segunda liberacin para aceptacin por parte de usuarios. Dado que se trata de un producto masivo, ERMIA est utilizando representantes de usuarios. Gracias a que la herramienta ser utilizada internamente en ERMIA para sus Proyectos, algunos miembros de ERMIA estn actuando como representantes de usuarios. Ya hubo una primera aceptacin por parte de este equipo y esta ser la segunda entrega para aceptacin.

06/12/2002: siguiendo con el razonamiento anterior, en esta fecha se instalar una versin beta en ERMIA para que sea utilizada en ambiente productivo antes de la liberacin final. 13/12/2002: finalmente en esta fecha se liberar la primera versin comercial para instalar en SANTE. Esta fecha es inamovible porque se trata de un compromiso adquirido con SANTE.

Indicador de Funcionalidad Completa:


40 C d igo C om ple to P tos. E S T IM A D O S A cum ula d os C d igo C om ple to P tos. R E A L A cum ula d o F u n cio n alid ad libe rada P tos. E S T IM A D O S A cum ula d os F u n cio n alid ad libe rada P tos. R E A L A cum ula d o

35

30

25

20

15

10

1 51 020 02

171020 02

2 21 020 02

2 41 020 02

281020 02

301020 02

1/1 1/2 00 2

5/1 1/2 00 2

7 /1 1 /2 00 2

11 / 11 / 20 02

13 / 11 / 20 02

1 5/ 1 1/ 20 02

19 / 11 / 20 02

21 / 11 / 20 02

2 5/ 1 1/ 20 02

27 / 11 / 20 02

29/ 11/ 20 02

3 /1 2 /2 00 2

5 /1 2 /2 00 2

9 /1 2 /2 00 2

1 1/ 1 2/ 20 02

13 / 12 / 20 02
13-12 P roduccin 2

15-11 A ceptacin 1

29-11 A ceptacin 2

6-12 P roduccin 1

Indicador de FC del Proyecto CE-EME El Indicador de FC muestra 4 curvas:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 46 de 61

Cdigo Completo Puntos Estimados acumulados: liberacin planificada de funcionalidad por el equipo de desarrollo Cdigo Completo Puntos Reales acumulados: liberacin real de funcionalidad por el equipo de desarrollo Funcionalidad Liberada Puntos Estimados acumulados: liberacin planificada de

funcionalidad por el equipo de QC Funcionalidad Liberada Puntos Reales acumulados: liberacin real de funcionalidad por el equipo de QC

Indicador de Evolucin de la Prueba:

Evolucin de la Prueba
600 500 Total 400 300 200 100 0
1/ 10 8/ 10 15/ 10 22/ 1 29/ 1 5/ 11 12/ 11 19/ 11 26/ 11

Cerrado Pendiente Suspendido

Indicador de Evolucin de la Prueba del Proyecto CE-EME

Total
Promedio de Detectados por da Promedio de Cerrados por da Relacin Cerrados / Total 11,86 9,791 83%

Estado/Severidad Abierto Analizado Revisado Corregido Cerrado No Reproducible Suspendido Total

A 7 0 0 2 81 0 0 90

B 10 0 0 2 89 0 1 102

C 40 3 0 3 170 0 0 216

D 19 0 0 1 132 0 5 157

Total 76 3 0 8 472 0 6 565

ltimos diez das


Promedio de Detectados por da Promedio de Cerrados por da Relacin Cerrados / Total 8,7 8,1 93%

ltimos cinco das


Promedio de Detectados por da Promedio de Cerrados por da Relacin Cerrados / Total 9,2 10,4 113%

El Indicador de Evolucin de la Prueba muestra 4 curvas:


Total: cantidad total de defectos acumulada Cerrados: cantidad acumulada de defectos cerrados por el equipo de QC. Pendientes: cantidad acumulada de defectos pendientes (defectos abiertos sin corregir, corregidos sin revisar por QC, analizados por desarrollo, etc.). Suspendidos: defectos suspendidos que quedarn para la prxima versin.

Indicador de Cobertura de la Prueba:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 47 de 61

P lanificado s

Cobertura de la Prueba
Positivos
800 700 600 500

Evolucin de la Cobertura de la Prueba


Positivos
800 700 600 500

Dispo nibles Cumplido s Ejecutado s OK

400 300 200 100 0

400 300 200 1 00

Planificados (Activos) Disponibles Cumplidos (Ejecutados + Ejecutados Ok + Ejecutados Error) Ejecutados Ok

0
01/ 10/2002 08/ 10/2002 15/10/2002 22/ 10/2002 29/ 10/2002 05/ 11/2002 12/11/2002 19/11/2002 26/11/2002

Indicador de Cobertura de la Prueba del Proyecto CE-EME El Indicador de Cobertura de la Prueba muestra 4 valores: Planificados: cantidad de casos de prueba planificados a ejecutar

Disponibles: cantidad de casos de prueba disponibles. Son los casos de prueba que pueden ejecutarse ya que el equipo de desarrollo liber la funcionalidad a la que hacen referencia. Cumplidos: cantidad de casos de prueba ejecutados por el equipo de QC. Ejecutados OK: cantidad de casos de prueba ejecutados en los que no se detectaron defectos. Totales: cantidad de casos totales, incluye los planificados ms lo que an no se han escrito pero se estima se escribirn. No figura el valor en el grfico, pero se estiman alrededor de 1.100.

Objetivo
Se pide analizar los indicadores en relacin a los prximos objetivos del Proyecto identificados por los tres hitos pendientes. El anlisis debe incluir: Anlisis detallado de cada Indicador conteniendo:
o o o o

Qu se lee? Cules son las posibles causas? Cules son los posibles impactos? Cules son las posibles acciones correctivas?

Acciones correctivas o Identifique las acciones correctivas a ejecutar

4.2 Anlisis de Indicadores de FC y Esfuerzo para el Proyecto GENERIC1


Escenario
Usted est utilizando un Indicador de FC y otro de Esfuerzo Acumulado para controlar el avance de un Proyecto de Desarrollo de Software, como se muestra en las siguientes figuras:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 48 de 61

FC Desa Estimado FC QC Estimado

FC Desa Real FC QC Real

45 40 35 30 25 20 15 10 5 0
Se Se Se Se Se Se Se Se Se Se Se Se Se Se m m m m m m1 m2 m3 m4 m5 m6 m7 m8 m9 10 11 12 13 14 0 0 0 0 0 0 0 0 5 0 0 0 8 0 5 0 13 4 8 1 20 6 13 1 24 11 20 4 24 29 33 38 41 41 41 29 33 38 41 41 41 41

FC Desa Estimado FC Desa Real FC QC Estimado FC QC Real

Indicador de FC
Esfuerzo Real 1200 1000 800 600 400 200 0 Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Esfuerzo Real 40 80 140 230 340 440 660 Esfuerzo Estimado

Esfuerzo Estimado 50

100 150 220 300 400 600 680 780 850 900 940 1000 1020

Indicador de Esfuerzo acumulado Usted tiene problemas para monitorear el avance. Mientras que el indicador de funcionalidad completa indica un retraso, el indicador de esfuerzo indica que se estn consumiendo las horas segn lo previsto, con un pequeo desvo.

Objetivo
Analizar la informacin de ambos indicadores con el objetivo de:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 49 de 61

Estimar la nueva fecha final de fin Estimar el nuevo costo en horas de hombre del Proyecto

El objetivo es obtener una tendencia de cuanto ms gastar el Proyecto tomando como base lo que ha gastado hasta el momento y la funcionalidad que ha logrado implementar con esas horas. Es decir, se pide tomar la historia del propio Proyecto para re-estimar el costo y calendario de lo que falta del mismo Proyecto. Hiptesis:

Horas de PL = 15% Horas de Analista = 15% Horas de Desarrollador = 45 % Horas de Tester = 25 % (no incluyen revisin de anlisis. El anlisis es revisado en forma cruzada entre los analistas del Proyecto y est incluido dentro del 15% de horas de analista)

4.3 Re-planificacin del Proyecto GENERIC1


Escenario
El mismo escenario de Anlisis de Indicadores de FC y Esfuerzo del Proyecto GENERIC1.

Objetivo
Luego de analizar los indicadores, re-planifique el Proyecto teniendo en cuenta que slo se admite 1 semana de desvo. Se pide:

Agregar dos nuevas curvas al indicador de FC llamadas: FC Desa estimado v2 y FC QC estimado v2. Agregar una nueva curva al indicador de Esfuerzo llamada: Esfuerzo estimado v2. Redisear el equipo de trabajo.
o o

Organigrama con la nueva estructura Gantt que indique la incorporacin de nuevos recursos y la desafectacin de los mismos

Identifique los riesgos de la re-planificacin

Hiptesis: Puede agregar ms horas y ms gente al Proyecto.

Asuma que el equipo actual est formado por un Project Leader, un Analista, un Desarrollador y un Tester.

4.4 Esquema de reuniones de avance para el Proyecto DATATEL


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto DATATEL.

Objetivo
Se pide que disee el esquema de reuniones de avance del Proyecto, incluyendo:

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 50 de 61

Reuniones internas, de avance del Proyecto, con sponsors, con proveedores, etc. Todas las reuniones que usted considere necesarias para ayudar a mantener el Proyecto bajo control y para darle visibilidad.

Por cada reunin definir objetivo, frecuencia, duracin, horario, participantes, quin conduce la reunin y qu material se presenta. Incluir adems la reunin de inicio del Proyecto o de etapas.

4.5 Estabilizacin de Liberacin a Produccin para el Proyecto APPITEL 1.0


Escenario
El mismo escenario de Planificacin de Recursos para el Proyecto APPITEL 1.0. Finalmente el Proyecto se est haciendo en los tres meses (12 semanas) previstos, dentro de los cuales las ltimas dos semanas (11 y 12) estn reservadas para Estabilizacin y Aceptacin. Se encuentra actualmente en la recta final y se presentan entre otros los siguientes defectos:

Defecto 989: durante el proceso de diseo, un diseador olvid un campo que almacena una opcin del cliente respecto a cada artculo pedido. Esa opcin permite al cliente identificar si el artculo puede ser reemplazado por otra marca o no en caso de que no se encuentre en stock. Defecto 992: la base de datos se corrompe cada vez que se elimina de la lista de artculos un artculo que se vende por peso. Esto slo ocurre cuando se est ejecutando en ese momento el proceso trimestral de actualizacin global del maestro. La primera ejecucin de este proceso se

realizar exactamente tres meses despus de instalado el producto en produccin. Defecto 1000: Ocasionalmente, cuando el telemarketer abre una segunda instancia de la aplicacin, la primera instancia se cierra sin aviso, perdiendo cualquier informacin no salvada. Defecto 1003: Hay varios errores de ortografa en los nombres de campo en la pantalla de Carga de Detalle del Pedido.

Objetivo
Se pide que clasifique cada uno de los defectos indicando: 1. Severidad: A, B, C o D 2. Prioridad: Urgente, Alta, Media, Baja o Suspendido (en caso que el defecto se postergue para una prxima versin).

Realice esta clasificacin en las siguientes situaciones: 1. 2. 3. 4. 5. Estos defectos se detectan al fin de la semana 8. Estos defectos se detectan al fin de la semana 9. Estos defectos se detectan al fin de la semana 10 (inicio de estabilizacin). Estos defectos se detectan al fin de la semana 11 (mitad de la estabilizacin) Estos defectos se detectan a mediados de la semana 12 (2 das antes de liberar)

4.6 Estabilizacin de Liberacin a Aceptacin para el Proyecto APPITEL 1.0


Escenario

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 51 de 61

El mismo escenario de Planificacin de Recursos para el Proyecto APPITEL 1.0. Finalmente el Proyecto se est haciendo en los tres meses (12 semanas) previstos, dentro de los cuales las ltimas dos semanas (11 y 12) estn reservadas para Estabilizacin y Aceptacin. Se encuentra actualmente en la recta final y se presentan entre otros los siguientes defectos:

Defecto 990: no funciona la aplicacin para las dos terceras partes de los clientes. Aquellos cuyo apellido comienza con las letras F a la Z. Se estima 4 a 5 das para la correccin de este defecto. Defecto 991: No se ha terminado con la Baja de Cliente. Se necesitan 3 das ms. Defecto 1001: Luego de la integracin se obtiene un error al llegar a la seccin de Forma de Pago que hace caer la aplicacin. Se estiman 2 das de correccin. Defecto 1002: Hay problemas graves con las bsqueda de artculos en algunos casos. Esta es la funcionalidad ms importante porque la mayor parte del tiempo del usuario se gasta en esta seccin, y la velocidad de bsqueda determina la velocidad de toma del pedido. Se estima un da de correccin.

El usuario slo ha visto el prototipo de la aplicacin y esta aceptacin es clave antes de salir a produccin. La fecha de produccin es inamovible.

Objetivo
Se pide que clasifique cada uno de los defectos indicando:

Severidad: A, B, C o D Prioridad: Urgente, Alta, Media, Baja o Suspendido (en caso que el defecto se postergue). Para los defectos postergados indique si se corregirn durante la estabilizacin o en la prxima versin Indique si en algn caso conviene mover la fecha de aceptacin

Realice esta clasificacin en las siguientes situaciones: 1. Estos defectos se encuentran el martes (por la maana) anterior al viernes en que se libera para 2. aceptacin. La prxima semana se inicia el perodo de Aceptacin de 2 semanas. Estos defectos se encuentran el jueves (por la maana) anterior al viernes en que se libera para aceptacin. La prxima semana se inicia el perodo de Aceptacin de 2 semanas.

4.7 Tratamiento de Riesgos para el Proyecto DATATEL


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto DATATEL. Se trata de un Proyecto de 14 semanas de duracin. Las siguientes situaciones se plantean a lo largo del Proyecto: 1. 2. 3. 4. 5. Semana 5: El jefe de Proyecto de CIRCULO se toma 15 das de vacaciones. Semana 8: El usuario manifiesta a travs de un mail enviado al Gerente de IT de CIRCULO no poder aprobar el producto porque no est seguro de que haga lo que l quiere. Semana 6: el Sponsor slo vino al Kick Off y a la primera reunin de avance. Semana 6: hay una semana de retraso en la liberacin de cdigo de interfaces por parte de Juan o Alberto. Manifiestan tener otras prioridades. Semana 7: todo anda bien. El Indicador de FC muestra que se estn cumpliendo las fechas. Por otro lado, tambin se est cumpliendo con el presupuesto del Proyecto. El usuario aprob el prototipo en la semana 5 (ver figura) 6. Semana 1: CIRCULO nunca ha trabajado con tecnologa de Datawarehousing. Es una tecnologa nueva para ellos.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 52 de 61

7.

Semana 8: el indicador registra un retraso. La entrega de cdigo completo se realizar una semana ms tarde. Semana 12 en lugar de semana 11.

45 40 35 30 25 20 15 10 5 0
FC Desa Estimado FC Desa Real FC QC Estimado FC QC Real FC Usuario Est. FC Usuario Real Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem Sem 1 2 3 4 5 6 7 8 9 10 11 12 13 14 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 0 8 8 5 3 0 0 13 12 8 8 8 8 20 20 13 11 8 24 27 20 22 8 8 8 8 8 8 41 41 24 29 33 38 41 41 41 29 33 38 41 41 41 41

Indicador de FC - Semana 7 Aplica al punto 5

Objetivo
Se pide hacer un anlisis de riesgos para cada una de las situaciones presentadas: Si existe un problema determinar la accin correctiva

Si existe un riesgo completar: o Identificacin


o o o

Anlisis Planificacin Responsable

4.8 Esquema de reuniones de avance para el Proyecto APPITEL 2.0


Escenario
El mismo escenario de Diseo de Equipo de Trabajo para el Proyecto APPITEL 2.0.

Objetivo
El mismo objetivo de Esquema de reuniones de avance para el Proyecto DATATEL.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 53 de 61

4.9 Earned Value para el Proyecto IDC 1


Escenario
Se encuentra en la semana del 22/09/2003 de su Proyecto y ha decidido obtener un indicador de Earned Value. Nunca ha trabajado con este indicador y tiene algunas dudas acerca de cmo tratar las tareas en ejecucin de manera de obtener un indicador lo ms preciso posible. Cuenta con la siguiente informacin: Estado de las tareas

Presupuesto Real hasta la fecha


Tarea 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 23 24 24 Tipo Valor Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real Presupuesto Real 18-Ago 25-Ago 4 1 21 14 18 10 3 2 01-Sep 08-Sep 15-Sep 22-Sep 29-Sep 06-Oct

Estado Terminada Terminada Terminada Terminada Terminada Terminada Comenzada Comenzada Comenzada Comenzada Comenzada Comenzada No comenzada No comenzada No comenzada No comenzada No comenzada No comenzada Terminada Terminada No comenzada No comenzada Terminada Terminada Comenzada Comenzada Comenzada Comenzada Comenzada Comenzada Terminada Terminada Terminada Terminada Terminada Terminada Terminada Terminada Comenzada Comenzada No comenzada No comenzada Comenzada Comenzada Comenzada Comenzada No comenzada No comenzada

9 3 2

6 1

6 7 4 6

6 3 5 2 0

6 2

7 11

2 15

8 16 10

1 4 2 3 3 3

7 8

16 23 30 19

1 4 4

14 24 21 12 7 4 6 8 3

7 14 21 22 23

5 2 18 2 2 9 5 5 3 5 4 0 5 2

5 3

5 18

2 6 7 4

2 2 7 8

2 3 7 6

2 7 1

2 7 85

Detalle de Presupuesto y Real de las Tareas

Objetivo
Graficar el indicador incluyendo: En el grfico:
o o o o

BCWS BCWP (definiendo el tratamiento para las tareas en ejecucin) ACWP CV

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 54 de 61

o o o

SV BAC EAC

o Tendencia de desvo de calendario Fuera del grfico o o

CPI SPI

Analizar el indicador. Nota para el alumno: Si necesita ms informacin, asuma que el jefe de Proyecto puede suministrarla. Utilice hiptesis.

Consulte en Internet si necesita ms informacin sobre Earned Value.

4.10 Priorizacin de defectos para el Proyecto CPP 1.0


Escenario
PI se encuentra actualmente en el Proyecto de construccin de CPP 1.0 (ver escenario de Estimacin de Recursos para el Proyecto CPP 1.0). Se cuenta con la informacin de los siguientes defectos: Defecto 1001 Descripcin La carga diaria de horas reales no muestra bien el total de horas por recursos. Hay un problema de redondeo que impide que la persona conozca con exactitud la cantidad de horas que ha reportado en el da. 1002 1003 Error de diseo. No se incluy fecha de valor de HH de los recursos. Se necesita una tabla histrica. Esto tendr impacto cuando comience a cambiar el valor de HH de los Recursos. El indicador de EV no grafica las curvas de CV y SV. El usuario ha pedido estas curvas luego de ver como ha quedado el indicador. Actualmente se muestra slo el nmero de estos valores a la fecha actual. Parece ser un nuevo requerimiento, aunque el usuario no piensa lo mismo. 1004 1005 No permite eliminar tareas. Hay un error de clculo en el BCWP. La curva se genera con un 5 % de error.

Objetivo
Complete la tabla adjunta, indicando por cada defecto: Severidad (A, B, C D)

Accin a tomar sugerida al usuario (corregir, suspender) en las siguientes etapas: o Estabilizacin: ltima semana del perodo de estabilizacin. Hacia fin de la semana se
o

libera para Aceptacin. Aceptacin: ltima semana del perodo de aceptacin. Hacia fin de la semana se libera

para Produccin. Si la accin es corregir, indique el orden de correccin donde 1 es lo ms prioritario. No repita el orden dentro de una misma etapa. Justifique su respuesta:

Def. 1001

Sev.

Etapa Actual Estabilizacin Aceptacin

Prxima Etapa Aceptacin Liberacin

Accin

Orden

Justificacin

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 55 de 61

4.11 Earned Value (terico)


Objetivo
Explicar el indicador de Earned Value a travs de un caso prctico de no ms de 7 tareas en diferentes estados. Explique y muestre los valores de ACWP, BCWP, BCWS, BAC, CV, SV y CPI.

Tarea Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5 Tarea 6 Tarea 7 Total Proyecto

BCWS

BCWP

ACWP

CV

SV

CPI

BAC

4.12 Anlisis de Indicadores para el Proyecto INDI 1


Escenario
Usted es el jefe del Proyecto INDI 1, que posee las siguientes caractersticas: Inicialmente tena fecha de fin a mediados de julio

Se hizo una re-planificacin que posee fecha de finalizacin en noviembre El planificado y real anterior a la fecha de replanificacin se igual. No quiere decir que originalmente hayan coincidido Se ha definido lo siguiente para las tres variables de control:
o o o

Funcionalidad: est fija Calendario: est libre Costo: es la variable de ajuste. No est totalmente abierta. Se debe controlar cada adicional de presupuesto para el Proyecto.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 56 de 61

La siguiente tabla muestra un poco ms de informacin que el grfico: Estado segn FC En elaboracin 84 puntos = 36 % Elaborado 150 puntos = 64% Estado detallado En elaboracin Cdigo Completo Calidad en Evaluacin Defectos Crticos Liberado por QC % Sub Estado 36% 19% 15% 15% 15% Descripcin del estado Actualmente desarrollo en elaboracin por el equipo de

Cdigo completo, an sin evaluar por QC, debido a que QC est con otros temas Actualmente en evaluacin por el equipo de QC Evaluado por QC y con defectos crticos pendientes de correccin Evaluado por QC y con defectos no crticos pendientes de correccin

BAC Plan (BCWS) Actual (ACWP) Earned Value (BCWP)

= = = =

Earned Value $ 3.105.000 $ 2.181.000 (al 20 de Junio) $ 2.184.000 (al 20 de Junio) $ 434.700 (al 20 de Junio)

Nota: se considera valor ganado a la funcionalidad liberada por QC

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 57 de 61

Total

Cerrados

Pendientes Suspendidos

Objetivo
Hoy es 20 de Junio y usted cuenta con indicadores de Funcionalidad Completa, Evolucin de la Prueba y Earned Value. Se pide que presente un diagnstico del Proyecto y evale las acciones correctivas propuestas: Diagnstico del Proyecto: Evale el estado actual del Proyecto haciendo un conciso anlisis de las siguientes variables:
o o

Calendario Costo

o Funcionalidad Adems realice un anlisis de la Calidad del producto que se est construyendo.

Evaluacin de las siguientes acciones correctivas: Indique sin considera apropiadas o no a cada una de las siguientes acciones correctivas, justificando por cada una el motivo y evaluando el impacto en cuanto a Calendario, Funcionalidad y Costos.

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 58 de 61

Incorporar ms recursos de QC Motivo Eleccin Impacto Calendario Impacto Costos Impacto Funcionalidad Incorporar ms recursos de Desarrollo Motivo Eleccin Impacto Calendario Impacto Costos Impacto Funcionalidad Suspender temporalmente la correccin de defectos de Severidad C y D Motivo Eleccin Impacto Calendario Impacto Costos Impacto Funcionalidad Suspender temporalmente el desarrollo de funcionalidad nueva Motivo Eleccin Impacto Calendario Impacto Costos Impacto Funcionalidad Cancelar el Proyecto Motivo Eleccin Impacto Calendario Impacto Costos Impacto Funcionalidad

APROPIADA

NO APROPIADA

APROPIADA

NO APROPIADA

APROPIADA

NO APROPIADA

APROPIADA

NO APROPIADA

APROPIADA

NO APROPIADA

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 59 de 61

4.13 Anlisis de Indicadores para el Proyecto INDI 2


Escenario
Usted est dirigiendo un Proyecto en el que participan tres equipos: A: desarrolla el 50% de la funcionalidad

B: desarrolla el 50% de la funcionalidad C: prueba el 100% de la funcionalidad

El equipo C gener los siguientes indicadores el 14 de Septiembre de 2001: Equipo A

Equipo B

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 60 de 61

Objetivo
Se necesita hacer un anlisis de la historia del Proyecto para concluir en las mejores acciones correctivas para la situacin actual. Se pide: Anlisis de la Historia: evale los hechos ms importantes ocurridos en el Proyecto desde su

inicio con los equipos A y B. Acciones correctivas para la fecha actual

En caso que considere que los indicadores no se encuentren en su mejor forma, se pide:

Definir el objetivo a lograr en los indicadores de ambos equipos Enumerar acciones correctivas a tomar

Agosto/2007 (versin 9.0)

Administracin y Control de Proyectos I

Pgina 61 de 61

Potrebbero piacerti anche