Guía de TP - fi.uba.arE1cticas/PI1%20-%20Gu%A1a%20TP%20...Administración y Control de Proyectos I...

Administración y Control de Proyectos I

Proyectos Informáticos

Guía de TP

2° Cuatrimestre de 2007 Trabajos Prácticos

Agosto de 2007 Versión 9.0

Agosto/2007 (versión 9.0) Administración y Control de Proyectos I Página 2 de 61

Índice Introducción ....................................................................................................4 1 Equipos de Trabajo .................................................................................10

1.1 Diseño de Equipo de Trabajo para el Proyecto “APPITEL 2.0” ..................................... 10 1.2 Diseño de Equipo de Trabajo para el Proyecto “DATATEL” ......................................... 11 1.3 Diseño de Equipo de Trabajo para el Proyecto “DWH LOPEC”..................................... 13 1.4 Diseño de Equipo de Trabajo para el Proyecto “DRUG 1” ........................................... 14 1.5 Diseño de Equipo de Trabajo para el Proyecto “BETA” ............................................... 15 1.6 Diseño de Equipo de Trabajo para el Proyecto “Comisiones II” ................................... 16 1.7 Diseño de Equipo de Trabajo para el Proyecto “Certificación ISO”............................... 18 1.8 Diseño de Equipo de Trabajo para el Proyecto “Cine & Video” .................................... 18

2 Etapa 1: Inicio (Alcance) .........................................................................20 2.1 WBS para el Proyecto “APPITEL 2.0”......................................................................... 20 2.2 Versiones y Entregas Incrementales para el Proyecto “APPITEL 2.0”........................... 21 2.3 Planificación de Recursos para el Proyecto “APPITEL 1.0”........................................... 22 2.4 Propuesta para el Proyecto “Help Desk” .................................................................... 24 2.5 Riesgos para el Proyecto “Help Desk” ....................................................................... 27 2.6 Alcance para el Proyecto “Help Desk”........................................................................ 27 2.7 Planificación de Recursos para el Proyecto “CPP 1.0” ................................................. 28 2.8 WBS para el Proyecto “Cine & Video”........................................................................ 28 2.9 Entregas Incrementales para el Proyecto “Cine & Video”............................................ 30 2.10 WBS para el Proyecto “DRUG 1” ............................................................................... 30 2.11 Planificación de Recursos para el Proyecto “ALFA” ..................................................... 30 2.12 Planificación de Recursos para el Proyecto “Comisiones” ............................................ 31 2.13 WBS para el Proyecto “BETA”................................................................................... 32 2.14 Planificación de recursos para el Proyecto “25 de Mayo Delivery”................................ 32 2.15 WBS para el Proyecto “K”......................................................................................... 33 2.16 WBS para el Proyecto “Certificación ISO” .................................................................. 34 2.17 Planificación de Recursos para el Proyecto “Cine & Video”.......................................... 34

3 Etapa 2: Organización .............................................................................35 3.1 Calendario Cliente / Distribución de Presupuesto para el Proyecto “APPITEL 1.0”......... 35 3.2 Calendario Cliente para el Proyecto “DATATEL” ......................................................... 36 3.3 Calendario Cliente para el Proyecto “APPITEL 2.0” ..................................................... 37 3.4 Calendario Build Diario para el Proyecto “APPITEL 1.0” .............................................. 37 3.5 Diseño de Indicador de Funcionalidad Completa para el Proyecto “APPITEL 1.0” ......... 38 3.6 Calendario Build Diario e Indicador de FC para el Proyecto “APPITEL 2.0” ................... 40 3.7 WBS de Calidad para el Proyecto “APPITEL 2.0” ........................................................ 40 3.8 Plan de Proyecto para el Proyecto “APPITEL 1.0”....................................................... 41 3.9 Plan de Adm. de Cambios para el Proyecto “APPITEL 2.0”.......................................... 41 3.10 Plan de Calidad para el Proyecto “APPITEL 2.0”......................................................... 41 3.11 Calendario Cliente para el Proyecto “Cine & Video” .................................................... 42 3.12 Calendario Build Diario para el Proyecto “Cine & Video” ............................................. 42 3.13 Calendario Build Diario para el Proyecto “ADP” .......................................................... 43 3.14 Calendario Cliente para el Proyecto “BETA” ............................................................... 44 3.15 Versiones, Entregas Incrementales y Calendario Cliente para el Proyecto “DRUG 1”..... 44 3.16 Calendario Cliente para el Proyecto “K” ..................................................................... 45

4 Etapa 3: Ejecución y Control ....................................................................46 4.1 Análisis de Indicadores para el Proyecto “CE-EME”..................................................... 46 4.2 Análisis de Indicadores de FC y Esfuerzo para el Proyecto “GENERIC1” ....................... 48


4.3 Re-planificación del Proyecto “GENERIC1”................................................................. 50 4.4 Esquema de reuniones de avance para el Proyecto “DATATEL” .................................. 50 4.5 Estabilización de Liberación a Producción para el Proyecto “APPITEL 1.0” ................... 51 4.6 Estabilización de Liberación a Aceptación para el Proyecto “APPITEL 1.0” ................... 51 4.7 Tratamiento de Riesgos para el Proyecto “DATATEL” ................................................. 52 4.8 Esquema de reuniones de avance para el Proyecto “APPITEL 2.0” .............................. 53 4.9 Earned Value para el Proyecto “IDC 1”...................................................................... 54 4.10 Priorización de defectos para el Proyecto “CPP 1.0” ................................................... 55 4.11 Earned Value (teórico) ............................................................................................. 56 4.12 Análisis de Indicadores para el Proyecto “INDI 1” ...................................................... 56 4.13 Análisis de Indicadores para el Proyecto “INDI 2” ...................................................... 60


Introducción Filosofía de los ejercicios:

• En general los ejercicios plantean situaciones y escenarios a ser analizados por un jefe de Proyecto. En base a ese análisis se debe diseñar una solución al problema planteado.

• El éxito en la resolución del ejercicio está dado por la capacidad de analizar el problema y plantear una solución y no por el uso de fórmulas mágicas.

• Es por eso que se recomienda no copiar resoluciones, ya que el parcial planteará el mismo tipo de ejercicios en donde la práctica de haber estado en situaciones similares será clave para resolverlos.

Dedicación de los alumnos: Para un correcto aprovechamiento de las clases y una buena preparación para los parciales recomendamos:

• Tomar las clases teóricas como base para la resolución de los ejercicios. • Resolver los ejercicios con calidad de presentación. Resolver un ejercicio en forma parcial puede

hacer que el alumno no obtenga las conclusiones del mismo. • Si hay dudas ante la resolución de un ejercicio, avanzar tomando hipótesis y justificando las

decisiones tomadas. La mayoría de las dudas serán resueltas por el mismo alumno. • Volver a resolver en forma completa todos los ejercicios luego de cada clase práctica para aplicar

los conocimientos adquiridos. • Ampliar la práctica con los ejercicios recomendados. • Dedicar un mínimo de 20 horas semanales a la materia.

Fórmula para estar bien preparado:

Clase Teórica + Pautas para resolución de Ejercicios + Resolución ejercicios obligatorios (1 y 2 ver calendario) y recomendados antes de la clase + Verificación de solución en Clase Práctica + Resolución ejercicios obligatorios y recomendados después de la clase = 20 HH semanales Diagrama de Secuencia de Ejercicios: La idea del siguiente diagrama es mostrar a los alumnos cómo 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.


Proyecto APPITEL 2.0 Proyecto DATATEL Proyecto DRUG 1

1.1 – Diseño de Equipo de Trabajo

2.1 – WBS

2.2 – Versiones y Entregas Incrementales

3.3 – Calendario Cliente

3.6 – Calendario Build Diario / IFC

3.7 – WBS Calidad

3.9 – Plan de Administración de Cambios

3.10 – Plan de Calidad

4.8 – Esquema de Reuniones de Trabajo

Semana 5 – Obligatorio

Semana 6 - Obligatorio



Semana 9 - Recomendado







4.4 – Esquema de Reuniones de Avance

4.7 – Tratamiento de Riesgos






2.10 – WBS

3.15 – Versiones, Ent. Inc. y Calendario Cliente

Semana 5 – Recomendado




Proyecto DWH LOPEC Proyecto BETA Proyecto Comisiones II Proyecto K Proyecto CINE & VIDEO


2.13 – WBS





2.9 – Entregas Incrementales

2.8 – WBS


3.12 – Calendario Build Diario





1.6 – Diseño de Equipo de Trabajo Semana 6 - Recomendado

1.3 – Diseño de Equipo de Trabajo Semana 6 - Recomendado


2.15 – WBS Semana 5 - Recomendado


1.8 – Diseño de Equipo de Trabajo Semana 6 - Obligatorio

2.17 – Diseño Equipo de Trabajo Semana 8 - Obligatorio


Proyecto APPITEL 1.0 Proyecto Comisiones Proyecto 25 de Mayo Delivery Proyecto CPP 1.0 Proyecto ALFA Proyecto ADP

3.1 – Calendario Cliente / Distribución Presupuesto

2.3 – Planificación de Recursos

3.4 – Calendario Build Diario

3.5 – Indicador Funcionalidad Completa

3.8 – Plan de Proyecto

4.5 – Estabilización Lib. a Producción

4.6 – Estabilización Lib. a Aceptación








2.12 – Planificación de Recursos Semana 8 - Obligatorio

2.11 – Planificación de Recursos Semana 8 - Recomendado

4.10 – Priorización de Defectos




3.13 – Calendario Build Diario Semana 8 - Recomendado


Proyecto CE-EME Proyecto HELP DESK Proyecto Certificación ISO Proyecto GENERIC1 Proyecto INDI2 Proyecto IDC1 Proyecto INDI1 Ejercicio Teórico

2.5 – Riesgos del Proyecto

2.4 – Propuesta de Proyecto

2.6 – Alcance del Proyecto




4.1 – Análisis de Indicadores Semana 9 - Obligatorio

4.3 – Replanificación de Proyecto

4.2 – Análisis IFC y Esfuerzo Semana 9 - Recomendado


4.13 – Análisis de Indicadores Semana 9 - Recomendado

4.9 – Earned Value Semana 10 - Obligatorio

4.12 – Análisis de Indicadores Semana 10 - Obligatorio

4.11 – Earned Value Semana 10 - Recomendado

1.7– Diseño de Equipo de Trabajo

2.16 – WBS Semana 5 - Obligatorio



Historial de Versiones:

Fecha / Versión Autor Anotaciones

Agosto de 2007 / 9.0

Patricia Inés Bus Modificación del Diagrama de Secuencia de Ejercicios por cambios en el orden de resolución y en el calendario. Nuevos ejercicios: 1.8 y 2.17

Marzo de 2007 / 8.0

Patricia Inés Bus Modificación del Diagrama de Secuencia de Ejercicios por cambios en el orden de resolución y en el calendario. Nuevos ejercicios: 1.7 y 2.16


Patricia Inés Bus Corrección de etiquetas en gráficos de los ejercicios 3.5, 4.2, 4.7 y 4.12 Modificación del Diagrama de Secuencia de Ejercicios.

Marzo de 2006 / 6.0

Mariana Gómez Modificación terminología. Corrección defectos.


Patricia Inés Bus Nuevos ejercicios: 1.5, 1.6, 2.12, 2.13, 2.14, 2.15, 3.14, 3.15, 3.16 Actualización del Diagrama de Secuencia de Ejercicios. Corrección del punto 5 del Ejercicio 4.7 (se cambió “semana 8” por “semana 5”).

Marzo de 2005 / 4.0

Patricia Inés Bus Incorporación del Diagrama de Secuencia de Ejercicios (sobre una idea de Alejandro Sasín) Eliminación de Organización de Clases Prácticas. Corrección de defectos de ortografía y redacción.


Patricia Inés Bus Nuevos ejercicios: 1.4, 2.10, 2.11, 3.13, 4.12, 4.13 Modificación en la Organización de Clases Prácticas. Eliminación del Calendario de Ejercicios. Corrección de defectos de ortografía y redacción.

Marzo de 2004 / 2.0

Juan Pablo Pussacq Laborde

Nuevos ejercicios: 1.3, 2.7, 2.8, 2.9, 3.11, 3.12, 4.10 y 4.11


Juan Pablo Pussacq Laborde (Colaboración de Raúl Martínez y Mariana Gómez en algunos ejercicios y en revisiones)

Versión inicial.


1 Equipos de Trabajo

1.1 Diseño de Equipo de Trabajo para el Proyecto “APPITEL 2.0” Escenario CIRCULO SA ha decidido renovar su aplicación de Atención de Pedidos Telefónicos en dos meses y medio. Se trata de una aplicación crítica con los siguientes lineamientos de arquitectura:

• Aplicación 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 análisis, diseño y QC. Además tomará la dirección del Proyecto. • Además proveerá uno o dos recursos de CIRCULO para el desarrollo de interfaces con otros

sistemas. El Proyecto ha sido aprobado y comienza la próxima semana. Usted pertenece a PI y ha sido designado como Jefe de Proyecto. La propuesta presentada por PI tiene las siguientes restricciones:

• Duración: 2 meses y medio (incluye construcción y puesta en marcha) • Presupuesto:

o 218 HH de Consultor Senior o 392 HH de Consultor

Su primer paso es diseñar la estructura de trabajo. Cuenta con la siguiente información: PI

• PI asigna dos personas al Proyecto. o Alejo (usted): consultor senior que además de dirigir el Proyecto, puede realizar tareas de

análisis, diseño y prueba. o Valentina: un consultor de PI que cuenta con experiencia en QC y algo de experiencia en

análisis y diseño. • 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. Aún no saben si serán uno,

dos o tres. Andrés, uno de ellos, participará seguro. • FX cuenta con dos socios (Martín y Carlos). Uno de los dos o los dos estarán también 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.


CIRCULO • Juan y Alberto estarán asignados para trabajar en el tema de Interfaces. Juan conoce mucho mejor

la problemática por lo cual es el principal asignado. Aunque en la reunión de Kick Off manifestó estar con demasiadas tareas.

• Norberto, el Gerente de Sistemas de CIRCULO, es quien decidió tercerizar y quién 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 Raúl. Andrea trabaja habitualmente con los usuarios y conoce claramente la problemática desde el punto de vista funcional. Raúl también conoce la problemática, pero fundamentalmente es una persona técnica con mucha experiencia en Visual Basic y arquitectura Web.

• José es el Gerente de Ventas. De él depende el Call Center que utiliza esta aplicación. • Norberto quiere que participen algunas de las supervisoras del Call Center ya que están en el día a

día y conocen claramente la problemática. Alicia estará involucrada en sus ratos libres en el Call Center y probablemente participe además alguna de las otras supervisoras.

Aún no se tiene muy claro cuál es la distribución de trabajo entre los distintos proveedores de desarrollo, pero una primera aproximación 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 diseñe la estructura del equipo de trabajo para presentar en la próxima reunión y validar con los demás participantes. Debe incluir:

• Diagrama estilo organigrama con nombres de las personas y funciones. Debe involucrar a todos los participantes.

• Descripción breve de responsabilidades de cada uno. • Identificar riesgos principales del equipo planteado.

1.2 Diseño 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 problemática de Datawarehousing. De hecho, este será el primer Proyecto con esta tecnología 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 próxima semana. Usted pertenece a PI y ha sido designado como Jefe de Proyecto. La propuesta presentada por PI tiene las siguientes restricciones:

• Duración: 2 meses y medio (incluye construcción y puesta en marcha)


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

Su primer paso es diseñar la estructura de trabajo. Cuenta con la siguiente información: PI

• PI asigna las siguientes personas al Proyecto. o Alejo (usted): jefe de Proyecto con experiencia en administración de Proyectos, sin

experiencia en Proyectos de Datawarehouse. Además tiene conocimiento del negocio por su participación en el Proyecto anterior.

o Mariano: consultor senior. Ha trabajado como desarrollador o como analista en otros Proyectos de Datawarehouse. Posee mucha experiencia.

o Cecilia: consultor que ha trabajado como desarrollador en otros Proyectos de Datawarehouse.

o Federico: especialista en la customización del Front End. Tomará algunas horas de desarrollo (de las 400) para posibles customizaciones. Se estiman alrededor de 80.

o Sebastián: tester con experiencia en Proyectos de datawarehouse. o Martín: tester junior. Colaborará con Sebastián en algunas tareas y es objetivo de PI que

este Proyecto le sirva de capacitación. • 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 Sebastián tienen 15 días 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 estarán asignados para trabajar en el tema de Interfaces. Juan conoce mucho mejor la problemática por lo cual es el principal asignado. Aunque en la reunión de Kick Off manifestó estar con demasiadas tareas.

• Norberto, el Gerente de Sistemas de CIRCULO, es quien decidió tercerizar y quién contrató a PI. • Oscar, un gerente de alto nivel cuya función 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 información del Tablero. • Omar, Jefe de Marketing, y Saúl, uno se sus empleados, esperan obtener buena información

también. • Florencia trabaja habitualmente con información en Excel y espera también conseguir buena

información. Muchos de sus informes son provistos directamente a Oscar y a Fernando, el CEO de la Compañía.

• El CEO espera obtener buena información también. • Adrián, quien trabaja en los aspectos operativos del circuito de Delivery, también espera ser usuario

de este Tablero. Estará involucrado en el Proyecto junto a María, una de sus empleadas. • Osvaldo trabaja en Administración y Finanzas. Norberto le pidió que se involucre en el Proyecto

porque la información puede serle útil a él también. • Dada la experiencia exitosa de APPITEL, Norberto asigna nuevamente a dos de sus mejores

recursos, Andrea y Raúl. Andrea trabaja habitualmente con los usuarios y conoce claramente la problemática desde el punto de vista funcional. Raúl también conoce la problemática, pero fundamentalmente es una persona técnica con mucha experiencia en Visual Basic y arquitectura Web. Raúl no tiene experiencia en Datawarehouse, pero está interesado en quedarse con algunos conocimientos de manera de poder resolver problemas de operación en el futuro.

• Norberto decide involucrar a más gente de su área dado que se trata de tecnología nueva: o Damián, un programador que colaborará con aspectos técnicos.


o Martina, quien trabajará junto a Andrea. • No se sabe cuándo ni quiénes, 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. Aún 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.

• Lucía, quién maneja los aspectos de Datawarehouse en CIRCULO CENTRAL, será el contacto. • Lucía involucrará a Antonio, especialista en Datawarehouse, para que valide que el Tablero de

Ventas para CIRCULO cumplan con los estándares de la Organización • Lucía hará participar también 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 diseñe la estructura del equipo de trabajo para presentar en la próxima reunión y validar con los demás participantes. Debe incluir:



1.3 Diseño 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 gestión que incluye los siguientes módulos:

1. Construcción de un Datawarehouse de Compras (a cargo de PI) 2. Desarrollo de una interfaz con el Sistema de Compras (a cargo de LOPEC) 3. Integración con el actual Datawarehouse de Ventas (a cargo de PI) 4. Desarrollo de un aplicativo que permita almacenar información que hoy no existe en el Sistema de

Compras (a cargo de PI) 5. Herramienta de explotación de Datawarehouse (provista por el proveedor SUBOSCURO)

LOPEC encargó a PI la dirección total del Proyecto, pidiendo que coordine los 5 módulos. La propuesta presentada por PI se basa en la siguiente estimación y asignación de recursos:


Rol / Tiempo Q1 Q2 Q3 Q4 Q5 Q6 Q7Analista (Laura) 1 1 0,5 0,5 0,5 0,5 0,5Desarrollador Datawarehouse 1 (Pedro) 0,5 1 1 1 1 1 1Desarrollador Datawarehouse 2 (Luis) 1 1 1 1 0,5Desarrollador Aplicativo 1 (Pablo) 1 1 1 1 1 1Desarrollador Aplicativo 2 (Andrés) 1 1 1 1 0,5Tester 1 (Mariana) 1 1 1 1 1 1Tester 2 (Juan Pablo) 1 1 1 1 1Jefe de Proyecto (Raúl) 1 1 1 1 1 1 1

1 = Full Time 0,5 = Part Time

Hipótesis:El Analista trabaja tanto en el análisis del Datwarehouse como en el del Aplicativo.El Analista instala, parametriza y capacita en la herramienta de explotación.El Analista diseña 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 más años en la compañía. • Silvia, personal de la Gerencia de Ventas que conoce en detalle el actual sistema de Gestión de

Ventas. • Antonio, Gerente de Sistemas, quien decidió subcontratar. • Andrea, personal de Sistemas quien se hará responsable de todos los aspectos funcionales y

técnicos que el Proyecto requiera a LOPEC. • Martín, Sebastián y Marita se encargarán del desarrollo de las interfaces. • Gabriela, responsable de Seguridad

Además participan:

• Miguel, de SUBOSCURO, quien vendió a LOPEC las licencias de su producto de explotación. • Cristian, consultor de SUBOSCURO encargado de brindar consultoría sobre la herramienta de

explotación a Laura (de PI). • Enrique, socio de PI

Objetivo Se pide que usted diseñe la estructura del equipo de trabajo para presentar en la próxima reunión y validar con los demás participantes. Debe incluir:



1.4 Diseño 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 líder del Proyecto DRUG 1. En este momento se encuentra en la primera reunión 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 próximo viernes, que será conducido por usted.


Descripción brindada por Adolfo:

En el año 1999, IRC SA desarrolló su producto / servicio IRC*SERVICE para operar con Obras Sociales, Farmacias y Médicos. SPAZIO compró IRC SA en el 2001. Así fue evolucionando IRC* SERVICE hasta la actualidad en que se encuentra en su versión 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 Médicos. SPAZIO de Estados Unidos ha construido un servicio similar, aunque con menos funcionalidad por tratarse de la primera versión: 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, deberán trabajar con la competencia o dejar de usar el servicio. El Proyecto que tenés que liderar finaliza con las instalación de DRUG 1 en todos los clientes y el cierre de IRC*SERVICE para siempre. Tu función es coordinar a las distintas partes involucradas. El Proyecto tiene un aspecto tecnológico que consiste en la localización del servidor de DRUG 1 para Argentina y en la customización de los clientes de DRUG 1 para cada una de las Obras Sociales. Una vez resuelto esto, deberán migrarse los clientes: Obras Sociales, Farmacias y Médicos. 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 localización, la customización y la instalación de Clientes y Servidor. Otro aspecto muy importante es la parte comercial. Es necesario calcular los nuevos precios del servicio y vendérselo 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 comunicación es importante. Margarita, del área de Comunicación de SPAZIO, estará encargada de este punto, que incluye tanto la comunicación interna dentro de SPAZIO Argentina como los comunicados de prensa, y comunicados a Obras Sociales, Farmacias y Médicos. No queremos que se genere ningún 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 decisión más alto del Proyecto. Paul es el referente tecnológico de DRUG 1 y nos podrá dar asistencia en ese aspecto.

Objetivo Se pide que diseñe la estructura del equipo de trabajo para presentar en la reunión de Kick Off y validar con los demás participantes. Debe incluir:



1.5 Diseño de Equipo de Trabajo para el Proyecto “BETA”


Escenario La empresa PI ha decidido lanzar un Proyecto para la construcción de un producto para el mercado financiero. Aún no sabe como será el producto, por lo cual ha decidido que parte del trabajo de este Proyecto sea la definición del mismo. El Proyecto debe arrancar con el desarrollo de la visión y finalizar con un entregable que incluya el CD y los manuales listos para la duplicación. El Proyecto está financiado en un 70% por PI y en un 30% por el gobierno de la provincia de Córdoba, en el contexto de una iniciativa para promover la industria del software en la provincia. El gobierno de Córdoba aportará presupuesto para que PI compre los equipos de hardware para los ambientes de desarrollo y prueba. Además aportará presupuesto para que el personal de PI afectado al Proyecto se capacite en la última tecnología 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 campaña de difusión y buscar posibles clientes mientras dure el desarrollo del producto. Además 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 información financiera que será consultada por una aplicación 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. Aún no están definidos estos beneficios. Objetivo Identifique los roles necesarios para el Proyecto, diagramando la estructura del equipo de trabajo.

1.6 Diseño de Equipo de Trabajo para el Proyecto “Comisiones II” Escenario Dos compañías 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 interés en el tema, decidió evaluar distintas alternativas para presentar la más conveniente. Objetivo Diseñe 5 posibilidades de equipo de trabajo que tengan entre 2 y 3 recursos (los únicos disponibles son Juan, Pedro y María) cubriendo los 5 roles enumerados. En cada posibilidad identifique puntos a favor y riesgos. Marque la alternativa recomendada para presentar como propuesta.

Equipo 1 Juan Pedro María Puntos a Favor Riesgos e inconvenientes

Project Leader

Analista

QC (Análisis)

Desarrollo

QC (Desarrollo)



Project Leader

Analista

QC (Análisis)

Desarrollo

QC (Desarrollo)


Project Leader

Analista

QC (Análisis)

Desarrollo

QC (Desarrollo)


Project Leader

Analista

QC (Análisis)

Desarrollo

QC (Desarrollo)


Project Leader

Analista

QC (Análisis)


Desarrollo

QC (Desarrollo)

1.7 Diseño de Equipo de Trabajo para el Proyecto “Certificación ISO” Escenario La Organización SOLUCIONES IT S.R.L. está interesada en realizar una certificación de Calidad, y se decidió por la Norma ISO 9001:2000. La fecha clave a cumplir es 01/12/2007. La Organización requiere certificar el 21/12/2007. Los Gerentes necesitan este proyecto para estar a la altura de sus competidores, además están interesados en definir los procesos que se requieran y la definición e implementación de un Sistema de Gestión de Calidad en su Organización. SOLUCIONES IT S.R.L. se dedica a proyectos de desarrollo, mantenimiento, Quality Control y Consutoría (mejora de procesos, etc.) En la Organización existen Administradores de Cuentas de Clientes, Responsables de Ventas, Project Leaders, Responsables de Tecnología, Consultores, y en el Centro de Desarrollo hay Analistas, Desarrolladores y Testers. Existe personal administrativo que se dedica a la administración de los recursos de SOLUCIONES IT S.R.L., así como también a la facturación y cobros a Clientes y pagos a Proveedores. La Gerencia está muy interesada en que se instaure en la Organización el nuevo Sistema de Calidad. La Organización tiene que seguir con los Proyectos en curso y a su vez se requerirá un esfuerzo adicional del personal para trabajar en este Proyecto. Joaquín es un Consultor, él tendrá a cargo la coordinación y la confección 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 Joaquín se va a seleccionar y contratar un especialista en la Norma ISO 9001:2000. El éxito del proyecto se mide en tener la certificación en ISO el 21/12/2007. Objetivo: Se pide que diseñe un equipo de trabajo para poder dar solución a la problemática de SOLUCIONES IT S.R.L.

1. Seleccione la forma de representar el equipo de trabajo, tiene que ser la más eficiente. Justifique su elección.

2. Diagrame el equipo de trabajo, indicando: roles, responsables y funciones de los roles. Ayuda:

Tenga en cuenta: • Estos conceptos: Diagrama de una Organización IT, Administración de Proyectos,

Administración de Riesgos, Administración de Cambios, Administración de Configuración. • El proceso de ventas, proceso de gestión de calidad, proceso de producción, etc. • El criterio definido para identificar el resto de los procesos.

1.8 Diseño de Equipo de Trabajo para el Proyecto “Cine & Video” Escenario El mismo escenario de WBS para el Proyecto “Cine & Video”. Objetivo


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.


2 Etapa 1: Inicio (Alcance)

2.1 WBS para el Proyecto “APPITEL 2.0” Escenario CIRCULO SA ha decidido renovar su aplicación de Atención de Pedidos Telefónicos en dos meses y medio. El Proyecto ya arrancó esta semana y los analistas de PI (la consultora que hará el análisis y el diseño) acaban de tener una reunión con los usuarios principales. A continuación se reproduce la entrevista realizada:

Analista (PI): ¿por qué quieren re-escribir el sistema? Representante de IT (CIRCULO): porque está hecho con tecnología obsoleta y nos resulta muy caro cada cambio que queremos hacer. Analista (PI): ¿podría describirnos la funcionalidad del sistema a grandes rasgos? Usuario (CIRCULO): es un sistema para tomar pedidos telefónicos. Los clientes llaman, se dan de alta, hacen su pedido, informan el método de pago, el horario y domicilio de entrega y allí termina. Representante de IT (CIRCULO): hoy el sistema trabaja con una base local de artículos y clientes. La base de artículos requiere actualización manual. Queremos que se actualice automáticamente desde nuestro servidor central. Analista (PI): ¿y los clientes? Representante de IT (CIRCULO): lo mismo, queremos centralizarlos porque en el servidor central tienen una codificación distinta. Esta sección la desarrollará CEREBE. Usuario (CIRCULO): si, eso es muy importante, porque queremos cruzar la información de clientes que compran por distintas bocas de expendio. Es importante para ofrecer un servicio más personalizado. Analista (PI): ¿Qué otra funcionalidad tiene la aplicación? Usuario (CIRCULO): nada más, 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 después 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 más vendidos. Analista (PI): ¿Cuántos reportes? Representante de IT (CIRCULO): 20. Usuario (CIRCULO): Sí, pero no los usamos. Sólo usamos los dos de locales, tres de telemarketers y uno de productos. Necesitamos un par más de Productos. Uno que agrupe por Familia y otro que agrupe por Fabricante. Analista (PI): ¿Cuáles son los otros requerimientos que mencionaba? Usuario (CIRCULO): Te leo la lista que me pasaron los otros usuarios:

1. Que cuando se cuelgue la máquina no tengamos que cargar todo el pedido de nuevo. 2. Que podamos buscar clientes por otros datos además del teléfono: Domicilio, nombre, DNI,

Cédula, etc. 3. Poder ver rápidamente cuáles son los productos que están de oferta. 4. Tener los precios de los productos actualizados. 5. Poder modificar los pedidos y volverlos a enviar. 6. 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. 7. Búsqueda de artículos por categorías. 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 artículos. La carga de artículos tiene que se muy veloz para que los telemarketers sean productivos.


Nada de mouse. Nada de buscar artículos 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. Que permita pagar con pesos y tickets. 9. 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 están de acuerdo, priorizaremos los nuevos requerimientos. (…) Analista (PI): muchas gracias a todos.

Objetivo Se pide que usted diseñe 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 análisis y termina con la instalación en el Call Center habiendo reemplazado la versión anterior.

• Identifique un responsable de cada bloque de la WBS teniendo en cuenta el equipo de trabajo que armó en el ejercicio Diseño de Equipo de Trabajo para el Proyecto “APPITEL 2.0”

• Efectúe 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 diseñe el plan de versiones y plan de entregas incrementales de la versión 1:

• Plan de Versiones: incluir por cada versión o Alcance: qué incluye o Objetivo principal de esa versión desde el punto de vista del usuario

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


2.3 Planificación de Recursos para el Proyecto “APPITEL 1.0” Escenario CIRCULO SA ha decidido crear un sistema de Atención de Pedidos Telefónicos en tres meses. Es un servicio nuevo para los clientes de CIRCULO. El objetivo es construir el producto en un máximo de 3 meses. Luego hay un período de 15 días planificado para la capacitación e instalación en producción. Las campañas publicitarias ya están 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 planificación:

• WBS (ver figura) • Estimación: 4 personas con diferentes perfiles estimaron las actividades principales:

administración del Proyecto, análisis y diseño, desarrollo y prueba. Esto permite tener una primera estimación construida por perfiles que conocen el tipo de trabajo a realizar (ver tabla)

Hipótesis:

• Calendario requerido por el negocio: 3 meses. • Alcance: el calendario a construir sólo incluye la etapa de construcción (análisis, desarrollo y

prueba). Incluir todo lo necesario para dejar un producto con cero defectos listo para liberar. • Métricas: CIRCULO maneja métricas históricas sobre los Proyectos. Las mismas arrojan la

siguiente relación entre roles para Proyectos de desarrollo de software: o Administración y Seguimiento: 19% del esfuerzo en horas total o Desarrollo: 40% del esfuerzo en horas total o Análisis y Diseño: 14% del esfuerzo en horas total o Prueba: 27% del esfuerzo en horas total (incluye prueba del análisis y el diseño)

Método de Trabajo: se requiere paralelismo entre tareas con el fin de integrar constantemente la solución y acotar el calendario. Dicho de otra manera, comenzar a desarrollar cuando ya se tenga algo de diseño y probar desde el primer día.

Características de la estimación: las estimación ha sido realizada sin tener en cuenta restricciones de calendario o estructuras de equipo de trabajo. Las personas que hicieron la estimación han asumido que las distintas tareas se harán con personal semi-senior.

Información disponible:


Registro de Pago

Cabecera de Pedido

Detalle del Pedido

Construcción

Búsqueda de Artículos

ABM Lista de Artículos

Búsqueda de Cliente

Alta de Cliente

Selección Forma de Pago

Envío del Pedido

Proyecto Pedidos

Telefónicos

Aceptación Puesta en Marcha

Modificación de Cliente

Selección de Banda Horaria

Selección de Local

Doc. de Usuario

Manual de Usuario

Manual de Instalación

Búsqueda de Ofertas

WBS

WBS 1 WBS 2 Jefe de Proyecto Analista Desarrollor

Tester (aplicado a

Análisis)

Tester (aplicado a desarrollo)

Búsqueda de cliente 30 24 70 12 36Alta de cliente 25 20 59 10 30Modificación de cliente 12 10 29 5 15Selección de local 25 20 59 10 30Selección de banda horaria 30 24 70 12 36Búsqueda de artículos 50 40 117 20 60ABM lista de artículos 87 70 205 36 105Búsqueda de ofertas 37 30 88 15 45Selección de forma de Pago 12 10 29 5 15Envío del Pedido 57 46 135 23 69Manual de Usuario 5 4 12 2 6Manual de Instalación 4 3 9 2 4

375 301 882 154 450 2.161Total

Cabecera del Pedido

Detalle del Pedido

Registro de Pago

Documentación de Usuario

17%

14%7%

21%

41%

Jefe de ProyectoAnalistaDesarrollorTester (aplicado a Análisis)Tester (aplicado a desarrollo) 0 50 100 150 200 250 300 350

Analista

Tester(aplicado

a Análisis)

0 200 400 600 800 1.000

Desarrollor

Tester(aplicado adesarrollo)

Estimación


Perfil Valor de HoraProject Leader 20Desarrollador 12Analista 15Tester 12Desarrollador Senior 15Analista Senior 18Tester Senior 15

Tabla para cálculo de costos 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 además si tienen asignación tiempo completo o tiempo parcial. • Costo del Proyecto: de Recursos Humanos solamente. Se requiere un análisis para fundamentar

las diferencias entre el costo que se obtiene directamente de la estimación versus el costo final que obtiene luego de diseñar el equipo de trabajo.

2.4 Propuesta para el Proyecto “Help Desk” Escenario La empresa BPF ha decido encarar un Proyecto para la construcción 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 estimación:

• Objetivo del Proyecto: documento adjunto generado por BPF • Minuta de reunión de Relevamiento: PI ha realizado una reunión para obtener un poco más de

detalle con el fin de hacer una estimación más acertada. BPF necesita la propuesta para la semana próxima y parece difícil conseguir alguna otra reunión.


Objetivo del Proyecto

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 unificación 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 líneas generales, podemos decir que básicamente 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 envíe 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. Básicamente debemos soportar de entrada el registro de los pedidos hasta que finalmente podamos hacer un análisis estadístico y desarrollar nuestro SLA (acuerdo de nivel de servicio). Más detalle: registro de incidentes, derivación, administración de estados, alarmas, etc.

Ing. Oscar López Jefe de Soporte Tecnológico

[email protected] BPF S.A.

Beneficios para la Farmacia

BBBPPPFFF


Minuta de Reunión de Relevamiento Objetivo

Definir:

• WBS: WBS del Proyecto. Este material será presentado en la propuesta para marcar los límites del Proyecto.

• Estimación: planilla de estimación en horas discriminada por rol y WBS. Es de uso interno. Las planillas de estimación de PI poseen habitualmente el último nivel de la WBS como fila y los distintos roles como columna. La estimación se hace en horas hombre.

• Cotización: precio del Proyecto obtenido de la estimación 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: identificación de Hitos Facturables del Proyecto. Comúnmente, PI factura cada 3 o 4 semanas.

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 básicas de cualquier herramienta de Help Desk. Nos ha pedido que incluyamos en la herramientas funcionalidades típicas, 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 Posibilidad de Análisis estadístico histórico de incidentes o Alarmas para los operadores de Help Desk o Escritorio de incidentes que permita filtrar y priorizar de diferentes maneras o Reportes e indicadores estándar o Impresión de informes de tickets para el área de soporte técnico. El objetivo es que

cada persona de soporte tenga su lista de tickets a atender en el día. • 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 específico, pero le gustaría que esté operativa en Marzo de 2004. Varios:

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


• Equipo de Trabajo: definición 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 completarán 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 análisis inicial de riesgos incluyendo exposición, responsable, tratamiento y contingencia de cada uno. Cuantificar los riesgos que correspondan. Corregir la propuesta de acuerdo a este análisis 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, cuál es su función. • Alcance del Sistema: qué incluye y qué no incluye. • Organización Usuaria: quiénes serán los usuarios del sistema. • Identificación 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. Según crea conveniente.

• Principales entidades de información: modelo de datos o identificación de entidades de alto nivel.

• Alternativas de Solución: descripción y comparación de alternativas de solución, identificando: o Visión Funcional o Visión Técnica


2.7 Planificación de Recursos para el Proyecto “CPP 1.0” Escenario PI ha encarado un Proyecto para la construcción de una herramienta de Control de Proyectos, CPP 1.0. Cuenta con una estimación preliminar que no tiene en cuenta calendario ni skills del equipo de trabajo:

Analista Desarrollador Tester Project Leader Total

1Creación de WBSEstimación de HH en WBS

100 600 300 200 1.200

2 Carga de HH RealesInforme de % de avance en WBS

100 600 300 200 1.200

3Reporte Presupuestado vs RealReporte Earned Value

80 480 240 160 960

4ABM RecursosABM Valor de HH por Recurso

40 240 120 80 480

3.840

Entrega Incremental

Hipótesis 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 optimización del uso de recursos. Aclare en cada caso si utiliza recursos seniors o juniors.

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12Mes 5 Mes 6

SkillMes 1 Mes 2 Mes 3 Mes 4

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 fusión 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 Córdoba. La dirección de CV ha creado la nueva tarjeta CV Plus, que permitirá a los clientes obtener puntos que podrán canjear por premios: ofertas especiales y descuentos. La CV Plus identifica unívocamente al cliente,


permitiendo que el sistema haga sugerencias especialmente orientada a él. Es parte de una estrategia de segmentación de clientes. El sistema de los Video Clubes se reconstruirá por completo. El sistema de los cines será modificado sólo en las funcionalidades que sean necesarias. Ambos sistemas deberán tener lectores ópticos para leer el código de barras de la CV Plus y reconocer automáticamente 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 trabajarán con BD locales que se actualizarán todas las noches con las novedades de los clientes. Para este proceso se contará con una BD de datos central. Las sucursales envían la información a la central y reciben luego la actualización. 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 además propuestas orientadas al cliente:

• Preferencias de actores: si vio 3 veces películas 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á además realizar todas sus funciones habituales: registro del pedido, emisión del ticket de venta, actualización de stock local de la sucursal luego de la venta. Se desea agregar la posibilidad de leer (con un lector óptico) las devoluciones de películas. Debe emitir además un informe de devoluciones pendientes, con el teléfono del cliente para hacer reclamos. El proceso de actualización diaria, además de actualizar la información de clientes, actualiza la información de precios de alquileres (el mismo precio para todas las sucursales) y la información de Stock: el ABM de películas 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 múltiples de precios:

• Todas las películas nuevas, estrenadas en determinada fecha • Todas las películas viejas, anteriores a una fecha. • Asignaciones individuales. Aquí se cargan las ofertas y los descuentos por uso de puntos.

Se debe permitir además 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, teléfono o nombre. Para acceder a las ofertas, debe presentar el DNI o la cédula. Nota sobre la infraestructura: no habrá cambios en la infraestructura de las sucursales, salvo por la adquisición 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 descripción. Considere que la WBS debe permitir

hacer una estimación


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 duración de 7 meses (implementación 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 Diseño 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 descripción. Considere que la WBS debe permitir

hacer una estimación

2.11 Planificación 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 programación. WSD no cuenta con desarrolladores que conozcan más de un lenguaje de programación. Usted debe definir el equipo de trabajo necesario para realizar el trabajo, teniendo en cuenta la siguiente lista de restricciones:

a. El análisis y diseño está siendo realizado por SPAZIO Argentina y estará completo para el momento en que comiencen los desarrollos: principios de Julio de 2004

b. La empresa DIM realizará el QC, el cual se divide en tres etapas: A. Prueba en paralelo mientras dure el desarrollo B. Estabilización de cada una de las aplicaciones C. Pruebas de integración entres todas las aplicaciones (las 3 desarrolladas por WSD y otras

desarrolladas por otras consultoras) c. Todos los desarrollos deberán terminar a más tardar a fines de enero de 2005 debido a:

A. Febrero está reservado como período de estabilización de cada una de las aplicaciones y se considera que el código de las mismas está completo

B. Marzo y Abril están reservados para las pruebas de integración d. WSD deberá proveer recursos para el desarrollo de las aplicaciones y para las correcciones de

defectos durante los períodos de estabilización y prueba integral e. 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


B. La aplicación 1 debe terminar a más tardar a fines de Noviembre de 2004 por un tema de dependencias

f. Personal de WSD ha realizado una estimación atómica, que no considera estructura de equipo de trabajo, temas de calendario, etc. El resultado de esta estimación es:

A. Aplicación 1: 2.500 horas B. Aplicación 2: 2.500 horas C. Aplicación 3: 3.000 horas D. Total: 8.000 horas E. Estas estimaciones no incluyen los tiempos de corrección de defectos para las etapas de

estabilización y prueba de integración F. 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 administración 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.

Asignación de recursos

Jul Ago Set Oct Nov Dic Ene Feb Mar AbrRol / Nivel

2004 2005

2.12 Planificación de Recursos para el Proyecto “Comisiones” Escenario Su empresa, PI, ha sido contratada para el desarrollo de una aplicación de software que calculará las comisiones a pagar a los vendedores de una compañía. Usted debe definir el equipo necesario para realizar el trabajo y así poder costear el Proyecto. La estimación inicial de tareas es la siguiente:

- Módulo 1: 400 HH de desarrollo, 200 de QC, 100 de análisis - Módulo 2: 400 HH de desarrollo, 200 de QC, 100 de análisis - Administración y seguimiento: 280 HH

Objetivo Genere dos equipos de trabajo de acuerdo a estas alternativas, utilizando hipótesis y justificaciones:

A) Minimizando el calendario


Ene Feb Mar Abr May Jun Jul Ago Sep OctRol / Nivel

Meses

B) Minimizando la cantidad de recursos



Ene Feb Mar Abr May Jun Jul Ago Sep OctRol / Nivel

Meses

2.13 WBS para el Proyecto “BETA” Escenario El mismo escenario de Diseño del Equipo de Trabajo para el Proyecto “BETA”. Objetivo Construya la WBS identificando el rol responsable de cada ítem.

2.14 Planificación de recursos para el Proyecto “25 de Mayo Delivery” Escenario La librería mayorista “25 de Mayo” ha contratado a su empresa, PI, para construir un software para la administración de los pedidos telefónicos de sus clientes. Ya se realizó una estimación inicial, donde se definió la WBS y el esfuerzo de cada rol necesario para llevar a cabo el Proyecto. Hipótesis:

No se incluye instalación en producción de la aplicación.

WBS 1 WBS 2 Jefe de Proyecto Analista Desarrollor

Tester (aplicado a

Análisis)

Tester (aplicado a desarrollo)

Búsqueda de cliente 30 24 70 12 36Alta de cliente 25 20 59 10 30Modificación de cliente 12 10 29 5 15Selección de local 25 20 59 10 30Selección de banda horaria 30 24 70 12 36Búsqueda de artículos 50 40 117 20 60ABM lista de artículos 87 70 205 36 105Búsqueda de ofertas 37 30 88 15 45Selección de forma de Pago 12 10 29 5 15Envío del Pedido 57 46 135 23 69Manual de Usuario 5 4 12 2 6Manual de Instalación 4 3 9 2 4

375 301 882 154 450 2.161Total

Cabecera del Pedido

Detalle del Pedido

Registro de Pago

Documentación de Usuario

17%

14%7%

21%

41%

Jefe de ProyectoAnalistaDesarrollorTester (aplicado a Análisis)Tester (aplicado a desarrollo) 0 50 100 150 200 250 300 350

Analista

Tester(aplicado

a Análisis)

0 200 400 600 800 1.000

Desarrollor

Tester(aplicado adesarrollo)

Estimación

Objetivo


Efectúe una planificación 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 Facturación y Contabilidad FOCUS por el sistema PARKING. Esta es una decisión corporativa, y por razones legales, el nuevo sistema PARKING debe estar en producción dentro de 4 meses. La fecha es inamovible, el incumplimiento de la misma generaría una multa impensable para CIRCULO SA. PI ha sido contratada por CIRCULO SA para que construya el SISTEMA K, cuyo objetivo es integrar la información 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 construcción de los siguientes módulos:

• Construcción del Sistema K que incluye: o Un módulo de procesamiento para cada una de las 7 aplicaciones origen o Un módulo para generar la salida para PARKING o Un módulo de monitoreo en línea del procesamiento o Un módulo de reprocesamiento o Un módulo de auditoria

• Extracción: modificación de las 7 aplicaciones origen para que puedan generar la información de pagos en el formato definido por el Sistema K

El Proyecto K no incluye la construcción de los siguientes módulos: • Carga: Construcción del proceso que tome la salida del Sistema K para cargarla en el sistema

PARKING. Este módulo será construido por SPAZIO, empresa que tiene a cargo todos los desarrollos sobre el Sistema PARKING.

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 integración, no intervendrán usuarios finales, pero participará personal del área de desarrollo de CIRCULO SA para ayudar a entender los requerimientos y las características de las 7 aplicaciones. El personal de CIRCULO SA no tiene conocimiento sobre PARKING, pero SPAZIO proveerá toda la información que PI necesite. Para el Sistema K se utilizará tecnología 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 Producción el Sistema K con las extracción 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 Producción el Sistema K con las extracción 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:

SistemaK

Aplicación Origen 1 Extracción Archivo

Archivo PARKINGCarga

Aplicación Origen 7 Extracción Archivo

(...)

PI SPAZIO

Proc. 1

Proc. 7


• 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 día) • Pedro: tester junior (full time)

El estado actual del Proyecto es no iniciado. Sólo se ha escrito el alcance. Debe iniciarse la etapa de análisis y de arquitectura global del Sistema K. PI no controla a SPAZIO. El alcance de PI incluye sólo el Sistema K, aunque obviamente debe relacionarse con el resto de los involucrados. Objetivo: Diseñe la WBS para el Proyecto K, identificando responsables para cada ítem.

2.16 WBS para el Proyecto “Certificación ISO” Escenario El mismo escenario de Diseño del Equipo de Trabajo para el Proyecto “Certificación ISO”. Objetivo Construya la WBS identificando el rol responsable de cada ítem.

2.17 Planificación de Recursos para el Proyecto “Cine & Video” Escenario El mismo escenario de WBS para el Proyecto “Cine & Video”. Objetivo Planificar la asignación de recursos que participarán en el Proyecto.


3 Etapa 2: Organización

3.1 Calendario Cliente / Distribución de Presupuesto para el Proyecto “APPITEL 1.0”

Escenario El mismo escenario de Estimación de Recursos para el Proyecto “APPITEL 1.0”. Se toma como hipótesis que la resolución del ejercicio Estimación de Recursos para el Proyecto “APPITEL 1.0” ha sido aprobada y por lo tanto constituye la restricción 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 Calendario de alto nivel con hitos principales del Proyecto. o Deben figurar los tres meses del Proyecto (que abarcan desde el inicio hasta la etapa de

construcción finalizada) o Deben ser hitos que tengan validez para el usuario. No incluye hitos internos. o Por cada hito incluir responsable del hito. o 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 Número de entrega o Contenido o Objetivo de la entrega para el cliente

S1 S2 S3 S4 S1 S2 S3 S4 S5 S1 S2 S3Hito 1 Responsable xHito 2 Responsable xHito 3 Responsable x...

Mes 2 Mes 3Hito Responsable Fecha Mes 1

Formato sugerido para el calendario

Para poder armar este calendario, usted deberá distribuir el presupuesto de horas hombres obtenido en el ejercicio Estimación de Recursos para el Proyecto “APPITEL 1.0”. Para ello deberá generar para uso interno la siguiente planilla:

• Distribución de Esfuerzo: o Tareas y Fechas o Recursos asignados o Presupuesto asignado a cada recurso


Tarea Recurso Mes 1 Mes … TotalSemana 1 Semana 2 Semana 3 Semana …

Tarea 1 Total Tarea 30 25 55Tarea 1 Recurso 1 asignado 10 5 15Tarea 1 Recurso 2 asignado 20 20 40Tarea 1 Recurso …Tarea 2 Total TareaTarea 2 Recurso …Tarea … Total TareaTarea … Recurso …

Formato sugerido para distribución de esfuerzo

3.2 Calendario Cliente para el Proyecto “DATATEL” Escenario El mismo escenario de Diseño 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 Diseño 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 Calendario de alto nivel con hitos principales del Proyecto. o Deben figurar los dos meses y medio del Proyecto (que abarcan desde el inicio hasta el

final, incluyendo instalación en producción del producto) o Deben ser hitos que tengan validez para el usuario. No incluye hitos internos. o Por cada hito incluir responsable. o Este calendario será utilizado como control durante las reuniones en que se informe el

avance del Proyecto al cliente

Hipótesis adicionales a las del escenario: • Hay tres entregas incrementales. Surgieron de la distribución de presupuesto que hizo PI:

o 1. Prototipo: semana 3 (no requiere ambiente de aceptación) o 2. Datawarehouse construido: semana 5 o 3. Procesos de extracción y carga / Interfaces: semana 7 (requiere interfaces)

• El producto trabajará con un volumen importante. Se requieren pruebas de performance a cargo de PI que deberán reflejarse en el calendario. CIRCULO proveerá datos de 1 año para realizar las pruebas una vez que haya terminado de construir las interfaces.

• Existe un equipo de aceptación que hay que instalar y configurar. Se utilizará en los ambientes de CIRCULO y la instalación estará a cargo de ellos.

• Se debe adquirir el equipo para producción. Esto es responsabilidad de CIRCULO GLOBAL. La compra lleva 1 mes aproximadamente y requiere una estimación 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 producción.


S1 S2 S3 S4 S1 S2 S3 S4 S5 S1 S2 S3

Hito 1 Responsable xHito 2 Responsable xHito 3 Responsable x...



3.3 Calendario Cliente para el Proyecto “APPITEL 2.0” Escenario El mismo escenario de Diseño 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 Diseño 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 Deben figurar los dos meses y medio del Proyecto (que abarcan desde el inicio hasta el

final, incluyendo instalación en producción del producto) o Deben ser hitos que tengan validez para el usuario. No incluye hitos internos. o Por cada hito incluir responsable del hito. o Este calendario será utilizado como control durante las reuniones en que se informe el

avance del Proyecto al cliente

Hipótesis adicionales a las del escenario: • Este Proyecto incluye sólo la versión 1 según se definió en la resolución del ejercicio Versiones y

Entregas Incrementales para el Proyecto ”APPITEL 2.0” • Existe un equipo de aceptación que hay que instalar y configurar. Se utilizará en los ambientes de

CIRCULO y la instalación estará a cargo de ellos. • Para Producción se utilizará el actual equipo del Call Center. La instalación no es en paralelo, se

baja la versión 1.0 e inmediatamente después se habilita la versión 2.0 • El Proyecto comienza el 1/9/2003 y termina el 7/11/2003 con el producto instalado en producción.

S1 S2 S3 S4 S1 S2 S3 S4 S5 S1 S2 S3

Hito 1 Responsable xHito 2 Responsable xHito 3 Responsable x...



3.4 Calendario Build Diario para el Proyecto “APPITEL 1.0” Escenario


El mismo escenario de Planificación de Recursos para el Proyecto “APPITEL 1.0”. Tomar como base el calendario de cliente y la distribución de esfuerzo del ejercicio Calendario Cliente / Distribución 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 pequeños (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 porción de código a ser liberada por un recurso.

o Cada recurso no debería pasar más de 3 días sin un hito o No se requieren hitos diarios. Habrá build diario, pero no todos los días se entregará

funcionalidad nueva. A veces sólo se entregarán correcciones de defectos. o No incluir en este calendario la etapa de análisis.

• Recurso responsable del hito. • Fecha.

Fecha Recurso 1 Recurso 2 Recurso 301/01/0302/01/03 Hito 103/01/0304/01/03 Día por examen05/01/0306/01/0307/01/0308/01/0309/01/0310/01/0311/01/0312/01/0313/01/0314/01/0315/01/0316/01/0317/01/0318/01/0319/01/03 Liberación Entrega 1

Estabilización

Formato sugerido para calendario de Build Diario

3.5 Diseño de Indicador de Funcionalidad Completa para el Proyecto “APPITEL 1.0”

Escenario El mismo escenario de Planificación 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:


1. Indicador de Funcionalidad Completa: construya el indicador a través de los siguientes pasos:

• Dividir al producto en partes. Estas partes podrían ser las porciones de código 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 liberación de la funcionalidad por parte del equipo de desarrollo. • Estimar la fecha de aprobación de la funcionalidad por parte de QC • Graficar el indicador con las fechas presupuestadas en donde:

1. El eje horizontal indique fechas 2. El eje vertical indique puntos de funcionalidad acumulados. Los puntos de funcionalidad se

obtienen de sumar la complejidad estimada a la fecha. 3. Existan dos curvas: una de liberación estimada de desarrollo y otra de liberación estimada

de QC. Ambas curvas deben llegar a la suma de puntos de funcionalidad.

0

5

10

15

20

25

30

35

40

45

Sem 1

Sem 2

Sem 3

Sem 4

Sem 5

Sem 6

Sem 7

Sem 8

Sem 9

Sem 10

Sem 11

Sem 12

Sem 13

Sem 14

FC Desa Estimado

FC QC Estimado

Ejemplo de gráfico de FC

2. Análisis preliminar del Indicador: analice el indicador con el objetivo de verificar si el calendario está correctamente armado. • Analice la separación de las curvas y efectúe correcciones • Analice la pendiente de las curvas y efectúe correcciones • Analice otros puntos que considere convenientes • Analice si este indicador le servirá para controlar el Proyecto. Ventajas y desventajas.

3. Comparación entre FC y Esfuerzo: construya un gráfico acumulado de esfuerzo y compárelo con el de funcionalidad entregada. • Grafique el esfuerzo acumulado en función del tiempo en donde:

1. El eje horizontal indique fechas 2. El eje vertical indique horas hombre acumuladas. 3. Existan dos curvas: una de esfuerzo estimado de desarrollo y otra de esfuerzo estimado de

QC. 4. Mezcle este gráfico con el anterior utilizando un eje secundario

• Analice 4. Agregado de liberaciones al usuario en el gráfico de FC: agrega las curvas de funcionalidad

liberada al usuario y aprobada por el usuario según indica el calendario que armó para el Cliente • Grafique las curvas nuevas • Analice


5. Comparación final con Esfuerzo total: analice finalmente las curvas principales de esfuerzo a lo largo del Proyecto • Grafique el esfuerzo sin acumular en función del tiempo en donde:

1. El eje horizontal indique fechas 2. El eje vertical indique horas hombre acumuladas. 3. Existan cinco curvas:

i. Administración y Seguimiento ii. Análisis iii. Revisión de Análisis iv. Desarrollo v. QC

• Analice 6. 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 Diseño 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 podría 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 Diseño 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 técnicas.


3.8 Plan de Proyecto para el Proyecto “APPITEL 1.0” Escenario El mismo escenario de Planificación 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: distribución de costos • Proceso: definición del proceso que utilizará para construir el producto • Plan de Calidad • Plan de Comunicación • Proceso de Administración de Cambios • Proceso de Administración de la Configuración • Proceso de Administración de Riesgos • Métricas

Tip: un documento de este tipo ocupa entre 15 y 25 páginas aproximadamente.

3.9 Plan de Adm. de Cambios para el Proyecto “APPITEL 2.0” Escenario El mismo escenario de Diseño de Equipo de Trabajo para el Proyecto “APPITEL 2.0”. Objetivo

Definir el Pan de Administración de Cambios para el Proyecto “APPITEL 2.0”. Incluir:

• Alcance: ítems bajo control de cambios. • Proceso: tareas, secuencia de tareas, roles, documentación 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 implementación en producción.

3.10 Plan de Calidad para el Proyecto “APPITEL 2.0” Escenario


El mismo escenario de Diseño de Equipo de Trabajo para el Proyecto “APPITEL 2.0”. Objetivo

Definir el Plan de Administración de la Calidad para el Proyecto “APPITEL 2.0”. Incluir:

• Alcance: qué incluye y qué no incluye el Proyecto. Tipos de prueba: funcional, técnica, aceptación, etc.

• Proceso: tareas, secuencia de tareas, roles, documentación 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 implementación en producción.

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 módulo Video Club. Esta primera entrega del módulo Video Club estará formada por:

Ítem Descripción

Alta de Cliente Datos básicos del cliente, domicilio y teléfono, generación automática de un código de barras que se pega en la tarjeta, información del servicio que presentó el cliente como garantía, datos que pueden servir para la segmentación de clientes (edad, grupo familiar, sexo, barrio). Cantidad de tarjetas adicionales que solicita.

Reconocimiento del Cliente manual

Según enunciado.


Reconocimiento del Cliente óptico

Comunicación (lectura) del dispositivo óptico, procesamiento del código de barras para identificar el cliente en la base, apertura automática de la pantalla de pedido con los datos del cliente reconocido.

Modificación de datos del Cliente

Modificación de datos y posibilidad de pedir más tarjetas adicionales

Emisión de la CV Plus Impresión del código de barras en la cantidad de etiquetas solicitadas. Las etiquetas se pegan luego en una tarjeta

Hipótesis:

• El Análisis y Diseño 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 duración desde el inicio de la construcción hasta la liberación para aceptación

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 Líder del Proyecto de construcción de una herramienta para Administración de Proyectos. La primera entrega incremental estará formada por las siguientes funcionalidades:

Ítem Descripción

Base de Datos Base de Datos para esta entrega: tablas Proyecto, Tarea, Recursos, Tipo de Tarea, Recursos x Tarea, Horas Cargadas

Pantalla ABM Proyecto Nombre, Descripción, Fecha de Inicio y Fin

Pantalla Administración de Tareas

Alta y Modificación de Tareas de un Proyecto. Nombre, Descripción, Fechas (*) de Inicio y Fin, Tipo de Tarea y Recursos (**) (*) Incluye validación de que las fechas estén 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 día.

Pantalla ABM Tipo de Tareas Nombre y Descripción Pantalla ABM Recursos Nombre y Descripción

Diseño de Pantalla Administración de Tareas


Nombre:

Descripción:

Fecha Inicio:

Fecha Fin:

Tipo de Tarea:

Recursos:

05/11/2004

05/11/2004

<seleccione de la lista>

Alejo

Valentina

Adolfo

<agregue un recurso>

Eliminar

Eliminar

Eliminar

Aceptar Cancelar

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

• El Análisis y Diseño 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á diseñado. • 3 semanas de duración desde el inicio de la construcción hasta la liberación para aceptación

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.

Fecha:

Proyecto / Tarea: 4,00

05/11/2004

Proyecto ALFA Análisis Eliminar

Eliminar

Eliminar

Aceptar Cancelar

5,00Proyecto ALFA Diseño

<seleccione> <seleccione>

9,00Total:

Diseño Pantalla Carga de Horas


• Construya un calendario orientado al Cliente para presentar en la reunión 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.


4 Etapa 3: Ejecución y Control

4.1 Análisis de Indicadores para el Proyecto “CE-EME” Escenario La empresa ERMIA S.A. está construyendo un producto de software relacionado con una práctica de Project Management. Se trata de la primera versión del producto que será instalada a modo de prueba en el cliente SANTE el 13 de diciembre de 2002. La etapa de construcción de esta primera versión se inició el 15 de octubre de 2002. Previamente hubo una etapa de análisis y diseño 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 próximos hitos.

• 29/11/2002: segunda liberación para aceptación 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 están actuando como representantes de usuarios. Ya hubo una primera aceptación por parte de este equipo y esta será la segunda entrega para aceptación.

• 06/12/2002: siguiendo con el razonamiento anterior, en esta fecha se instalará una versión beta en ERMIA para que sea utilizada en ambiente productivo antes de la liberación final.

• 13/12/2002: finalmente en esta fecha se liberará la primera versión comercial para instalar en SANTE. Esta fecha es inamovible porque se trata de un compromiso adquirido con SANTE.

Indicador de Funcionalidad Completa:

Indicador de FC del Proyecto CE-EME

El Indicador de FC muestra 4 curvas:

0

5

10

15

20

25

30

35

40

15-10-2002

17-10-2002

22-10-2002

24-10-2002

28-10-2002

30-10-2002

1/11/2002

5/11/2002

7/11/2002

11/11/2002

13/11/2002

15/11/2002

19/11/2002

21/11/2002

25/11/2002

27/11/2002

29/11/2002

3/12/2002

5/12/2002

9/12/2002

11/12/2002

13/12/2002

Código Com pleto Ptos. ESTIM ADOS Acum uladosCódigo Com pleto Ptos. REALAcum ulado Funcionalidad liberada Ptos. ESTIM ADOS Acum uladosFuncionalidad liberada Ptos. REALAcum ulado

15-11Aceptación 1

29-11Aceptación 2

6-12 Producción 1 13-12

Producción 2


• Código Completo – Puntos Estimados acumulados: liberación planificada de funcionalidad por el equipo de desarrollo

• Código Completo – Puntos Reales acumulados: liberación real de funcionalidad por el equipo de desarrollo

• Funcionalidad Liberada – Puntos Estimados acumulados: liberación planificada de funcionalidad por el equipo de QC

• Funcionalidad Liberada – Puntos Reales acumulados: liberación real de funcionalidad por el equipo de QC

Indicador de Evolución de la Prueba:

Indicador de Evolución de la Prueba del Proyecto CE-EME

Estado/Severidad A B C D TotalAbierto 7 10 40 19 76Analizado 0 0 3 0 3Revisado 0 0 0 0 0Corregido 2 2 3 1 8Cerrado 81 89 170 132 472No Reproducible 0 0 0 0 0Suspendido 0 1 0 5 6Total 90 102 216 157 565

El Indicador de Evolución 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 quedarán para la próxima versión.

Indicador de Cobertura de la Prueba:

TotalPromedio de Detectados por día 11,86Promedio de Cerrados por día 9,791Relación Cerrados / Total 83%

Últimos diez díasPromedio de Detectados por día 8,7Promedio de Cerrados por día 8,1Relación Cerrados / Total 93%

Últimos cinco díasPromedio de Detectados por día 9,2Promedio de Cerrados por día 10,4Relación Cerrados / Total 113%

Evolución de la Prueba

0

100

200

300

400

500

600

1/ 10 8/ 10 15/ 10 22/ 1 29/ 1 5/ 11 12/ 11 19/ 11 26/ 11

TotalCerradoPendienteSuspendido


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 más lo que aún no se han escrito pero

se estima se escribirán. No figura el valor en el gráfico, pero se estiman alrededor de 1.100. Objetivo Se pide analizar los indicadores en relación a los próximos objetivos del Proyecto identificados por los tres hitos pendientes. El análisis debe incluir:

• Análisis detallado de cada Indicador conteniendo: o Qué se lee? o Cuáles son las posibles causas? o Cuáles son los posibles impactos? o Cuáles son las posibles acciones correctivas?

• Acciones correctivas o Identifique las acciones correctivas a ejecutar

4.2 Análisis 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:

Cobertura de la PruebaPositivos

0

100

200

300

400

500

600

700

800

Planif icados (Activos)DisponiblesCumplidos (Ejecutados + Ejecutados Ok + Ejecutados Error)Ejecutados Ok

Evolución de la Cobertura de la PruebaPositivos

0

100

200

300

400

500

600

700

800

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

Planificados DisponiblesCumplidos Ejecutados OK


05

1015202530354045

FC Desa Estimado FC Desa RealFC QC Estimado FC QC Real

FC Desa Estimado 0 0 5 8 13 20 24 29 33 38 41 41 41 41

FC Desa Real 0 0 0 0 4 6 11

FC QC Estimado 0 0 0 5 8 13 20 24 29 33 38 41 41 41

FC QC Real 0 0 0 0 1 1 4

Sem 1

Sem 2

Sem 3

Sem 4

Sem 5

Sem 6

Sem 7

Sem 8

Sem 9

Sem 10

Sem 11

Sem 12

Sem 13

Sem 14

Indicador de FC

0

200

400

600

800

1000

1200

Esfuerzo Real Esfuerzo Estimado

Esfuerzo Real 40 80 140 230 340 440 660

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

Sem 1

Sem 2

Sem 3

Sem 4

Sem 5

Sem 6

Sem 7

Sem 8

Sem 9

Sem 10

Sem 11

Sem 12

Sem 13

Sem 14

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 están consumiendo las horas según lo previsto, con un pequeño desvío. Objetivo Analizar la información de ambos indicadores con el objetivo de:


• 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 más 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. Hipótesis:

• Horas de PL = 15% • Horas de Analista = 15% • Horas de Desarrollador = 45 % • Horas de Tester = 25 % (no incluyen revisión de análisis. El análisis es revisado en forma cruzada

entre los analistas del Proyecto y está incluido dentro del 15% de horas de analista)

4.3 Re-planificación del Proyecto “GENERIC1” Escenario El mismo escenario de Análisis de Indicadores de FC y Esfuerzo del Proyecto “GENERIC1”. Objetivo Luego de analizar los indicadores, re-planifique el Proyecto teniendo en cuenta que sólo se admite 1 semana de desvío. 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. • Rediseñar el equipo de trabajo.

o Organigrama con la nueva estructura o Gantt que indique la incorporación de nuevos recursos y la desafectación de los mismos

• Identifique los riesgos de la re-planificación Hipótesis:

• Puede agregar más horas y más 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 Diseño de Equipo de Trabajo para el Proyecto “DATATEL”. Objetivo Se pide que diseñe el esquema de reuniones de avance del Proyecto, incluyendo:


• 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 reunión definir objetivo, frecuencia, duración, horario, participantes, quién conduce la reunión y qué material se presenta.

• Incluir además la reunión de inicio del Proyecto o de etapas.

4.5 Estabilización de Liberación a Producción para el Proyecto “APPITEL 1.0”

Escenario El mismo escenario de Planificación 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) están reservadas para Estabilización y Aceptación. Se encuentra actualmente en la recta final y se presentan entre otros los siguientes defectos:

• Defecto 989: durante el proceso de diseño, un diseñador olvidó un campo que almacena una opción del cliente respecto a cada artículo pedido. Esa opción permite al cliente identificar si el artículo 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 artículos un artículo que se vende por peso. Esto sólo ocurre cuando se está ejecutando en ese momento el proceso trimestral de actualización global del maestro. La primera ejecución de este proceso se realizará exactamente tres meses después de instalado el producto en producción.

• Defecto 1000: Ocasionalmente, cuando el telemarketer abre una segunda instancia de la aplicación, la primera instancia se cierra sin aviso, perdiendo cualquier información no salvada.

• Defecto 1003: Hay varios errores de ortografía 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

próxima versión). Realice esta clasificación en las siguientes situaciones:

1. Estos defectos se detectan al fin de la semana 8. 2. Estos defectos se detectan al fin de la semana 9. 3. Estos defectos se detectan al fin de la semana 10 (inicio de estabilización). 4. Estos defectos se detectan al fin de la semana 11 (mitad de la estabilización) 5. Estos defectos se detectan a mediados de la semana 12 (2 días antes de liberar)

4.6 Estabilización de Liberación a Aceptación para el Proyecto “APPITEL 1.0”

Escenario


El mismo escenario de Planificación 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) están reservadas para Estabilización y Aceptación. Se encuentra actualmente en la recta final y se presentan entre otros los siguientes defectos:

• Defecto 990: no funciona la aplicación para las dos terceras partes de los clientes. Aquellos cuyo apellido comienza con las letras F a la Z. Se estima 4 a 5 días para la corrección de este defecto.

• Defecto 991: No se ha terminado con la Baja de Cliente. Se necesitan 3 días más. • Defecto 1001: Luego de la integración se obtiene un error al llegar a la sección de Forma de Pago

que hace caer la aplicación. Se estiman 2 días de corrección. • Defecto 1002: Hay problemas graves con las búsqueda de artículos en algunos casos. Esta es la

funcionalidad más importante porque la mayor parte del tiempo del usuario se gasta en esta sección, y la velocidad de búsqueda determina la velocidad de toma del pedido. Se estima un día de corrección.

El usuario sólo ha visto el prototipo de la aplicación y esta aceptación es clave antes de salir a producción. La fecha de producción 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 corregirán durante la estabilización o en la

próxima versión • Indique si en algún caso conviene mover la fecha de aceptación

Realice esta clasificación en las siguientes situaciones:

1. Estos defectos se encuentran el martes (por la mañana) anterior al viernes en que se libera para aceptación. La próxima semana se inicia el período de Aceptación de 2 semanas.

2. Estos defectos se encuentran el jueves (por la mañana) anterior al viernes en que se libera para aceptación. La próxima semana se inicia el período de Aceptación de 2 semanas.

4.7 Tratamiento de Riesgos para el Proyecto “DATATEL” Escenario El mismo escenario de Diseño de Equipo de Trabajo para el Proyecto “DATATEL”. Se trata de un Proyecto de 14 semanas de duración. Las siguientes situaciones se plantean a lo largo del Proyecto:

1. Semana 5: El jefe de Proyecto de CIRCULO se toma 15 días de vacaciones. 2. Semana 8: El usuario manifiesta a través 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. 3. Semana 6: el Sponsor sólo vino al Kick Off y a la primera reunión de avance. 4. Semana 6: hay una semana de retraso en la liberación de código de interfaces por parte de Juan o

Alberto. Manifiestan tener otras prioridades. 5. Semana 7: todo anda bien. El Indicador de FC muestra que se están cumpliendo las fechas. Por otro

lado, también 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 tecnología de Datawarehousing. Es una tecnología nueva para ellos.


7. Semana 8: el indicador registra un retraso. La entrega de código completo se realizará una semana más tarde. Semana 12 en lugar de semana 11.

0

5

10

15

20

25

30

35

40

45

FC Desa Estimado 0 0 5 8 13 20 24 29 33 38 41 41 41 41

FC Desa Real 0 0 0 8 12 20 27

FC QC Estimado 0 0 0 5 8 13 20 24 29 33 38 41 41 41

FC QC Real 0 0 0 3 8 11 22

FC Usuario Est. 0 0 0 0 8 8 8 8 8 8 8 8 41 41

FC Usuario Real 0 0 0 0 8

Sem 1

Sem 2

Sem 3

Sem 4

Sem 5

Sem 6

Sem 7

Sem 8

Sem 9

Sem 10

Sem 11

Sem 12

Sem 13

Sem 14

Indicador de FC - Semana 7 – Aplica al punto 5

Objetivo Se pide hacer un análisis de riesgos para cada una de las situaciones presentadas:

• Si existe un problema determinar la acción correctiva • Si existe un riesgo completar:

o Identificación o Análisis o Planificación o Responsable

4.8 Esquema de reuniones de avance para el Proyecto “APPITEL 2.0” Escenario El mismo escenario de Diseño de Equipo de Trabajo para el Proyecto “APPITEL 2.0”. Objetivo El mismo objetivo de Esquema de reuniones de avance para el Proyecto “DATATEL”.


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 cómo tratar las tareas en ejecución de manera de obtener un indicador lo más preciso posible. Cuenta con la siguiente información:

• Estado de las tareas • Presupuesto • Real hasta la fecha

Estado Tarea Tipo Valor 18-Ago 25-Ago 01-Sep 08-Sep 15-Sep 22-Sep 29-Sep 06-OctTerminada 1 Presupuesto 4Terminada 1 Real 1Terminada 2 Presupuesto 21Terminada 2 Real 9 14 1Terminada 3 Presupuesto 3 18Terminada 3 Real 2 10Comenzada 4 Presupuesto 3 6 6 6 6 6 6Comenzada 4 Real 2 1 7 3 2Comenzada 5 Presupuesto 5Comenzada 5 Real 4 2Comenzada 6 Presupuesto 7 6Comenzada 6 Real 11 0 2No comenzada 7 Presupuesto 15 8No comenzada 7 RealNo comenzada 8 Presupuesto 16 10No comenzada 8 RealNo comenzada 9 Presupuesto 1 1No comenzada 9 RealTerminada 10 Presupuesto 4 2Terminada 10 Real 3 3No comenzada 11 Presupuesto 3 3No comenzada 11 RealTerminada 12 Presupuesto 16Terminada 12 Real 7 23Comenzada 13 Presupuesto 8 30 14Comenzada 13 Real 19 24 7Comenzada 14 Presupuesto 21 14Comenzada 14 Real 12 21Comenzada 15 Presupuesto 7 22Comenzada 15 Real 4 23Terminada 16 Presupuesto 6Terminada 16 Real 1 1 8Terminada 17 Presupuesto 4Terminada 17 Real 4 3Terminada 18 Presupuesto 5Terminada 18 Real 2Terminada 19 Presupuesto 18Terminada 19 Real 2 9 3 0Comenzada 20 Presupuesto 5 5 5 5 5Comenzada 20 Real 2 5 4 2 3No comenzada 21 Presupuesto 18No comenzada 21 RealComenzada 22 Presupuesto 2 2 2 2 2Comenzada 22 Real 6 2 3Comenzada 23 Presupuesto 7 7 7 7 7Comenzada 23 Real 4 8 6 1No comenzada 24 Presupuesto 85No comenzada 24 Real

Detalle de Presupuesto y Real de las Tareas Objetivo Graficar el indicador incluyendo:

• En el gráfico: o BCWS o BCWP (definiendo el tratamiento para las tareas en ejecución) o ACWP o CV


o SV o BAC o EAC o Tendencia de desvío de calendario

• Fuera del gráfico o CPI o SPI

Analizar el indicador. Nota para el alumno:

• Si necesita más información, asuma que el jefe de Proyecto puede suministrarla. Utilice hipótesis. • Consulte en Internet si necesita más información sobre Earned Value.

4.10 Priorización de defectos para el Proyecto “CPP 1.0” Escenario PI se encuentra actualmente en el Proyecto de construcción de CPP 1.0 (ver escenario de Estimación de Recursos para el Proyecto CPP 1.0). Se cuenta con la información de los siguientes defectos:

Defecto Descripción

1001 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 día.

1002 Error de diseño. No se incluyó fecha de valor de HH de los recursos. Se necesita una tabla histórica. Esto tendrá impacto cuando comience a cambiar el valor de HH de los Recursos.

1003 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 sólo el número de estos valores a la fecha actual. Parece ser un nuevo requerimiento, aunque el usuario no piensa lo mismo.

1004 No permite eliminar tareas.

1005 Hay un error de cálculo 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) • Acción a tomar sugerida al usuario (corregir, suspender) en las siguientes etapas:

o Estabilización: última semana del período de estabilización. Hacia fin de la semana se libera para Aceptación.

o Aceptación: última semana del período de aceptación. Hacia fin de la semana se libera para Producción.

• Si la acción es corregir, indique el orden de corrección donde 1 es lo más prioritario. No repita el orden dentro de una misma etapa.

• Justifique su respuesta:

Def. Sev. Etapa Actual Próxima

Etapa Acción Orden Justificación

Estabilización Aceptación 1001

Aceptación Liberación


4.11 Earned Value (teórico) Objetivo Explicar el indicador de Earned Value a través de un caso práctico de no más de 7 tareas en diferentes estados. Explique y muestre los valores de ACWP, BCWP, BCWS, BAC, CV, SV y CPI.

Tarea BCWS BCWP ACWP CV SV CPI BAC

Tarea 1

Tarea 2

Tarea 3

Tarea 4

Tarea 5

Tarea 6

Tarea 7

Total Proyecto

4.12 Análisis de Indicadores para el Proyecto “INDI 1” Escenario Usted es el jefe del Proyecto INDI 1, que posee las siguientes características:

• Inicialmente tenía fecha de fin a mediados de julio • Se hizo una re-planificación que posee fecha de finalización en noviembre • El planificado y real anterior a la fecha de replanificación se igualó. No quiere decir que

originalmente hayan coincidido • Se ha definido lo siguiente para las tres variables de control:

o Funcionalidad: está fija o Calendario: está libre o Costo: es la variable de ajuste. No está totalmente abierta. Se debe controlar cada

adicional de presupuesto para el Proyecto.


La siguiente tabla muestra un poco más de información que el gráfico: Estado según FC Estado detallado % Sub

Estado Descripción del estado

En elaboración 84 puntos = 36 %

En elaboración 36% Actualmente en elaboración por el equipo de desarrollo

Código Completo 19% Código completo, aún sin evaluar por QC, debido a que QC está con otros temas

Calidad en Evaluación

15% Actualmente en evaluación por el equipo de QC

Defectos Críticos 15% Evaluado por QC y con defectos críticos pendientes de corrección

Elaborado 150 puntos = 64%

Liberado por QC 15% Evaluado por QC y con defectos no críticos pendientes de corrección

Earned Value

BAC = $ 3.105.000 Plan (BCWS) = $ 2.181.000 (al 20 de Junio) Actual (ACWP) = $ 2.184.000 (al 20 de Junio) Earned Value (BCWP) = $ 434.700 (al 20 de Junio) Nota: se considera valor ganado a la funcionalidad liberada por QC


Objetivo Hoy es 20 de Junio y usted cuenta con indicadores de Funcionalidad Completa, Evolución de la Prueba y Earned Value. Se pide que presente un diagnóstico del Proyecto y evalúe las acciones correctivas propuestas: Diagnóstico del Proyecto: Evalúe el estado actual del Proyecto haciendo un conciso análisis de las siguientes variables:

o Calendario o Costo o Funcionalidad

Además realice un análisis de la Calidad del producto que se está construyendo. Evaluación 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.

Total

Pendientes

Cerrados

Suspendidos


Incorporar más recursos de QC APROPIADA NO APROPIADA

Motivo Elección

Impacto Calendario

Impacto Costos

Impacto Funcionalidad

Incorporar más recursos de Desarrollo APROPIADA NO APROPIADA

Motivo Elección

Impacto Calendario

Impacto Costos


Suspender temporalmente la corrección de defectos de Severidad C y D APROPIADA NO APROPIADA

Motivo Elección

Impacto Calendario

Impacto Costos


Suspender temporalmente el desarrollo de funcionalidad nueva APROPIADA NO APROPIADA

Motivo Elección

Impacto Calendario

Impacto Costos


Cancelar el Proyecto APROPIADA NO APROPIADA

Motivo Elección

Impacto Calendario

Impacto Costos



4.13 Análisis 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


Objetivo Se necesita hacer un análisis de la historia del Proyecto para concluir en las mejores acciones correctivas para la situación actual. Se pide:

• Análisis de la Historia: evalúe los hechos más 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

Guía de TP - fi.uba.arE1cticas/PI1%20-%20Gu%A1a%20TP%20...Administración y Control de Proyectos I...

Documents

Transcript of Guía de TP - fi.uba.arE1cticas/PI1%20-%20Gu%A1a%20TP%20...Administración y Control de Proyectos I...