1

Universidad de Costa Rica

Escuela de Ciencias de la Computacin e Informtica

GUA PARA ELABORAR PLANES DE ADMINISTRACION DE PROYECTOS DE SOFTWARE

Autora: Prof. Gabriela Salazar Bermdez

I Semestre- 2006

Resumen
El objetivo de este documento es guiar a los estudiantes de pre-grado y pos-grado de la carrera de Ciencias de la Computacin e Informtica de la Universidad de Costa Rica a planificar un proyecto de software de acuerdo a los estndares internacionales. El documento es una adaptacin del ANSI/IEEE Std. 1058.1-1987, IEEE Standard for Software Project Management Plans e incorpora algunas tcnicas recomendadas por el PMBOK GUIDE 2004, con el fin de que los estudiantes conozcan y utilicen prcticas internacionales en materia de planificacin de proyectos de software. El objetivo general de planificar es establecer una estrategia prctica para controlar, registrar y monitorear un proyecto tcnico complejo, y as obtener un producto de software Antes de planificar un proyecto de calidad y en el tiempo oportuno. de software es necesario conocer su alcance con el fin de entender las necesidades del cliente, el contexto del negocio, los lmites del proyecto y posibles cambios. Para determinar el alcance es necesario aplicar tcnicas de extraccin del conocimiento como: entrevistas, anlisis de documentos, lluvia de ideas, modelado del sistema a definir dealcance del proyecto se recomienda utilizardetalle conozcamos de Para travs el casos de uso, prototipado, etc.. Entre ms la metodologa la explicada aplicacin,ese documento se su planificacin. en [5]. En ms certera ser explica la metodologa para conceptualizar un proyecto de software y evaluar su viabilidad. Si se determina que el proyecto es viable, seguidamente se debe planificar siguiendo los lineamientos indicados en este estndar. Sin embargo, por ser la etapa de conceptualizacin una etapa tan temprana en el ciclo de vida de un proyecto, se Posteriormente, conforme se obtenga ms informacin se refinarn los debe planificar a nivel de actividades, sin detallar las tareas correspondientes a cada requerimientos y se actualizar lo planificado. Para actualizar el cronograma se actividad [8]. recomienda estimar el tamao de la aplicacin utilizando las reglas y guas del IFPUG (Internacional Function Point Users Group), las cuales hacen posible realizar el conteo de Puntos de Funcin una vez que los requerimientos se hayan finalizado. Refirase a [6] para obtener informacin sobre la metodologa de Puntos de Funcin.

Tabla de contenido 2.1

2. Contenido del Plan de Administracin de Proyectos de Software ............... 3 Portada .......................................................................................................... 3 1.2.2 Hoja de Aprobacin...................................................................................... 3 Introduccin ...................................................................................................... 1 2.3 Bitcora de 1.1 Evolucin del Cambios..................................................................................... Plan........................................................................................ 1 3 2.4 Definiciones y 1.2 Tabla de Contenido....................................................................................... 4 Abreviaturas ......................................................................... 2 2.5 1.2.1 Definiciones........................................................................................... Introduccin.................................................................................................. 4 2 2.5.1 Descripcin General del Proyecto ......................................................... 1.2.2 Abreviaturas........................................................................................... 4 2 2.5.2 Productos 1.3 Referencias Finales (Entregables) ............................................................ 5 bibliogrficas ............................................................................ 2 2.5.3 Definiciones y Abreviaturas .................................................................. 7 2.5.4 Referencias ............................................................................................ 7 2.6 Organizacin del Proyecto............................................................................ 7 2.6.1 Modelo de Ciclo de Vida del Proyecto.................................................. 7 2.6.2 Estructura Organizacional ..................................................................... 7 2.6.3 Responsabilidades.................................................................................. 9 2.7. Proceso Administrativo ............................................................................. 11 2.7.1 Objetivos y Prioridades de la Gerencia ............................................... 11 2.7.2 Suposiciones y Restricciones............................................................... 11 2.7.3 Administracin del Riesgo .................................................................. 11 2.7.4 Mecanismos de Control ....................................................................... 17 2.7.5 Plan de Consecucin de Recursos Humanos ....................................... 17 2.8. Proceso Tcnico......................................................................................... 18 2.8.1 Mtodos, Herramientas y Tcnicas...................................................... 18 2.8.2 Documentacin del Proyecto............................................................... ANEXO 1: Ejemplo de la metodologa de Administracin de Riesgos ......... 22 18 2.9. Elaboracin del Cronograma ..................................................................... ANEXO 2: Plantilla de Actividades (WBS)...................................................... 25 19 2.9.1 Definir actividades............................................................................... 19 2.9.2 Establecer la secuencia de las actividades........................................... 19 2.9.3 Estimar los recursos de las actividades................................................ 19 2.9.4 Estimar la duracin de las actividades................................................. 19 2.9.5 Desarrollar el cronograma ................................................................... 20 3. Formato del Plan de Administracin de Proyectos de Software .................. 21

1 1. Introduccin Todo proyecto de software que se desarrolle debe tener su propio plan de desarrollo. Este estndar prescribe el formato para elaborar dicho plan. Identifica un conjunto mnimo de elementos que debe aparecer en todo plan. Su uso no est restringido por el La seccin 1 de este documento introduce algunos aspectos generales que el lector tamao, debe entender antes de iniciar software a de planificacin. El apartado 1.1 explica el complejidad o grado crtico del su proceso desarrollar. procedimiento para administrar las diferentes versiones del documento de planificacin para un proyecto especfico y el apartado 1.2 indica algunas definiciones y abreviaturas que se utilizaron en este documento. El apartado 1.3 presenta las referencias bibliogrficas que se utilizaron para elaborar este documento. La seccin 2 explica con detalle los puntos que debe contener el plan de un proyecto Est dividido en 7 secciones que son: Portada, Tabla de contenido, Introduccin, Organizacin del proyecto, Proceso administrativo, Proceso tcnico y Elaboracin del Cronograma. En dicha seccin se describen los procedimientos que apoyarn el proceso de planificacin. 1.1 Evolucin del Plan Como todo proyecto est expuesto a sufrir cambios durante el tiempo de desarrollo, el documento de planificacin debe reflejar estos cambios, por lo tanto, es necesario contar con un procedimiento que permita administrar las diferentes versiones que se generen 1. Cada cambio debe ser evaluado y avalado por los miembros del Comit de del Desarrollo descrito en la seccin 2.6.2. de este documento. plan para cada proyecto. A continuacin se describe el procedimiento: 2. La informacin correspondiente al Plan del proyecto debe mantenerse en un archivo electrnico, el cual seguir el siguiente esquema: Siglas del sistema- Nmero de versin Por ejemplo: CLAR-1, en donde CLAR corresponde a las siglas del sistema para el que se est elaborando el plan y 1 indica que es la primera versin del plan. 3. Cada vez que se requiera modificar el Plan debido a cambios en los requerimientos, el calendario, los recursos, etc., se debe mantener una copia del archivo electrnico con la versin anterior y obtener una copia de ese archivo pero con un nombre diferente, en el cual se incorporarn los cambios 4. El nombre necesarios. de la versin donde se incorporarn los cambios se debe modificar, incrementando en 1 el nmero que identifica la versin. Por ejemplo: CLAR-1 debe modificarse a CLAR-2, al pasar de la versin 1 a la 2. 5. El detalle de cada cambio debe describirse en la seccin Bitcora de Cambios del Plan del proyecto correspondiente a la versin modificada. El formato de la Bitcora de Cambios que se debe utilizar se encuentra en la seccin 2.3 de este documento.

2 6. Toda la informacin correspondiente a la planificacin del proyecto debe mantenerse junta, incluyendo las diferentes versiones. 1.2 Definiciones y Abreviaturas 1.2.1 Definiciones Software. Conjunto de programas fuente y ejecutables, as como toda la documentacin que los acompaa. Versin. Software que se hace disponible al usuario final. WBS. Es una descripcin jerrquica de la organizacin del proyecto. Divide el proyecto en actividades y las actividades en tareas o sub-actividades a las cuales se les asigna tiempo y recursos. 1.2.2 Abreviaturas ACS: Aseguramiento de Calidad del Software WBS: Work Breakdown Structure en ingls (en espaol Estructura de Divisin del Trabajo). RAM: Responsability Assignment Matrix en ingls (en espaol Matriz de asignacin de responsabilidades). 1.3 Referencias bibliogrficas [1] ANSI/IEEE Std. 1058.1-1987, IEEE Standard for Software Project Management Plans [2] Pressman Roger. Ingeniera del software. Un enfoque prctico. Mc Graw Hill. Quinta Edicin. [3] ANSI/IEEE Std. 729-1983, IEEE Standard for Software Quality Assurance Plans, IEEE, Inc., New York, 1984. [4] Fundamentos de la Direccin de Proyectos. Tercera Edicin. Gua del PMBOK. ANSI/PMI 99-001-2004. [5] Salazar Gabriela. Gua para elaborar la descripcin conceptual de un proyecto de software. Versin 1, 2005. [6] Salazar Gabriela. Metodologa para medir el proceso de desarrollo del software. Versin 2, 2005. [7] ANSI/ISO/IEEE Std. 1012-1986, IEEE Standard for Software Verification and Validation Plans. [8] ANSI/ISO/IEEE Std. 1074-1991, IEEE Standard for Developing Software Life Cycle Processes.

3 2. Contenido del Plan de Administracin de Proyectos de Software Esta seccin describe las partes que debe contener el plan del proyecto y los procedimientos para realizarlo. 2.1 Portada La portada debe seguir el formato descrito en la figura 1. Debe incluir al menos la siguiente informacin: nombre de la institucin, el nombre del documento, el nombre del sistema que se va a planificar, los autores del Plan, el nmero de versin y la fecha de aprobacin.

Universidad de Costa Rica Plan del proyecto

Sistema Administracin de Requerimientos Elaborado por: Juan Rojas Arias Versin 1.0 Aprobado el 03 de marzo del 2003

Figura 1. Ejemplo de una portada de un plan de proyecto 2.2 Hoja de Aprobacin Debe contener los nombres y firmas de las personas que elaboraron y aprobaron el plan. La figura 2 muestra un ejemplo de una hoja de aprobacin.

Universidad de Costa Rica Plan del proyecto

Sistema Administracin de Requerimientos Elaborado por: ____________ ____________ Aprobado por: ____________

Figura 2. Ejemplo de una hoja de aprobacin de un plan de proyecto 2.3 Bitcora de Cambios Tal y como se muestra en la figura 3 debe existir una lista de todas las modificaciones que se le hacen al Plan del proyecto. La Bitcora de Cambios es donde se

4 va a mantener esa lista con la informacin correspondiente a cada cambio que se realice. Cada versin del Plan tendr su correspondiente Bitcora de Cambios.
Bitcora de cambios Nombre del proyecto:___________________
Fecha Cambio 12/02/03 # Seccin Descripcin en el plandel cambio 2.8.5 Justificacin del cambio Autor y firma

Actualizarel Se atras la Carlos F cronograma.entregadel mdulo X.

Figura 3. Ejemplo de una hoja de aprobacin de un plan de proyecto A continuacin se presenta una descripcin de cada uno de los campos que como mnimo debe contener la Bitcora de Cambios. Por cada cambio se debe utilizar un rengln e indicar la siguiente informacin: Fecha Cambio: Corresponde a la fecha en que se realiz el cambio. # Seccin: Indica la seccin dentro del plan del proyecto donde se est incorporando el cambio. Descripcin del cambio: Breve descripcin del cambio que se est incorporando. Justificacin del cambio: Indica el propsito del cambio de manera que se justifique la razn por la que se est haciendo. Autor y firma: Nombre y firma de las personas que modificaron el documento. 2.4 Tabla de Contenido Corresponde a la tabla de contenido del Plan del proyecto que se est planificando. En la seccin 3 de este documento se encuentra el formato a seguir. 2.5 Introduccin El objetivo de esta seccin es guiar al lector sobre la naturaleza y estructura del proyecto a desarrollar. Se explica la naturaleza y estructura del proyecto, los productos de software que se van a entregar al usuario, definiciones y abreviaturas que se van a utilizar en el documento y referencias bibliogrficas. Estas cuatro secciones se describen a continuacin. 2.5.1 Descripcin General del Proyecto El propsito es presentarle al lector un resumen de lo que ser el proyecto. Se deben describir los siguientes aspectos: a. Objetivos especficos del proyecto. b. Funciones principales que debe proveer el software una vez implementado. c. Recursos requeridos (materiales y humanos).

5 d. Hitos importantes y duracin total del proyecto. e. Presupuesto estimado. Se recomienda utilizar [5] para conceptualizar el proyecto y definir los objetivos especficos y funciones principales. El resto de los aspectos que hay que indicar en esta seccin tal como: recursos requeridos, duracin y presupuesto del proyecto, se obtienen casi finalizado el proceso de planificacin. 2.5.2 Productos Finales (Entregables) Se debe elaborar una descripcin de los productos de software que se entregarn al usuario del proyecto. Entendindose por productos de software tanto los entregables obtenidos en cada fase del ciclo de vida (tales como: especificacin de requerimientos, especificacin del diseo, etc.), as como el cdigo ejecutable de la aplicacin. En los casos en donde la entrega del sistema se hace por etapas se deben indicar los productos finales importante resaltar que la informacin de esta seccin es provista por el Es que se entregarn en cada etapa. usuario, porque no necesariamente todos los productos de software que se van a administrar como parte de la Administracin de la Configuracin del Software (identificados en el punto 2.8.2 de este documento) son entregables. Por ejemplo: puede ser que al usuario no le interesa que le entreguen un producto intermedio tal como: los Diagramas de Rational Rose, o la Descripcin Conceptual, etc. Sin embargo para fines del curso se debern entregar los indicados en de seccin 2.8.2. Por cada producto la software entregable se debe identificar: El nombre del entregable. La fecha de entrega. Descripcin del entregable. El nmero de copias o cantidades necesarias. El medio en que se entregar (electrnico o papel). Si es instalado o si se entregar para que la oficina lo instale. Si se implantar (quin se har cargo de digitar los datos de produccin, qu funciones le tocar a cada parte respecto a la transferencia del sistema viejo al nuevo, etc.). Tipo de capacitacin y responsables de realizarla. Cada producto de software debe ser identificado como nico usando un sistema de numeracin en forma sistemtica. Se recomienda (si el tipo de informacin lo permite) presentar esta informacin siguiendo un formato de tabla como se muestra a continuacin para facilitar su comprensin.

El analista J.M. se encargar instalado el Una vez de capacitar al sistema eq CAPACITACI uipo de usuarios en el analista P.Z. N su organizacin, una vez encargar se No aplica No aplica instalado el sistema. de capacitar al equ ipo de usuarios en su organizacin.

IMPLANTACI datos datos Tabla 1: N ser responsabilidad del ser responsabilidad del Formato No aplica No aplica equipo de usuarios. equipo de usuarios. de present acin de La La empresa los INSTALACIN empresa desarrollado se encargar entrega Archivo Archivo ra se encargar de de instalarlo en el ambie instalarlo nte del usuario. No aplica No aplica en el bles del ambiente del usuario. e impr sistema. electrnicoelectrnico e impr eso eso MEDIO DEENTREGA

La digitacin de los

La digitacin de los

Archivo electr nico

Archivo electr nico

NO. DECOPIAS

Planificacin del Especifica Implementar el el Implementar el mantenimiento proyecto diseo del mantenimiento de las de las notas con los que permitir sistema facturas, los clientes y diferentes conceptos que son cob darle un a nivel de datos, d los tems. (Refirase rados en ella y los reportes mens a control adecuado e arquitectura,requerimientos 1, 2 y 3 Refirase a los los de uales. al desarrollo. componentes y de en la Descripcin indicados requerimientos 4 y 5 indicados interfaces. Conceptual en la Descripcin Conceptual del Sistema y/o en la Especific del Sistema y/o en acin de Requerimientos. Especificacin de Requerimient la os. DESCRIPCIN

18/12/2005 FECHA 10/11/2005 18/12/2005 DEENTREGA

8/02/2006

Especificacin Mdulo 2: Implementar Plan del pro diseo del las notas con Mdulo 1: Mantenimient yecto los conceptos cobrados. Imple NOMBREENTREG o Facturas Mantenimient mentacin de los reportes. ABLE o Clientes

NO.

2.5.3 Definiciones y Abreviaturas Se definen todos los trminos y abreviaturas que se utilicen en el resto del documento. 2.5.4 Referencias Se deben enumerar todas las referencias completas (por ejemplo: ttulo, autor, fecha, editorial, etc.) de todos los documentos mencionados en el plan del proyecto, as como cualquier otra documentacin complementaria que est relacionada con ste. 2.6 Organizacin del Proyecto En esta seccin se debe presentar el modelo del ciclo de vida que se utilizar para desarrollar los sistemas de informacin, la estructura organizacional que soportar el proyecto, y las reas de responsabilidad individual que apoyarn cada una de las actividades presentadas en el modelo. 2.6.1 Modelo de Ciclo de Vida del Proyecto Es conveniente mostrar el diagrama con el modelo del ciclo de vida que se utilizar durante el desarrollo del proyecto. La seleccin del ciclo de vida debe hacerse previo a la elaboracin del cronograma, porque con base en ste se definen las fases del proyecto y se organiza su desarrollo. Entre los modelos que se pueden utilizar estn: Cascada, Evolutivo, 2.6.2 Estructura Organizacional Espiral, Entrega por Etapas, Cascada Modificada Por Subproyectos, etc.. Se recomienda mostrar grficamente la estructura interna que estar a cargo del proyecto y las fronteras administrativas entre el proyecto y cualquier grupo que tenga relacin con el mismo. La figura 4 muestra un ejemplo de una posible estructura organizacional (organigrama). Se presenta la jerarqua del Comit de Desarrollo que es el equipo encargado de desarrollar la aplicacin y la relacin con otros participantes durante el proceso de desarrollo como puede ser cualquier grupo de soporte.

Otros participantes

Grupo ACS
Control

Coordinacin o comunicacin

Director Proyecto

Equipo Tcnico

Equipo Usuarios

Comit de Desarrollo

Figura 4. Ejemplo de una estructura organizacional Es conveniente que la estructura interna del Comit de Desarrollo, est compuesta por un mnimo de tres personas: el Director o Lder del Proyecto, un miembro del Equipo Tcnico y un miembro del Equipo Usuarios. En la fase de planificacin el Director del Proyecto es el responsable principal de elaborar el plan del proyecto. Los otros integrantes del Comit de Desarrollo son co-responsables. Sin embargo las decisiones se deben tomar Equipo Tcnico est formado por los miembros del equipo, encargados de El entre las tres partes. desarrollar los productos de software durante cada una de las fases del ciclo de vida del proyecto, bajo la coordinacin del director del proyecto. A su vez, el Equipo Usuarios debe asegurar la comprensin y claridad en la definicin de los objetivos y los requerimientos de la aplicacin a desarrollar. Se recomienda que peridicamente el Director del Proyecto se rena con el Equipo de Usuario para determinar prioridades respecto a funcionalidad, calidad, costo y cronograma del proyecto que puedan cambiar durante el desarrollo. Por otro lado, fuera del Comit de Desarrollo representado en la figura 4, se muestran otras entidades que de nuevo, de acuerdo a la aplicacin y organizacin donde se desarrolle podran no existir. Como se muestra en esta figura es al Director del Proyecto al que le corresponde coordinar con otras oficinas (si fuera el caso). La relacin entre el Director del Proyecto y las oficinas se describe a continuacin: debido a que los - Con el Grupo ACS podra existir una relacin de control, miembros de este grupo deben participar en las Revisiones Tcnicas que se aplican a travs del desarrollo del proyecto. - Otros posibles participantes podran ser grupos de soporte como: administracin de la configuracin del software, soporte tcnico (redes de comunicaciones, administracin de bases de datos y alguna herramienta en particular), gerente funcional del departamento usuario (contraparte del sistema), contratistas y proveedores, patrocinador del proyecto, propietario de la empresa y agencias gubernamentales.

2.6.3 Responsabilidades Es necesario identificar, documentar y asignar los roles (quin hace qu?), las responsabilidades (quin decide qu?) y las lneas de reporte a cada uno de los participantes del proyecto. Estas asignaciones pueden ser dirigidas a individuos o grupos, dentro o fuera de la organizacin. Una herramienta muy til recomendada por [4] para este propsito, es la matriz de responsabilidades RAM (Responsability Assignment Matrix) la RAM es una estructura que relaciona a la organizacin del proyecto con el WBS cual se Breakdown Structure), para asegurar que cada elemento del alcance del (Work muestra en la tabla 2 de este documento. proyecto tenga un responsable individual. En proyectos grandes se pueden tener RAM en varios niveles. Uno de alto nivel que asigna responsabilidades por grupo para cada componente del WBS y otro de bajo nivel que asigna responsabilidades a individuos. La informacin que contenga la RAM debe coincidir con la informacin del cronograma, en cuanto a los responsables de realizar cada tarea del WBS.

10

SubcontratistaSubco ntratista Familia equipoFamilia equipo Contralora Participan tes GeneralContralora General externos GobiernoGobier no Clientes Proveedor 3Proveedor 3 Proveedor 2Proveedor 2 Proveedor 1Proveedor 1

Tabla 2. 3MIEMBRO 3 Matriz MATRIZ MIEMBRO 2 de DE respons RESPONS abilidad ABILIDAD MIEMBRO 1MIEMBRO 1 ES Participan es

MIEMBRO

tes Miembros del dentro de equipoMiembros del la equipo Departamento organizac 3Departamento 3 in Departamento 2 Departamento 1Departamento 1 Gerentes deGerentes de departamentodepar tamento Oficina de control proyectoproyecto Gerente ProyectoGerente Proyecto PatrocinadorPatroc inador
Descripcin de la

Responsable Actividad PROYECTO administrativoResponsable SIMBOLO tcnicoDebe ser TAREA 1 GIA consultadoPuede ser consultadoDebe ser notificadoDebe aprobar A B 1

TAREA 2

TAREA 3

WBS

1.1 1.1.11.1.21.1.31.2 1.2.11.2.21.2.31.2.41.3 1.3.11.3.2

11 2.7. Proceso Administrativo En esta seccin se debe presentar el proceso para administrar los riesgos del proyecto y los mecanismos que se utilizarn para monitorear el progreso del proyecto. 2.7.1 Objetivos y Prioridades de la Gerencia de alcance, tiempo y costo. A la hora de administrar los requerimientos hay una triple restriccin entre estos tres factores. Los productos de alta calidad entregan el producto requerido con el alcance solicitado, puntualmente y dentro del presupuesto. La relacin entre estos tres factores es tal, que si cambia uno de estos factores algn otro se ve afectado. Estos objetivos deben ser claros y especficos, tangibles y verificables, alcanzables y consistentes con los recursos disponibles y polticas de la organizacin para facilitar su verificacin. Si no se pueden cuantificar son un compromiso de alto riesgo. [1, pg. 56] Se describen los objetivos y prioridades de la administracin en cuanto a criterios

2.7.2 Suposiciones y Restricciones Se deben identificar y describir las suposiciones y las restricciones del proyecto. Si ya se definieron en la fase de factibilidad, en esta fase de planificacin solamente deben mejorarse. Suposiciones: son factores que para el proceso de planificacin se consideran seguros, reales o verdaderos. Las suposiciones afectan todos los aspectos de planificacin del proyecto y son parte de la elaboracin progresiva del proyecto. Los equipos del proyecto los identifican, documentan y validan como parte de su proceso de planificacin. Por ejemplo si la fecha en que una persona clave va a estar disponible es insegura el equipo puede asumir una fecha especfica de inicio. Las suposiciones involucran un grado de Restricciones: son factores que limitarn opciones del equipo administrador del riesgo. proyecto. Por ejemplo: un presupuesto predefinido es una restriccin que limita fuertemente el alcance del proyecto, el personal y el cronograma.

2.7.3 Administracin del Riesgo Los riesgos identifican potenciales problemas presupuestarios, de calendario, de personal, de recursos, de requisitos y otros, y su impacto sobre el proyecto. El riesgo implica un cambio, implica una eleccin, y la falta de certeza de que la eleccin sea la correcta. Cuando se trata el riesgo se deben tomar en cuenta tres consideraciones conceptuales: Cules son los riesgos que pueden hacer que el proyecto fracase?
Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

12 Cmo se afecta el xito del proyecto por los cambios en los requerimientos, en las tecnologas y en otros aspectos relacionados con el proyecto? Qu acciones tomar en caso de que ocurra? Para administrar los riesgos apropiadamente [2] aconseja realizar un procedimiento de anlisis cualitativo de los riesgos que consta de tres pasos los cuales son: 1. Identificar y listar el evento de riesgo. 2. Estimar el evento riesgo. 3. Planear la respuesta al riesgo. Los resultados obtenidos a travs del procedimiento de administracin de riesgos deben incluirse en la tabla 3 recomendada por [4]. A continuacin se explica cada paso de este procedimiento. Tabla 3. Administracin de Riesgos.
Anlisis cualitativo
WBS Fecha de entrada Evento de riesgo Probabilidad Impacto Severidad Plazo

Plan de respuesta al riesgo

Estrategia Accin Responsable

10

DATOS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. General y/o elemento WBS. Fecha de entrada. Descripcin del evento. 0.0 1.0 0.0 1.0 (tiempo, costo y calidad) P+I-(P*I) P*I Permanente, corto, mediano y largo. Evitar, mitigar, transferir y aceptar. Medias a tomar. Responsable.

PROCESO

1.

Ordenar de acuerdo a la severidad y al plazo. Seleccionar los primeros de la lista para monitoreo y control.

3.

Programar y presupuestar considerando esta informacin. Actualizar peridica y sistemticamente la informacin.

2.

4.

Paso 1: Identificar y listar el evento del riesgo. Es el proceso de identificar sistemticamente todo posible evento de riesgo que pueda tener algn impacto en el proyecto. Segn [4] los riesgos deben ser identificados en cada una de las actividades/tareas de la WBS (refirase a la figura 5) y adems debe indicarse la posible fecha en la que se puede presentar el riesgo. Con esta informacin se pueden completar las columnas 1, 2 y 3 de la tabla 3.
Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

13 Para identificar el evento se puede hacer la interrogante: Qu puede suceder? En esta tarea se puede usar la tcnica de lluvia de ideas.
Proyecto

Fase I

Fase II

Fase III

Fase IV
Revise riesgos: Tcnicos Hardware Recursos Humanos Presupuesto Tamao del software Cronograma Calidad software Etc..

Figura 5. Identificacin de riesgos en la WBS Algunos eventos de riesgos a considerar son: Riesgos tcnicos: 1. Problemas potenciales de diseo, implementacin, interfaz. 2. Poca familiaridad del equipo de desarrollo con el hardware, el software, los estndares y los procedimientos. 3. Ambigedad de la especificacin por incomprensin o falta de informacin. 4. Tecnologa nueva u obsoleta. Riesgos del proyecto: 1. Los riesgos asociados al presupuesto. Por ejemplo: que los costos de implementacin sean superiores a los estimados. 2. Los riesgos dados por el tamao. A medida que aumenta el tamao del proyecto se puede afectar el nmero personas encargadas del desarrollo, el nmero de departamentos afectados y el tiempo de duracin del proyecto. 3. Los riesgos asociados al cronograma. Por ejemplo: que el tiempo de implementacin sea superior al estimado. 4. Los riesgos asociados a los recursos humanos: de capacitacin, adquisicin y retencin del personal. Por ejemplo: que el rendimiento tcnico del personal 5.sea inferior al estimado debido a una dbil capacitacin. falta de Los riesgos asociados a la complejidad del producto por aceptacin del producto, o por no tener los beneficios anticipados debido a la complejidad del producto. 6. Los riesgos contractuales en caso de que el desarrollo sea contratado externamente. Por ejemplo: incumplimiento de algunas clusulas claves.
Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

14

Paso 2. Estimar el evento de riesgo. Se deben analizar los riesgos de acuerdo a la probabilidad de que ocurran y al impacto potencial sobre el proceso de desarrollo, para despus estimar la severidad. En este paso se puede completar la informacin de las columnas 4, 5, 6 y 7 de la tabla 3. Paso 2.1 Estimar la probabilidad del riesgo: Cul es la probabilidad de que ocurra el evento? Para estimar la probabilidad de que ocurra el riesgo se debe asignar un peso que refleje la probabilidad observada. El peso se debe tomar de una escala previamente establecida que puede estar entre 0.0 y 1.0. Una posible escala a utilizar se muestra en la tabla 4. Tabla 4. Escala para evaluar la probabilidad de que ocurra el riesgo. Fase Seguro Casi seguro Probablemente Puede ser Quizs No creo Improbable Probabilidad 1.00 0.90 0.80 0.60 0.40 0.20 0.10

Paso 2.2 Evaluar el impacto del riesgo: El impacto se refiere al grado hasta el cual, el xito del proyecto se puede ver afectado por la ocurrencia del riesgo. Para estimarlo se debe establecer tambin una escala la cual puede estar entre 0.0 y 1.0. Una posible escala a utilizar se muestra en la tabla 5. Para usar esta tabla se debe ubicar el criterio a evaluar (tiempo, costo o calidad) y analizar el alcance del riesgo y esto determina la calificacin del impacto. Por ejemplo: si el criterio es costo y presumimos que podra darse un sobre-costo de 7.5% a 10%, entonces se le asigna una calificacin de impacto de 0.8. Si el criterio es tiempo y sospechamos que podra haber un retraso de un 8% la calificacin al impacto es 0.6%.

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

15 Tabla 5. Evaluacin de la impacto del riesgo sobre el proyecto. TIEMPO COSTO CALIDAD - DESEMPEO Inservible Degradacin de funciones y/o caractersticas importantes Media Pequea Mnima No hay efecto ALCANCE 1.0 0.8 0.6 0.4 0.2 0.1

Retraso mayor al Sobre costo mayor 20% al 10% Retraso del 10% al 20% Retraso hasta el 10% Elimina holguras totales Sobre costo del 7.5% al 10% Sobre costo del 5% al 7.5% Sobre costo del 2.5% al 5%

Elimina holguras Sobre costo mayor libresal 2.5% No hay efecto No hay efecto

Paso 2.3 Estimar la severidad del riesgo: Para estimar la severidad del riesgo se puede hacer de dos formas: Severidad (S) = Probabilidad (P) * Impacto (I) Severidad (S) = Probabilidad (P)+ Impacto (I) (Probabilidad (P)*Impacto (I)) En este punto bien podra decidirse si suspender el proyecto o continuarlo pero con un costo adicional. Hasta aqu se han determinado las columnas 4, 5 y 6 correspondientes a la Probabilidad, Impacto y Severidad de la tabla 3. Para completar la columna correspondiente al Plazo del riesgo, se debe analizar el evento de riesgo desde el punto de vista de permanencia en el tiempo: un riesgo se puede presentar permanentemente durante el proceso de desarrollo, o puede presentarse durante un perodo de tiempo corto, mediano o largo. Paso 3. Planear la respuesta al riesgo. En este paso del procedimiento se puede completar la informacin de las columnas 7, 8, 9 y 10 de la tabla 3. Para planear una respuesta al riesgo se debe definir una estrategia que permita aumentar las oportunidades de alcanzar los objetivos del proyecto y Para reducir lasevitar gastos excesivos en la administracin del riesgo, se pueden seleccionar amenazas que atentan contra ellos. de la lista de riesgos priorizada por la severidad (elaborada en los pasos anteriores), los 10 primeros y definir un Plan de respuesta para cada uno de ellos, el cual contendr Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: acciones 28/08/2006. concretas queGabriela Salazar. Universidadpara reducir la probabilidad de que ocurra una se deben emprender de Costa Rica. Autora: Profesora situacin

16 que afecte el desarrollo del proyecto. Otra forma de seleccionar los principales riesgos del proyecto es de aplicar la regla de Pareto 80-20 [2] y seleccionar el 20% de la lista de riesgos. Este Plan de respuesta incluye tres aspectos por cada riesgo (la estrategia, el plan y el responsable de monitorear el riesgo) y sern explicados a continuacin: Paso 3.1 Definir la estrategia y el plan de accin: Para definir la estrategia nos podemos hacer ciertas preguntas claves: Cmo se puede evitar este riesgo? Puede reducirse este riesgo? Puede ser compartido o transferido el riesgo? Debemos aceptar el riesgo y en su caso, cules seran las reservas necesarias?

Las estrategias pueden ser: Evitar, Mitigar, Transferir o Aceptar. Una vez que hemos determinado la estrategia podemos planear las acciones. A continuacin se presenta cada estrategia y posibles acciones a realizar. Se podran definir nuevas acciones. Evitar. Significa no aceptar esta accin debido a sus resultados desfavorables potenciales. Acciones Eliminar la causa del evento. Suspender el proyecto. Modificar el procedimiento tecnologa. Cambiar los requerimientos y/o especificaciones. Mitigar. Significa estar enterado del riesgo y hacer lo mejor para minimizar las posibilidades de que ocurra, as como su efecto. La mitigacin es efectiva cuando la accin se toma oportunamente y cuando los gastos de mitigacin son bajos comparados con el impacto del riesgo. Acciones Reducir el impacto. Reducir la probabilidad de ocurrencia Transferir. Significa estar enterado del riesgo y transferirlo todo o parte a un tercero. Acciones Seguros y finanzas. Estrategias de contratacin. Aceptar. Significa estar enterado del riesgo y estar dispuesto a aceptar las consecuencias si esto llega a ocurrir. Hay una decisin consciente de no cambiar el plan del proyecto. Hay un reconocimiento de que no es posible identificar una estrategia de respuesta. Acciones Reservas de tiempo y costo. Planes de contingencia.
Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

17 Paso 3.2 Asignar un responsable al evento de riesgo: Se debe identificar un responsable de estar monitoreando el riesgo y en caso de que se presente, ste le debe comunicar al lder del proyecto para proceder a ejecutar las acciones planificadas y corregir as las condiciones de riesgo. Esto involucra el uso de revisiones tcnicas y administrativas. Es conveniente asignar como responsable de monitorear los riesgos a una sola persona para el anexo 1 de este documento se presenta un ejemplo de la metodologa de En evitar que se diluya la responsabilidad. administracin de riesgos.

2.7.4 Mecanismos de Control El proyecto debe controlarse tanto a nivel administrativo como a nivel tcnico. Para controlar el progreso a nivel administrativo se recomienda aplicar Revisiones Administrativas que aseguren la ejecucin efectiva de los planes de desarrollo. Estas revisiones sirven para evaluar el avance del proyecto contra lo planificado y permiten tomar decisiones que le den la direccin adecuada. Asimismo, cada vez que surjan situaciones inesperadas que requieran modificar lo planificado se debe actualizar el plan. Estas revisiones deben estar incorporadas en el cronograma, es decir, deben haber hitos en el cronograma asociados a revisiones administrativas. Para controlar el desarrollo del software a nivel tcnico se recomienda aplicar cualquiera de las tcnicas recomendadas en [7] como son: Revisiones Tcnicas, Caminatas, Inspecciones, dependiendo del producto y de la fase que se est evaluando, las cuales deben incorporarse de Consecucin de Recursos Humanos 2.7.5 Plan tambin en el cronograma del proyecto. En esta seccin se deben identificar el nmero y perfil tcnico de todo el personal requerido para cada tarea del proyecto. Para esto es necesario indicar especficamente: 1) El nmero de funcionarios que se encargarn del desarrollo. 2) El perfil requerido para realizar las tareas y la fase en la que se requiere. 3) A partir de qu fecha se requiere el personal y por cunto tiempo. 4) Si es necesario capacitar al personal se debe definir: a. El rea en que requiere la capacitacin (redes de comunicacin, una herramienta especfica, etc.). b. El responsable de la capacitacin c. La fecha de inicio. d. La duracin e. Los recursos necesarios para realizar la capacitacin (material, equipo, instalacin fsica, etc).

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

18 Si no se tuviera la informacin disponible para planificar la capacitacin se debe actualizar el plan del proyecto en el momento en que se obtenga. 2.8. Proceso Tcnico 2.8.1 Mtodos, Herramientas y Tcnicas que se utilizarn para desarrollar el proyecto. A continuacin se muestran algunos ejemplos: Metodologas de desarrollo que se utilizarn como por ejemplo: anlisis y diseo estructurado, anlisis y diseo orientado a objetos, etc.. En esta seccin se deben especificar los mtodos, las herramientas y las tcnicas

El Sistema Administrador de Base de Datos que se utilizar y caractersticas como por ejemplo: distribuido o centralizado. Diseo de Bases de Datos como por ejemplo: Microsoft SQL Server 2000. Herramientas para programar como por ejemplo: Microsoft Visual Studio .NET. Herramientas para probar, instalar y mantener el software. Herramientas de apoyo. Algunos ejemplos son: Microsoft Project 2000 para administrar el proyecto, Rational Rose para especificar el anlisis y el diseo, Microsoft Word, Excel, etc..

2.8.2 Documentacin del Proyecto En esta seccin se deben especificar todos los productos de software que deberan ser administrados como parte de la configuracin del software, es decir, aquellos que se requiere mantener durante la ejecucin del proyecto y el mantenimiento del software. Entre los elementos que se deben mantener estn: Alcance o Descripcin Conceptual del Sistema. Plan del proyecto. Diagramas de Rational Rose (Diagramas de Casos de Uso con su respectiva especificacin, Diagramas de Secuencia, Diagramas de Clases). Especificacin de Requerimientos. Especificacin del Diseo. Cdigo (programa fuente y ejecutable). Casos de pruebas y reporte de pruebas del sistema. Manuales tcnicos. Manual de usuario incluyendo manual de instalacin. Software para la instalacin de la aplicacin. Documentos administrativos como: Reporte Tcnico, Reporte Administrativo, Listas de Chequeo, Reportes de Auditora y todas las minutas de las reuniones.

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

19 Debe existir respaldo de esta documentacin fuera del sitio donde se desarrolla. 2.9. Elaboracin del Cronograma En esta seccin se deben especificar los paquetes de trabajo, las relaciones de dependencias entre ellos, el presupuesto y los recursos para los paquetes de trabajo y establecer un cronograma. A continuacin se indican las tareas que se deben realizar para elaborar un cronograma de acuerdo a [4]: 2.9.1 Definir actividades Identificar actividades especficas del cronograma que se deben realizar para producir los diferentes productos entregables del proyecto. Por ejemplo para obtener la especificacin de requerimientos que podra ser un acuerdo o entregable, es necesaria la actividad de Anlisis la cual est compuesta por una serie de tareas. Para lograrlo se debe elaborar un diagrama WBS que muestre las relaciones jerrquicas entre las actividades. En el 2.9.2 Establecer la secuencia de las actividades anexo 2 de este documento se presenta una plantilla de WBS. Identifica y documenta las relaciones lgicas denominadas dependencias, entre las actividades del cronograma. Pueden estar ordenadas en forma lgica con relaciones de precedencia adecuadas o pueden incluir adelantos y retrasos para respaldar el desarrollo posterior de un cronograma realista. Algunas herramientas para establecer la secuencia de las actividades son los diagramas de red, los cuales son representaciones esquemticas de las actividades del cronograma y las relaciones lgicas entre ellas. Dos enfoques son: el PDM (Mtodo de Diagramacin por Precedencia) y el ADM (Mtodo de Diagramacin 2.9.3 Estimar los diagramas las actividades con Flechas). Estos recursos dese pueden elaborar con un software de administracin de Estima el tipo y las cantidades de recursos necesarios para realizar cada actividad proyectos como Microsoft Project. [4] del cronograma. Determina cules son los recursos (personas, equipo o material) y qu cantidad de cada recurso se utilizar y cundo estar disponible cada recurso para realizar las actividades del proyecto. La misma herramienta de Project ayuda en esta tarea. 2.9.4 Estimar la duracin de las actividades Estima la cantidad de perodos laborables que sern necesarios para completar cada actividad del cronograma. Para determinar la cantidad de perodos laborables se requiere estimar la cantidad de esfuerzo de trabajo necesario, para completar la actividad del cronograma. Entre las herramientas que se puede utilizar est el juicio de expertos guiado por informacin histrica, la estimacin por analoga (que es utilizar la duracin real de una actividad de un cronograma anterior y similar como base, para la estimacin de una actividad de un futuro cronograma) y la estimacin por Valor Esperado (que incorpora Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: la 28/08/2006. rangos esperados y se basa en tres valores: Ms Probable, Pesimista y nocin de Autora: Profesora Gabriela Salazar. Universidad de Costa Rica. Optimista). Se recomienda utilizar como complemento de las dos primeras la del Valor

20 Esperado pero obtenido a partir de Puntos de Funcin y datos histricos de productividad (Refirase a [6] para conocer esta metodologa). 2.9.5 Desarrollar el cronograma Analiza las secuencias de las actividades, la duracin de las actividades, los requisitos de recursos y las restricciones del proyecto para crear el cronograma. Exige que se revisen y corrijan las estimaciones de duracin y de los recursos para crear un cronograma aprobado que pueda servir como lnea base, con respecto a la cual se pueda medir el avance. El cronograma contina actualizndose a lo largo del proyecto, a medida que el trabajo avanza el plan cambia. Como herramientas se utiliza: Anlisis de la red del cronograma, el Mtodo de la Ruta Crtica, Nivelacin de recursos, Compresin del Nota importante: cronograma, aspectos que se salen del alcance de este documento pero se explican detalladamente en [4]. Al plan del proyecto se le debe anexar el archivo electrnico del cronograma y todos los clculos realizados para estimar el esfuerzo, incluyendo el clculo de Puntos de Funcin y la distribucin del tiempo en las fases del ciclo de vida.

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

21 3. Formato del Plan de Administracin de Proyectos de Software A continuacin se muestra el formato en que se debe presentar todo plan de un proyecto. Todos estos puntos fueron explicados en detalle en la seccin 2 de este documento. Portada Hoja de Aprobacin Bitcora de Cambios Tabla de Contenido 1. Introduccin 1.1 Descripcin General del Proyecto 1.2 Productos Finales (Entregables) 1.3 Definiciones y abreviaturas 1.4 Referencias 2. Organizacin del Proyecto 2.1 Modelo del Ciclo de Vida del Proyecto 2.2 Estructura Organizacional 2.3 Responsabilidades 3. Proceso Administrativo 3.1 Objetivos y prioridades de la gerencia 3.2 Suposiciones, Dependencias y Restricciones 3.3 Administracin del Riesgo 3.4 Mecanismos de Control 3.5 Plan de Recursos Humanos 4. Proceso Tcnico 4.1 Mtodos, Herramientas y Tcnicas 4.2 Documentacin del Proyecto 5. Elaboracin del Cronograma 5.1 Definir actividades 5.2 Establecer la secuencia de las actividades 5.3 Estimar los recursos de las actividades 5.4 Estimar la duracin de las actividades 5.5 Desarrollar el cronograma

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

22

ANEXO 1: Ejemplo de la metodologa de Administracin de Riesgos

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

23 Lista De Posibles Riesgos A) Se retrasa el proyecto. B) Desconocimiento del software utilizado durante el desarrollo. C) Uno o ms laboratorios son cerrados o reservados sin previo aviso, provocando falta de mquinas para trabajar. D) Es desinstalado de los laboratorios uno de los paquetes de software necesarios para el desarrollo del proyecto. E) Prdida del respaldo electrnico del cdigo fuente. F) Uno de los compaeros de trabajo debe ausentarse por causas fuera de su control (enfermedad, presas, etc.). G) Cambio de ltima hora en los requerimientos del proyecto. H) Disminucin de la disponibilidad del equipo de desarrollo debido al compromiso con otras tareas. I) Retraso debido a falta de disponibilidad por parte del cliente en el momento de realizar alguna consulta. Lista de Acciones Para Enfrentar Riesgos 1. 2. 3. 4. 5. 6. 7. 8. 9. Replanteamiento de la fecha de entrega. Reasignacin de tarea a responsable Solicitar soporte o capacitacin en la herramienta de software. Solicitar al responsable de reservar los laboratorios, avise por lo menos una semana antes, para as poder organizarnos con el uso de los mismos. Estar en contacto con el administrador de la red para poder estar al tanto de cualquier cambio en los paquetes instalados en cada laboratorio. Procurar una buena administracin de la configuracin del software. Aceptar el riesgo y reasignar la carga de trabajo del compaero faltante entre el resto del grupo. Estar en contacto con el usuario. Reajustar el tiempo de trabajo del miembro del grupo o reorganizar las responsabilidades del grupo para evitar un posible retraso.

Los datos presentados en la siguiente tabla no necesariamente son reales, son solo para ejemplificar la metodologa.

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

24

Observe que: 1) los riesgos pueden repetirse en diferentes actividades 1, 2 y 3 1, 2 Accin y 3 1, 2 y 3 1, 2 y 3 pero el estado 6 6 4 5 4 4 4 4 1 3 7 6 de cada uno (probabilidad, impacto,severid Estrategi ad AceptarMitigar Mitigar Aceptar AceptarMitigar Aceptar y plazo) Mitigar Evitar Evitar Evitar Evitar Evitar a Mitigar Mitigar Mitigar depende de la actividad del proyecto en que se est dando. 2) Un evento de Mediano Tabla 6. Mediano Mediano Mediano Mediano Mediano Mediano Corto Mediano riesgo se le Largo Corto Corto Corto Plazo Ejemplo Corto Corto CortoLargo MedianoLargo Corto pueden aplicar de una o administ msacciones racin para alcanzar la de estrategia. 3) Es Severida riesgos0.54 0.32 0.32 0.24 0.16 0.12 0.12 0.04 0.54 0.32 0.24 0.16 0.32 0.24 0.16 0.4 conveniente Gua para d Elaborar asignar a una Planes de Administraci nica persona n de como Proyectos de responsable de Software. Fecha de monitorear los Impacto 0.2 0.6 0.8 0.4 0.6 0.8 0.8 0.4 0.4 0.2 0.6 0.4 0.8 0.4 0.4 0.4 creacin: riesgos yaplicar 28/08/2006.A las acciones,utora: Profesora para evitar que se diluya la Gabriela Salazar. Probabili responsabilidad. Universidad
Q D A C D A JM C A D JM Q C D JM Q

Responsa ble

dad0.9 0.4 0.4 0.6 0.4 0.6 0.2

0.2 0.9 0.4 0.6

0.4 0.4 0.6

0.4

0.1

de Costa Rica.

Evento
A D A D A D F A D A F B C E G H

Fecha

21/04/200404/05/2004 07/05/2004 28/05/2004 28/05/200401/09/2004 23/04/2004 12/05/2004 01/09/2004 15/06/200406/10/2004 N/A

Todo

WBS
1.1.3

1.2.1.1 1.2.1.4 1.3

el Proyecto 1.3.3 1.4

25

ANEXO 2: Plantilla de Actividades (WBS)

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

26 1. Conceptualizar el Proyecto 1.1Realizar diagnstico, requerimientos sistema, alcance, supuestos y restricciones, del Sistema 1.2Definir los requerimientos del usuario 1.3Estimar el esfuerzo de implementacin 1.4Evaluar la viabilidad del proyecto 1.5Revisar Descripcin Conceptual 1.6Entregar Descripcin Conceptual (hito) 2. Planificar el Proyecto 2.1Definir Organizacin del Proyecto 2.2Definir el Proceso Administrativo (objetivos, suposiciones y restricciones, riesgos y mecanismos de control) 2.3Definir el Proceso Tcnico (mtodos, herramientas, tcnicas y documentacin del proyecto) 2.4Elaborar el Cronograma 2.5Revisar Plan de Proyecto 2.6Entregar Plan de Proyecto aprobado (hito) 3. Analizar Requerimientos 3.1Elaborar Modelo de Anlisis 3.2Modelar Interacciones entre los Objetos 3.3Elaborar Diagrama de Clases 3.4Elaborar Prototipo de Interfaces (pantallas, navegacin) 3.5Especificar Requerimientos 3.6Elaborar Casos de Prueba 3.7Revisar Especificacin de Requerimientos 3.8Entregar Especificacin de Requerimientos aprobado (hito) 4. Disear Sistema 4.1Disear Implementacin del Objeto (descripcin de los mtodos) 4.2Documentar Especificacin del Diseo 4.3Revisar Especificacin del Diseo 4.4Entregar Especificacin del Diseo. (hito) 5. Programar Mdulos 5.1Genera Bases de Datos. 5.2Programar Mdulos 5.2.1 Programar Mdulo 1 5.2.2 Programar Mdulo n 6. Probar 6.1Realizar pruebas de Unidad del Mdulo 6.2Realizar pruebas de Integracin de los Mdulos 7 Entregar 7.1 Crear manuales de usuario y procedimiento de instalacin 7.2Realizar Pruebas de Aceptacin del Sistema. 7.3 Evaluar informes de defectos.
Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.

27

Gua para Elaborar Planes de Administracin de Proyectos de Software. Fecha de creacin: 28/08/2006. Autora: Profesora Gabriela Salazar. Universidad de Costa Rica.