Contenido Temtico U-1

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

INDICE Pg.
Objetivos Generales ...........................................................................................4 Captulo I. Estandarizacin de Proyectos ..................................................4 1.1 El PMI .................................................................................................... 4 1.1.1 Que es el PMI ............................................................................. 4 1.1.2 La estandarizacin en los Proyectos............................................. 6 1.1.3 Qu es el PMBOK .......................................................................7 1.2 Usando el PMBOK......................................................................................7 1.2.1 Los Procesos Bsicos .................................................................. 7 1.2.2 Las reas de Conocimiento ......................................................... 8 1.2.3 Identificando las reas ................................................................9 Captulo II. Elaboracin Prctica de un Proyecto........................................9 2.1 Caractersticas de un Proyecto ..................................................................9 2.1.1 Generales ....................................................................................9 2.1.2 Segn el PMI ............................................................................. 10 2.1.3 Ejercicio Prctico ...................................................................... 10 2.2 El Ciclo de Vida de un Proyecto ............................................................. 11 2.2.1 Identificacin de Necesidades.................................................... 11 2.2.2 Soluciones Propuestas ............................................................... 14 2.2.3 Desarrollo del Proyecto ............................................................. 16 2.2.4 Cierre del Proyecto .................................................................... 17 2.3 Las Programacin del Proyecto .............................................................. 19 2.3.1 Actividades ............................................................................... 19 2.3.2 Hitos ......................................................................................... 20 2.3.3 Secuencia de Actividades .......................................................... 21 2.3.4 Diagramacin por Dependencias y Precedencias ....................... 21 2.3.5 La estructura del trabajo ............................................................ 22 2.4 Los Recursos .......................................................................................... 25 2.4.1 Tipos de Recursos ..................................................................... 26 2.4.2 Asignar Tiempos ....................................................................... 27 2.5 Los Costos .............................................................................................. 31 2.5.1 Costos de Recursos.................................................................... 31 2.5.2 Costos de material ..................................................................... 31 2.5.3 Costos Generales del Proyecto ................................................... 31 2.6 El Seguimiento ....................................................................................... 31 2.6.1 Comprobacin de Tareas ........................................................... 31 2.6.2 Actualizacin de Trabajos ......................................................... 32 2.6.3 Comprobacin de Costos ........................................................... 32 2.6.4 Comprobacin de Tiempos ........................................................ 32 2.6.5 Anlisis de la Ruta Crtica ......................................................... 32

U1

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Captulo III Aprendizaje de la Herramienta Microsoft Project 2007 ....... 34 3.1 Aprendizaje bsico de Microsoft Project 2007 ........................................... 34 3.1.1 Definicin y descripcin de la pantalla. Barras de Herramientas .... 3.1.2 Manejo de los Archivos de proyecto .............................................. 3.1.3 Visualizacin de la informacin en vistas ...................................... 3.1.4 Ajuste de la escala temporal .......................................................... 3.1.5 Fecha de Comienzo del Proyecto ................................................... 3.1.6 Calendario del Proyecto Configuracin del Calendario Laboral ..... Bibliografa ..........................................................................................................

U1

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Objetivo General de la Unidad

Conocer conceptos clave de Gestin y Administracin de Proyectos, determinar los elementos del Proyecto tales como Actividades, Recursos, Costos, Planeacin, manejo de la herramienta Microsoft Project etc. Que permitan disear posteriormente en el Microsoft Project. Iniciar el

U1

Contenidos
Captulo I. Estandarizacin de Proyectos Objetivos de captulo:

Conocer el PMI Conocer acerca del PMBOK y sus estndares Conocer los elementos bsicos de un Proyecto Aprender a Interpretar un proyecto

1.1 El PMI 1.1.1 Que es el PMI

Por casi 40 aos, PMI ha defendido el profesionalismo de la gerencia de proyecto en todo el mundo. Con ms de medio milln de miembros y acreditados en ms de 170 ciudades, PMI es la asociacin lder en la gestin de proyectos. El Project Management Institute (PMI) es una asociacin sin fines de lucro, lder en la Industria de la Gerencia de Proyectos, dedicada al progreso y

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

fomento de su aplicacin efectiva a travs de la prctica. Fundada en 1969 en Pensilvania, Estados Unidos de Norteamrica. Actualmente est presente en 172 pases, con ms de 420,000 miembros y profesionales certificados, organizados en 250 Captulos.

Sobre el Captulo PMI LIMA PERU El PMI LIMA PERU Chapter es la representante en el Per de PMI Internacional. Conectando profesionales, empresas, centros de negocio, entidades pblicas, universidades y asociaciones promueve un contacto cara a cara entre colegas de numerosas organizaciones, privadas y pblicas, grandes y pequeas, que trabajan y necesitan de la Gerencia de Proyectos. A travs de las actividades del captulo, pretendemos desarrollar el profesionalismo de la Direccin de Proyectos. El PMI Per Chapter promueve encuentros, reuniones y programas de formacin diseados para desarrollar el conocimiento, la conciencia y la comprensin de los principios, mtodos, tcnicas y herramientas de la Direccin de Proyectos. El PMI est presente en Per desde 1999 en nuestro pas. Los profesionales que lo conforman pertenecen a distintos sectores, tales como minera, banca, salud, informtica y construccin. Los Proyectos en el Mundo En todo el mundo el nmero de proyectos aumenta constantemente y es por ello necesario ms personas acreditadas en la gestin de proyectos. Solamente en el Golfo Prsico y el Mar de China - donde ciudades enteras se estn construyendo, al parecer la noche a la maana - se proyecta una falta de profesionales en proyectos de 6 millones para el 2013. Esto sumado al hecho actual que, de los 20 millones de personas que participan en proyectos en todo el mundo, solamente un milln tienen algn reconocimiento formal de entrenamiento sobre como ejecutar exitosamente estos proyectos. En este escenario una cosa se hace clara: la demanda de hbiles gerentes de proyectos esta a un nivel de urgencia critica. La gerencia de proyectos permite a las personas comunicarse con un lenguaje comn, sin importar su industria, geografa, o si gestionan proyectos, programas o portafolios. Este lenguaje comn anuda las organizaciones mediante el logro de repetible y predecibles resultados en sus proyectos, lo cual es crtico cuando 12 trillones de dlares estn siendo invertidos en proyectos de infraestructura y capital en todo el mundo para los prximos 12 meses. La Gerencia de Proyectos en el Per Actualmente la gerencia de proyectos en el Per es ampliamente usada en proyectos de TI, Minera y algunos proyectos del sector inmobiliario. Sin embargo su potencial puede aplicarse a los sectores de gobierno, legislacin, medicina, ingeniera y desarrollo cientfico.

U1

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Proyectos como la Central Hidroelctrica El Platanal (de 200 MW y 220 millones de USD) usan el estndar PMBOK (Project Management Body of Knowledge). Organizaciones como Osinerming estn implementando Oficinas de Proyectos (PMO por sus siglas en ingles) en algunas divisiones de su organizacin como proyectos iniciales para su aplicacin total. El BCP trabaja con el estndar PMBOK aplicndolo es sus reas de sistemas y marketing. Cambiando de rubro Cosapi y GyM aplica el estndar PMBOK en diferentes proyectos inmobiliarios y de construccin. Esto es reflejo de los ms de 200 certificados PMP (Project Management Profesional) que actualmente existen en el mercado peruano y que vienen aplicando el estndar en las diferentes reas y empresa donde trabajan, sin mencionar que esta cifra viene creciendo rpidamente proyectndose para fin de ao cerca de 300. Es por ello que en el Per existen ms de 700 miembros del Capitulo PMI LIMA PERU, que participan activamente en la difusin del estndar PMBOK y garantizan calidad en los proyectos de la regin.

U1

1.1.2 La estandarizacin en los Proyectos

La Gerencia de Proyectos En los trminos simples, un proyecto es un emprendimiento nico y temporal, con un inicio y final. Usando esta amplia definicin, existen proyectos en toda industria en el mundo, desde la industria automotriz hasta la industria de la construccin, pasando por la industria aeroespacial y de software. Es fcil ver como los gerentes de proyecto aquellos profesionales que dirigen los proyectos consistentemente con procedimientos probados son parte vital de una fuerza de trabajo global. Los gerentes de proyectos contribuyen a la calidad, eficiencia y resultados de negocios a travs de las diversas empresas. Ms formalmente, el PMI define a la gerencia de proyectos como la aplicacin de los conocimientos, habilidades, herramientas y tcnicas a un amplio rango de actividades en orden. Estndares Globales del PMI Los estndares globales son cruciales para la profesin de la gerencia de proyectos. Un estndar asegura que un entorno bsico de la gerencia de proyectos aplicado mundialmente. El PMI ha elaborado y publicado 11 (once) estndares globales (que incluyen Gestin de Programas y de Portafolios de Proyectos). As mismo ha logrado mantener en circulacin cerca de 2 millones de ejemplares de la Gua para el Cuerpo de Conocimiento de la Gerencia de Proyectos (Guide to the Project Management Body of Knowledge - PMBOK Guide). Credenciales del PMI Las credenciales del PMI y las oportunidades de desarrollo profesional pueden ayudar a las personas a iniciar, construir o avanzar en sus carreras en la gestin de proyectos, programas y portafolios de proyectos. A continuacin las credenciales que ofrece el PMI:

Certified Associates in Project Management (CAPM)

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Project Management Professionals (PMP) Program Management Professionals (PgMP) PMI Risk Management Professional (PMI-RMPSM) PMI Scheduling Professional (PMI-SPSM)

De esta forma el PMI ofrece un programa de certificacin completo para personas con diferentes niveles de experiencia. Este programa soporta un entorno de desarrollo de carrera en la gestin de proyectos.

1.1.3 Qu es el PMBOK
La Gua del PMBOK (Project Management Body of Knowledge) es un estndar en la gestin de proyectos desarrollado por el Project Management Institute (PMI). Se encuentra disponible en 11 idiomas: ingls, espaol, chino simplificado, ruso, coreano, japons, italiano, alemn, francs, portugus de Brasil y rabe. En 1987, el PMI public la primera edicin del PMBOK en un intento por documentar y estandarizar informacin y prcticas generalmente aceptadas en la gestin de proyectos. La edicin actual, la cuarta, provee de referencias bsicas a cualquiera que est interesado en la gestin de proyectos. Posee un lxico comn y una estructura consistente para el campo de la gestin de proyectos La Gua del PMBOK es ampliamente aceptada por ser el estndar en la gestin de proyectos, sin embargo existen algunas crticas: La mayor viene de los seguidores de la Cadena Crtica (en oposicin al Mtodo de la ruta crtica)

U1

1.2

Usando el PMBOK

1.2.1 Los Procesos Bsicos

Desde su misma Introduccin, el PMBOK deja muy claro su carcter y finalidad: el conjunto de conocimientos (the body of knowledge) para dirigir un proyecto residen en los practicantes y acadmicos que los aplican y los desarrollan; en otras palabras, estos conocimientos representan un conjunto vivo, extraordinariamente amplio, producto tanto de la experiencia como del estudio y del desarrollo sistemticos. Este conjunto de conocimientos se encuentra distribuido en miles de personas, organizaciones y textos; por ende, el lector no debe esperar tal cosa como un manual que le vaya a explicar los nueve pasos fciles para hacer de su proyecto un xito. La finalidad del PMBOK, entonces, no es la de exponer las disciplinas, tcnicas y experiencias aplicables a la direccin de proyectos, sino simplemente la de identificar el subconjunto de stas que es generalmente reconocido como buenas prcticas. Para que estas buenas prcticas sean asequibles, el PMBOK divide el conjunto de conocimientos para la direccin de proyectos en cuatro grupos de procesos: todo proyecto (as como sus distintas fases e iteraciones) tiene que transitar por una serie de actividades de inicio, de planeacin, de ejecucin y cierre, bajo el gobierno de un grupo de procesos ms general de supervisin y cierre.

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

1.2.2 Las reas de Conocimiento

El meollo del PMBOK, sin embargo, lo representan las nueve reas de conocimiento, y que son propiamente las que contienen las tcnicas para poder realizar los proyectos. Las nueve reas de conocimiento son:

U1

Para cada una de estas reas de conocimiento, el PMBOK recomienda la realizacin de una serie de procesos. Por ejemplo, la Gestin del alcance comprende los procesos Planificar alcance, Definicin del alcance, Crear estructura de desglose de tareas, Verificacin de alcance y Control de alcance. Podemos apreciar los primeros tres de stos en el siguiente diagrama:

Para cada uno de estos procesos de las reas de conocimiento, el PMBOK plantea o sugiere una serie de entradas, tcnicas y salidas. Como ya se ha explicado, el PMBOK identifica las mejores prcticas que son generalmente aceptadas para la realizacin de cada uno de estos procesos.

1.2.3 Identificando las reas

Aunque muchas de las descripciones de estos procesos contienen valiosas observaciones, el lector no deber considerarlas como un manual de tcnicas, sino ms bien como la descripcin del estndar para manejo de proyectos. Las tcnicas mismas

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

estn contenidas en textos de diversos autores, en cursos y en la prctica misma de las organizaciones dedicadas a manejo de proyectos.

Captulo II. Elaboracin Prctica de un Proyecto

2.1 Caractersticas de un Proyecto 2.1.1 Generales
Proyecto y administracin de proyectos Antes de involucrarnos en el apasionante tema de la administracin de proyectos, es necesario conocer de manera clara el significado de las palabras que le componen. A manera de introduccin a continuacin les presentamos las definiciones de administracin y proyecto, para luego entonces, enumerar las caractersticas y reas que componen la administracin de proyectos. Qu es la administracin: Es el proceso de planear, organizar, dirigir y controlar, las actividades y el uso de los recursos con el fin de lograr uno o ms objetivos. Qu es un proyecto: Es un trabajo o esfuerzo que se ejecuta una sola vez y que persigue un fin especfico, y tiene como caracterstica principal producir resultados como un producto o un servicio. Para alcanzar el fin establecido, es necesario definir objetivos o metas (qu hacer) y actividades o procesos (cmo hacer) que debern cumplirse en un tiempo asignado, considerando para ello el inicio y termino del mismo. Necesario es entonces tambin, la asignacin y organizacin de todos los recursos involucrados para su ejecucin. Para su ejecucin y xito, el proyecto debe seguir una serie de pasos realizados por roles involucrados, para ir cumpliendo objetivos y/o desarrollando productos y recursos. En consecuencia podemos decir que los principales parmetros de un proyecto son: Alcance Recursos (costo del esfuerzo principalmente) Tiempo

U1

Dichos parmetros renen las 2 caractersticas siguientes: Cada parmetro es funcin de los otros 2. Mover un parmetro implica cambios a los otros (por lo menos a 1)

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

En conclusin podemos decir que un proyecto es la ejecucin en un momento determinado de un proceso o actividades con un tiempo, un costo y un alcance definido y es el principal objetivo del lder de proyecto el planearlos y controlarlos.

2.1.2 Segn el PMI

U1

2.1.3 Ejercicio Prctico

Elaborar un Proyecto informtico que involucre un Software de Administracin en el cual se desarrolle un Sistema Contable, Planillas, Almacenes e Inventarios.

10

UNIDAD 01 2.2

CONCEPTO DE PROYECTOS Y CASO PRCTICO

El Ciclo de Vida de un Proyecto

U1

2.2.1 Identificacin de Necesidades

El propsito de la gestin de requerimientos es asegurar que el proyecto cumple con las expectativas de sus clientes y de sus interesados, tanto externos como internos, siendo el proceso que garantiza el vnculo entre lo que esperan los clientes y usuarios, y lo que los equipos de proyecto tienen que desarrollar.

11

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Si bien muchos de sus principios pueden ser adaptados a todo tipo de proyectos, es en los proyectos de desarrollo de software donde adquieren todo su sentido, garantizando el proceso y sirviendo de referencia para asegurar y controlar los cambios que en el proyecto puedan surgir (trazabilidad). A menudo, incluye la elaboracin de planes especficos para diferentes aspectos como la recoleccin, gestin e integracin de los requerimientos. Definicin de requerimiento y Stakeholders (Interesados) Segn la definicin del PMBOK, un requerimiento es la condicin o capacidad que debe tener un sistema, producto, servicio o componente para satisfacer un contrato, estndar, especificacin, u otros documentos formalmente establecido. Son todas aquellas caractersticas observables que cualquier interesado desea que estn contenidas en el sistema. Como requisitos se incluyen las necesidades, deseos y expectativas del patrocinador, cliente, usuarios, y otros interesados. Como requerimiento se podra establecer:

U1

Una capacidad necesaria para un cliente o usuario que soluciona un problema o consigue un objetivo. Una capacidad que debe incluirse en un sistema para satisfacer los objetivos del proyecto. Una restriccin impuesta por algn interesado

Definiendo el concepto de stakeholder (interesado) como alguien que est afectado por el proyecto que se desarrolla, podremos encontrar que hay de dos tipos:

Usuarios: Aquellos que utilizaran el sistema. Clientes: aquellos que requieren el sistema y son los responsables de su validacin o aprobacin.

Es importante distinguir entre estos dos grupos de interesados, dado que muchas veces podremos encontrarnos que hay un conflicto entre los requerimientos de ambos. En la mayora de los casos, los requerimientos de los clientes tienen prioridad sobre los requerimientos de los usuarios. Caractersticas de los requerimientos Un requerimiento debe cumplir ciertos criterios y caractersticas:

nico: El requerimiento debe poder ser interpretado inequvocamente de una sola manera. Verificable: Su implementacin debe poder ser comprobada. El test debe dar como resultado CORRECTO o INCORRECTO. Claro: Los requerimientos no deben contener terminologa innecesaria. Deben ser establecidos de forma clara y simple. Viable (realstico y posible): El requerimiento debe ser factible segn las restricciones actuales de tiempo, dinero y recursos disponibles. Necesario: Un requerimiento no es necesario si ninguno de los interesados necesita el requerimiento o bien si la retirada de dicho requerimiento no tiene ningn efecto

12

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Adems de los criterios para los requerimientos individuales, para el conjunto de ellos debe cumplirse:

Independiente: Para comprender el requerimiento no debe ser necesario el conocimiento de otro. Consistente: No debe existir ningn conflicto entre requerimientos. Los conflictos pueden ser: - Directos: Ante una misma situacin, espera comportamientos diferentes. - Indirectos: Se produce cuando no es posible cumplir con dos requisitos al mismo tiempo, aunque describan funcionalidades distintas. No redundante: Cada requerimiento debe ser formulado una sola vez, y no sobreponerse con otros requerimientos. Completo: Un requerimiento debe ser especificado teniendo en cuenta todas las condiciones que puedan ocurrir.

U1

Organizacin y estructura de la gestin de requerimientos Segn el origen y caractersticas, los requisitos pueden dividirse en diferentes tipos., que pueden representarse en forma de pirmide, en cuyo nivel superior se sitan las necesidades de los interesados. En los niveles ms bajos son caractersticas, casos de uso y requisitos complementarios tal como se muestra en la figura:

Necesidad: Un interesado demanda un requerimiento. Caracterstica: Un servicio proporcionado por el sistema, por lo general formulado por un analista de negocios. Caso de uso: Una descripcin del comportamiento del sistema descrito como una secuencias de acciones. Requisito complementario: Otro requisito (generalmente no funcional) que no puede ser contemplado en los casos de uso. Caso de prueba: Una especificacin de las entradas necesarias para una prueba, las condiciones de ejecucin y resultados esperados. Tiene el papel de comprobar

13

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

si los casos de uso derivados de los casos de prueba y los requisitos complementarios se aplican correctamente. Escenario: Una secuencia especfica de acciones o una ruta de acceso especfica a travs de un caso de uso. Ayudan a derivar en casos de uso a partir de los casos de prueba y facilitan el diseo e implementacin a travs de los casos de uso.

Con bastante frecuencia, a diferentes niveles de los requisitos, se especifican diferentes niveles de detalle. Cuanto menor sea el nivel, ms detallado es el requisito. Sin embargo, corresponde a los analistas de negocio decidir el nivel de detalle en cada nivel, aunque no sera incorrecto establece requisitos muy detallados en el nivel de necesidades. Trazabilidad La trazabilidad de los requerimientos se refiere a la documentacin de la vida de cada uno de ellos, y debe permitir seguir el historial desde su formulacin original hasta el momento actual. Cada cambio realizado debe por tanto ser documentado para conseguir dicha trazabilidad. Incluso la implementacin de las caractersticas determinadas por los requerimientos debe poder ser trazada. Los requerimientos surgen de diversas fuentes: el cliente, el manager, el usuario final, etc... Todas y cada una de ellas tienen diferentes requerimientos para el producto. Utilizando la trazabilidad, puede seguirse el historial de una caracterstica implementada hasta las personas o grupos que la solicitaron durante la generacin de los requerimientos, permitiendo un rpido anlisis en cada fase del proyecto para:

U1

Determinar la visin original y permitir una discusin controlada de los cambios en el alcance. Determinar qu elementos se vern afectados cuando consideramos agregar un nuevo requerimiento o modificar uno ya existente. Verificar que el requerimiento contempla todos lo que el interesado solicit. Evitar el Gold Platting: Verificar que la aplicacin no implementa funcionalidades no demandadas por el cliente.

2.2.2 Soluciones Propuestas

Especificacin de requerimientos: Es la habilidad de detallar el comportamiento de un sistema. En cada estadio del proceso de desarrollo, variaran la forma y el nivel de detalle en la especificacin de los requerimientos. Para ilustrarlo, considrese un proceso estndar de desarrollo en cinco fases: Investigacin, Viabilidad, diseo, construccin y test, lanzamiento.

Investigacin En la fase de investigacin, se recopilan requerimientos entre los usuarios y los miembros del equipo de desarrollo. Para cada uno de ellos se formulan cuestiones similares acerca

14

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

de cules son los logros, las restricciones y las herramientas o procesos disponiblesSlo cuando estos requerimientos sean bien entendidos, se pueden desarrollar los requerimientos funcionales. Hay que tener muy presente que los requerimientos no pueden ser completamente definidos al inicio del proyecto. Algunos cambiarn, bien porque sean simplemente suprimidos, o debido a los intereses y modificaciones que afecten al ciclo de vida del proyecto. Por ello, la flexibilidad en los planteamientos y las operaciones, son condiciones para el xito. El entregable del estadio de investigacin es un documento de requerimientos que haya sido aprobado por todos los miembros del equipo. Despus, y durante el desarrollo, este documento ser clave para prevenir la corrupcin del alcance o los cambios innecesarios. Mientras que muchas organizaciones todava utilizan solo documentos para gestionar los requerimientos, otras gestionan a partir de herramientas de software. Estas herramientas permiten gestionar los requerimientos en una base de datos y acostumbran a tener funciones para automatizar la trazabilidad, como por ejemplo permitir la vinculacin electrnica entre la jerarqua de requerimientos, el control de versiones y la gestin de cambios Viabilidad Durante el estudio de viabilidad, se determinan: Los costes de los requerimientos: Para los requerimientos de usuario, se comparan los costes actuales con los futuros, una vez se haya implementado el nuevo sistema. Los costes de operacin: Indicarn qu departamento tiene presupuesto para ello y cul es el retorno de inversin para este producto, incluyendo la reduccin de costes si se desarrolla un nuevo sistema ms fcil de utilizar. Los costes tcnicos: Estn relacionados con los costes de desarrollo de software y los costes del hardware. El equipo debe indagar si los nuevos equipos y herramientas aadirn suficiente potencia de procesamiento para transferir suficiente carga de trabajo del usuario al sistema que permita un ahorro significativo de tiempo y costes al personal El entregable para el estadio de estudio de viabilidad son la programacin y el presupuesto para el proyecto. Diseo Asumiendo que los costes han sido determinados con precisin y que los beneficios a obtener son suficientemente importantes, el proyecto puede pasar al estadio de diseo. En dicho estadio, la actividad principal de la gestin de requerimientos es comparar los resultados del diseo con el documento de requerimientos, para asegurarse de que el trabajo est contemplado dentro del alcance. Implementacin y test En el estadio de implementacin y test, la actividad principal de la gestin de requerimientos, es asegurar que el trabajo y el coste se desarrollan de acuerdo con la programacin y el presupuesto, y que las nuevas herramientas cumplen de hecho con los

U1

15

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

requerimientos. La herramienta principal utilizada en este estadio es la construccin de prototipos y el test iterativo. Para una aplicacin de software, la interfaz de usuario puede ser creada en papel y probada con los usuarios potenciales, mientras est siendo creado el entorno de software. Los resultados de dichos test son archivados en una gua de diseo de interfaz de usuario y trasladado al equipo de diseo, cuando este est listos para desarrollar la interface. Esto ahorra tiempo y hace el trabajo mucho ms fcil. Lanzamiento Podra pensarse que la gestin de requerimientos finaliza al entregar el producto, pero no es del todo cierto. Desde este punto, se recopilan los datos provenientes de la aceptacin de la aplicacin, y utilizados posteriormente en la fase de investigacin de la nueva generacin o versin. Entonces, el proceso empieza de nuevo.

U1

2.2.3 Desarrollo del Proyecto

16

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

2.2.4 Cierre del Proyecto

El proceso de cierre de proyecto establece los procedimientos para coordinar las actividades necesarias para verificar y documentar los entregables del proyecto, para coordinar e interactuar en la formalizacin de estos entregables por el cliente, e investigar y documentar las acciones tomadas si el proyecto es cerrado antes de su completamiento [PMBOK2, 2004]. Segn las prcticas definidas por PMBOK7, estndar en la gestin de proyectos, este proceso debe tener como entradas fundamentales, entre otras, al Plan de desarrollo del proyecto, documentos contractuales y los productos finales que deben ser entregados al cliente. A partir de estas entradas, y aplicando la metodologa que se haya definido para el desarrollo, as como el apoyo de sistemas automatizados de gestin y la valoracin del personal experto que se posea, se obtendrn como salidas fundamentales dos procedimientos para llevar a cabo las actividades de cierre necesarias, adems por supuesto de los productos definidos inicialmente.
Procedimiento de cierre administrativo: Detalla todas las actividades, interacciones, roles y responsabilidades de los miembros el equipo de proyecto, as como el resto de las personas involucrada en la ejecucin de este procedimiento de cierre del proyecto. Los procedimientos para transferir los productos o servicios a la produccin u operacin son desarrollados y establecidos. Este procedimiento

17

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

provee una metodologa paso a paso para el cierre administrativo, que indica las accione y actividades necesarias para:
o definir la aprobacin de los entregables en cualquier nivel por parte de todos los

involucrados.
o confirmar que el proyecto ha cumplido con los requerimientos de clientes,

patrocinadores, etc.
o verificar que todos los entregables han sido entregados y aceptados. o validar que los criterios para el momento de conclusin han sido alcanzados. o satisfacer los criterios de conclusin para el proyecto. Procedimiento de cierre contractual: Incluye todas las actividades necesarias

U1

para establecer y cerrar cualquier acuerdo contractual establecido por el proyecto, as como definir aquellas actividades que apoyan el cierre administrativo formal del proyecto. Este procedimiento incluye la verificacin que todo el trabajo ha sido completado correcta y satisfactoriamente y el cierre administrativo (actualizacin de los documentos contractuales que reflejen los resultados finales, as como el proceso de archivar toda la informacin para un uso futuro). Los trminos y condiciones del contrato tambin pueden prescribir especificaciones para el cierre del proyecto que pueden ser parte de este procedimiento. La conclusin temprana del un contrato es un caso especial de cierre de contrato que podra involucrar, por ejemplo, la incapacidad de entrega del producto, sobregiro de los presupuestos, o la ausencia de recursos necesarios. Como conclusin de todo este proceso se sugiere obtener, adems de otros definidos en los procedimientos establecidos, dos documentos finales que agrupan el mayor bagaje informativo, el Informe de cierre de proyecto y el Informe de evaluacin del proyecto. Informe de cierre de proyecto El Informe de cierre de proyecto es un documento final producido en el proyecto y usado por la directiva de la organizacin para evitar que persistan an faltas y de esa manera concluirlo formalmente. El mismo debe desarrollarse para detallar las actividades realizadas como cierre formal y definir los problemas, riesgos, y recomendaciones fundamentales que deben seguirse a partir de ese momento. De manera general, el documento debe listar las actividades de cierre y cualquier elemento importante que se considere. Normalmente debe ser producido una vez que el proyecto ha sido completado exitosamente y entregado a los clientes, o cuando se decida cerrar el proyecto por alguna razn. Se recomienda siempre hacer un Informe de chequeo de cada fase que se vaya terminando en el caso de que el proyecto sea grande o complejo, de manera tal que luego sea mucho ms simple.

18

UNIDAD 01 2.3 La Programacin

CONCEPTO DE PROYECTOS Y CASO PRCTICO del Proyecto

2.3.1 Actividades

U1

19

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

2.3.2 Hitos

20

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

2.3.3 Secuencia de Actividades 2.3.4 Diagramacin por Dependencias y Precedencias

U1

21

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

22

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

2.3.5 La estructura del Trabajo

U1

23

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

24

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

2.4

Los Recursos

25

UNIDAD 01 2.4.1 Tipos de Recursos

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

26

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

2.4.2 Asignar Tiempos

27

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

28

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

29

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

30

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

2.5 Los Costos 2.5.1 Costos de Recursos de Personal

En este rubro debe estar representado el tiempo que le dedicarn al proyecto los recursos de la organizacin, en trminos de cantidad de horas por valor hora. No olvidemos que el costo de los recursos en relacin de dependencia est dado por el costo de oportunidad. La gente que estar en el proyecto tiene un sueldo, eso sueldo tiene asociado un valor hora. Este valor hora multiplicado por las horas dedicadas al proyecto nos da el costo del recurso. Para calcular el valor hora de un recurso de la organizacin se debe tener en cuenta su sueldo bruto ms las cargas sociales e impuestos correspondientes para el empleador.

U1

2.5.2 Costos de material

El costo de los materiales que se necesita comprar para el proyecto. Se llaman materiales pero pueden ser tangibles o intangibles: maquinaria, equipamiento, materiales de construccin, costos de suscripcin a algn servicio de informacin, licencias de software, papel, pintura, etc.

2.5.3 Costos Generales del Proyecto

Proveedores, consultores y asesores: cuando el equipo del proyecto no har todo el trabajo, porque no tiene las habilidades necesarias o porque no estar disponible, se contratan servicios profesionales externos. En este rubro figuran todos los honorarios de estos colaboradores. Alquiler de equipos e instalaciones: quizs adems de comprar materiales se alquilen equipos, maquinarias o instalaciones para uso del proyecto. En este rubro entran esos costos. Si los equipos o instalaciones sern usados para varios proyectos, se deben prorratear correspondientemente. Viajes, alojamiento, alimentos: si el equipo del proyecto debe incurrir en este tipo de gastos, esto es parte del costo del proyecto. Las propuestas comerciales de proveedores, consultores y asesores externos pueden o no incluir viajes, alojamiento y alimentos. Estos costos debe ser sumados a los costos del equipo del proyecto cuando corresponda.

2.6 El Seguimiento 2.6.1 Comprobacin de Tareas

Si ha establecido una lnea de base para el proyecto, puede ver cmo las tares progresan en el tiempo y ver si sus fechas de comienzo y fin se estn retrasando. Puede hacer un seguimiento del proceso comparando las fechas previstas y las programadas o las fechas reales de comienzo y de fin.

31

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

2.6.2 Actualizacin de Trabajos

A medida que el trabajo en el proyecto avanza, puede actualizar el plan con las fechas de comienzo y de fin reales, el trabajo real y la duracin restante y real, as como con el porcentaje completado y porcentaje de trabajo completado actuales.

2.6.3 Comprobacin de Costos

Determinar en qu grado afecta la calidad a los costos Piense en las opciones que tiene si debe reducir los costos. Optimizar el plan para cumplir el presupuesto Haga clic en los vnculos que proceda: Quitar una asignacin de recursos o reemplazarla para eliminar los costos de un recurso concreto o para reemplazar un recurso concreto con otro que requiera menos dinero o pueda hacer el trabajo ms rpidamente. La sustitucin de un recurso podra reducir la cantidad de tiempo necesaria para finalizar la tarea. Reducir las tasas de recursos y los costos fijos de las tareas para optimizar los costos del proyecto. Puede reducir los costos de recursos globales aplicando una tasa distinta que puede facturar una persona por los distintos tipos de trabajo o usando materiales de otra calidad. La reduccin de los costos de tareas fijos, como los costos de viajes o de impresin, puede reducir o eliminar gastos que no son esenciales para finalizar una tarea. Modificar la duracin de una tarea si desea reducir el alcance de una tarea concreta.

U1

2.6.4 Comprobacin de Tiempos 2.6.5 Anlisis de la Ruta Crtica

El PERT/CPM fue diseado para proporcionar diversos elementos tiles de informacin para los administradores del proyecto. Primero, el PERT/CPM expone la "ruta crtica" de un proyecto. Estas son las actividades que limitan la duracin del proyecto. En otras palabras, para lograr que el proyecto se realice pronto, las actividades de la ruta crtica deben realizarse pronto. Por otra parte, si una actividad de la ruta crtica se retarda, el proyecto como un todo se retarda en la misma cantidad. Las actividades que no estn en la ruta crtica tienen una cierta cantidad de holgura; esto es, pueden empezarse ms tarde, y permitir que el proyecto como un todo se mantenga en programa. El PERT/CPM identifica estas actividades y la cantidad de tiempo disponible para retardos. El PERT/CPM tambin considera los recursos necesarios para completar las actividades.

32

UNIDAD 01
ANTECEDENTES

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Dos son los orgenes del mtodo del camino crtico: el mtodo PERT (Program Evaluation and Review Technique) desarrollo por la Armada de los Estados Unidos de Amrica, en 1957, para controlar los tiempos de ejecucin de las diversas actividades integrantes de los proyectosespaciales, por la necesidad de terminar cada una de ellas dentro de los intervalos de tiempo disponibles. Fue utilizado originalmente por el control de tiempos del proyecto Polaris y actualmente se utiliza en todo el programa espacial. El mtodo CPM (Crtical Path Method), el segundo origen del mtodo actual, fue desarrollado tambin en 1957 en los Estados Unidos de Amrica, por un centro de investigacin de operaciones para la firma Dupont y Remington Rand, buscando el control y la optimizacin de los costos de operacin mediante la planeacin adecuada de las actividades componentes del proyecto. Definicin: El mtodo del camino crtico es un proceso administrativo de planeacin, programacin, ejecucin y control de todas y cada una de las actividades componentes de un proyecto que debe desarrollarse dentro de un tiempo crtico y al costo ptimo. Usos: El campo de accin de este mtodo es muy amplio, dada su gran flexibilidad y adaptabilidad a cualquier proyecto grande o pequeo. Para obtener los mejores resultados debe aplicarse a los proyectos que posean las siguientes caractersticas: a. Que el proyecto sea nico, no repetitivo, en algunas partes o en su totalidad. b. Que se deba ejecutar todo el proyecto o parte de el, en un tiempo mnimo, sin variaciones, es decir, en tiempo crtico. c. Que se desee el costo de operacin ms bajo posible dentro de un tiempo disponible. DIFERENCIAS ENTRE PERT Y CPM Como se indic antes, la principal diferencia entre PERT y CPM es la manera en que se realizan los estimados de tiempo. E1 PERT supone que el tiempo para realizar cada una de las actividades es una variable aleatoria descrita por una distribucin de probabilidad. El CPM por otra parte, infiere que los tiempos de las actividades se conocen en forma determinsticas y se pueden variar cambiando el nivel de recursos utilizados. La distribucin de tiempo que supone el PERT para una actividad es una distribucin beta. La distribucin para cualquier actividad se define por tres estimados: (1) el estimado de tiempo ms probable, m; (2) el estimado de tiempo ms optimista, a; y (3) el estimado de tiempo ms pesimista, b. METODOLOGA DEL CPM (CRITICAL PATH METHOD) El Mtodo del Camino Critico consta de dos ciclos: 1. Planeacin y Programacin. 1.1.- Definicin del proyecto 1.2.- Lista de Actividades 1.3.- Matriz de Secuencias 1.4.- Matriz de Tiempos 1.5.- Red de Actividades 1.6.- Costos y pendientes 1.7.- Compresin de la red

U1

33

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

1.8.- Limitaciones de tiempo, de recursos y econmicos 1.9.- Matriz de elasticidad 1.10.- Probabilidad de retraso 2. Ejecucin y Control. 2.1.- Aprobacin del proyecto 2.2.- Ordenes de trabajo 2.3.- Grficas de control 2.4.- Reportes y anlisis de los avances 2.5.- Toma de decisiones y ajustes

U1

34

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Captulo III Aprendizaje Bsico de la Herramienta Microsoft Project 2007 Objetivos de captulo:

Conocer el interface Del Microsoft Project 2007 Aprender a utilizar las Barras de Herramientas Manipular Archivos de un Proyecto Conocer Las Escalas de Tiempo y crear el Calendario del Proyecto

U1

3.1

Aprendizaje bsico de Microsoft Project 2007 descripcin de la pantalla. Barras de

3.1.1 Definicin y Herramientas

Indicador de Inicio

Fin de la Barra

Iconos ocultos

3.1.2 Manejo de los Archivos de proyecto CREAR UN ARCHIVO

Inicie el programa En el Men Inicio haga clic en la opcin Nuevo

35

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

En el cuadro de dilogo que aparece en la parte izquierda de la pantalla seleccione si va a generar un nuevo proyecto o va a utilizar uno existente

En este momento se debe definir si la programacin se har a partir desde la fecha de finalizacin o de la fecha de inicio del proyecto. (Para un proyecto programado desde la fecha de finalizacin, las tareas que no requieran una fecha especfica se programarn lo ms tarde posible, en lugar de hacerlo lo ms pronto posible). Cuando ya tenga toda la informacin clara: Haga clic en Proyecto Informacin del Proyecto

36

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

U1

En el cuadro de dilogo que aparece escriba: Fecha de comienzo escriba la fecha de comienzo del proyecto. El programa calcular automticamente la fecha de fin. Programar a Partir de Escoja si va a utilizar la programacin desde el inicio o desde el final del proyecto

37

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Cuando se programa desde el final del proyecto la fecha que debe ponerse es en el cuadro Fecha de Fin y dejar constante la Fecha Inicio del Proyecto Por defecto el programa utilizar la fecha del da que aparece en el cuadro Fecha de Hoy para iniciar la programacin. Si usted desea iniciar desde otra fecha modifquela. Cuando haya terminado haga clic en Aceptar para cerrar el cuadro de dilogo

3.1.3 Visualizacin de la informacin en vistas 3.1.4 Ajuste de la escala temporal ESCALAS TEMPORALES La escala temporal aparece en el rea del grfico de un proyecto. Project puede mostrar hasta tres escalas de tiempo cada una de ellas llamadas nivel. Por ejemplo: Ao Mes Semana, Ao Semana - Da. El nivel superior muestra el periodo de tiempo ms extenso y el nivel inferior muestra el perodo de tiempo ms detallado. La escala temporal predeterminada muestra dos niveles: das dentro semanas Para definir las opciones de la escala temporal, siga estos pasos: Muestre en la pantalla una vista que contenga una escala temporal. (El ms conveniente es utilizar el Diagrama de Gantt) Clic en Formato Escala temporal

U1

Aparecer el cuadro de dilogo Escala Temporal que tiene cuatro fichas: Nivel Superior, Nivel Intermedio, Nivel Inferior y Periodo No Laborable.

El nivel intermedio es el que generalmente se modifica segn los requerimientos de la programacin, lo ms comn es mostrar la programacin en semanas y das.

38

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

3.1.5 Fecha de Comienzo del Proyecto

U1

COMO APLICAR UN CALENDARIO BASE AL PROYECTO Clic en Proyecto Informacin del Proyecto En el cuadro Calendario, seleccione el nombre del calendario base que se aplicar al proyecto. Clic en Aceptar.

39

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

3.1.6 Calendario del Proyecto Configuracin del Calendario Laboral DEFINIR EL CALENDARIO DEL PROYECTO Microsoft Project proporciona tres calendarios base. Estos calendarios son plantillas de calendario que se pueden aplicar a un conjunto de recursos, de tareas o al proyecto en general. Estndar: est establecido de lunes a viernes, de 9:00 a.m. a 7:00 p.m. con una hora libre a medio da. Este es el calendario predeterminado que utiliza el programa para el proyecto, las tareas y los recursos. Turno de Noche: El calendario laboral est establecido desde las 11:00 p.m. hasta las 8:00 a.m. cinco das a la semana, con una hora libre de 3:00 a 4:00 de la maana. 24 horas: est determinado para perodos de 24 horas todos los das de la semana, sin detenerse. Para modificar cualquiera de estos calendarios segn las necesidades del proyecto: Haga clic en Herramientas Cambiar Calendario Laboral

U1

Para hacer el cambio de calendario, es recomendable saber cuales son los das de descanso que afectan la programacin y las horas de trabajo que se vaya a implementar en el proyecto. Se debe tener en cuenta que el calendario del proyecto es diferente al de las tareas y los recursos. Aunque en casi todo proyecto, estos tres calendarios coinciden.

40

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO

Aparecer, entonces, un cuadro de dialogo donde usted debe decidir: si modificar algn calendario base o va a crear uno totalmente nuevo.

Para Modificar Un Calendario Base: En el cuadro Para Calendario, seleccione el nombre del calendario base que desea modificar.

U1

41

UNIDAD 01

CONCEPTO DE PROYECTOS Y CASO PRCTICO BIBLIOGRAFA

1. A guide to the Project Management Body of Knowledment (PMBOK guide), tercera edicin, Project Management Institute, 2004. 2. A guide to the Software Engineering Body of Knowledment (SWEBOK guide), Captulo 8, version 2004, IEEE, 2004. 3. Brooks, Frederick. The mythical Man month. Addyson Wesley Professional, 2nd edition, 1995. 4. Chrissis M.B., Konrad M., Shrum S.: CMMI: Guidelines for Process Integration and Product Improvement. Addison Wesley, 2003. 5. Goldenson D.R., Gibson D.L., Ferguson R.W.: Why Should I Switch to CMMI? Initial Evidence about Impact and Value Added. 3rd. Annual CMMI Technology Conference and User Group: Track on Impact and Benefits of CMMI. Pittsburgh, 2003. 6. Humphrey, W. S.: Managing the Software Process. Reading, MA: AddisonWesley, 1989. 7. Neumann, Peter. System development woes. Association for computing machinery, 1997. 8. Pressman, R. Software engineering: A practicioners approach. Addyson Wesley Professional, 6th Edition, 2004. 9. Young, Ralph R, Recommended Requirements Gathering Practices,STSC, Abril 2002. 10. Gottesdiener, Ellen, Good Practices for Developing User Requirements , STSC, Marzo 2008. 11. Zielczynski, Peter . Requirements Management Using IBM Rational RequisitePro, IBM Press., 2008.

U1

42