MAESTRÍA EN ADMINISTRACIÓN DE PROYECTOS · maestrÍa en administraciÓn de proyectos universidad para la cooperaciÓn internacional (uci) ... informe de revisiÓn cierre del proyecto.....124

MAESTRÍA EN ADMINISTRACIÓN DE PROYECTOS

UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)

ESTÁNDAR MODELO DE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMÁCIÓN PARA LA DEFENSORÍA DE HABITANTES DE LA REPÚBLICA (VERSIÓN 1.0).

JUAN OSVALDO RAMÍREZ SANDÍ

PROYECTO FINAL DE GRADUACIÓN PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TÍTULO DE MASTER EN ADMINISTRACIÓN DE PROYECTOS

SAN JOSÉ, COSTA RICA

SEPTIEMBRE, 2007

MAESTRÍA EN ADMINISTRACIÓN DE PROYECTOS

ii

UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)

Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito para optar por el grado de Master en Administración de Proyectos

_________________________________ YURI KOGAN SCHMUKLER

PROFESOR TUTOR

_________________________________ YORLENI HIDALGO MORALES

LECTOR 1

_________________________________ BERNARDO LÓPEZ GONZÁLEZ

LECTOR 2

_________________________________ JUAN OSVALDO RAMÍREZ SANDÍ

SUSTENTANTE

DEDICATORIA Este trabajo final de graduación lo dedico a las personas que más amo, y que siempre han estado a mi lado brindándome su apoyo y su amor: A Dios. Por haberme permitido llegar hasta este punto y haberme dado salud para lograr mis objetivos, además de su infinita bondad, misericordia y amor. A mi Andreita. Por todo su apoyo y motivación constante, por su paciencia, por enseñarme a crecer como persona, por hacerme mostrar mis defectos y mis virtudes descubriéndome a mi mismo, por mostrarme un camino diferente en mi vida lleno de ideales y de luchas, por haberme dado las mejores lecciones de mi vida, porque soy una persona diferente gracias a ti. Y sobre todo mi muñequita linda… por tu inmenso amor a pesar de todas las circunstancias… A mi hija María Estefanía. Por ser una estrella preciosa que brilla en el horizonte de mi caminar, por hacer de mi el papá mas orgulloso del mundo, por ser la hija más linda del universo. A mi madre Miriam. Por haberme apoyado en todo momento, por sus consejos, sus valores, por la motivación constante que me ha permitido ser una persona de bien, por su sufrimientos en silencio, por su valentía para afrontar las condiciones de vida que ha tenido, pero más que nada, por su amor. A mi padre de mi infancia. Por los ejemplos de perseverancia y constancia que lo caracterizan y que me ha infundado siempre, por el valor mostrado para salir adelante y por su amor. A mis familiares. A mi hermano Luis Fernando por ser el ejemplo de hermano, luchando en esta vida a pesar de su enfermedad y de quien aprendo cada día más a pesar de su corta edad; a mis hermanos Nuvia y Adolfo, mis sobrinas Nayeli y Valeria, a mi tía Marita, a mi ahijado Gabriel y a todos aquellos que participaron directa o indirectamente en la elaboración de esta tesis.

iii

RECONOCIMIENTOS Deseo expresar mis más sinceras muestras de agradecimiento: A mi Jesús de la Misericordia por permitirme llegar a este momento tan especial en mi vida. Por los triunfos y los momentos difíciles que me han enseñado a valorarte cada día más. A ti Madre, por haberme educado y soportar mis errores. Gracias a tus consejos, por el amor que siempre me has brindado, por cultivar e inculcar ese sabio don de la responsabilidad. ¡Gracias por darme la vida! ¡Te quiero mucho! A ti Andreita, a quien amo tanto en esta vida, te agradezco el cariño, la comprensión, la paciencia y el apoyo que me brindó para culminar mi carrera profesional. A mis Hermanos, por que siempre he contado con ellos para todo, gracias a la confianza que siempre nos hemos tenido; por el apoyo y amistad. ¡Gracias! A mis Familiares. Gracias a mi hija por sacrificar su tiempo por mí, a todas mis sobrinas que directamente me impulsaron para llegar hasta este lugar, a todos mis familiares que me resulta muy difícil poder nombrarlos en tan poco espacio, sin embargo ustedes saben quienes son. A mis amigos. A quienes me apoyamos mutuamente en nuestra formación profesional y que hasta ahora, seguimos siendo amigos: a Milenia, Sergio y Cristian por formar parte de mi equipo de trabajo en toda la maestría. A mis amigos Natalie y Alexander por su amistad incondicional. A Marita y a Rodrigo quienes además de ser familiares son verdaderos y especiales amigos. A la UCI y en especial a la Maestría en Administración de Proyectos por permitirme ser parte de una generación de triunfadores y gente productiva para el país.

iv

v

ÍNDICE DE CONTENIDO RESUMEN EJECUTIVO....................................................................................................xiv 1. INTRODUCCIÓN.........................................................................................................16

1.1. ANTECEDENTES....................................................................................................16 1.1.1. ESTRATEGIA INSTITUCIONAL Y TECNOLOGÍAS DE INFORMACIÓN .............16 1.1.2. PROBLEMÁTICA ............................................................................................17

1.2. JUSTIFICACIÓN DEL PROYECTO...........................................................................18 1.3. OBJETIVOS DEL PROYECTO .................................................................................19

1.3.1. OBJETIVO GENERAL .....................................................................................19 1.3.2. OBJETIVOS ESPECÍFICOS.............................................................................19

2. MARCO TEÓRICO .....................................................................................................20 2.1. MARCO INSTITUCIONAL ........................................................................................20

2.1.1. LA DEFENSORÍA DE LOS HABITANTES DE LA REPÚBLICA..........................20 2.1.2. MISIÓN...........................................................................................................20 2.1.3. VISIÓN ...........................................................................................................20 2.1.4. ANTECEDENTES DE LA FIGURA ...................................................................21 2.1.5. ANTECEDENTES DE LA INSTITUCIÓN EN COSTA RICA ................................21 2.1.6. COMPETENCIA Y RESPONSABILIDADES ......................................................24 2.1.7. COMPOSICIÓN E INDEPENDENCIA................................................................26 2.1.8. FUNCIONAMIENTO ........................................................................................27 2.1.9. ESTRUCTURA ORGÁNICA .............................................................................29 2.1.10. FUNCIONAMIENTO Y MANEJO DEL PRESUPUESTO .....................................30

2.2. ADMINISTRACIÓN DE PROYECTOS.......................................................................30 2.2.1. ¿QUÉ ES UN PROYECTO? .............................................................................30

2.2.1.1. CARACTERÍSTICAS DEL PROYECTO ........................................................30 2.2.1.1.1. TEMPORAL ..........................................................................................30 2.2.1.1.2. PRODUCTOS, SERVICIOS O RESULTADOS ÚNICOS ...........................31 2.2.1.1.3. ELABORACIÓN GRADUAL ...................................................................31

2.2.2. PROYECTOS FRENTE A TRABAJOS OPERATIVOS .......................................31 2.2.3. PROYECTOS Y PLANIFICACIÓN ESTRATÉGICA............................................32 2.2.4. ¿QUÉ ES LA DIRECCIÓN DE PROYECTOS? ..................................................33 2.2.5. CONTEXTO DE LA DIRECCIÓN DE PROYECTOS ...........................................34

2.2.5.1. PROGRAMAS Y DIRECCIÓN DE PROGRAMAS ..........................................34 2.2.5.2. PORTAFOLIOS Y GESTIÓN DEL PORTAFOLIO ..........................................35 2.2.5.3. SUBPROYECTOS .......................................................................................35 2.2.5.4. OFICINA DE GESTIÓN DE PROYECTOS .....................................................36

2.2.6. CICLO DE VIDA DEL PROYECTO ...................................................................37 2.2.6.1. CARACTERÍSTICAS DEL CICLO DE VIDA DEL PROYECTO........................37 2.2.6.2. CARACTERÍSTICAS DE LAS FASES DEL PROYECTO................................40 2.2.6.3. RELACIONES DEL CICLO DE VIDA DEL PROYECTO Y DEL CICLO DE VIDA DEL PRODUCTO ........................................................................................................41 2.2.6.4. INTERESADOS EN EL PROYECTO .............................................................42

vi

2.2.7. PROCESOS DE DIRECCIÓN DE PROYECTOS ................................................45 2.2.7.1. GRUPO DE PROCESOS DE DIRECCIÓN DE PROYECTOS..........................46

2.2.7.1.1. GRUPO DE PROCESOS DE INICIACIÓN ...............................................47 2.2.7.1.2. GRUPO DE PROCESOS DE PLANIFICACIÓN........................................47 2.2.7.1.3. GRUPO DE PROCESOS DE EJECUCIÓN ..............................................48 2.2.7.1.4. GRUPO DE PROCESOS DE SEGUIMIENTO Y CONTROL ......................49 2.2.7.1.5. GRUPO DE PROCESOS DE CIERRE .....................................................50

2.2.7.2. INTERACCIONES ENTRE PROCESOS........................................................50 2.2.8. ÁREAS DE CONOCIMIENTO DE LA DIRECCIÓN DE PROYECTOS..................51

2.2.8.1. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO ......................................51 2.2.8.2. GESTIÓN DEL ALCANCE DEL PROYECTO ................................................51 2.2.8.3. GESTIÓN DEL TIEMPO DEL PROYECTO ....................................................52 2.2.8.4. GESTIÓN DE LOS COSTES DEL PROYECTO .............................................53 2.2.8.5. GESTIÓN DE LA CALIDAD DEL PROYECTO ..............................................54 2.2.8.6. GESTIÓN DE LOS RECURSOS HUMANOS DEL PROYECTO ......................55 2.2.8.7. GESTIÓN DE LAS COMUNICACIONES DEL PROYECTO ............................56 2.2.8.8. GESTIÓN DE LOS RIESGOS DEL PROYECTO ............................................57 2.2.8.9. GESTIÓN DE LAS ADQUISICIONES DEL PROYECTO.................................59

2.3. PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACIÓN .......................60 2.3.1. CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN .................................61

2.3.1.1. CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS ....................62 2.3.1.2. MÉTODO DE DESARROLLO POR ANÁLISIS ESTRUCTURADO ..................64

2.3.1.2.1. COMPONENTES ...................................................................................65 2.3.1.2.2. DISEÑO ESTRUCTURADO. ...................................................................65 2.3.1.2.3. ANÁLISIS DE FLUJO DE DATOS...........................................................66 2.3.1.2.4. HERRAMIENTAS ..................................................................................66 2.3.1.2.5. DIAGRAMA DE FLUJO DE DATOS........................................................66

2.3.1.3. MÉTODO DEL PROTOTIPO DE SISTEMAS .....................................................67 3. MARCO METODOLÓGICO ...................................................................................70

3.1. FUENTES DE INFORMACIÓN .....................................................................................70 3.2. MÉTODO DE INVESTIGACIÓN....................................................................................71 3.3. TÉCNICAS DE INVESTIGACIÓN .................................................................................72

4. DESARROLLO .............................................................................................................77 4.1. POLITICAS PARA LA ADMINISTRACIÓN DE PROYECTOS........................................77

4.1.1. ORGANIZACIÓN DE TECNOLOGÍAS DE INFORMACIÓN DE LA DEFENSORÍA DE LOS HABITANTES..........................................................................................................78 4.1.2. PRINCIPALES PARTICIPANTES Y SU PAPEL.....................................................78

4.1.2.1. COMITÉ DIRECTOR INFORMÁTICO................................................................79 4.1.2.2. DEPARTAMENTO DE INFORMÁTICA. ............................................................79 4.1.2.3. ÁREAS USUARIAS. ........................................................................................80 4.1.2.4. AUDITORIA INTERNA. ....................................................................................81 4.1.2.5. DEPARTAMENTO DE PLANIFICACIÓN ESTRATÉGICA. .................................82 4.1.2.6. ENTIDADES EXTERNAS. ................................................................................82

vii

4.1.3. FUNCIONES DEL ADMINISTRADOR DE PROYECTOS. .......................................83 4.1.4. FUNCIONES DEL LÍDER DE PROYECTO. ...........................................................86 4.1.5. ESQUEMAS ORGANIZATIVOS DE PROYECTOS.................................................88 4.1.6. CRITERIOS PARA LA ORGANIZACIÓN DE PROYECTOS....................................90 4.1.7. CONCEPTUALIZACIÓN DE PROYECTOS. ..........................................................93

4.1.7.1. ELABORACIÓN Y JUSTIFICACIÓN DE UN ÁREA DE LA NECESIDAD DE UN PROYECTO DE TECNOLOGÍAS DE INFORMACIÓN....................................................93 4.1.7.2. APROBACIÓN O RECHAZO DE LA SOLICITUD DE PROPUESTA DE PROYECTO. ...............................................................................................................95 4.1.7.3. DESARROLLO DEL DOCUMENTO ENUNCIADO DEL ALCANCE DEL PROYECTO PRELIMINAR...........................................................................................98 4.1.7.4. ENUNCIADO DEL ALCANCE DEL PROYECTO PRELIMINAR. .......................100 4.1.7.5. APROBACIÓN DEL PROYECTO (ELABORACIÓN DEL DOCUMENTO ACTA DE CONSTITUCIÓN DEL PROYECTO Y DEL DOCUMENTO MATRIZ DE INVOLUCRADOS DEL PROYECTO)......................................................................................................102

4.2. PROCEDIMIENTO GENERAL DE GESTIÓN DE PROYECTOS INFORMÁTICOS. .......105 4.2.1. OBJETIVO. .......................................................................................................105 4.2.2. ÁMBITO............................................................................................................105 4.2.3. METODOLOGÍA................................................................................................105 4.2.4. PUESTA EN PRÁCTICA DE LA METODOLOGÍA. ..............................................106 4.2.5. REFERENCIAS. ................................................................................................106 4.2.6. FUNCIONES Y RESPONSABILIDADES. ............................................................107 4.2.7. ENTRADAS. .....................................................................................................108 4.2.8. SALIDAS. .........................................................................................................109 4.2.9. MECANISMOS DE CONTROL. ..........................................................................110 4.2.10. DESCRIPCIÓN DEL PROCEDIMIENTO..............................................................110

4.2.10.1. INICIACIÓN DEL PROYECTO....................................................................110 4.2.10.2. PLANIFICACIÓN DEL PROYECTO. ...........................................................112

4.2.10.2.1. ORGANIZACIÓN DEL PROYECTO. .......................................................112 4.2.10.2.2. PROCESOS DE GESTIÓN DE PROYECTOS. .........................................113 4.2.10.2.3. ELABORACIÓN DEL PLAN DE GESTIÓN DEL PROYECTO. ..................114 4.2.10.2.4. OTRAS ACTIVIDADES DE PLANIFICACIÓN. .........................................117

4.2.10.3. SEGUIMIENTO Y CONTROL DEL PROYECTO...........................................118 4.2.10.3.1. EL ARCHIVO DEL PROYECTO..............................................................121 4.2.10.3.2. ELABORACIÓN DE INFORMES SOBRE EL PROYECTO. ......................122 4.2.10.3.3. INFORMES SOBRE EL PROGRESO DEL PROYECTO. ..........................123 4.2.10.3.4. INFORME DE REUNIONES DE ACEPTACIÓN DE FASES/ETAPAS. .......123 4.2.10.3.5. INFORMES SOBRE EMERGENCIAS/PROBLEMAS. ..............................123 4.2.10.3.6. INFORMES SOBRE SOLICITUDES DE CAMBIO. ...................................123 4.2.10.3.7. INFORME DE REVISIÓN CIERRE DEL PROYECTO. ..............................124

4.2.10.4. FINALIZACIÓN (CIERRE) DEL PROYECTO. ..............................................124 4.2.11. PLANTILLAS Y LISTAS DE VERIFICACIÓN ASOCIADOS..................................127

4.3. PLANTILLAS Y HERRAMIENTAS DE LA GESTIÓN DE PROYECTOS. ......................128

viii

4.3.1. PLANTILLAS DE LA GESTIÓN DE PROYECTOS...............................................128 4.3.1.1. PLANTILLAS DE CONCEPTUALIZACIÓN DE PROYECTOS ..........................130

4.3.1.1.1. (CON-SPP-01) SOLICITUD DE PROPUESTA DE PROYECTO ................131 4.3.1.1.2. (CON-ARP-02) ANÁLISIS DE REQUERIMIENTOS PRELIMINAR ............138 4.3.1.1.3. (CON-EAPP-03) ENUNCIADO DEL ALCANCE DEL PROYECTO PRELIMINAR ........................................................................................................146 4.3.1.1.4. (CON-ACP-04) ACTA DE CONSTITUCIÓN DEL PROYECTO ..................155 4.3.1.1.5. (CON-MIP-05) MATRIZ DE INVOLUCRADOS DEL PROYECTO ..............159 4.3.1.1.6. (CON-LVCRAP-06) LISTA DE VERIFICACIÓN – COMPROBACIÓN DE LA REUNIÓN DE APROBACIÓN DEL PROYECTO......................................................161

4.3.1.2. PLANTILLAS DE INICIO DE PROYECTOS.....................................................163 4.3.1.2.1. (INI-LVFIP-01) LISTA VERIFICACIÓN – FASE INICIO DEL PROYECTO ..164

4.3.1.3. PLANTILLAS DE PLANIFICACIÓN DE PROYECTOS .....................................166 4.3.1.3.1. (PLA-PGP-01) PLAN DE GESTIÓN DEL PROYECTO .............................167 4.3.1.3.2. (PLA-LVRAPGP-02) LISTA DE VERIFICACIÓN - REUNIÓN DE ACEPTACIÓN DEL PLAN DE GESTIÓN DEL PROYECTO......................................182 4.3.1.3.3. (PLA-PGT-03) PLAN DE GESTIÓN DEL TIEMPO ...................................185 4.3.1.3.4. (PLA-PDA-04) PLANTILLA - DEFINICIÓN DE ACTIVIDADES ................211 4.3.1.3.5. (PLA-PRP-05) PLANTILLA - RECURSOS DEL PROYECTO...................213 4.3.1.3.6. (PLA-PCRP-06) PLANTILLA - CALENDARIO DE RECURSOS ...............215 4.3.1.3.7. (PLA-PWBSI-07) PLANTILLA – WBS INCREMENTAL ............................217 4.3.1.3.8. (PLA-PWBSE-08) PLANTILLA – WBS EVOLUTIVO................................219 4.3.1.3.9. (PLA-PWBSC-09) PLANTILLA – WBS CASCADA ..................................221

4.3.1.4. PLANTILLAS DE SEGUIMIENTO Y CONTROL DE PROYECTOS....................223 4.3.1.4.1. (SEG-LVSCP-01) LISTA DE VERIFICACIÓN – SEGUIMIENTO Y CONTROL DEL PROYECTO...................................................................................................224 4.3.1.4.2. SEG-PIAEP-02 PLANTILLA - INFORME ACTIVIDAD DEL EQUIPO DE PROYECTO ..........................................................................................................227 4.3.1.4.3. (SEG-PISPP-03) PLANTILLA – INFORME SEMANAL DEL PROGRESO DEL PROYECTO ..........................................................................................................229 4.3.1.4.4. (SEG-PIMAP-04) PLANTILLA - INFORME MENSUAL DEL AVANCE DEL PROYECTO ..........................................................................................................233 4.3.1.4.5. (SEG-PRAFEP-05) PLANTILLA - REUNIÓN DE ACEPTACIÓN DE FASES / ETAPAS DEL PROYECTO ....................................................................................237 4.3.1.4.6. (SEG-LVRAFEP-06) LISTA DE VERIFICACIÓN – REUNIÓN DE ACEPTACIÓN DE FASES/ETAPAS DEL PROYECTO.............................................240 4.3.1.4.7. (SEG-PIEPP-07) PLANTILLA - INFORME DE EMERGENCIAS/PROBLEMAS DEL PROYECTO...................................................................................................243 4.3.1.4.8. (SEG-PSCP-08) PLANTILLA - SOLICITUD CAMBIOS DEL PROYECTO..247 4.3.1.4.9. (SEG-PARPP-09) PLANTILLA – ACTA DE RECEPCIÓN DE PRODUCTOS DEL PROYECTO...................................................................................................252

4.3.1.5. PLANTILLAS DE CIERRE DE PROYECTOS ..................................................254

ix

4.3.1.5.1. (FIN-LVRRCP-01) LISTA DE VERIFICACIÓN – REUNIÓN REVISIÓN Y CIERRE DEL PROYECTO .....................................................................................255 4.3.1.5.2. (FIN-PIRCP-02) PLANTILLA - INFORME REVISIÓN Y CIERRE DEL PROYECTO ..........................................................................................................258 4.3.1.5.3. (FIN-PIOMP-03) PLANTILLA - INFORME DE OPORTUNIDADES DE MEJORAS AL PROCESO......................................................................................266 4.3.1.5.4. (FIN-PAC-04) PLANTILLA - ACCIONES CORRECTIVAS .......................273 4.3.1.5.5. (FIN-LVCP-05) LISTA DE VERIFICACIÓN – CIERRE DEL PROYECTO ...277 4.3.1.5.6. (FIN-PEU-06) PLANTILLA - EVALUACIÓN AL USUARIO .......................279 4.3.1.5.7. (FIN-PETP-07) PLANTILLA - EVALUACIÓN TÉCNICA PRODUCTO.......281

4.3.2. HERRAMIENTAS Y TÉCNICAS DE LA GESTIÓN DE PROYECTOS ....................283 4.3.2.1. GUÍA DE HERRAMIENTAS Y TÉCNICAS.......................................................283 4.3.2.2. GUÍA DE TÉCNICAS DE ESTIMACIÓN. .........................................................324 4.3.2.3. GUÍA DE REUNIONES. .................................................................................345

4.3.2.3.1. (APGR-PCR-04) PLANTILLA CONVOCATORIA DE REUNIÓN................354 4.3.2.3.2. (APGR-PCA-05) PLANTILLA CONTROL DE AUDIENCIA .......................356 4.3.2.3.3. (APGR-PAR-06) PLANTILLA ACTA DE REUNIÓN .................................358 4.3.2.3.4. (APGR-PSA-07) PLANTILLA SEGUIMIENTO DE ACUERDOS ................361 4.3.2.3.5. (APGR-PMR-08) PLANTILLA MINUTA DE REUNIÓN .............................363 4.3.2.3.6. (APGR-PIEA-09) PLANTILLA INFORME ESTADO DE ACCIONES ..........366

4.3.2.4. FLUJOGRAMA DE APLICACIÓN DE LA METODOLOGÍA. .............................368 4.3.2.5. DIRECTORIO DE APLICACIÓN DE LAS PLANTILLAS. ..................................376

5. CONCLUSIONES......................................................................................................381 5.1. ESPECÌFICAS SOBRE EL ESTÁNDAR MODELO DE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN DE LA DEFENSORÍA DE LOS HABITANTES (VERSIÓN 1.0). ...........................................................................................381 5.2. ESPECÍFICAS SOBRE EL PROCESO DE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN...................................................................................381

5.2.1. INICIO ..........................................................................................................382 5.2.2. PLANIFICACIÓN...........................................................................................382 5.2.3. EJECUCIÓN, SEGUIMIENTO Y CONTROL ....................................................383 5.2.4. CIERRE ........................................................................................................384

6. RECOMENDACIONES.............................................................................................387 6.1. ESPECÍFICAS SOBRE EL ESTÁNDAR MODELO DE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN DE LA DEFENSORÍA DE LOS HABITANTES (VERSIÓN 1.0). ...........................................................................................387 6.2. ESPECÍFICAS SOBRE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN. ................................................................................................................388

6.2.1. PERSONAS ..................................................................................................389 6.2.1.1. MOTIVACIÓN DÉBIL. ................................................................................389 6.2.1.2. PERSONAL MEDIOCRE............................................................................390 6.2.1.3. EMPLEADOS PROBLEMÁTICOS INCONTROLADOS. ...............................390 6.2.1.4. HAZAÑAS. ...............................................................................................390

x

6.2.1.5. AÑADIR MÁS PERSONAL A UN PROYECTO RETRASADO.......................391 6.2.1.6. OFICINAS REPLETAS Y RUIDOSAS. ........................................................391 6.2.1.7. FRICCIONES ENTRE LOS CLIENTES Y DESARROLLADORES. ................391 6.2.1.8. EXPECTATIVAS POCO REALISTAS. ........................................................392 6.2.1.9. FALTA DE UN PROMOTOR EFECTIVO DEL PROYECTO. .........................392 6.2.1.10. FALTA DE PARTICIPACIÓN DE LOS IMPLICADOS. ..............................393 6.2.1.11. FALTA DE PARTICIPACIÓN DEL USUARIO. .........................................393 6.2.1.12. POLÍTICA ANTES QUE DESARROLLO. ................................................393 6.2.1.13. ILUSIONES. ..........................................................................................394

6.2.2. PROCESO. ...................................................................................................395 6.2.2.1. PLANIFICACIÓN EXCESIVAMENTE OPTIMISTA. ......................................395 6.2.2.2. GESTIÓN DE RIESGOS INSUFICIENTE.....................................................395 6.2.2.3. FALLOS DE LOS CONTRATADOS. ...........................................................396 6.2.2.4. PLANIFICACIÓN INSUFICIENTE. ..............................................................396 6.2.2.5. ABANDONO DE LA PLANIFICACIÓN BAJO PRESIÓN. .............................396 6.2.2.6. PÉRDIDA DE TIEMPO EN EL INICIO DIFUSO. ...........................................396 6.2.2.7. ESCATIMAR EN LAS ACTIVIDADES INICIALES. .......................................397 6.2.2.8. DISEÑO INADECUADO.............................................................................397 6.2.2.9. ESCATIMAR EN EL CONTROL DE LA CALIDAD. ......................................397 6.2.2.10. CONTROL INSUFICIENTE DE LA DIRECTIVA. ......................................398 6.2.2.11. CONVERGENCIA PREMATURA O EXCESIVAMENTE FRECUENTE. .....398 6.2.2.12. OMITIR TAREAS NECESARIAS EN LA ESTIMACIÓN. ...........................398 6.2.2.13. PLANIFICAR PONERSE AL DÍA MÁS ADELANTE. ................................399 6.2.2.14. PROGRAMACIÓN A DESTAJO. ............................................................399

6.2.3. PRODUCTO..................................................................................................399 6.2.3.1. EXCESO DE REQUERIMIENTOS...............................................................399 6.2.3.2. CAMBIO DE LAS PRESTACIONES. ..........................................................400 6.2.3.3. DESARROLLADORES METICULOSOS. ....................................................400 6.2.3.4. TIRAS Y AFLOJAS EN LA NEGOCIACIÓN. ...............................................400 6.2.3.5. DESARROLLO ORIENTADO A LA INVESTIGACIÓN..................................401

6.2.4. TECNOLOGÍA...............................................................................................401 6.2.4.1. SÍNDROME DE LA PANACEA. ..................................................................401 6.2.4.2. SOBREESTIMACIÓN DE LAS VENTAJAS DEL EMPLEO DE NUEVAS HERRAMIENTAS O MÉTODOS. ................................................................................402 6.2.4.3. CAMBIAR DE HERRAMIENTAS A MITAD DE PROYECTO. ........................402 6.2.4.4. FALTA DE CONTROL AUTOMÁTICO DEL CÓDIGO FUENTE. ...................402

7. BIBLIOGRAFÍA .........................................................................................................404 8. ANEXOS ....................................................................................................................407

8.1. ANEXO A: CHARTER DEL PROYECTO FINAL DE GRADUACIÓN .........................407 8.2. ANEXO B: DECLARACIÓN DEL ALCANCE PROYECTO FINAL DE GRADUACIÓN 411 8.3. ANEXO C: EDT – WBS..........................................................................................415 8.4. ANEXO D: DESARROLLO DEL CRONOGRAMA DEL PROYECTO FINAL DE GRADUACIÓN ..................................................................................................................417

xi

ÍNDICE DE ILUSTRACIONES Figura N° 1: Organigrama de la Defensoría de los Habitantes de la República. .............................. 29 Figura N° 2: Fases del Ciclo de Vida de Administración de Proyectos Informáticos. ....................... 74 Figura N° 3: Organización Proyectizada........................................................................................... 89 Figura N° 4: Organización Funcional................................................................................................ 90 Figura N° 5: Jerarquía de Estructura de Trabajo (WBS) de Proyecto ............................................ 113 Figura N° 6: Formulario fases del ciclo de producción de proyectos .............................................. 176 Figura N° 7: Estructura de Desglose de Recursos (RBS) .............................................................. 207 Figura N° 8: RBS de recursos propios............................................................................................ 208 Figura N° 9: Gráfica GANTT del proyecto propuesto. .................................................................... 294 Figura N° 10: Diagrama PERT de las actividades A, B y C............................................................ 296 Figura N° 11: Diagrama PERT de las actividades A, B, C, D y E. .................................................. 297 Figura N° 12: Diagrama PERT de las actividades A, B, C, D, E y F............................................... 298 Figura N° 13: Diagrama PERT de las actividades A, B, C, D, E, G, H y F. .................................... 298 Figura N° 14: Diagrama PERT de las actividades A, B, C, D, E, F, G, H, I e J............................... 299 Figura N° 15: Diagrama PERT del proyecto con tiempos estimados. ............................................ 301 Figura N° 16: Gráfica del Tiempo de inicio más temprano: ............................................................ 304 Figura N° 17: Gráfica del Tiempo de inicio más temprano aplicada al Proyecto Alfa. .................... 304 Figura N° 18: Diagrama de red con los tiempos LS y LF............................................................... 306 Figura N° 19: Ruta crítica Proyecto Alfa ......................................................................................... 309 Figura N° 20: Diagrama de red del Proyecto Alfa........................................................................... 312 Figura N° 21: Diagrama de Red del Proyecto Alfa reformulado ..................................................... 314 Figura N° 22: Distribución Normal de los tiempos esperados......................................................... 316

xii

ÍNDICE DE CUADROS Cuadro N° 1: EDT de las Actividades propuestas. ......................................................................... 293 Cuadro N° 2: Lista de actividades del proyecto con duraciones estimadas. .................................. 300 Cuadro N° 3: Lista de actividades para cálculo de ruta crítica del Proyecto Alfa............................ 308 Cuadro N° 4: Lista de actividades del Proyecto Alfa ...................................................................... 312 Cuadro N° 5: Lista de actividades del Proyecto Alfa reformulado .................................................. 313 Cuadro N° 6: Lista de actividades del Proyecto Alfa con distribución normal de las duraciones.... 317 Cuadro N° 7: Método de Puntos de Función. ................................................................................. 334 Cuadro N° 8: Ponderación del método de puntos de función......................................................... 335 Cuadro N° 9: Tabla de distribución de esfuerzo normal ................................................................. 338 Cuadro N° 10: Método de estimación basado en transacciones. ................................................... 340

ÍNDICE DE ABREVIACIONES

CPM: Critical Path Method (Método de la ruta crítica).

DHR: Defensoría de los Habitantes de la República.

EDT: (Estructura de Desglose de Trabajo)

EF: Early Finísh (Tiempo más temprano de finalización).

ES: Early Start (Tiempo más temprano de inicio).

LS: Last Start (Tiempo más tarde de inicio).

LF: Last Finísh (Tiempo más tarde de finalización).

PERT: Program Evaluation Review Technique (Técnicas de revisión y evaluación de programas).

PMI: Project Management Institute.

PMBOK: Project Management Body of Knowledge.

PMO: Project Management Office (Oficina de Administración de Proyectos).

QA: Quality Assurance (Aseguramiento de la Calidad).

RBS: Resource Breakdown Structure (Estructura de Desglose de Recursos).

TI: Tecnologías de Información.

WBS: Work Breakdown Structure (Estructura de Desglose de Trabajo).

xiii

RESUMEN EJECUTIVO El Estándar Modelo de Administración de Proyectos de Tecnologías de Información (versión 1.0) se elaboró para la Gestión de Desarrollo de Sistemas de Información de la Defensoría de los Habitantes de la República. La Defensoría de los Habitantes de la República es una institución del Estado Costarricense, que fue creada con el propósito de defender, promocionar y divulgar los derechos e intereses de los habitantes de la República. Para ello debe velar porque el buen funcionamiento del sector público se ajuste a la moral, la justicia, la Constitución Política, las leyes, los convenios, los tratados, los pactos suscritos por el Gobierno y los principios generales del Derecho. El proyecto nace a raíz de que en la actualidad la Defensoría de los Habitantes carece de políticas, procedimientos y herramientas que le ayuden a construir un marco que permita la gobernabilidad, el control y la auditoria de las Tecnologías de Información, la experiencia de los años reflejan una debilidad institucional en el manejo de una cantidad importante de proyectos sin éxito, llevados a cabo con prácticas al azar que han atentado contra los presupuestos, los plazos y sobre todo la calidad de los mismos. El desarrollo de un estándar modelo responde a la necesidad que tiene la institución de tener “buenas practicas” que ayuden a optimizar las inversiones en información. Es un primer paso institucional para implantar la cultura de proyectos, y la base para desarrollar una metodología de gestión de proyectos de sistemas de información completa, eficiente y eficaz. El desarrollo del Estándar Modelo de Administración de Proyectos de Tecnologías de Información (versión 1.0) le permitirá a la Defensoría de los Habitantes contar con un marco general inicial para la administración de los Proyectos de Desarrollo de Sistemas de Información, bajo los lineamientos estandarizados del Project Management Institute (PMI, 2004). El objetivo general del proyecto de investigación es desarrollar un Estándar Modelo de Administración de Proyectos de Tecnologías de Información (versión 1.0). Los objetivos específicos del proyecto son: definir las políticas, desarrollar procedimientos, diseñar y construir las plantillas necesarias para la gestión de proyectos de Tecnologías de Información en la Defensoría de los Habitantes.

Para el logro de los objetivos de este proyecto se utilizó el método de investigación exploratoria y documental, se hizo de uso de diferentes herramientas y técnicas como juicio de expertos y software de apoyo a la gestión de proyectos. El estándar modelo de administración de Proyectos de Tecnologías de Información de la Defensoría de los Habitantes (Versión 1.0) desarrollado está compuesto de tres partes según los objetivos de la tesis.

xiv

En la primera parte se definen las políticas que soportaran la estructura organizacional en administración de proyectos, hacen énfasis en la organización de Tecnologías de Información en la Defensoría de los Habitantes, en los principales participantes de la gestión de proyectos, las funciones del Administrador y del Líder de Proyectos, en los principales esquemas y criterios para la organización de proyectos y en los lineamientos para determinar la generación de nuevos proyectos. En la segunda parte de la tesis se desarrolla un procedimiento general para administrar los proyectos de Tecnologías de Información en la Defensoría de los Habitantes. El procedimiento hace énfasis en las actividades o fases generales del ciclo de vida de administración de proyectos, como lo son: inicio, planificación, seguimiento y control, cierre. La tercera y última parte está contiene el diseño y construcción de las herramientas (plantillas de trabajo) necesarias para gestionar proyectos de Tecnologías de Información en la Defensoría de los Habitantes. Consta de una serie de plantillas y guías desarrolladas para cada una de las distintas fases del ciclo de vida de administración de proyectos (Plantillas para la fase de Inicio, Plantillas para la fase de Planificación, Plantillas para Seguimiento y Control de Proyectos, y Plantillas para el cierre de Proyectos). El estándar modelo de administración de Proyectos de Tecnologías de Información de la Defensoría de los Habitantes (Versión 1.0) contiene el desarrollo de una serie de guías y herramientas de utilidad para el personal de gestión de proyectos, como son: una guía de reuniones, guía de herramientas y técnicas, guía de técnicas de estimación, un directorio de aplicación de las plantillas y un flujograma de aplicación de la metodología. Se concluye que el estándar modelo de administración de Proyectos de Tecnologías de Información de la Defensoría de los Habitantes (Versión 1.0) se convierte en el marco de referencia inicial de gestión de proyectos de la institución; las políticas y los procedimientos desarrollados impulsan el cambio de cultura, mantienen dirección y proporcionan un ambiente de control en condiciones de resistencia. Las plantillas y herramientas de trabajo creadas son el insumo de trabajo primordial con que cuentan los administradores, líderes y equipos de trabajo para desempeñar sus funciones en los proyectos futuros. El estándar desarrollado provee a la organización de una estructura que permite gestionar integralmente el inicio, planificación, ejecución, seguimiento, control y cierre de los proyectos. Se recomienda en un corto plazo complementar esta versión del estándar incorporando los planes de gestión que quedaron fuera del alcance de este trabajo; crear una oficina de proyectos, ayudar en el proceso del cambio hacia la cultura de proyectos e investigar sobre el uso e implementación de nuevas técnicas y herramientas que sean útiles para la gestión de proyectos. Adicionalmente se hacen una serie de recomendaciones sobre prácticas no recomendables en administración de proyectos informáticos, son acciones tomadas muy comúnmente en relación con las personas, los procesos, los productos y las tecnologías que inducen muy frecuentemente al fracaso de los proyectos.

xv

16

1. INTRODUCCIÓN

1.1. ANTECEDENTES

1.1.1. ESTRATEGIA INSTITUCIONAL Y TECNOLOGÍAS DE INFORMACIÓN El proyecto surge como parte de la estrategia institucional de dotar a la Defensoría de los Habitantes de la República con las tecnologías de información necesarias que le permitan brindar un servicio eficiente, eficaz y con la mejor calidad a la ciudadanía Costarricense. La dirección de la organización tiene como prioridad ejecutar los proyectos relacionados con la adquisición de las tecnologías y desarrollo de sistemas de información que integren los procesos de los diferentes departamentos funcionales y ejecutivos, herramientas que servirán de soporte y colaboración para el logro de la misión y visión de la institución. En la búsqueda de optimizar y asegurar el retorno de la inversión en nuevas tecnologías la organización busca implementar procedimientos que ayuden a controlar y a dirigir el rumbo institucional, comprende que los sistemas de información, las personas y los procesos son la bases, y reconoce que para ser una organización exitosa debe comprender y manejar los riesgos asociados con la implementación de nuevas tecnologías. En Administración de Proyectos, el desarrollo de un estándar para Tecnologías de Información se convierte en el primer paso que da la organización en el tema. Carece de personal calificado en Administración de Proyectos, y no se cuenta con ningún tipo de insumo que se pueda tomar como base de conocimiento. Los proyectos desarrollados han sido gestionados de forma empírica con resultados desfavorables para los intereses de la institución. No existe cultura de proyectos en la organización, por lo que se estima que habrá una gran resistencia al cambio.

17

El Departamento de Informática se convierte en el promotor y patrocinador del desarrollo e implementación de herramientas de administración profesional de proyectos que garanticen el éxito de los proyectos de Tecnologías de Información.

1.1.2. PROBLEMÁTICA Los resultados poco convenientes que han tenido los proyectos ejecutados en la Defensoría de los Habitantes motivan a la institución a realizar un cambio en la forma en como debe emprender, gestionar y ejecutar los del futuro. Pero no se tiene, ni se conoce nada sobre administración profesional de proyectos. La institución debe garantizar que los recursos invertidos en la adquisición de nuevas tecnologías serán ejecutados correctamente, pero carece de un marco que le permita administrar, controlar y auditar el nuevo esquema institucional que supone dependerá en gran parte de estos nuevos servicios de información. En la actualidad la Defensoría de los Habitantes carece de políticas, procedimientos y herramientas que le ayuden a construir un marco que permita la gobernabilidad, el control y la auditoria de las Tecnologías de Información, la experiencia de los años reflejan una debilidad institucional en el manejo de una cantidad importante de proyectos sin éxito, llevados a cabo con prácticas al azar que han atentado contra los presupuestos, los plazos y sobre todo la calidad de los mismos. El desarrollo de un estándar modelo responde a la necesidad que tiene la institución de tener “buenas practicas” que ayuden a optimizar las inversiones en información. Es un primer paso institucional para implantar la cultura de proyectos, y la base para desarrollar una metodología de gestión de proyectos de sistemas de información completa, eficiente y eficaz.

18

La institución carece de un modelo de referencia para administrar y ejecutar los proyectos de Tecnologías de Información, tal metodología es requerida dado que se supone que la organización debe establecer un marco de administración general de administración de proyectos que defina el ámbito de aplicación y los límites, así como la metodología de administración de proyectos que ha de adoptarse y aplicarse a cada uno de los proyectos emprendidos. El estándar que se desarrollará es un medio estructurado para ejecutar las tareas de desarrollo de los sistemas computadorizados desde el punto de vista, tanto de desarrollo interno como de contrataciones externas “Outsourcing” que satisfacen las necesidades de información de la Defensoría de los Habitantes de la República, con el fin de ayudar en el logro de los objetivos de la organización. El modelo propuesto esta basado en el estándar metodológico del Project Management Institute (PMBOOK, 2004).

1.2. JUSTIFICACIÓN DEL PROYECTO

El desarrollo de un Estándar Modelo de Administración de Proyectos le permitirá a la Defensoría de los Habitantes contar con un marco general para la administración de Proyectos de Tecnologías de Información que responde a las necesidades que tiene la organización de solventar la criticidad de los siguientes puntos:

• El aumento de la dependencia de la información y de los sistemas que lo proveen;

• La escala y los costos de las inversiones actuales y futuras en información y en sistemas de información; y

• El potencial que poseen las tecnologías para cambiar drásticamente las organizaciones y las prácticas de negocio, crear nuevas oportunidades y reducir costos.

19

1.3. OBJETIVOS DEL PROYECTO

1.3.1. OBJETIVO GENERAL Desarrollar un Estándar Modelo de Administración de Proyectos de Tecnologías de Información para la Defensoría de Habitantes de la República (versión 1.0).

1.3.2. OBJETIVOS ESPECÍFICOS

• Definir las políticas generales para la gestión de proyectos de Tecnologías de Información de la Defensoría de los Habitantes.

• Desarrollar un procedimiento general para la gestión de los proyectos de Tecnologías de Información de la Defensoría de los Habitantes.

• Diseñar y construir las herramientas (plantillas de trabajo) necesarias para gestionar proyectos de Tecnologías de Información de la Defensoría de los Habitantes.

20

2. MARCO TEÓRICO

2.1. MARCO INSTITUCIONAL

2.1.1. LA DEFENSORÍA DE LOS HABITANTES DE LA REPÚBLICA La Defensoría de los Habitantes de la República nace a la vida institucional costarricense con el propósito de defender, promocionar y divulgar los derechos e intereses de los habitantes de la República; para ello debe velar porque el buen funcionamiento del sector público se ajuste a la moral, la justicia, la Constitución Política, las leyes, los convenios, los tratados, los pactos suscritos por el Gobierno y los principios generales del Derecho (DHR, 2006). La institución se encuentra ubicada en la ciudad de San José, sita en Barrio Mexico, 500 metros al norte de la Torre Mercedes. Su horario de atención al público es de 8:00 a.m. a 4:00 p.m. de Lunes a Viernes. La Defensoría de los Habitantes tiene Oficinas Regionales en las ciudades de Liberia, Pérez Zeledón, San Carlos y Limón.

2.1.2. MISIÓN Promover y divulgar los derechos e intereses de las personas y defenderlos frente a las acciones y omisiones del Sector Público (DHR, 2006).

2.1.3. VISIÓN Seremos una institución fortalecida, dinámica y con credibilidad, regionalizada y accesible en el ámbito nacional, que defenderá los derechos e intereses de las personas, contribuyendo al mejoramiento del Sector Público (DHR, 2006).

21

2.1.4. ANTECEDENTES DE LA FIGURA La figura del “Ombudsman” (Defensor del Pueblo) nace y se desarrolla en Suecia. Desde un inicio la misión de este funcionario consistió en ejercer una estricta vigilancia para asegurar el cumplimiento de las leyes y las normas existentes, además de velar porque los servidores públicos cumplieran con sus obligaciones. Para cumplir con dichas atribuciones, este funcionario podía recurrir y plantear cualquier tipo de acción ante los Tribunales de Justicia (DHR, 2006). En un inicio, este Procurador era designado directamente por el rey. Sin embargo, como producto de una serie de revueltas que se produjeron en Suecia en 1809, se dictó una nueva Constitución que incluyó en su artículo 96 la designación del Ombudsman por parte del Parlamento. Según texto constitucional, el Parlamento debía designar a un jurisconsulto de “probada ciencia y de singular integridad” encargado de controlar la observancia de las leyes y velar porque los funcionarios las cumplan en el ejercicio de sus funciones (DHR, 2006). Casi inmediatamente, la figura del Ombudsman fue incorporada al régimen jurídico-político finlandés y más adelante, ya entrado el siglo XX, se difundió por el resto de los países nórdicos. Luego pasó a formar parte del sistema institucional de Nueva Zelanda y de ahí la figura del Ombudsman fue difundida por los países anglosajones; posteriormente se extendió a Francia y España. A partir de ese momento, su difusión alcanzó gran cantidad de países, incluyendo más recientemente a los del Continente Americano. No obstante que estas instituciones conservan la esencia originaria, la figura ha sido en cada caso adaptada a las exigencias propias del sistema social, político y jurídico de las sociedades que la adoptaron. Ello ha sido posible gracias a la flexibilidad que presenta y a los rasgos que la caracterizan. (DHR, 2006).

2.1.5. ANTECEDENTES DE LA INSTITUCIÓN EN COSTA RICA La incorporación de la figura al sistema institucional costarricense fue parte de una tendencia que se desarrolló desde muchos años atrás. En un inicio, la Procuraduría de Derechos Humanos, creada

22

como órgano de la Procuraduría General de la República en septiembre de 1982, cumplió funciones de defensa de derechos humanos. En la misma ley en que se creó la Procuraduría, se estableció la figura del Procurador del Consumidor. Posteriormente, se crearon el Defensor de Derechos

Humanos para el Sistema Penitenciario, el Defensor de los Usuarios del Registro Nacional y el Defensor de los Derechos de los Refugiados. Este último órgano fue suprimido tiempo después (DHR, 2006). Más adelante, en el seno del Ministerio de Justicia, se crearon instancias específicas para velar por la tutela de los derechos de la mujer y de la infancia. Este proceso tomó fuerza con la aprobación de la Ley de Promoción de la Igualdad Social de la Mujer (Ley Nº 7124) que vino a crear lo que se denominó la Defensoría General de los Derechos Humanos. Esta Defensoría se creó como un órgano adscrito al Ministerio de Justicia y tuvo como función la protección de los derechos humanos, por lo que se dividió en seis órganos específicos: Defensoría General (que atendía asuntos relacionados con minorías y grupos vulnerables), Defensoría de la Mujer, Defensoría de la Infancia,

Defensoría del Consumidor, Defensoría de los Internos y las Internas del Sistema Penitenciario y

Defensoría del Usuario del Registro Nacional (DHR, 2006). La organización, atribuciones y competencias de estas Defensorías fueron determinadas por reglamento ejecutivo. Aún cuando estas oficinas lograron alcanzar ciertos resultados de importancia, su vinculación jerárquica y presupuestaria con el Poder Ejecutivo, específicamente con el Ministerio de Justicia, significó una limitación para su trabajo (DHR, 2006). De ahí la importancia de que, conforme lo señala la doctrina, el órgano de control de la Administración Pública se ubique en una posición de independencia que le permita ejercer su función con la mayor libertad posible (DHR, 2006). De forma paralela a este proceso, se trabajó en la elaboración de un Proyecto de “Ley del Defensor de los Habitantes de la República”, el cual fue presentado a la Asamblea Legislativa el 7 de noviembre de 1985 por el Presidente de la República y el Ministro de Justicia de ese entonces. La

23

redacción de dicho proyecto se basó en la Ley del Defensor del Pueblo Español (Ley Orgánica del 6 de abril de 1981) (DHR, 2006). En el mes de noviembre de 1992 la Ley Nº 7319 del Defensor de los Habitantes de la República fue aprobada por la Asamblea Legislativa y publicada en la Gaceta #287 del 10 de diciembre de 1992, con vigencia a partir del 10 de marzo de 1993. Reformada mediante la Ley Nº 7423 del 18 de julio de 1994, se sustituyó la palabra “Defensor” por “Defensoría”, tanto en el título como en algunos de los artículos (DHR, 2006). La Asamblea Legislativa nombra al Defensor de los Habitantes de la República por un período de cuatro años, mediante mayoría absoluta de los diputados presentes. El Defensor podrá ser reelegido únicamente por un nuevo período (DHR, 2006). La Defensoría de los Habitantes abrió sus puertas el 1º de octubre de 1993, luego de que su primer Defensor, Rodrigo Alberto Carazo Zeledón, asumiera su cargo a partir del 22 de marzo de 1993. La primera Defensora Adjunta, Joyce Zürcher Blen de Carrillo, fue elegida el 28 de abril de 1993. Desde entonces, la Defensoría ha velado por el buen funcionamiento de los servicios del sector público, procurando que sus actos se ajusten a la moral, la justicia y a todo el ordenamiento jurídico. Además, le corresponde divulgar y promover los derechos de los habitantes de todo el territorio nacional (DHR, 2006). Como segunda Defensora, fue nombrada la señora Sandra Piszk (1997-2001) y como Defensor Adjunto el señor Rolando Vega Robert (1997-1999) y Max Esquivel Faerron (1999-2001). Como tercer Defensor de los Habitantes, fue nombrado el Lic. Jose Manuel Echandi Meza (2001-2005) y como Defensor Adjunto el señor Max Esquivel Faerron (2001-2005). La actual Defensora de los Habitantes es la señora Lisbeth Quesada Tristán, nombrada por la Asamblea Legislativa para el periodo 2005-2009.

24

2.1.6. COMPETENCIA Y RESPONSABILIDADES De conformidad con lo dispuesto en la Ley, la Defensoría de los Habitantes de la República es un órgano adscrito al Poder Legislativo, con plena independencia funcional, administrativa y de criterio. Esto significa que, junto con la Contraloría General de la República, es auxiliar de la Asamblea Legislativa en la labor de control que ejerce este poder público (DHR, 2006). En esta triada que compone al Poder Legislativo, la Asamblea es la que ejerce el control político directa y explícitamente, mientras que la Contraloría lo ejerce a través de la vigilancia superior de la hacienda pública y la Defensoría de los Habitantes lo hace mediante el control de la legalidad, la moralidad y la justicia de las acciones u omisiones de la actividad administrativa del sector público, en tanto puedan afectar derechos e intereses de los habitantes (DHR, 2006). La Defensoría actúa de oficio o a solicitud de parte. En estos casos, no existe costo alguno para el quejoso ni se le exige ninguna formalidad especial. Si en el ejercicio de sus funciones, la Defensoría llega a tener conocimiento de la ilegalidad o arbitrariedad de una acción, debe recomendar y prevenir al órgano respectivo, la rectificación correspondiente, bajo los apercibimientos de ley, pero si se considera que el hecho puede constituir delito, debe denunciarlo ante el Ministerio Público (DHR, 2006). El ámbito de acción de la Defensoría es el sector público; carece de competencia para intervenir en asuntos entre sujetos privados. Tampoco puede intervenir en asuntos que estén en conocimiento de los tribunales de justicia (incluye Sala Constitucional y Tribunales Contencioso-Administrativos) (DHR, 2006). En principio, no puede actuar en casos que tengan más de un año de haber ocurrido; no obstante, la ley da un margen de discrecionalidad para atender asuntos fuera de ese plazo. La Defensoría no puede sustituir los actos, actuaciones materiales ni las omisiones de la actividad administrativa. No puede ordenar que se ejecute o se deje de ejecutar un acto ni mucho menos puede realizarlo. El

25

principio de separación de poderes que inspira nuestro ordenamiento asigna a cada uno de los poderes su ámbito de acción. Corresponde al Poder Ejecutivo primordialmente dictar los actos y al Poder Judicial, eventualmente, ordenar la suspensión de los mismos o por el contrario, ordenar su ejecución (DHR, 2006). Atendiendo el principio de obligación de consulta y obviamente el derecho de respuesta, el artículo 361 inciso 2 de la Ley General de la Administración Pública establece la obligación de consultar a las entidades representativas de intereses generales o corporativos que se vean afectadas por alguna disposición, salvo cuando se opongan a ello razones de interés público o de urgencia. La Defensoría ha manifestado al Poder Ejecutivo que el espíritu de esa norma, que data de 1978, implica la intervención del Ombudsman en tal proceso de consulta (DHR, 2006). La Defensoría, en coordinación con la Asamblea Legislativa y a través de una oficina de enlace, ha dispuesto un mecanismo que permite darle seguimiento a los proyectos de ley y debates parlamentarios, con el objetivo de incidir en el proceso legislativo, contribuyendo a mejorar de alguna manera la emisión de leyes, lo que brinda la posibilidad de actuar preventivamente en la defensa de los derechos e intereses de los habitantes (DHR, 2006). La institución también considera que la divulgación y promoción de los derechos humanos es una acción necesaria en el cumplimiento de sus objetivos y la participación comunitaria se convierte en un factor fundamental en la protección de esos intereses. En este sentido, la Defensoría de los Habitantes ha desarrollado una serie de proyectos con la asistencia de la cooperación internacional, con la finalidad de rescatar y fortalecer el principio de que los habitantes no sólo deben ser los receptores pasivos de los servicios de la institución sino los actores protagonistas de un proceso de lucha cívica por los derechos, bajo la premisa de que el mejor defensor de los habitantes es el habitante mismo (DHR, 2006).

26

2.1.7. COMPOSICIÓN E INDEPENDENCIA La Asamblea Legislativa nombra al Defensor de los Habitantes de la República por un período de cuatro años, mediante mayoría absoluta de los diputados presentes. El Defensor podrá ser reelegido únicamente por un nuevo período (DHR, 2006). Como órgano independiente, la Defensoría de los Habitantes dicta sus propios reglamentos internos de funcionamiento y no requiere de directrices o instrucciones para la administración de sus propias oficinas. Así mismo, el Defensor de los Habitantes goza de independencia de criterio para la resolución de los asuntos que son sometidos a su conocimiento, de tal manera que no está sujeto a directrices ni orden superior alguna. Lo anterior no significa que el Defensor no tenga que rendir cuenta de sus actuaciones. Debe rendir anualmente un informe escrito en la primera semana de junio a la Asamblea Legislativa, la cual debe evaluarlo para establecer cuál ha sido el funcionamiento de la institución en su conjunto y cuál el de las instituciones cuya labor la Defensoría de los Habitantes debe vigilar. Desde el punto de vista presupuestario, la Defensoría de los Habitantes tiene un título aparte en el Presupuesto Nacional, dedicado exclusivamente a la institución e independiente del de la Asamblea Legislativa. De conformidad con lo que establece el artículo 11 de la Ley Nº 7319, el Defensor de los Habitantes tiene la potestad de nombrar y remover libremente al personal de la institución. (DHR, 2006). La idea promovida por el Defensor de los Habitantes desde un inicio fue la de conformar una institución pequeña, sin excesos en el número de funcionarios, muy eficiente y con una amplia capacidad de respuesta, con el objetivo de conformar una institución de carácter multidisciplinario en la que se contara con la colaboración de profesionales de los más variados campos del saber. Por ese motivo, se creyó necesario buscar una combinación entre experiencia, dinamismo, entusiasmo,

27

formación profesional y capacidad de gestión, para tener una visión institucional mucho más amplia que la de organismos que se limitan a enfocar su accionar desde un punto de vista exclusivamente jurídico. A ello se agrega la decisión de contar con un equipo de trabajo conformado en igualdad de condiciones por hombres y mujeres (DHR, 2006).

2.1.8. FUNCIONAMIENTO Los habitantes cuentan con la posibilidad de presentar sus quejas, reclamos, o consultas en forma personal, por escrito (correo, telegrama o facsímil), por teléfono o cualquier otro medio idóneo. La queja es recibida por personal calificado y después de valorar su contenido y determinar que reúne los requisitos establecidos se distribuye a alguna de las áreas de la Defensoría (DHR, 2006). Una vez asignada al área respectiva, ésta inicia el proceso de investigación, ya sea mediante un contacto informal con la autoridad involucrada o a quien atañe el asunto con la finalidad de orientar y buscar una solución satisfactoria a los intereses del habitante, o bien iniciando la tramitación formal del asunto mediante el traslado de la denuncia y solicitud de informe al funcionario denunciado y al jefe o jerarca de la entidad denunciada. De este traslado se le envía copia al denunciante para su información. El funcionario o el jerarca de la institución, según corresponda, cuenta con un plazo de cinco días hábiles a partir de recibida la notificación respectiva para referirse al asunto, presentar los alegatos que estime pertinentes y las pruebas de descargo, así como cualquier otra información que se relacione con el asunto. Este informe se caracteriza por ser obligatorio, debe rendirse a la mayor brevedad, de manera informal y concreta. La ley le otorga al Defensor de los Habitantes una serie de potestades para el mejor desempeño de su función. Así, podrá realizar inspecciones en cualquier oficina pública sin previo aviso, podrá requerir cualquier tipo de documentos o información y se encuentra legitimado para interponer cualquier tipo de acciones o recursos administrativos o judiciales. Igualmente, la ley establece

28

expresamente que todos los funcionarios y órganos públicos deberán colaborar en forma preferente con las gestiones que realice esta institución. La falta de colaboración puede dar lugar a sanciones penales y disciplinarias para el funcionario renuente (DHR, 2006). Los funcionarios públicos citados por la Defensoría, deben comparecer personalmente el día y la hora señalados; de no hacerlo, podrán ser obligados a comparecer por medio de la Fuerza Pública, salvo en los casos de legítimo impedimento. Se exceptúan los funcionarios que gozan de inmunidad. La Defensoría emite recomendaciones basadas en la investigación del hecho denunciado y la constatación de la existencia de una acción u omisión lesiva para los intereses y derechos de los administrados. Las resoluciones pueden ser de dos tipos:

• Informe Final: Corresponde a los casos en los cuales una vez realizada la investigación se ha podido constatar que no existe acto, actuación u omisión de la Administración Pública, que atente o amenace los derechos e intereses de los habitantes. En esta resolución se informa al interesado del resultado de la investigación, se explica la actuación del funcionario o de la entidad involucrada y, en algunas situaciones, se le confirma el cumplimiento de los deberes de la Administración Pública. De esta resolución se remite copia al funcionario o al jerarca al cual se solicitó el informe respectivo, con el fin de dejar constancia de que no se ha encontrado ningún tipo de violación.

• Recomendación: Cuando la investigación realizada evidencia la existencia de actos, actuaciones u omisiones por parte de un funcionario o de una dependencia o entidad pública que sean violatorios de los derechos e intereses de los habitantes, de manera fundamentada, el Defensor de los Habitantes o la Defensora Adjunta, por delegación de éste, emite las recomendaciones que se estimen pertinentes, con el fin de que se proceda a tomar las previsiones necesarias para corregir la falta y se restituya o reconozca al interesado los derechos o intereses lesionados.

29

Las recomendaciones pueden ser de carácter general o específico. Son generales cuando se trata de corregir procedimientos o criterios que son violatorios de derechos y que afectan a un número indeterminado de personas. En este supuesto, cuando el acto violatorio emane de una disposición legal o reglamentaria podrá sugerirse su modificación o la adopción de la normativa pertinente. La Defensoría de los Habitantes se encuentra facultada para acudir a los medios de comunicación colectiva para hacer de conocimiento de la opinión pública la actuación irregular del funcionario o la entidad. Esta facultad se ejerce en forma discrecional, atendiendo criterios de oportunidad y conveniencia, el interés de la colectividad y el derecho a la información, en la cual siempre media, por supuesto, el derecho fundamental de todo funcionario público de ser respetado en su persona y en su honor (DHR, 2006).

2.1.9. ESTRUCTURA ORGÁNICA Para el cumplimiento de sus atribuciones, la Defensoría de los Habitantes se organiza de la

siguiente forma:

Figura N° 1: Organigrama de la Defensoría de los Habitantes de la República.

30

2.1.10. FUNCIONAMIENTO Y MANEJO DEL PRESUPUESTO

El presupuesto de la Defensoría es asignado a través del Ministerio de Hacienda y aprobado finalmente por la Asamblea Legislativa. La Institución se encuentra cubierta bajo el ámbito de acción de la Contraloría General de la República, órgano de rango constitucional adscrito a la Asamblea Legislativa, que tiene la responsabilidad de fiscalizar el manejo y uso de los recursos financieros del Estado costarricense. De tal forma que la Defensoría de los Habitantes está sujeta a las normas y directrices que emite el órgano contralor para la utilización del presupuesto asignado (DHR, 2006).

2.2. ADMINISTRACIÓN DE PROYECTOS

2.2.1. ¿QUÉ ES UN PROYECTO?

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único (PMI, 2004).

2.2.1.1. CARACTERÍSTICAS DEL PROYECTO

2.2.1.1.1. TEMPORAL

Temporal significa que cada proyecto tiene un comienzo definido y un final definido. El final se alcanza cuando se han logrado los objetivos del proyecto o cuando queda claro que los objetivos del proyecto no serán o no podrán ser alcanzados, o cuando la necesidad del proyecto ya no exista y el proyecto sea cancelado. Temporal no necesariamente significa de corta duración; muchos proyectos duran varios años. En cada caso, sin embargo, la duración de un proyecto es limitada. Los proyectos no son esfuerzos continuos (PMI, 2004).

31

2.2.1.1.2. PRODUCTOS, SERVICIOS O RESULTADOS ÚNICOS

Un proyecto crea productos entregables únicos. Productos entregables son productos, servicios o resultados. Los proyectos pueden crear:

• Un producto o artículo producido, que es cuantificable, y que puede ser un elemento terminado o un componente

• La capacidad de prestar un servicio como, por ejemplo, las funciones del negocio que respaldan la producción o la distribución

• Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de investigación se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiará a la sociedad (PMI, 2004).

2.2.1.1.3. ELABORACIÓN GRADUAL

La elaboración gradual es una característica de los proyectos que acompaña a los conceptos de temporal y único. “Elaboración gradual” significa desarrollar en pasos e ir aumentando mediante incrementos. Por ejemplo, el alcance de un proyecto se define de forma general al comienzo del proyecto, y se hace más explícito y detallado a medida que el equipo del proyecto desarrolla un mejor y más completo entendimiento de los objetivos y de los productos entregables (PMI, 2004).

2.2.2. PROYECTOS FRENTE A TRABAJOS OPERATIVOS Las organizaciones realizan trabajos con el fin de lograr un conjunto de objetivos. Por lo general, los trabajos se clasifican en proyectos y operaciones, aunque en algunos casos estos se superponen. Pueden compartir varias de las siguientes características:

• Realizados por personas.

32

• Restringidos por la limitación de los recursos.

• Planificados, ejecutados y controlados. Los proyectos y las operaciones difieren primordialmente en que las operaciones son continuas y repetitivas, mientras que los proyectos son temporales y únicos. Los objetivos de los proyectos y las operaciones son fundamentalmente diferentes. La finalidad de un proyecto es alcanzar su objetivo y luego concluir. Por el contrario, el objetivo de una operación continua es dar respaldo al negocio. Los proyectos son diferentes porque el proyecto concluye cuando se alcanzan sus objetivos específicos, mientras que las operaciones adoptan un nuevo conjunto de objetivos y el trabajo continúa. Los proyectos se llevan a cabo en todos los niveles de la organización y pueden involucrar a una sola persona o a varios miles. Pueden durar entre unas pocas semanas y varios años. Los proyectos pueden incluir una o varias unidades organizativas, como, por ejemplo, las asociaciones transitorias y los convenios para un proyecto determinado (PMI, 2004).

2.2.3. PROYECTOS Y PLANIFICACIÓN ESTRATÉGICA Los proyectos son una forma de organizar actividades que no pueden ser tratadas dentro de los límites operativos normales de la organización. Por lo tanto, los proyectos se usan a menudo como un medio de lograr el plan estratégico de la organización, ya esté empleado el equipo del proyecto por la organización o sea un proveedor de servicios contratado. Generalmente, los proyectos son autorizados como resultado de una o más de las siguientes consideraciones estratégicas:

• Una demanda del mercado (por ejemplo, una compañía petrolera autoriza un proyecto para construir una nueva refinería en respuesta a una escasez crónica de gasolina)

33

• Una necesidad de la organización (por ejemplo, una compañía de formación autoriza un proyecto para crear un nuevo curso a fin de aumentar sus ingresos).

• Una solicitud de un cliente (por ejemplo, una compañía eléctrica autoriza un proyecto para construir una nueva subestación para abastecer a un nuevo polígono industrial).

• Un avance tecnológico (por ejemplo, una firma de software autoriza un nuevo proyecto para desarrollar una nueva generación de videojuegos después de la introducción de nuevos equipos de juegos por parte de las empresas de electrónica).

• Un requisito legal (por ejemplo, un fabricante de pinturas autoriza un proyecto para establecer los procedimientos de manejo de un nuevo material tóxico) (PMI, 2004).

2.2.4. ¿QUÉ ES LA DIRECCIÓN DE PROYECTOS?

La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. La dirección de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. El director del proyecto es la persona responsable de alcanzar los objetivos del proyecto. La dirección de un proyecto incluye:

• Identificar los requisitos.

• Establecer unos objetivos claros y posibles de realizar

• Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costes.

• Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados.

Los directores del proyecto a menudo hablan de una “triple restricción” —alcance, tiempos y costes del proyecto— a la hora de gestionar los requisitos concurrentes de un proyecto. La calidad del proyecto se ve afectada por el equilibrio de estos tres factores. Los proyectos de alta calidad

34

entregan el producto, servicio o resultado requerido con el alcance solicitado, puntualmente y dentro del presupuesto. La relación entre estos tres factores es tal que si cambia cualquiera de ellos, se ve afectado por lo menos otro de los factores. Los directores de proyectos también gestionan los proyectos en respuesta a la incertidumbre. El riesgo de un proyecto es un evento o condición inciertos que, si ocurre, tiene un efecto positivo o negativo al menos en uno de los objetivos de dicho proyecto. Es importante destacar que muchos de los procesos incluidos en la dirección de proyectos son repetitivos debido a la existencia o a la necesidad de elaborar gradualmente el proyecto durante el ciclo de vida del proyecto. Esto significa que, a medida que un equipo de dirección del proyecto conoce más en profundidad un proyecto, el equipo puede luego dirigirlo con un mayor nivel de detalle (PMI, 2004).

2.2.5. CONTEXTO DE LA DIRECCIÓN DE PROYECTOS La dirección de proyectos existe en un contexto más amplio que incluye la dirección de programas, la gestión del portafolio y la oficina de gestión de proyectos. Con frecuencia, hay una jerarquía de plan estratégico, portafolio, programa, proyecto y subproyecto, dentro de la cual un programa que consta de varios proyectos asociados contribuye a lograr un plan estratégico (PMI, 2004).

2.2.5.1. PROGRAMAS Y DIRECCIÓN DE PROGRAMAS Un programa es un grupo de proyectos relacionados cuya dirección se realiza de manera coordinada para obtener beneficios y control que no se obtendrían si fueran dirigidos de forma individual. Los programas pueden incluir elementos de trabajo relacionados que están fuera del alcance de los proyectos discretos del programa. Por ejemplo:

• Un programa para un nuevo modelo de automóvil puede dividirse en proyectos para el diseño y actualizaciones de cada componente principal (por ejemplo, transmisión, motor,

35

interior, exterior) mientras que la fabricación continua tiene lugar en la cadena de montaje.

• Muchas empresas de electrónica tienen directores de programas que son responsables tanto del lanzamiento de productos individuales (proyectos) como de la coordinación de múltiples lanzamientos durante un período determinado (una operación continua) (PMI, 2004).

2.2.5.2. PORTAFOLIOS Y GESTIÓN DEL PORTAFOLIO

Un portafolio es un conjunto de proyectos o programas y otros trabajos, que se agrupan para facilitar la gestión efectiva de ese trabajo, a fin de cumplir con los objetivos estratégicos de negocio. Los proyectos o programas del portafolio no necesariamente tienen que ser interdependientes o estar directamente relacionados. La recaudación y el respaldo pueden asignarse sobre la base de categorías de riesgo / recompensa, líneas de negocio específicas o tipos generales de proyectos, como la mejora de la infraestructura y del proceso interno. Las organizaciones gestionan sus portafolios sobre la base de metas específicas. Una de las metas de la gestión del portafolio es maximizar el valor del portafolio evaluando con cuidado los proyectos y programas candidatos a ser incluidos en el portafolio, y la exclusión oportuna de proyectos que no cumplan con los objetivos estratégicos del portafolio. Otras metas son equilibrar el portafolio entre inversiones incrementales y radicales, y usar los recursos de forma eficiente. Los altos gerentes o altos equipos de dirección, por lo general, asumen la responsabilidad de la gestión del portafolio para una organización (PMI, 2004).

2.2.5.3. SUBPROYECTOS Con frecuencia, los proyectos se dividen en componentes o subproyectos más fáciles de gestionar, aunque los subproyectos individuales pueden ser considerados proyectos y dirigidos como tales. A

36

menudo, los subproyectos se contratan a una empresa externa o a otra unidad funcional dentro de la organización ejecutante. Algunos ejemplos son:

• Subproyectos basados en el proceso del proyecto, como una fase individual del ciclo de vida del proyecto.

• Subproyectos de acuerdo con los requisitos de habilidades de recursos humanos, como los fontaneros o electricistas necesarios en un proyecto de construcción.

• •Subproyectos que involucren tecnología especializada, como la comprobación automatizada de programas de ordenador en un proyecto de desarrollo de software.

En proyectos muy grandes, los subproyectos pueden componerse de una serie de subproyectos aún más pequeños (PMI, 2004).

2.2.5.4. OFICINA DE GESTIÓN DE PROYECTOS Una oficina de gestión de proyectos (PMO) es una unidad de la organización para centralizar y coordinar la dirección de proyectos a su cargo. Una PMO también puede denominarse “oficina de gestión de programas”, “oficina del proyecto” u “oficina del programa”. Una PMO supervisa la dirección de proyectos, programas o una combinación de ambos. Es posible que la única relación entre los proyectos respaldados o administrados por la PMO sea que son dirigidos al mismo tiempo. Sin embargo, algunas PMO coordinan y dirigen proyectos relacionados. En muchas organizaciones, esos proyectos están agrupados o relacionados de alguna forma, de acuerdo con la manera en que la PMO vaya a coordinar y dirigir esos proyectos. La PMO pone el énfasis en la planificación coordinada, la priorización y la ejecución de proyectos y subproyectos vinculados con los objetivos de negocio generales de la organización matriz o del cliente. Las PMO pueden operar con continuidad en aspectos que van desde proporcionar las funciones de respaldo para la dirección de proyectos bajo la forma de formación, software, políticas

37

estandarizadas y procedimientos, hasta la dirección y responsabilidad directas en sí mismas para lograr los objetivos del proyecto. Se puede delegar a una PMO específica la autoridad para actuar como interesada integral y estar encargada de tomar decisiones clave durante la etapa de iniciación de cada proyecto; también puede estar autorizada para hacer recomendaciones o concluir proyectos a fin de ser congruente con sus objetivos de negocio. Además, la PMO puede participar en la selección, dirección y reubicación, si fuera necesario, del personal compartido de los proyectos y, si es posible, del personal dedicado de los proyectos (PMI, 2004).

2.2.6. CICLO DE VIDA DEL PROYECTO Para facilitar la gestión, los directores de proyectos o la organización pueden dividir los proyectos en fases, con los enlaces correspondientes a las operaciones de la organización ejecutante. El conjunto de estas fases se conoce como ciclo de vida del proyecto. Muchas organizaciones identifican un conjunto de ciclos de vida específico para usarlo en todos sus proyectos (PMI, 2004).

2.2.6.1. CARACTERÍSTICAS DEL CICLO DE VIDA DEL PROYECTO El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto con su fin. Por ejemplo, cuando una organización identifica una oportunidad a la cual le interesaría responder, frecuentemente autoriza un estudio de viabilidad para decidir si se emprenderá el proyecto. La definición del ciclo de vida del proyecto puede ayudar al director del proyecto a determinar si deberá tratar el estudio de viabilidad como la primera fase del proyecto o como un proyecto separado e independiente. Cuando el resultado de dicho esfuerzo preliminar no sea claramente identificable, lo mejor es tratar dichos esfuerzos como un proyecto por separado. Las fases del ciclo de vida de un proyecto no son lo mismo que los Grupos de Procesos de Dirección de Proyectos. La transición de una fase a otra dentro del ciclo de vida de un proyecto generalmente implica y, por lo general, está definida por alguna forma de transferencia técnica. Generalmente, los productos

38

entregables de una fase se revisan para verificar si están completos, si son exactos y se aprueban antes de iniciar el trabajo de la siguiente fase. No obstante, no es inusual que una fase comience antes de la aprobación de los productos entregables de la fase previa, cuando los riesgos involucrados se consideran aceptables. Esta práctica de superponer fases, que normalmente se realiza de forma secuencial, es un ejemplo de la aplicación de la técnica de compresión del cronograma denominada ejecución rápida. No existe una única manera, que sea la mejor, para definir el ciclo de vida ideal de un proyecto. Algunas organizaciones han establecido políticas que estandarizan todos los proyectos con un ciclo de vida único, mientras que otras permiten al equipo de dirección del proyecto elegir el ciclo de vida más apropiado para el proyecto del equipo. Asimismo, las prácticas comunes de la industria a menudo conducen a usar un ciclo de vida preferido dentro de dicha industria. Los ciclos de vida del proyecto generalmente definen:

• Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué fase se debe realizar el trabajo del arquitecto?)

• Cuándo se deben generar los productos entregables en cada fase y cómo se revisa, verifica y valida cada producto entregable.

• Quién está involucrado en cada fase (por ejemplo, la ingeniería concurrente requiere que los implementadores estén involucrados en las fases de requisitos y de diseño)

• Cómo controlar y aprobar cada fase. Las descripciones del ciclo de vida del proyecto pueden ser generales o detalladas. Las descripciones muy detalladas de los ciclos de vida pueden incluir formularios, diagramas y listas de control para proporcionar estructura y control. La mayoría de los ciclos de vida de proyectos comparten determinadas características comunes:

39

• En términos generales, las fases son secuenciales y, normalmente, están definidas por alguna forma de transferencia de información técnica o transferencia de componentes técnicos.

• El nivel de coste y de personal es bajo al comienzo, alcanza su nivel máximo en las fases intermedias y cae rápidamente cuando el proyecto se aproxima a su conclusión.

• El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no cumplir con los objetivos es más elevado al inicio del proyecto. La certeza de terminar con éxito aumenta gradualmente a medida que avanza el proyecto.

• El poder que tienen los interesados en el proyecto para influir en las características finales del producto del proyecto y en el coste final del proyecto es más alto al comienzo y decrece gradualmente a medida que avanza el proyecto. Una de las principales causas de este fenómeno es que el coste de los cambios y de la corrección de errores generalmente aumenta a medida que avanza el proyecto.

Aun cuando muchos ciclos de vida de proyectos tienen nombres de fases similares y requieren productos entregables similares, muy pocos ciclos de vida son idénticos. Algunos tienen cuatro o cinco fases, pero otros pueden tener nueve o más. En una misma área de aplicación pueden darse variaciones significativas. El ciclo de vida del desarrollo de software de una organización puede tener una única fase de diseño, mientras que otro puede tener fases separadas para el diseño arquitectónico y el detallado. Los subproyectos también pueden tener distintos ciclos de vida de proyectos. Por ejemplo, una empresa de arquitectura contratada para diseñar un nuevo edificio de oficinas participa primero en la fase de definición del propietario, mientras hace el diseño, y luego en la fase de implementación del propietario, mientras da soporte al esfuerzo de construcción. El proyecto de diseño del arquitecto, sin embargo, tendrá su propia serie de fases, desde el desarrollo conceptual, pasando por la definición e implementación, hasta llegar a la conclusión. El arquitecto puede, inclusive, tratar el diseño de los edificios y el soporte a la construcción como proyectos separados, cada uno con su propio conjunto de fases (PMI, 2004).

40

2.2.6.2. CARACTERÍSTICAS DE LAS FASES DEL PROYECTO

La conclusión y la aprobación de uno o más productos entregables caracterizan a una fase del proyecto. Un producto entregable es un producto de trabajo que se puede medir y verificar, tal como una especificación, un informe del estudio de viabilidad, un documento de diseño detallado o un prototipo de trabajo. Algunos productos entregables pueden corresponder al mismo proceso de dirección de proyectos, mientras que otros son los productos finales o componentes de los productos finales para los cuales se creó el proyecto. Los productos entregables, y en consecuencia las fases, son parte de un proceso generalmente secuencial, diseñado para asegurar el adecuado control del proyecto y para obtener el producto o servicio deseado, que es el objetivo del proyecto. En cualquier proyecto específico, las fases se pueden subdividir en subfases en función del tamaño, complejidad, nivel de riesgo y restricciones del flujo de caja. Cada subfase se alinea con uno o más productos entregables específicos para el seguimiento y control. La mayoría de estos productos entregables de las subfases están relacionados con el producto entregable de la fase principal, y las fases normalmente toman el nombre de estos productos entregables de las subfases: requisitos, diseño, construcción, prueba, puesta en marcha, rotación, entre otros, según corresponda. Por lo general, una fase del proyecto concluye con una revisión del trabajo logrado y los productos entregables, a fin de determinar la aceptación, tanto si aún se requiere trabajo adicional como si se debe considerar cerrada la fase. (PMI, 2004). Con frecuencia, la dirección lleva a cabo una revisión para tomar una decisión a fin de comenzar las actividades de la siguiente fase sin cerrar la fase actual, por ejemplo, cuando el director del proyecto elige la ejecución rápida como curso de acción. Otro ejemplo es cuando una compañía de tecnología de la información elige un ciclo de vida iterativo donde más de una fase del proyecto puede avanzar de forma simultánea. Los requisitos de un módulo se pueden recopilar y analizar antes de que el módulo sea diseñado y construido. Mientras se lleva a cabo el análisis de un módulo, se puede comenzar a recopilar los requisitos de otro módulo de forma paralela (PMI, 2004).

41

Del mismo modo, se puede cerrar una fase sin la decisión de iniciar alguna otra fase. Por ejemplo, el proyecto está completo o se considera que el riesgo es demasiado alto para permitir la continuidad del proyecto. La conclusión formal de la fase no incluye la autorización de la fase posterior. Para un control efectivo, cada fase se inicia formalmente para producir una salida, dependiente de la fase, del Grupo de Procesos de Iniciación, que especifique lo que está permitido y lo que se espera para dicha fase. Se puede realizar una revisión al final de cada fase con el objetivo explicito de obtener la autorización para cerrar la fase actual e iniciar la fase posterior. En ocasiones, se pueden obtener ambas autorizaciones en una sola revisión. Las revisiones al final de cada fase son también conocidas como: salidas de fase, entradas a la fase o puntos de cancelación. (PMI, 2004).

2.2.6.3. RELACIONES DEL CICLO DE VIDA DEL PROYECTO Y DEL CICLO DE VIDA DEL PRODUCTO

Muchos proyectos están vinculados con el trabajo continuo de la organización ejecutante. Algunas organizaciones aprueban formalmente los proyectos sólo tras haber concluido un estudio de viabilidad, un plan preliminar o alguna otra forma equivalente de análisis. En estos casos, la planificación o el análisis preliminar adquiere la forma de un proyecto separado. Por ejemplo, se pueden presentar fases adicionales como resultado de desarrollar y probar un prototipo antes de iniciar un proyecto para el desarrollo del producto final (PMI, 2004). Algunos tipos de proyectos, especialmente los proyectos de desarrollo de servicios internos o productos nuevos, se pueden iniciar de manera informal durante un período limitado que permita obtener la aprobación formal de fases o actividades adicionales. Las fuerzas impulsoras que crean los estímulos para un proyecto se conocen habitualmente como problemas, oportunidades o requisitos de negocio. El efecto de estas presiones es que, en general, la dirección debe priorizar esta solicitud con respecto a las necesidades y a las demandas de recursos de otros posibles proyectos.

42

La definición del ciclo de vida del proyecto también identificará qué tareas de transición al final del proyecto están incluidas y cuáles no, a fin de vincular el proyecto con las operaciones de la organización ejecutante. Por ejemplo, cuando se envía un nuevo producto a fabricación o comercializa un nuevo programa de software. Debe tenerse cuidado en distinguir entre el ciclo de vida del proyecto y el ciclo de vida del producto. Por ejemplo, un proyecto emprendido para colocar en el mercado un nuevo ordenador de escritorio es sólo un aspecto del ciclo de vida del producto. El ciclo de vida del proyecto atraviesa una serie de fases para crear el producto. Proyectos adicionales pueden incluir una actualización del rendimiento del producto. En algunas áreas de aplicación, tales como el desarrollo de nuevos productos o el desarrollo de software, las organizaciones consideran el ciclo de vida del proyecto como parte del ciclo de vida del producto (PMI, 2004).

2.2.6.4. INTERESADOS EN EL PROYECTO Los interesados en el proyecto son personas y organizaciones que participan de forma activa en el proyecto o cuyos intereses pueden verse afectados como resultado de la ejecución del proyecto o de su conclusión. También pueden influir sobre los objetivos y resultados del proyecto. El equipo de dirección del proyecto debe identificar a los interesados, determinar sus requisitos y expectativas y, en la medida de lo posible, gestionar su influencia en relación con los requisitos para asegurar un proyecto exitoso. Los interesados tienen niveles de responsabilidad y autoridad variables al participar en un proyecto, que pueden cambiar a lo largo del curso del ciclo de vida del proyecto. Su responsabilidad y autoridad varía desde la colaboración ocasional en encuestas y grupos de consumidores hasta el patrocinio total del proyecto, que incluye proporcionar respaldo financiero y político. Los interesados que ignoren esta responsabilidad pueden tener un impacto perjudicial sobre los objetivos del

43

proyecto. Del mismo modo, los directores del proyecto que ignoren a los interesados también pueden esperar un impacto perjudicial sobre los resultados del proyecto. A veces, la identificación de los interesados puede resultar difícil. Por ejemplo, algunos consideran que un operario de una cadena de montaje, cuyo empleo futuro depende del resultado de un proyecto de diseño de un nuevo producto, es un interesado. No identificar un interesado clave puede causar problemas significativos a un proyecto. Por ejemplo, el reconocimiento tardío de que el departamento legal era un interesado importante en un proyecto de actualización de software de transición al año 2000 (Y2K) hizo que se agregaran muchas tareas de documentación adicionales a los requisitos del proyecto. Los interesados pueden influir de manera positiva o negativa en el proyecto. Los interesados de influencia positiva son aquellos que normalmente se beneficiarían de un resultado exitoso del proyecto, mientras que los interesados de influencia negativa son aquellos que ven resultados negativos como consecuencia del éxito del proyecto. Por ejemplo, los líderes empresariales de una comunidad que se beneficiará de un proyecto de expansión industrial pueden ser interesados de influencia positiva, ya que pronostican un beneficio económico para la comunidad con el éxito del proyecto. Por el contrario, los grupos ecologistas podrían ser interesados de influencia negativa si consideran que el proyecto perjudica al medio ambiente. En el caso de los interesados de influencia positiva, sus intereses se satisfacen mejor contribuyendo al éxito del proyecto, por ejemplo, ayudando al proyecto a obtener los permisos necesarios para proceder. El interés de los interesados de influencia negativa se satisface mejor impidiendo que el proyecto avance, exigiendo informes de evaluación ambiental más exhaustivos. Con frecuencia, los interesados de influencia negativa son ignorados por el equipo del proyecto, poniendo en riesgo el éxito de sus proyectos. Entre los interesados clave de los proyectos se encuentran:

44

• Director del proyecto: La persona responsable de dirigir el proyecto.

• Cliente/usuario: La persona u organización que utilizará el producto del proyecto. Puede haber múltiples niveles de clientes. Por ejemplo, dentro de los clientes para un nuevo producto farmacéutico pueden encontrarse los médicos que lo recetan, los pacientes que lo toman y las entidades aseguradoras que pagan por él. En algunas áreas de aplicación, cliente y usuario son sinónimos, mientras que en otras, cliente se refiere a la entidad que adquiere el producto del proyecto, mientras que los usuarios son aquellos que utilizan directamente el producto del proyecto.

• Organización ejecutante: La empresa cuyos empleados participan más directamente en el trabajo del proyecto.

• Miembros del equipo del proyecto: El grupo que realiza el trabajo del proyecto.

• Equipo de dirección del proyecto: Los miembros del equipo del proyecto que participan directamente en las actividades de dirección del proyecto.

• Patrocinador: La persona o el grupo que proporciona los recursos financieros, monetarios o en especie, para el proyecto.

• Influyentes: Personas o grupos que no están directamente relacionados con la adquisición o el uso del producto del proyecto, pero que, debido a su posición en la organización del cliente u organización ejecutante, pueden ejercer una influencia positiva o negativa sobre el curso del proyecto.

• Oficina de Gestión de Proyectos (PMO): Si existe en la organización ejecutante, la PMO puede ser un interesado si tiene responsabilidad directa o indirecta sobre el resultado del proyecto.

Además de estos interesados clave, hay muchos nombres y categorías diferentes de interesados en los proyectos, incluidos los internos y los externos, los propietarios y los inversores, los vendedores y los contratistas, los miembros del equipo y sus familias, las agencias del gobierno y los medios de comunicación, los ciudadanos particulares, las organizaciones de influencia temporales o permanentes, y la sociedad en general. La nomenclatura y el agrupamiento de los interesados es principalmente una ayuda para identificar qué personas y organizaciones se ven a sí mismos como

45

interesados. Los roles y las responsabilidades de los interesados pueden solaparse, como cuando una empresa de ingeniería proporciona financiación para una planta que ella misma está diseñando. Los directores del proyecto deben gestionar las expectativas de los interesados, lo cual puede resultar difícil ya que, a menudo, los interesados tienen objetivos diferentes o contradictorios. Por ejemplo:

• El gerente de un departamento que ha solicitado un nuevo sistema de información de la gestión puede desear un bajo coste, el arquitecto del sistema puede hacer hincapié en la excelencia técnica, y el contratista de programación puede estar más interesado en maximizar su beneficio.

• El vicepresidente de investigación de una empresa de electrónica puede definir el éxito de un producto nuevo como tecnología punta, el vicepresidente de fabricación puede definirlo como prácticas de nivel mundial, y el vicepresidente de comercialización puede estar principalmente preocupado por la cantidad de nuevas funciones (PMI, 2004).

2.2.7. PROCESOS DE DIRECCIÓN DE PROYECTOS

La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para satisfacer los requisitos del mismo. La dirección de proyectos se logra mediante la ejecución de procesos, usando conocimientos, habilidades, herramientas y técnicas de dirección de proyectos que reciben entradas y generan salidas. Para que un proyecto tenga éxito, el equipo del proyecto debe:

• Seleccionar los procesos apropiados dentro de los Grupos de Procesos de la Dirección de Proyectos (también conocidos como Grupos de Procesos) que sean necesarios para cumplir con los objetivos del proyecto.

46

• Usar un enfoque definido para adaptar las especificaciones del producto y los planes de tal forma que se puedan cumplir los requisitos del proyecto y del producto.

• Cumplir con los requisitos para satisfacer las necesidades, deseos y expectativas de los interesados.

• Equilibrar las demandas concurrentes de alcance, tiempo, costes, calidad, recursos y riesgos para producir un producto de calidad.

Esta norma documenta la información necesaria para iniciar, planificar, ejecutar, supervisar y controlar, y cerrar un proyecto individual, e identifica los procesos de la dirección de proyectos que han sido reconocidos como buenas prácticas para la mayoría de los proyectos, la mayor parte del tiempo. Estos procesos se aplican globalmente y en todos los grupos industriales. Buenas prácticas significa que existe un acuerdo general en que se ha comprobado que la aplicación de esos procesos de dirección de proyectos aumenta las posibilidades de éxito en una amplia variedad de proyectos (PMI, 2004).

2.2.7.1. GRUPO DE PROCESOS DE DIRECCIÓN DE PROYECTOS Los detalles específicos de un proyecto se definen como objetivos que deben cumplirse sobre la base de la complejidad, el riesgo, el tamaño, el plazo, la experiencia del equipo del proyecto, el acceso a recursos, la cantidad de información histórica, la madurez de la organización en la dirección de proyectos, la industria y área de aplicación. Los Grupos de Procesos requeridos y los procesos que los componen son guías para aplicar los conocimientos y habilidades apropiados relativos a la dirección de proyectos durante el proyecto. Además, la aplicación de los procesos de dirección de proyectos a un proyecto es repetitiva, y muchos de los procesos son reiterados y revisados durante el proyecto. El director del proyecto y el equipo del proyecto son responsables de determinar qué procesos de los Grupos de Procesos serán utilizados, quién los usará, y el grado de rigor de ejecución de esos procesos para alcanzar el objetivo deseado del proyecto (PMI, 2004).

47

2.2.7.1.1. GRUPO DE PROCESOS DE INICIACIÓN

El Grupo de Procesos de Iniciación se compone de procesos que facilitan la autorización formal para comenzar un nuevo proyecto o una fase del mismo. Los procesos de iniciación, por lo general, se realizan fuera del ámbito de control del proyecto por la organización o por los procesos del programa o del portafolio, lo cual puede hacer borrosos los límites del proyecto en lo que se refiere a entradas iniciales del proyecto. Por ejemplo, antes de comenzar con las actividades del Grupo de Procesos de Iniciación, se documentan las necesidades o requisitos de negocio de la organización. La viabilidad de la nueva empresa puede establecerse a través de un proceso de evaluación de alternativas para elegir la mejor de ellas. Se establecen descripciones claras de los objetivos del proyecto, incluidas las razones por las cuales un proyecto específico es la mejor solución alternativa para satisfacer los requisitos. La documentación de esta decisión también contiene una descripción básica del alcance del proyecto, de los productos entregables, de la duración del proyecto y un pronóstico de los recursos para el análisis de inversión de la organización. El marco conceptual del proyecto puede aclararse documentando los procesos de selección del proyecto. La relación entre el proyecto y el plan estratégico de la organización identifica las responsabilidades de dirección dentro de la organización. En los proyectos de múltiples fases, los procesos de iniciación se llevan a cabo durante fases posteriores para validar las asunciones realizadas y las decisiones tomadas durante los procesos originales Desarrollar el Acta de Constitución del Proyecto y Desarrollar el Enunciado del Alcance del Proyecto (Preliminar) (PMI, 2004).

2.2.7.1.2. GRUPO DE PROCESOS DE PLANIFICACIÓN El equipo de dirección del proyecto usa el Grupo de Procesos de Planificación, y los procesos e interacciones que lo componen, para planificar y gestionar con éxito un proyecto para la organización. El Grupo de Procesos de Planificación ayuda a recoger información de varias fuentes

48

de diverso grado de completitud y confianza. Los procesos de planificación desarrollan el plan de gestión del proyecto. Estos procesos también identifican, definen y maduran el alcance del proyecto, el coste del proyecto y planifican las actividades del proyecto que se realizan dentro del proyecto. A medida que se obtenga nueva información sobre el proyecto, se identificarán o resolverán nuevas dependencias, requisitos, riesgos, oportunidades, asunciones y restricciones. Como consecuencia de la naturaleza multidimensional de la dirección de proyectos se producen bucles de retroalimentación repetidos que se utilizan para nuevos análisis. A medida que se obtiene más información o características del proyecto, y que éstas son comprendidas, pueden ser necesarias acciones de seguimiento. Los cambios significativos durante el ciclo de vida del proyecto provocan la necesidad de reiterar uno o más de los procesos de planificación y, posiblemente, alguno de los procesos de iniciación (PMI, 2004).

2.2.7.1.3. GRUPO DE PROCESOS DE EJECUCIÓN El Grupo de Procesos de Ejecución se compone de los procesos utilizados para completar el trabajo definido en el plan de gestión del proyecto a fin de cumplir con los requisitos del proyecto. El equipo del proyecto debe determinar cuáles son los procesos necesarios para el proyecto específico del equipo. Este Grupo de Procesos implica coordinar personas y recursos, así como integrar y realizar las actividades del proyecto, de acuerdo con el plan de gestión del proyecto. Este Grupo de Procesos también aborda el alcance definido en el enunciado del alcance del proyecto e implementa los cambios aprobados Las variaciones en la ejecución normal harán necesaria cierta replanificación. Estas variaciones pueden incluir las duraciones de las actividades, la productividad y disponibilidad de los recursos, y

49

los riesgos no anticipados. Tales variaciones pueden o no afectar al plan de gestión del proyecto, pero es posible que requieran un análisis. Los resultados del análisis pueden provocar una solicitud de cambio que, si fuera aprobada, modificaría el plan de gestión del proyecto, y posiblemente sería necesario establecer una nueva línea base. La mayor parte del presupuesto del proyecto se invertirá en los procesos del Grupo de Procesos de Ejecución (PMI, 2004).

2.2.7.1.4. GRUPO DE PROCESOS DE SEGUIMIENTO Y CONTROL El Grupo de Procesos de Seguimiento y Control se compone de aquellos procesos realizados para observar la ejecución del proyecto de forma que se puedan identificar los posibles problemas oportunamente y adoptar las acciones correctivas, cuando sea necesario, para controlar la ejecución del proyecto. El equipo del proyecto debe determinar cuáles de los procesos son necesarios para el proyecto específico del equipo. El beneficio clave de este Grupo de Procesos es que el rendimiento del proyecto se observa y se mide regularmente para identificar las variaciones respecto del plan de gestión del proyecto. El Grupo de Procesos de Seguimiento y Control también incluye controlar los cambios y recomendar acciones preventivas como anticipación de posibles problemas. El Grupo de Procesos de Seguimiento y Control incluye, por ejemplo:

• El seguimiento de las actividades en curso del proyecto, comparándolas con el plan de gestión del proyecto y la línea base de rendimiento del proyecto.

• Influir sobre los factores que podrían eludir el control integrado de cambios de tal forma que solamente se implementen los cambios aprobados.

Este seguimiento continuo proporciona al equipo del proyecto una idea acerca de la salud del proyecto y resalta cualquier área que necesite atención adicional. El Grupo de Procesos de

50

Seguimiento y Control no solamente supervisa y controla el trabajo que se realiza dentro de un Grupo de Procesos, sino que también supervisa todo el esfuerzo del proyecto. En los proyectos de múltiples fases, el Grupo de Procesos de Seguimiento y Control también proporciona retroalimentación entre las fases del proyecto, a fin de implementar acciones correctivas o preventivas para hacer que el proyecto cumpla con el plan de gestión del proyecto. Cuando las variaciones ponen en peligro los objetivos del proyecto, se revisan los procesos de dirección de proyectos correspondientes dentro del Grupo de Procesos de Planificación, como parte del ciclo modificado planificar-hacer-revisar-actuar. De esta revisión pueden surgir actualizaciones recomendadas para el plan de gestión del proyecto. Por ejemplo, no haber cumplido con la fecha de finalización de una actividad puede requerir ajustes al plan de asignación de personal actual, implementar horas extra o realizar concesiones entre los objetivos de presupuesto y del cronograma (PMI, 2004).

2.2.7.1.5. GRUPO DE PROCESOS DE CIERRE El Grupo de Procesos de Cierre incluye los procesos utilizados para finalizar formalmente todas las actividades de un proyecto o de una fase de un proyecto, entregar el producto terminado a terceros o cerrar un proyecto cancelado. Este Grupo de Procesos, una vez completado, verifica que los procesos definidos se completan dentro de todos los Grupos de Procesos para cerrar el proyecto o una fase del proyecto, según corresponda, y establece formalmente que se ha finalizado un proyecto o fase del proyecto (PMI, 2004).

2.2.7.2. INTERACCIONES ENTRE PROCESOS Los Grupos de Procesos de Dirección de Proyectos están relacionados por los resultados que producen. La salida de un proceso, por lo general, se convierte en una entrada a otro proceso o es un producto entregable del proyecto.

51

El Grupo de Procesos de Planificación proporciona al Grupo de Procesos de Ejecución un plan de gestión del proyecto documentado y un enunciado del alcance del proyecto, y a menudo actualiza el plan de gestión del proyecto a medida que avanza el proyecto. Además, los Grupos de Procesos pocas veces son eventos discretos o que ocurren una única vez; son actividades superpuestas que se producen con distintos niveles de intensidad a lo largo del proyecto (PMI, 2004).

2.2.8. ÁREAS DE CONOCIMIENTO DE LA DIRECCIÓN DE PROYECTOS

2.2.8.1. GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO El Área de Conocimiento de Gestión de la Integración del Proyecto incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los distintos procesos y actividades de dirección de proyectos dentro de los Grupos de Procesos de Dirección de Proyectos. En el contexto de la dirección de proyectos, la integración incluye características de unificación, consolidación, articulación y acciones de integración que son cruciales para concluir el proyecto y, al mismo tiempo, cumplir satisfactoriamente con los requisitos de los clientes y otros interesados, y gestionar las expectativas. La integración, en el contexto de la dirección de un proyecto, consiste en tomar decisiones sobre dónde concentrar recursos y esfuerzos cada día, anticipando las posibles polémicas de modo que puedan ser tratadas antes de que se conviertan en polémicas críticas y coordinando el trabajo para el bien del proyecto en general. El esfuerzo de integración también implica hacer concesiones entre objetivos y alternativas en competencia (PMI, 2004).

2.2.8.2. GESTIÓN DEL ALCANCE DEL PROYECTO La Gestión del Alcance del Proyecto incluye los procesos necesarios para asegurarse que el proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto

52

satisfactoriamente. La gestión del alcance del proyecto se relaciona principalmente con la definición y el control de lo que está y no está incluido en el proyecto. Incluye:

• Planificación del Alcance: crear un plan de gestión del alcance del proyecto que refleje cómo se definirá, verificará y controlará el alcance del proyecto, y cómo se creará y definirá la Estructura de Desglose del Trabajo (EDT).

• Definición del Alcance: desarrollar un enunciado del alcance del proyecto detallado como base para futuras decisiones del proyecto.

• Crear EDT: subdividir los principales productos entregables del proyecto y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar.

• Verificación del Alcance: formalizar la aceptación de los productos entregables completados del proyecto.

• Control del Alcance: controlar los cambios en el alcance del proyecto. Estos procesos interaccionan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede involucrar el esfuerzo de una o más personas o grupos de personas, sobre la base de las necesidades del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se produce en una o más fases del proyecto, si el proyecto se encuentra dividido en fases (PMI, 2004).

2.2.8.3. GESTIÓN DEL TIEMPO DEL PROYECTO La Gestión del Tiempo del Proyecto incluye los procesos necesarios para lograr la conclusión del proyecto a tiempo. Los procesos de Gestión del Tiempo del Proyecto incluyen lo siguiente:

• Definición de las Actividades: identifica las actividades específicas del cronograma que deben ser realizadas para producir los diferentes productos entregables del proyecto.

• Establecimiento de la Secuencia de las Actividades: identifica y documenta las dependencias entre las actividades del cronograma.

53

• Estimación de Recursos de las Actividades: estima el tipo y las cantidades de recursos necesarios para realizar cada actividad del cronograma.

• Estimación de la Duración de las Actividades: estima la cantidad de períodos laborables que serán necesarios para completar cada actividad del cronograma.

• Desarrollo del Cronograma: analiza las secuencias de las actividades, la duración de las actividades, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto.

• Control del Cronograma: controla los cambios del cronograma del proyecto. Estos procesos interaccionan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede implicar el esfuerzo de una o más personas o grupos de personas, dependiendo de las necesidades del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se produce en una o más fases del proyecto, si el proyecto se encuentra dividido en fases (PMI, 2004).

2.2.8.4. GESTIÓN DE LOS COSTES DEL PROYECTO La Gestión de los Costes del Proyecto incluye los procesos involucrados en la planificación, estimación, preparación del presupuesto y control de costes de forma que el proyecto se pueda completar dentro del presupuesto aprobado. Incluye:

• Estimación de Costes: desarrollar una aproximación de los costes de los recursos necesarios para completar las actividades del proyecto.

• Preparación del Presupuesto de Costes: sumar los costes estimados de actividades individuales o paquetes de trabajo a fin de establecer una línea base de coste.

• Control de Costes: influir sobre los factores

Estos procesos interactúan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede involucrar el esfuerzo de una o más personas o grupos de

54

personas, dependiendo de las necesidades del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se realiza en una o más fases del proyecto, si el proyecto se encuentra dividido en fases. La Gestión de los Costes del Proyecto se ocupa principalmente del coste de los recursos necesarios para completar las actividades del cronograma. Sin embargo, la Gestión de los Costes del Proyecto también debería considerar el efecto de las decisiones del proyecto sobre los costes del uso, mantenimiento y soporte del producto, servicio o resultado del proyecto. Por ejemplo, limitar el número de revisiones del diseño puede reducir el coste del proyecto a expensas de un aumento de los costes operativos del cliente. Esta visión más amplia de la Gestión de los Costes del Proyecto se denomina frecuentemente cálculo de costes del ciclo de vida. El cálculo de costes del ciclo de vida, junto con las técnicas de ingeniería del valor, puede mejorar la toma de decisiones, y se usa para reducir el coste y el tiempo de ejecución, y para mejorar la calidad y el rendimiento del producto entregable del proyecto (PMI, 2004).

2.2.8.5. GESTIÓN DE LA CALIDAD DEL PROYECTO Los procesos de Gestión de la Calidad del Proyecto incluyen todas las actividades de la organización ejecutante que determinan las políticas, los objetivos y las responsabilidades relativos a la calidad de modo que el proyecto satisfaga las necesidades por las cuales se emprendió. Implementa el sistema de gestión de calidad a través de la política, los procedimientos y los procesos de planificación de calidad, aseguramiento de calidad y control de calidad, con actividades de mejora continua de los procesos que se realizan durante todo el proyecto, según corresponda. Los procesos de Gestión de la Calidad del Proyecto incluyen lo siguiente:

• Planificación de Calidad: identificar qué normas de calidad son relevantes para el proyecto y determinando cómo satisfacerlas.

55

• Realizar Aseguramiento de Calidad: aplicar las actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto utilice todos los procesos necesarios para cumplir con los requisitos.

• Realizar Control de Calidad: supervisar los resultados específicos del proyecto, para determinar si cumplen con las normas de calidad relevantes e identificar modos de eliminar las causas de un rendimiento insatisfactorio.

Estos procesos interaccionan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede implicar el esfuerzo de una o más personas o grupos de personas, dependiendo de las necesidades del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se realiza en una o más fases del proyecto, si el proyecto se encuentra dividido en fases (PMI, 2004).

2.2.8.6. GESTIÓN DE LOS RECURSOS HUMANOS DEL PROYECTO La Gestión de los Recursos Humanos del Proyecto incluye los procesos que organizan y dirigen el equipo del proyecto. El equipo del proyecto está compuesto por las personas a quienes se les han asignado roles y responsabilidades para concluir el proyecto. Si bien es común hablar de asignación de roles y responsabilidades, los miembros del equipo deberían participar en gran parte de la planificación y toma de decisiones del proyecto. La participación temprana de los miembros del equipo aporta experiencia durante el proceso de planificación y fortalece el compromiso con el proyecto. El tipo y la cantidad de miembros del equipo del proyecto a menudo pueden cambiar, a medida que avanza el proyecto. Los miembros del equipo del proyecto pueden denominarse personal del proyecto. 9 El equipo de dirección del proyecto es un subgrupo del equipo del proyecto y es responsable de las actividades de dirección de proyectos, tales como la planificación, el control y el cierre. Este grupo puede denominarse equipo central, equipo ejecutivo o equipo de liderazgo. Para proyectos más pequeños, las responsabilidades de la dirección de proyectos pueden ser compartidas por todo el

56

equipo o administradas únicamente por el director del proyecto. El patrocinador del proyecto trabaja con el equipo de dirección del proyecto, ayudando generalmente con cuestiones tales como la financiación del proyecto, aclarando preguntas sobre el alcance y ejerciendo influencia sobre otros a fin de beneficiar al proyecto. Los procesos de Gestión de los Recursos Humanos del Proyecto incluyen lo siguiente:

• Planificación de los Recursos Humanos: identificar y documentar los roles del proyecto, las responsabilidades y las relaciones de informe, así como crear el plan de gestión de personal.

• Adquirir el Equipo del Proyecto: obtener los recursos humanos necesarios para concluir el proyecto.

• Desarrollar el Equipo del Proyecto: mejorar las competencias y la interacción de los miembros del equipo para lograr un mejor rendimiento del proyecto.

• Gestionar el Equipo del Proyecto: hacer un seguimiento del rendimiento de los miembros del equipo, proporcionar retroalimentación, resolver polémicas y coordinar cambios a fin de mejorar el rendimiento del proyecto.

Estos procesos interaccionan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede implicar el esfuerzo de una o más personas o grupos de personas, dependiendo de las necesidades del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se realiza en una o más fases del proyecto, si el proyecto se encuentra dividido en fases (PMI, 2004).

2.2.8.7. GESTIÓN DE LAS COMUNICACIONES DEL PROYECTO La Gestión de las Comunicaciones del Proyecto es el Área de Conocimiento que incluye los procesos necesarios para asegurar la generación, recogida, distribución, almacenamiento, recuperación y destino final de la información del proyecto en tiempo y forma. Los procesos de

57

Gestión de las Comunicaciones del Proyecto proporcionan los enlaces cruciales entre las personas y la información, necesarios para unas comunicaciones exitosas. Los directores de proyectos pueden invertir una cantidad excesiva de tiempo comunicándose con el equipo del proyecto, los interesados, el cliente y el patrocinador. Todas las personas involucradas en el proyecto deben comprender cómo afectan las comunicaciones al proyecto como un todo. Los procesos de Gestión de las Comunicaciones del Proyecto incluyen lo siguiente:

• Planificación de las Comunicaciones: determinar las necesidades de información y comunicaciones de los interesados en el proyecto.

• Distribución de la Información: poner la información necesaria a disposición de los interesados en el proyecto cuando corresponda.

• Informar el Rendimiento: recopilar y distribuir información sobre el rendimiento. Esto incluye informes de estado, medición del progreso y proyecciones.

• Gestionar a los Interesados: gestionar las comunicaciones a fin de satisfacer los requisitos de los interesados en el proyecto y resolver polémicas con ellos.

Estos procesos interaccionan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede implicar el esfuerzo de una o más personas o grupos de personas, dependiendo de las necesidades del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y en una o más fases del proyecto, si el proyecto se encuentra dividido en fases (PMI, 2004).

2.2.8.8. GESTIÓN DE LOS RIESGOS DEL PROYECTO

La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con la planificación de la gestión de riesgos, la identificación y el análisis de riesgos, las respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto; la mayoría de estos procesos se actualizan durante el proyecto.

58

Los objetivos de la Gestión de los Riesgos del Proyecto son aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos adversos para el proyecto. Los procesos de Gestión de los Riesgos del Proyecto incluyen lo siguiente: 1

• Planificación de la Gestión de Riesgos: decidir cómo enfocar, planificar y ejecutar las actividades de gestión de riesgos para un proyecto.

• Identificación de Riesgos: determinar qué riesgos pueden afectar al proyecto y documentar sus características.

• Análisis Cualitativo de Riesgos: priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando su probabilidad de ocurrencia y su impacto.

• Análisis Cuantitativo de Riesgos: analizar numéricamente el efecto de los riesgos identificados en los objetivos generales del proyecto.

• Planificación de la Respuesta a los Riesgos: desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto.

• Seguimiento y Control de Riesgos: realizar el seguimiento de los riesgos identificados, supervisar los riesgos residuales, identificar nuevos riesgos, ejecutar planes de respuesta a los riesgos y evaluar su efectividad a lo largo del ciclo de vida del proyecto.

Estos procesos interactúan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede implicar el esfuerzo de una o más personas o grupos de personas, dependiendo de las necesidades del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se realiza en una o más fases del proyecto, si el proyecto se encuentra dividido en fases (PMI, 2004).

59

2.2.8.9. GESTIÓN DE LAS ADQUISICIONES DEL PROYECTO La Gestión de las Adquisiciones del Proyecto incluye los procesos para comprar o adquirir los productos, servicios o resultados necesarios fuera del equipo del proyecto para realizar el trabajo. Este capítulo presenta dos perspectivas de adquisición. La organización puede ser la compradora o la vendedora del producto, servicio o resultados bajo un contrato. La Gestión de las Adquisiciones del Proyecto incluye los procesos de gestión del contrato y de control de cambios necesarios para administrar contratos u órdenes de compra emitidas por miembros autorizados del equipo del proyecto. La Gestión de las Adquisiciones del Proyecto también incluye la administración de cualquier contrato emitido por una organización externa (el comprador) que esté adquiriendo el proyecto a la organización ejecutante (el vendedor), y la administración de las obligaciones contractuales que corresponden al equipo del proyecto en virtud del contrato. Los procesos de Gestión de las Adquisiciones del Proyecto incluyen lo siguiente:

• Planificar las Compras y Adquisiciones: determinar qué comprar o adquirir, y cuándo y cómo hacerlo.

• Planificar la Contratación: documentar los requisitos de los productos, servicios y resultados, e identificar a los posibles vendedores.

• Solicitar Respuestas de Vendedores: obtener información, presupuestos, licitaciones, ofertas o propuestas, según corresponda.

• Selección de Vendedores: revisar ofertas, elegir entre posibles vendedores, y negociar un contrato por escrito con cada vendedor.

• Administración del Contrato: gestionar el contrato y la relación entre el comprador y el vendedor, revisar y documentar cuál es o fue el rendimiento de un vendedor a fin de establecer las acciones correctivas necesarias y proporcionar una base para relaciones

60

futuras con el vendedor, gestionar cambios relacionados con el contrato y, cuando corresponda, gestionar la relación contractual con el comprador externo del proyecto.

• Cierre del Contrato: completar y aprobar cada contrato, incluida la resolución de cualquier tema abierto, y cerrar cada contrato aplicable al proyecto o a una fase del proyecto.

Estos procesos interactúan entre sí y también con los procesos de las demás Áreas de Conocimiento. Cada proceso puede implicar el esfuerzo de una o más personas o grupos de personas, dependiendo de los requisitos del proyecto. Cada proceso tiene lugar por lo menos una vez en cada proyecto y se realiza en una o más fases del proyecto, si el proyecto se encuentra dividido en fases (PMI, 2004).

2.3. PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACIÓN En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones, las empresas consideran con mucho cuidado las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia (Senn, 1992) Al establecer los sistemas de información basados en computadoras deben tener la certeza de que se logren dos objetivos principales: que sea un sistema correcto y que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia u organización. (Kendall & Kendall, 1991) Si los dispositivos de un sistema de información no se adaptan a su población de clientes, no lograra sus objetivos potenciales. A mismo tiempo, aun cuando se identifiquen precisamente las necesidades del usuario, un sistema de información va tener un valor único si funciona en forma adecuada (Senn, 1992).

http://www.monografias.com/trabajos6/napro/napro.shtml

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos15/computadoras/computadoras.shtml

http://www.monografias.com/trabajos5/ancar/ancar.shtml

http://www.monografias.com/trabajos12/decis/decis.shtml

http://www.monografias.com/trabajos11/empre/empre.shtml

http://www.monografias.com/trabajos11/teosis/teosis.shtml


http://www.monografias.com/trabajos13/mercado/mercado.shtml

http://www.monografias.com/trabajos7/compro/compro.shtml

http://www.monografias.com/trabajos15/computadoras/computadoras.shtml

http://www.monografias.com/trabajos16/objetivos-educacion/objetivos-educacion.shtml



http://www.monografias.com/trabajos16/objetivos-educacion/objetivos-educacion.shtml

http://www.monografias.com/trabajos3/gerenylider/gerenylider.shtml

http://www.monografias.com/trabajos6/napro/napro.shtml


http://www.monografias.com/trabajos/explodemo/explodemo.shtml

http://www.monografias.com/trabajos11/sercli/sercli.shtml

http://www.monografias.com/trabajos6/meti/meti.shtml


http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml

61

Los informes y las salidas producidas por el sistema deben ser precisos, confiables y completos. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios (Senn, 1992). El Proceso de gestión para la creación de un sistema o software encierra un conjunto de actividades, de las cuales es la estimación uno de los más delicados de realizar, estimar es echar un vistazo al futuro aceptando cierto grado de incertidumbre (Senn, 1992). Aunque la estimación, es más un arte que una ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena ingeniería sistemas y software (Senn, 1992). Al estimar se toma en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones (Senn, 1992). A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del software. La disponibilidad de información histórica es otro elemento que determina el riesgo de la estimación (Senn, 1992).

2.3.1. CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo específico de actividades del analista y del usuario (Senn, 1992).

Según James Senn, existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método

http://www.monografias.com/trabajos14/informeauditoria/informeauditoria.shtml

http://www.monografias.com/trabajos7/mafu/mafu.shtml

http://www.monografias.com/trabajos11/metods/metods.shtml#ANALIT

http://www.monografias.com/trabajos12/elproduc/elproduc.shtml

http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE

http://www.monografias.com/trabajos15/sistemas-control/sistemas-control.shtml

http://www.monografias.com/Computacion/Software/

http://www.monografias.com/Arte_y_Cultura/index.shtml

http://www.monografias.com/trabajos10/fciencia/fciencia.shtml

http://www.monografias.com/trabajos6/juti/juti.shtml

http://www.monografias.com/trabajos6/meti/meti.shtml

http://www.monografias.com/trabajos7/plane/plane.shtml

http://www.monografias.com/trabajos12/pmbok/pmbok.shtml

http://www.monografias.com/trabajos14/historiaingenieria/historiaingenieria.shtml


http://www.monografias.com/Computacion/Software/

http://www.monografias.com/trabajos13/mapro/mapro.shtml

http://www.monografias.com/trabajos12/pmbok/pmbok.shtml

http://www.monografias.com/trabajos4/refrec/refrec.shtml

http://www.monografias.com/trabajos4/costos/costos.shtml

http://www.monografias.com/trabajos7/plane/plane.shtml


http://www.monografias.com/trabajos13/ripa/ripa.shtml

62

de construcción de prototipos de sistemas. Cada una de estas estrategias tiene un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada.

2.3.1.1. CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:

a. Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

b. Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de

sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

• ¿Qué es lo que hace?

• ¿Cómo se hace?

• ¿Con que frecuencia se presenta?

• ¿Qué tan grande es el volumen de transacciones o decisiones?

• ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

• ¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

63

c. Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

d. Desarrollo del software: Los encargados de desarrollar software pueden instalar software

comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

e. Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera

experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

f. Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

64

• Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

• Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

• Opinión de los administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

• Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo (Senn, 1992).

2.3.1.2. MÉTODO DE DESARROLLO POR ANÁLISIS ESTRUCTURADO

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de:

• La división del sistema en componentes

• La construcción de un modelo del sistema. El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento,

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos12/dispalm/dispalm.shtml

65

etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado (Senn, 1992). El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente (Senn, 1992).

2.3.1.2.1. COMPONENTES

a) Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

b) Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser

manual o automatizado.

c) Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

d) Reglas: estándares para describir y documentar el sistema en forma correcta y completa

(Senn, 1992).

2.3.1.2.2. DISEÑO ESTRUCTURADO. El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.

http://www.monografias.com/trabajos5/andi/andi.shtml

http://www.monografias.com/trabajos15/logica-metodologia/logica-metodologia.shtml

66

El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él (Senn, 1992).

2.3.1.2.3. ANÁLISIS DE FLUJO DE DATOS. Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos (Senn, 1992).

2.3.1.2.4. HERRAMIENTAS

Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.

2.3.1.2.5. DIAGRAMA DE FLUJO DE DATOS Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes. El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más

http://www.monografias.com/trabajos14/flujograma/flujograma.shtml

http://www.monografias.com/trabajos7/filo/filo.shtml

http://www.monografias.com/trabajos14/flujograma/flujograma.shtml

http://www.monografias.com/trabajos/fintrabajo/fintrabajo.shtml

http://www.monografias.com/trabajos12/diccienc/diccienc.shtml

http://www.monografias.com/trabajos4/acciones/acciones.shtml

67

detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación. El diagrama físico de datos da un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos. El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos específicos y la localización de los almacenes de datos o personas en el sistema. Sin indicarse las características físicas (Senn, 1992).

2.3.1.3. MÉTODO DEL PROTOTIPO DE SISTEMAS

La construcción de prototipos representa una estrategia de desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que incluye el desarrollo interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso (McLeod, 2000). Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos (McLeod, 2000). Así mismo este método resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación (McLeod, 2000). El método del prototipo de sistemas consta de 5 etapas:

http://www.monografias.com/trabajos12/alma/alma.shtml

68

1) Identificación de requerimientos conocidos: La determinación de los requerimientos de una aplicación es tan importante para el m‚todo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.

2) Desarrollo de un modelo de trabajo: Es fácil comenzar el proceso de construcción del

prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo. Un cronograma para el inicio y el fin de la primera interacción es de gran ayuda. En el desarrollo del prototipo se preparan los siguientes componentes:

a. El lenguaje para el dialogo o conversación entre el usuario y el sistema. b. Pantallas y formatos para la entrada de datos. c. Módulos esenciales de procesamiento. d. Salida del sistema

3) Utilización del prototipo: Es responsabilidad del usuario trabajar con el prototipo y

evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas.

4) Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar

información sobre los que les gusta y lo que les desagrada a los usuarios. Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.

5) Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite

varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que

69

el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias (Pressman, 1998).

Un proyecto de desarrollo de un Sistema de Información comprende varios componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno más de los componentes: Software, hardware, personas, base de datos, documentación y procedimientos (Pressman, 1998).

70

3. MARCO METODOLÓGICO Los métodos de investigación son procedimientos ordenados que se siguen para establecer el significado de los hechos y fenómenos hacia los que se dirige el interés para encontrar, demostrar, refutar, descubrir y aportar al conocimiento (Hernández et al., 1998).

3.1. FUENTES DE INFORMACIÓN

La fuente de información es el lugar donde se encuentran los datos requeridos, que posteriormente se pueden convertir en información útil para el investigador. Los datos son todos aquellos fundamentos o antecedentes que se requieren para llegar al conocimiento exacto de un objeto de estudio (Eyssautier, 2002). La categoría de las fuentes de información seleccionadas para llevar a cabo el Proyecto Final de Graduación son secundarias en su mayoría. Se utiliza el juicio experto de las personas para aportar, verificar y aprobar la información seleccionada, esta información se podría considerar primaria. Fuentes de información secundarias se refieren a todos aquellos portadores de datos e información que han sido previamente retransmitidos o grabados en cualquier documento, y que utilizan el medio que sea. Esta información se encuentra a disposición de todo investigador que la necesite (Eyssautier, 2002). El tipo de investigación utilizada en este proyecto de acuerdo con las fuentes de información secundarias es la investigación documental.

La investigación documental son trabajos cuyo método de investigación se centra exclusivamente en la recopilación de datos existentes en forma documental, ya sea libros, textos o cualquier otro tipo de documentos. Su único propósito es obtener antecedentes para profundizar en las teorías y

71

aportaciones, ya emitidas sobre el tema en particular que es objeto de estudio, y complementarlas, refutarlas o derivar, en su caso, conocimientos nuevos. En concreto, son aquellas investigaciones en cuya recopilación de datos se utilizan documentos que aportan antecedentes sobre el tópico en estudio.

Las fuentes de información principalmente utilizadas son el PMBOK 2004 (PMI, 2004), Ingeniería del Software: Un Enfoque Práctico (Pressman, 1998), Análisis y Diseño de Sistemas de Información (Senn, 1992), Manuales de Procedimientos de la Defensoría de los Habitantes y juicio experto del personal de informática.

3.2. MÉTODO DE INVESTIGACIÓN

El método es la ruta que se sigue en las ciencias para alcanzar un fin propuesto; y la metodología, el cuerpo de conocimiento que describe y analiza los métodos para el desarrollo de una investigación. (Eyssautier, 2002).

Los métodos de investigación son procedimientos ordenados que se siguen para establecer el significado de los hechos y fenómenos hacia los que se dirige el interés para encontrar, demostrar, refutar, descubrir y aportar al conocimiento. Existen muchas versiones de métodos, y en general implican procesos de análisis, síntesis, inducción y deducción (Eyssautier, 2002).

El método de investigación utilizado para realizar el estándar modelo de administración de proyectos de Tecnologías de Información de la Defensoría de los Habitantes es el Método analítico – sintético, en especial para desarrollar las plantillas propuestas en el tercer objetivo específico de este trabajo.

72

El método analítico – sintético descompone una unidad en sus elementos más simples, examina cada uno de ellos por separado, volviendo a agrupar las partes para considerarlas en conjunto. Para llevar a cabo una investigación analítica, el especialista tiene que cubrir sistemáticamente varias fases de manera continua:

1. Observación

2. Descripción

3. Examen crítico

4. Descomposición del fenómeno

5. Enumeración de sus partes

6. Ordenación

7. Clasificación

La síntesis es la meta y resultado final del análisis. El método sintético no es propiamente un método de investigación, sino una operación fundamental por medio de la cual se logra la comprensión de la esencia de lo que se ha conocido en todos sus componentes particulares a partir del análisis (Jurado, 2003).

3.3. TÉCNICAS DE INVESTIGACIÓN Las técnicas utilizadas para lograr los objetivos de esta investigación son:

1. Definir las políticas generales para la gestión de proyectos de Tecnologías de Información de la Defensoría de los Habitantes.

73

1.1. Se utiliza el juicio experto del personal del Departamento de Informática y se realiza una investigación documental exploratoria basada en Manual de Procedimientos y otros documentos institucionales con el objetivo de determinar y proponer lo siguiente:

1.1.1. Organización de Tecnologías de Información en la Defensoría de los Habitantes.

1.1.2. Principales participantes en la gestión de Proyectos de Tecnologías de Información

1.1.3. Funciones del Administrador de Proyectos.

1.1.4. Funciones del Líder de Proyectos.

1.1.5. Principales esquemas organizativos de proyectos

1.1.6. Criterios para la organización de proyectos

1.1.7. Conceptualización de Proyectos (¿Cómo nace un proyecto?)

1.1.7.1. Elaboración y justificación de la necesidad de un proyecto de tecnologías de información.

1.1.7.2. Aprobación o rechazo de la solicitud de propuesta de proyecto.

1.1.7.3. Desarrollo del documento Enunciado del Alcance del Proyecto Preliminar.

1.1.7.4. En base a la información documentada se diseña y construye las plantillas requeridas.

2. Desarrollar un procedimiento general para la gestión de los proyectos de Tecnologías de Información de la Defensoría de los Habitantes.

2.1. Se utiliza el juicio experto del personal del Departamento de Informática y se realiza una investigación exploratoria basada en el Área de Integración que propone el PMBOOK 2004 (PMI, 2004) y otros documentos institucionales para desarrollar un procedimiento cuyas fases sean consecuentes con el siguiente ciclo de vida de la administración de proyectos:

2.1.1. El ciclo de administración de proyectos contiene puntos de transición que deben ser identificados y administrados. El ciclo de vida de un proyecto contiene varios

74

elementos que se solapan entre una actividad o fase y otra. Esta situación requiere de un plan de proyecto integrado que asegure la continuidad y consistencia de estas fases.

Bajo la consideración anterior podemos establecer cinco fases principales en que pueden subdividirse las distintas etapas del ciclo de vida de un proyecto, las cuales son:

• Inicio

• Planificación

• Ejecución

• Seguimiento y Control

• Cierre.

En la figura 2 siguiente se muestra la relación entre estas fases y la superposición que se da entre las mismas.

INICIO

EJECUCIÓN

CIERRE

PLANIFICACIÓN

SEGUIMIENTO Y CONTROL

Figura N° 2: Fases del Ciclo de Vida de Administración de Proyectos Informáticos.

3. Diseñar y construir las herramientas (plantillas de trabajo) necesarias para gestionar proyectos de Tecnologías de Información de la Defensoría de los Habitantes.

75

3.1. Se diseñan y construyen las plantillas necesarias para dar soporte al ciclo de vida de administración de proyectos descrito anteriormente.

3.2. Las plantillas son realizados según la información aportada por las fuentes documentales descritas anteriormente, y bajo la verificación del juicio experto del personal de informática constatando que se adaptan a las necesidades institucionales de información, estás plantillas según el orden de aparición por fases son:

3.2.1. Plantillas de Conceptualización de Proyectos

• (CON-SPP-01) Solicitud de Propuesta de Proyecto • (CON-ARP-02) Análisis de Requerimientos Preliminar • (CON-EAPP-03) Enunciado del Alcance del Proyecto Preliminar • (CON-ACP-04) Acta de Constitución del Proyecto • (CON-MIP-05) Matriz de Involucrados del Proyecto • (CON-LVCRAP-06) Lista de Verificación – Comprobación de la Reunión de

Aprobación del Proyecto

3.2.2. Plantillas de Inicio de Proyectos

• (INI-LVFIP-01) Lista de Verificación – Fase Inicio del proyecto

3.2.3. Plantillas de Planificación de Proyectos

• (PLA-PGP-01) Plan de Gestión del Proyecto • (PLA-LVRAPGP-02) Lista de Verificación - Reunión de Aceptación del Plan de

Gestión del Proyecto. • (PLA-PGT-03) Plan de Gestión del Tiempo • (PLA-PDA-04) Plantilla - Definición de Actividades • (PLA-PRP-05) Plantilla - Recursos del Proyecto • (PLA-PCRP-06) Plantilla - Calendario de Recursos • (PLA-PWBSI-07) Plantilla – WBS Incremental • (PLA-PWBSE-08) Plantilla – WBS Evolutivo • (PLA-PWBSC-09) Plantilla – WBS Cascada

3.2.4. Plantillas de Seguimiento y Control de Proyectos

76

• (SEG-LVSCP-01) Lista de Verificación – Seguimiento y Control del Proyecto • SEG-PIAEP-02 Plantilla - Informe Actividad del Equipo de Proyecto • (SEG-PISPP-03) Plantilla – Informe Semanal del Progreso del Proyecto • (SEG-PIMAP-04) Plantilla - Informe Mensual del Avance del proyecto • (SEG-PRAFEP-05) Plantilla - Reunión de Aceptación de Fases/Etapas del Proyecto • (SEG-LVRAFEP-06) Lista de Verificación – Reunión de Aceptación de Fases/Etapas

del Proyecto. • (SEG-PIEPP-07) Plantilla - Informe de Emergencias/Problemas del Proyecto • (SEG-PSCP-08) Plantilla - Solicitud de Cambios del Proyecto • (SEG-PARPP-09) Plantilla – Acta de Recepción de Productos del Proyecto

3.2.5. Plantillas de Cierre de Proyectos.

• (FIN-LVRRCP-01) Lista de Verificación – Reunión Revisión y Cierre del Proyecto • (FIN-PIRCP-02) Plantilla - Informe Revisión y Cierre del Proyecto • (FIN-PIOMP-03) Plantilla - Informe de Oportunidades de Mejoras al Proceso • (FIN-PAC-04) Plantilla - Acciones Correctivas • (FIN-LVCP-05) Lista de Verificación – Cierre del Proyecto • (FIN-PEU-06) Plantilla - Evaluación al Usuario • (FIN-PETP-07) Plantilla - Evaluación Técnica Producto

3.2.6. Plantillas de Herramientas de la Gestión de Proyectos.

• (AP-GHT-01) Guía de Herramientas y Técnicas • (AP-GTE-02) Guía de Técnicas de Estimación • (AP-GR-03) Guía de Reuniones • (APGR-PCR-04) Plantilla Convocatoria de Reunión • (APGR-PCA-05) Plantilla Control de Audiencia • (APGR-PAR-06) Plantilla Acta de Reunión • (APGR-PSA-07) Plantilla Seguimiento de Acuerdos • (APGR-PMR-08) Plantilla Minuta de Reunión • (APGR-PIEA-09) Plantilla Informe Estado de Acciones • (AP-GFAM-10) Guía Flujograma de Aplicación de la Metodología • (AP-GDAP-11) Guía Directorio de Aplicación de las Plantillas

77

4. DESARROLLO A continuación se encuentra el desarrollo del estándar modelo de administración de Proyectos de Tecnologías de Información de la Defensoría de los Habitantes (Versión 1.0) Esta versión es un primer paso de muchos que tendrán que seguirse para que la Defensoría de los Habitantes de la República cuente con un instrumento completo de trabajo que colabore con la organización para administrar profesionalmente los proyectos de tecnologías de información que emprenda. Es un modelo por dos razones: porque no existe un desarrollo similar a este en la institución y porque está sujeto a cambios que ayuden a mejorarlo. El estándar está compuesto de tres partes:

• Las políticas generales para la administración de proyectos

• Un procedimiento general para gestionar proyectos informáticos

• Las herramientas de trabajo (plantillas) que sirvan como material de insumo para la gestión de proyectos.

El estándar modelo de administración de Proyectos de Tecnologías de Información de la Defensoría de los Habitantes (Versión 1.0) se describe en adelante.

4.1. POLITICAS PARA LA ADMINISTRACIÓN DE PROYECTOS. A continuación se describen los lineamientos generales propuestos para implantar una cultura de administración de proyectos en la Defensoría de los Habitantes de la República.

78

4.1.1. ORGANIZACIÓN DE TECNOLOGÍAS DE INFORMACIÓN DE LA DEFENSORÍA DE LOS HABITANTES.

La Defensoría de los Habitantes mantiene una organización funcional, dentro de la cual es posible establecer estructuras matriciales para la planificación y desarrollo de proyectos. Se considera que las estructuras matriciales de diferente intensidad, según sea la importancia y tamaño del proyecto, constituyen la mejor forma en que pueden ser enfrentados los proyectos de la Defensoría, tanto internos como por medio de contrataciones externas. A continuación se describen los principales participantes que interactuarán con la organización de proyectos descrita en esta tesis:

a) Comité Director Informático. b) Departamento de Informática. c) Áreas usuarias. d) Auditoria Interna e) Departamento de Planificación Estratégica. f) Entidades externas a la Defensoría de los Habitantes.

4.1.2. PRINCIPALES PARTICIPANTES Y SU PAPEL.

Cada una de las diferentes unidades funcionales involucradas en el desarrollo de proyectos de la Defensoría tiene un papel determinante en el logro del éxito. No obstante es importante que se tenga presente que la intensidad y dedicación de las funciones de cada participante están en una estrecha relación con la magnitud del proyecto emprendido. A continuación se puntualizan las funciones básicas para cada uno de los componentes organizacionales. Estas funciones se desarrollan y describen porque no existen en la organización.

79

4.1.2.1. COMITÉ DIRECTOR INFORMÁTICO. Este Comité es el órgano de decisión más alto en lo que respecta a la administración de los proyectos de tecnologías de información de la Defensoría.

A nivel de lo que corresponde a los proyectos de Tecnología de Información, este Comité debe reunirse de manera ordinaria como mínimo una vez al mes, sesión en la que se revisa el avance de los proyectos institucionales, las prioridades, relación con proveedores y peticiones generadas desde las direcciones de los diferentes proyectos. Las funciones más representativas de este Comité en lo referente a los proyectos de tecnologías de Información son:

a) Seguimiento de las estrategias institucionales y su traslado a proyectos de tecnologías de Información.

b) La asignación de prioridades y recursos entre los diferentes proyectos informáticos que se ejecutan paralelamente en la organización.

c) Resolución de conflictos entre proyectos o en la relación con proveedores externos. d) Traslado de las políticas gerenciales al desarrollo de los proyectos, así como el

asesoramiento informático a nivel institucional.

4.1.2.2. DEPARTAMENTO DE INFORMÁTICA. Este Departamento tiene bajo su responsabilidad el control general de la función de tecnologías de información, asegurando que los proyectos emprendidos estén acorde a los planes y lineamientos institucionales. Además, su participación es vital en la resolución de conflictos interdepartamentales, determinando la necesidad de escalabilidad de situaciones problemáticas. Su representación estará conformada por un Comité Interno Informático.

80

Dentro de las situaciones que este Comité debe atender resaltan:

a) La priorización y otorgamiento de los recursos informáticos, tanto humanos como

materiales, a los proyectos. b) La negociación de contratos y situaciones de conflicto con proveedores y

desarrolladores externos. c) La elevación de recomendaciones sobre decisiones de alto impacto organizacional a

las instancias superiores de la Defensoría, en especial al Comité Director Informático y el seguimiento de las acciones sobre las mismas.

4.1.2.3. ÁREAS USUARIAS.

Las áreas usuarias (Clientes) involucradas en los proyectos son determinantes para lograr el éxito. Estos usuarios deben aportar su trabajo a los proyectos en dos clasificaciones básicas. Como aportadores de información, bajo la cual señalan las características de los productos deseados y su verificación constante a lo largo del desarrollo.

Deben también participar como Directores de Proyecto y Patrocinadores, en donde velarán por la eliminación de obstáculos para el logro del éxito del proyecto, así como por la asignación de los recursos adecuados en el momento oportuno.

En la organización de los proyectos, debe existir un Líder de Proyecto, el cual es un usuario que fungirá como soporte en la definición funcional del proyecto y que compartirá con el Administrador de Proyectos la responsabilidad por el éxito del mismo. El Líder y Administrador del proyecto tienen un campo de acción determinado por su especialidad y deben trabajar de manera totalmente coordinada.

Las funciones básicas del área usuaria en los proyectos se pueden resumir en:

81

a) Aporte de los requerimientos funcionales para el desarrollo del producto. b) El Administrador de Proyectos debe coordinar de manera muy estrecha con el Líder de

Proyecto que se defina para el proyecto. c) Seguimiento y verificación del apego a los requerimientos funcionales. d) Tomar las acciones correctivas que sean necesarias en su área de competencia, o

escalar oportunamente la toma de decisiones. e) Crear un ambiente de apertura, criticidad y mejoramiento continuo al proceso de creación

de los sistemas. f) Promover un enfoque a la generación de soluciones enfocadas a la resolución de

necesidades específicas, que puedan evolucionar paulatinamente en nuevos alcances. g) Aportar los recursos idóneos para el desarrollo de los proyectos. h) Participar activamente en los procesos de pruebas, documentación, instalación,

depuración, carga de datos y evaluación de los productos intermedios y finales de sus proyectos.

4.1.2.4. AUDITORIA INTERNA.

La Auditoria Interna desempeña dos papeles fundamentales en el desarrollo de proyecto, el primero como un usuario más con las características mencionadas anteriormente. Por otra parte la Auditoria Interna también funge como asesor en aspectos de control, seguridad y procedimientos durante todo el proceso de desarrollo.

Bajo este último papel las tareas que desarrolla esta unidad son:

a) Revisión y recomendaciones sobre los diferentes productos parciales que se

generen en el ciclo de desarrollo. b) Participación activa en las sesiones de trabajo enfocadas al estudio de factibilidad,

la definición de requerimientos y conceptualización de las soluciones informáticas.

82

c) Participación en las sesiones de inspección y pruebas del ciclo de desarrollo, esto según los lineamientos de aseguramiento de la calidad que se establecerán en el Plan de Gestión de Calidad de los proyectos informáticos (Fuera del Alcance de esta Tesis).

d) Promover una actitud constructiva, crítica y abierta al mejoramiento dentro de los equipos de trabajo en que participe.

4.1.2.5. DEPARTAMENTO DE PLANIFICACIÓN ESTRATÉGICA.

El Departamento de Planificación Estratégica participa activamente en el proceso de desarrollo, pues es el llamado a establecer el enlace entre las soluciones propuestas y los procedimientos administrativos establecidos o por establecer del área en estudio. De manera concreta, esta unidad se encarga de:

a) Revisar, actualizar y definir los procedimientos administrativos necesarios para el máximo aprovechamiento de las soluciones informáticas.

b) Asesorar a los equipos de trabajo sobre las consideraciones administrativas asociadas a las áreas involucradas en el desarrollo de una solución.

c) Buscar los mecanismos más eficientes para promover el mejoramiento continuo y el correcto acoplamiento de sistemas y procedimientos.

d) Participar activamente en las sesiones enfocadas al estudio de factibilidad, estudio de requerimientos y conceptualización de la solución.

4.1.2.6. ENTIDADES EXTERNAS.

Entidades Externas son todas aquellas empresas fuera de la Defensoría que están involucradas en el desarrollo de los diferentes proyectos. Las funciones de estas entidades dependen de su relación con el proyecto, pudiendo estar en tareas de asesoría, ejecución de tareas, aporte de información o

83

receptor de información. En cualquiera de los casos, es necesario que las responsabilidades y funciones de estas unidades estén claramente estipuladas en los términos del proyecto y que exista aceptación y entendimiento de los mismos por los participantes.

4.1.3. FUNCIONES DEL ADMINISTRADOR DE PROYECTOS.

El administrador de Proyectos es un profesional certificado en Administración de Proyectos (MAP ó PMP) encargado de la gestión de la cartera de proyectos de la Defensoría de los Habitantes, recomendablemente a través de la Oficina de Gestión de Proyectos (PMO). Dentro de sus principales funciones están:

a. Confirmar y revisar los objetivos, alcances y responsabilidades de los proyectos, de manera

previa al inicio de los mismos. b. Velar por la aplicación de toda normativa establecida por el Departamento de Informática

relacionada con la administración de proyectos.

c. Establecer el Plan de Gestión de Proyectos de acuerdo con lo establecido en el Procedimiento General de Gestión de Proyectos Informáticos, con el nivel de calidad establecido en el Plan de Gestión de Calidad (Fuera del Alcance de esta tesis) y en el proceso de Ingeniería de Desarrollo de Software (Fuera del alcance de esta tesis) cuando aplique.

d. Recomendar y formar Líderes de proyectos.

e. Responsable en conjunto con el Líder del Proyecto de planear, organizar, coordinar, dirigir y

controlar todas las actividades relacionadas con cada proyecto asignado bajo su responsabilidad y a su equipo de trabajo, con el propósito de organizar en forma lógica y

84

sistemática las actividades y responsabilidades de los miembros del equipo de proyecto, de forma tal que se alcancen los objetivos del proyecto, en particular:

• Velar por la integración correcta del equipo de trabajo y fluidez de las comunicaciones.

• Asignar los recursos humanos y coordinar sus actividades.

• Resolver problemas y restricciones de recursos.

• Velar por el cumplimiento del plan de calidad asociado.

• Aportar conocimiento de los procesos bajo análisis.

• Realizar seguimiento de las actividades.

• Comunicar en forma oportuna las desviaciones que se tienen en el proyecto (en alcance, tiempo, costo, calidad) planteando alternativas de solución.

f. Construir el entorno del proyecto que brinde los estándares, métodos, técnicas y

herramientas que le faciliten a los miembros del equipo de trabajo el generar productos de calidad con una alta productividad.

g. En conjunto con el Líder del Proyecto desarrollar, mantener y comunicar los diferentes tipos

de planes que se requieran a lo largo del proyecto.

h. Coordinar el trabajo de los diferentes integrantes de su grupo de proyecto, los cuales incluyen analistas de sistemas, personal de otros procesos de Tecnología de Información, personal de las Áreas Usuarias relacionadas y proveedores externos cuando aplique. En el caso del personal de las áreas de Usuarias o de Operaciones la asignación de tareas se realizará en conjunto con el Líder del Proyecto, siendo este último el responsable de que se cumplan las tareas asignadas a este personal.

i. Administrar, liderar, asesorar y desarrollar a cada uno de los miembros de su equipo de

trabajo.

85

j. Vigilar de manera constante y objetiva, la calidad de los productos finales e intermedios del proyecto, de tal forma que se cumplan los estándares establecidos y se logren los compromisos adquiridos con sus Usuarios.

k. Generar y promover una actitud de proactividad ante el horizonte del proyecto, de tal manera

que tanto él como los miembros de su equipo de trabajo presenten una vigilancia constante del medio y de los posibles inconvenientes que pueda enfrentar su proyecto.

l. Planificar, coordinar y controlar las actividades de gestión del cambio, de divulgación, y

otros planes del proyecto, a fin de que los resultados que se generen sean oportunos de acuerdo al plan principal del proyecto y sus objetivos.

m. Identificar, ponderar y clasificar los riesgos preparando un plan de riesgos del proyecto.

Responsable de realizar una revisión periódica al menos una vez al mes de los riesgos identificados, de incluir nuevos riesgos así como de cerrar aquellos que ya no representen amenaza alguna para el proyecto.

n. Coordinar el proceso de adquisición de bienes y servicios en la confección de las

especificaciones técnicas de los distintos carteles y contratos para la obtención de los insumos del proyecto.

o. Acatar las recomendaciones de los Responsables de la Calidad, Gestión del Riesgo y

Auditoria Interna, para la buena marcha de los proyectos y para cumplir las normativas y metodologías.

p. Mantener informado del avance de los proyectos, así como de los desfases, impacto y

asesorar con soluciones propuestas, a sus superiores inmediatos para una toma de decisiones oportuna, en todas las fases del proyecto.

86

q. Evaluar con los líderes técnicos y funcionales lo necesario para evitar que en los sistemas en operación o los que se estén desarrollando, existan incompatibilidades o duplicidad de funcionalidades y a fin de garantizar que las tareas asignadas son factibles y efectivamente se ajusten a los planes de proyecto.

r. Generar todos los requerimientos para la puesta en producción de los sistemas o productos

finales generados de cada uno de los proyectos según requerimientos establecidos para facilitar su posterior mantenimiento, administración y control post implantación.

s. Coordinar estrechamente con el Líder del Proyecto.

t. Generación de informes de avances semanales, mensuales y de cierre de proyecto.

4.1.4. FUNCIONES DEL LÍDER DE PROYECTO.

El Líder del Proyecto será el funcionario responsable por el éxito del proyecto, teniendo entre sus funciones:

a. Elaborar y someter al Comité Director Informático para su aprobación el resultado del estudio preliminar y de factibilidad (cuando es requerido) como requisito para poder iniciar un proyecto.

b. Presentar al Comité Director Informático el Plan de Gestión del Proyecto, para su aprobación, el cronograma de trabajo en el que consten los recursos, el tiempo, presupuesto, supuestos, restricciones y los riesgos.

c. En coordinación con el Administrador del Proyecto que se asigne del Departamento de Informática, planificar, organizar, coordinar y dirigir el proyecto a lo largo de todas las etapas o fases del mismo.

87

d. Procurar los recursos necesarios y controlar las actividades realizadas por todos los miembros del grupo de trabajo para el correcto logro de los objetivos del proyecto.

e. Mantener debidamente informados a sus superiores jerárquicos sobre el avance del proyecto, así como las dificultades que afectan su normal funcionamiento.

f. Informar al Comité Director Informático sobre el avance del trabajo que se realiza en relación al cronograma aprobado.

g. Aprobar los productos resultantes del trabajo asignado a cada uno de los miembros del grupo o de la empresa contratada (en el caso del desarrollo por parte de empresas externas); así mismo, es también responsable de aprobar los productos que se deriven de cada una de las etapas y actividades que abarque el cronograma de trabajo. La aprobación estará fundamentada en el cumplimiento de dichos productos con respecto a los requerimientos especificados.

h. Dar visto bueno para que la administración o área que recibe el bien o servicio proceda a pagar las facturas que le son presentadas por las empresas externas. Para ello solicitará la aprobación técnica del Administrador del Proyecto de los productos que presente la empresa externa y que sean requisito para tramitar dicho pago. Ambas acciones deben constar por escrito.

i. Mantener una estrecha comunicación y coordinación con el Patrocinador del Proyecto, con la Dirección del Departamento de Informática y con las demás direcciones de la Organización, para lograr el desarrollo del proyecto según lo planteado.

j. Realizar reuniones de control de avance del proyecto a los miembros del Equipo de Trabajo, por lo menos una vez por semana y a las reuniones que considere necesario a otros usuarios involucrados.

k. Elaborar en conjunto con el administrador de proyectos informes de avance semanales, mensuales y de cierre del proyecto.

l. Cualquier otra actividad que conduzca a lograr los objetivos del proyecto.

88

4.1.5. ESQUEMAS ORGANIZATIVOS DE PROYECTOS. La organización de los proyectos variará sobre diferentes niveles de organizaciones matriciales, algunas con inclinación hacia esquemas funcionales y otras hacia esquemas por proyecto. Como regla general, serán las variables de tamaño del proyecto e importancia del mismo los que determinarán el tipo de organización. Entre más grande sea el proyecto y mayor sea su importancia, mayor es la necesidad que su organización se oriente a una “Matriz por Proyecto”, mientras que en el sentido inverso si las dos variables tienden hacia menor tamaño e importancia, la organización respectiva se orienta a una “Matriz Funcional”. La organización de Matriz por Proyecto tiene las siguientes características:

a) La mayor parte de sus recursos están dedicados de manera exclusiva al desarrollo del proyecto.

b) Las entidades que por lo general tienen participaciones esporádicas en el ciclo de desarrollo, cambian a tener una fuerte participación, incluso con personal a tiempo completo en ciertas actividades.

c) La definición de las prioridades laborales del personal gira de manera preponderante sobre los resultados del proyecto.

d) Se tienen canales de comunicación especialmente definidos para el proyecto, altamente ágiles y efectivos.

e) Existe un nivel importante en el poder de decisión de los miembros del equipo de trabajo. f) Existe una definición clara del momento en que se debe entregar el producto final,

después de la cual pierde su valor estratégico. g) La ubicación física del equipo de trabajo asignado por lo general es separada del resto

de la organización normal.

89

h) Al concluir el proyecto la estructura generada se disuelve y los miembros del equipo de trabajo retornan a los esquemas funcionales de la organización de sus departamentos respectivos.

i) Existe un fuerte compromiso para con el proyecto de parte de las Áreas funcionales involucradas en el desarrollo.

Figura 2-8. Organización ProyectizadaCoordinación Del Proyecto Ejecutivo

en Jefe

Administrador Administrador Administrador de Proyecto de Proyecto de Proyecto

Staff Staff Staff

Staff Staff Staff

Staff Staff Staff

(Las celdas negras representan a staff comprometida con actividades del proyecto)

Figura N° 3: Organización Proyectizada. En lo que se refiere a la organización de Matriz Funcional encontramos las siguientes características:

a) Solo una pequeña porción del equipo de trabajo está dedicada de manera exclusiva al proyecto, por lo general solo el personal técnico.

b) Se utilizan las estructuras administrativas y canales formales de comunicación existentes en la organización.

c) El peso del factor tiempo está por debajo de las consideraciones de costo, cumplimiento de requerimientos y consumo de recursos.

90

d) La participación de personal de áreas de soporte, auditoria interna y análisis organizacional están focalizadas en tareas específicas y con periodicidades bien establecidas.

Figura 2-7. Organización FuncionalCoordinación

Ejecutivo Del Proyectoen Jefe

Administrador Administrador Administrador Funcional Funcional Funcional

Staff Staff Staff

Staff Staff Staff

Staff Staff Staff

(Las celdas negras representan a staff comprometida con actividades del proyecto)

Figura N° 4: Organización Funcional.

4.1.6. CRITERIOS PARA LA ORGANIZACIÓN DE PROYECTOS. Además de las consideraciones de tamaño e importancia del proyecto, la organización también debe estar determinada por los siguientes aspectos:

a) Si lo que se efectúa es una contratación externa, la organización debe orientarse a establecer una contraparte acorde a las dimensiones del proyecto, de forma tal que pueda responder adecuadamente al ritmo de desarrollo planeado. En estos casos la contraparte designada por la Defensoría será responsable por:

• Facilitar a la empresa contratada la interacción con las diferentes áreas de la Defensoría que estén involucradas en el desarrollo.

• Cumplir con las tareas de inspección de cada uno de los productos que se generen.

91

• Asegurar la participación efectiva de los diferentes niveles de Usuarios que estén involucrados en el proyecto.

• Responder oportunamente en las tareas que les corresponda según el plan de trabajo.

• Asegurar que la Defensoría no sufra de una dependencia tecnológica del proveedor del servicio, esto mediante el involucramiento minucioso en todas las tareas del ciclo de desarrollo.

• La contraparte no debe limitarse a participar solo cuando los productos intermedios estén confeccionados, sino que debe participar activamente en la confección de los mismos, principalmente como aportador y formulador de caminos de solución.

b) Al establecer la estructura del proyecto, se debe estar claro en las fortalezas y debilidades

del equipo asignado, de tal forma que puedan ser atacados los posibles riesgos de forma anticipada y efectiva.

c) La designación del Administrador de Proyectos y de los Líderes de Proyectos debe estar

acorde con sus responsabilidades funcionales y con los requerimientos de esfuerzo que demanden los proyectos. En la medida en que el proyecto tenga dimensiones importantes para la Defensoría, así debe considerarse una abstracción de las responsabilidades funcionales cotidianas, de tal forma que se asegure un accionar y seguimiento oportunos para el éxito de los proyectos.

d) En la medida de lo posible el personal asignado a un proyecto deberá estar concentrado en

éste, disminuyendo su rotación a otros proyectos y su participación en proyectos simultáneos.

e) Por lo general, el personal asignado a tiempo completo al desarrollo de los proyectos

corresponde a administradores de proyectos y analistas de sistemas. No obstante, según sean las dimensiones del proyecto puede ser necesario que personal de otras áreas,, sean

92

asignados a tiempo completo al proyecto, como podría ser: Líderes de proyecto, control de calidad, auditoria interna, usuarios especializados o análisis organizacional.

f) Los miembros del equipo de trabajo deben estar claros en todo momento que la estructura

definida para determinado proyecto es temporal y dinámica durante el ciclo de desarrollo, por lo que debe evitarse el aferrarse a las estructuras y personas establecidas en la organización.

g) Los recursos asignados a un proyecto de manera exclusiva deben estar por completo a

disposición del Administrador de Proyectos, teniendo este último la autoridad sobre la definición de las tareas que cada uno de estos recursos deberá desarrollar. Durante el desarrollo del proyecto, el Administrador es el responsable por el otorgamiento de las vacaciones, permisos y concesiones que requiera el personal a su cargo.

h) Los recursos asignados a un proyecto deben estar comprometidos con alcanzar el éxito del

proyecto, para lo cual participarán en forma proactiva y serán responsables de entregar las tareas que les asigne el Administrador de Proyectos en el tiempo previsto, con la calidad esperada y con los estándares establecidos en las metodologías de la Defensoría que estén siendo aplicadas en el proyecto.

i) El Líder de Proyecto debe tener una alta disponibilidad y participación en los proyectos, ya

que en buena medida la calidad funcional, correcta interpretación de los requerimientos y enfoque de la solución pretendida, dependen de manera directa de la cantidad y calidad de sus aportes, así como de la coordinación que pueda realizar en su correspondiente área de la Defensoría.

j) El Administrador de Proyectos y el Líder de Proyecto son responsables por la asignación

equitativa y adecuada de la carga de trabajo del personal a su cargo. Por asignación

93

adecuada se entiende el no exceder la carga normal de cada funcionario ya que esta condición dificultaría el enfrentar posibles contingencias en el transcurso del desarrollo.

k) El Líder de Proyectos designado para el proyecto debe efectuar una utilización eficiente de

los recursos asignados, con medidas como la inclusión de personal al proyecto para tareas específicas (por ejemplo programación) y el mantener un nivel de conocimiento redundante en el equipo de trabajo que aminore los efectos de la rotación.

4.1.7. CONCEPTUALIZACIÓN DE PROYECTOS.

En la Defensoría de los Habitantes el inicio de un proyecto se dará con el proceso que se denominará la conceptualización del proyecto. Esta conceptualización está compuesta de las siguientes etapas:

a) Elaboración y justificación de un Área Usuaria de la necesidad de un proyecto de tecnologías de información. b) Aprobación o rechazo de la Solicitud de Propuesta de Proyecto. c) Elaboración del documento Enunciado del Alcance del Proyecto Preliminar. d) Aprobación o cancelación del proyecto propuesto, elaboración del documento Acta de Constitución del Proyecto y del documento Matriz de Involucrados del Proyecto.

A continuación se describen en mayor detalle las mismas.

4.1.7.1. ELABORACIÓN Y JUSTIFICACIÓN DE UN ÁREA DE LA NECESIDAD DE UN PROYECTO DE TECNOLOGÍAS DE INFORMACIÓN.

Cuando un Área Usuaria o de Tecnología de Información requiera de una nueva solución de Tecnología de Información entre las cuales podríamos tener:

94

1. Adquisición e implantación de un nuevo paquete de software. En este rubro se considerarán también aquellas soluciones que involucren componentes de Tecnología de Información que por primera vez utiliza la Defensoría y que estén orientados a satisfacer las necesidades de un área.

2. Desarrollo interno de un nuevo sistema de información que requiera de más de tres meses calendario y de al menos tres analistas de sistemas.

3. Una mejora sustancial o desarrollo de un nuevo módulo en un sistema existente que por su complejidad requiera de más de tres meses calendario e involucre más de tres analistas de sistemas.

4. Cambios en la infraestructura de Tecnología de Información que por su complejidad requieran de tres o más meses para su desarrollo.

En estos casos la solución se considerará como un proyecto y el área interesada deberá elaborar una Solicitud de Propuesta de Proyecto. Todas las Áreas Usuarias deberán de elaborar una Solicitud de Propuesta de Proyecto para la adquisición o desarrollo de una solución de Tecnología de Información.

Las propuestas se deberán plantear de la siguiente forma:

• El objetivo del proyecto: Enunciado en función del Plan Estratégico Institucional, el Plan

Anual Operativo Informático (PAO), relacionarse con el alcance de alguna de las metas propuestas, objetivos o prioridades de la Institución; para cumplir reglamentaciones de entes fiscalizadores o leyes; para mejorar el servicio al cliente interno o externo; o bien para mejorar la toma de decisiones institucional.

95

• Análisis de costo / beneficio: En este punto debe indicarse una estimación de los costos relacionados con la operación o prestación cotidiana del servicio y su balance con los beneficios esperados.

El contenido mínimo de la Solicitud de Propuesta de Proyecto está indicado en la plantilla del documento Solicitud de Propuesta de Proyecto (CON-SPP-01).

La Solicitud de Propuesta de Proyecto deberá ser presentada por el Área interesada al Despacho del Defensor/a y al Comité Director Informático para su aprobación respectiva.

4.1.7.2. APROBACIÓN O RECHAZO DE LA SOLICITUD DE PROPUESTA DE PROYECTO.

Para obtenerse la aprobación de la Solicitud de Propuesta de Proyecto y su aceptación como proyecto se deben seguir los pasos que se describen a continuación, con el fin de que la aprobación de la iniciativa de un nuevo proyecto se dé en el marco del Plan Estratégico Institucional, Plan Anual

Operativo de Informática (PAO), objetivos o metas del institucionales, objetivos o prioridades de la Organización o para cumplir con reglamentaciones de entes reguladores o leyes.

1. El Área Usuaria nombrará un Patrocinador del Proyecto quien se encargará preliminarmente de consultar la Solicitud de Propuesta de Proyecto con el Comité Interno Informático.

2. El Comité Interno Informático realiza una valoración preliminar de la Solicitud de Propuesta

de Proyecto en la que se estima a nivel muy general y preliminar los siguientes aspectos: recursos humanos de tecnologías de información, recursos de software, hardware, telecomunicaciones, interfases y otros, así como las características, disponibilidad y/o costos

96

de los mismos; considera los tiempos, plazos, factibilidad de cumplimiento técnico e impacto dentro de la cartera de proyectos en ejecución; tanto desde el punto de vista de lo que se requiere para atender el nuevo proyecto como para su posterior operación y mantenimiento.

Este Comité, con base en el resultado de lo anterior, puede solicitar al Patrocinador la realización de un Estudio de Factibilidad (Fuera del Alcance de esta Tesis) en caso de que no hubiera sido solicitado previamente, o bien solicitarle mayor información.

También, de acuerdo a los resultados del análisis, asigna un Administrador para el proyecto. El Comité Interno Informático deberá enviar un informe con los resultados y observaciones del estudio preliminar. Puede ser un criterio negativo justificado o positivo con observaciones o recomendaciones.

3. El Patrocinador del Proyecto recibe las valoraciones técnicas de las otras áreas a las cuales

se envió oficio con la Solicitud de Propuesta de Proyecto sin aprobar. 4. El Patrocinador deberá retroalimentar al Comité Director Informático, al Despacho del

Defensor/a, según corresponda, el criterio técnico emitido por las diferentes dependencias involucradas en el proyecto, antes de continuar con el proceso. La Solicitud de Propuesta de

Proyecto es enviada al Comité Director Institucional para su respectiva aprobación.

5. El Comité correspondiente con base en criterios de interés institucional y en los criterios técnicos emitidos por el Comité Interno Informático y las otras dependencias involucradas, debe valorar si continúa o no con el proyecto, fundamentado en elementos de índole jurídico, por aspectos de orden presupuestario, o por consideración de plazos, viabilidad e impacto en la cartera de proyectos de la Defensoría y prioridades institucionales.

97

También debe considerar para la decisión, si los requerimientos de recursos humanos y tecnológicos que requiere el proyecto se adecuan a los disponibles en la Institución. Además debe tomar en cuenta si el proyecto es considerado como prioritario por dentro de los planes estratégicos. El proyecto para ser aprobado debe demostrar su factibilidad y viabilidad. Debe quedar claro además que los proyectos deben ir en concordancia con el Plan Estratégico Institucional. El Comité respectivo deberá brindar su determinación en un plazo no mayor a cinco días hábiles.

6. El Comité respectivo debe informar la decisión de rechazar el proyecto al patrocinador del

proyecto. Considerando los elementos que el Comité respectivo utilice para no dar continuación al Proyecto, el Patrocinador debe comunicar dicha determinación al área usuaria, al Comité Interno Informático y a las otras áreas involucradas de la Defensoría mediante oficio.

7. Si el Comité respectivo da su aprobación al proyecto, el Patrocinador elaborará un oficio

solicitando al Administrador del Proyecto que inicie las gestiones con el Departamento de Informática y cualesquiera otras áreas involucradas para la preparación de los documentos Acta de Constitución del Proyecto y Desarrollo del Enunciado del Alcance del Proyecto

Preliminar, el cual posteriormente será presentado al Comité Director Informático para la aprobación del Proyecto.

8. La Solicitud de Propuesta de Proyecto aprobada por el Comité Director Informático debe ser

aprobado y firmado también por el Despacho del Defensor/a.

9. Si la Solicitud de Propuesta de Proyecto es aprobada el Comité Director Informático nombrará un Líder de Proyectos.

98

4.1.7.3. DESARROLLO DEL DOCUMENTO ENUNCIADO DEL ALCANCE DEL PROYECTO PRELIMINAR.

Para la preparación de este documento es necesario realizar un análisis de requerimientos, en el cual se identifiquen las necesidades indispensables y las deseables incluidas en la Solicitud de

Propuesta de Proyecto. En todo proyecto es prioritario identificar los requerimientos, por lo tanto, se requiere realizar una revisión de las necesidades plasmadas en el informe para identificar las indispensables en forma clara, concisa y de común acuerdo con el área interesada y cualesquiera otras áreas involucradas o interesadas en el proyecto. Este análisis de requerimientos alineará las necesidades del área interesada en términos de requerimientos a nivel de proyecto. Para realizar el análisis de requerimientos el Líder de Proyecto en conjunto con el Administrador de Proyectos identificarán los usuarios con más conocimiento y/o experiencia del área interesada que deberán participar en las entrevistas para identificar los requerimientos funcionales del proyecto. Cuando las necesidades de un proyecto resultan muy complejas o requieren de la integración y acuerdo de varias áreas de la Defensoría lo más conveniente es realizar sesiones de trabajo en conjunto con los interesados, en las cuales se valoren las opiniones de los participantes y se llegue a un acuerdo común del requerimiento a resolver. Los requerimientos serán expresados como entregables del proyecto que satisfacerán las necesidades del o las área(s) interesada(s). Es indispensable que el Patrocinador, el Líder de Proyecto y el Administrador de Proyectos tengan bien definido y establecido que el análisis se realizará para identificar los requerimientos indispensables que permitirán cumplir con el alcance establecido en el informe respectivo para el proyecto. Este análisis no está orientado a identificar funcionalidades deseables, ni tampoco podrá dejar por fuera una funcionalidad indispensable plasmada en el informe aprobado.

99

Para desarrollar un análisis de requerimientos exitoso es necesario que el Administrador de Proyectos haya desarrollado habilidades que le permitan asegurar obtener los requerimientos indispensables para el proyecto, entre estas habilidades se tienen:

• La habilidad para tratar con los usuarios, que permitirá identificar lo que ellos realmente necesitan.

• Manejo del entorno del proyecto: Se deben identificar quienes tienen la mayor influencia en el resultado del proyecto. Sin embargo debe tenerse presente que también se encontrarán con usuarios finales que individualmente no tienen influencia pero que al agruparse pueden tener gran influencia o poder en el resultado del proyecto. Para evitar problemas en el proyecto no debe olvidarse considerar las opiniones de estos usuarios finales.

• Competencia técnica: El Administrador de Proyectos debe estar en capacidad de establecer una comparación entre las necesidades del usuario y una solución técnica.

• Mente abierta y buena imaginación: Dos problemas no tienen la misma solución, pero reconociendo los elementos comunes un buen análisis de requerimientos se encontrará una solución que combine elementos de otras soluciones.

• Alta tolerancia por la ambigüedad: Los usuarios no siempre tienen bien definidas sus necesidades. Se trabajará con el usuario final entendiendo que se deberá manejar un nivel de ambigüedad en la definición de los requerimientos, sin embargo se debe tener presente de que se debe ayudar al usuario a definir en forma específica su requerimiento.

• Contexto o ambiente en el cual se realizará el análisis de requerimientos: Se debe conocer en detalle la organización, las entradas, salidas y obstáculos que se encontrarán al desarrollar la tarea. Se deben conocer los factores que conllevan a un alto nivel de productividad de los participantes y cuales tendrán un efecto negativo.

El análisis de los requerimientos debe quedar plasmado en el documento Análisis de

Requerimientos Preliminar (CON-ARP-02), que deberá ser revisado y aprobado por el Líder y el Administrador del Proyecto. Para su elaboración se utilizará la Guía - Especificación de los

Requisitos del Proyecto, (Fuera del Alcance de esta Tesis).

100

Componentes del documento Análisis de Requerimientos Preliminar son los resultados y acuerdos obtenidos con los participantes de las reuniones y entrevistas. Para la documentación de las reuniones y entrevistas se utilizarán las plantillas especificadas en la Guía de Reuniones, (AP-GR-03). Una vez identificados los requerimientos principales el Administrador de Proyectos determinará la viabilidad técnica del proyecto. El Administrador será el responsable de asesorar al Líder del Proyecto y al Patrocinador de la factibilidad técnica de dar solución a los requerimientos identificados. Para determinar la factibilidad técnica entre otros elemento se puede considerar costo, conveniencia, accesibilidad, flexibilidad y confiabilidad, disponibilidad de los elementos tecnológicos requeridos, beneficios esperados, restricciones tecnológicas de la Defensoría o del mercado. Para determinar la viabilidad técnica el Administrador de Proyectos se apoyará en las distintas áreas de Tecnología de Información para valorar la solución propuesta. Una vez identificados los requerimientos a satisfacer con el proyecto y la solución tecnológica propuesta se deberán documentar:

4.1.7.4. ENUNCIADO DEL ALCANCE DEL PROYECTO PRELIMINAR.

En el Enunciado del Alcance del Proyecto Preliminar se debe indicar:

• Visión del proyecto: La visión está definida en términos del área o áreas a que va orientada la solución producto del proyecto, el problema a resolver, el contexto de la solución, el plazo y la interrelación con otras funciones dentro del entorno bancario institucional.

• Identificar los objetivos o alcances del proyecto: en forma precisa y clara que delimitará de antemano los criterios de aceptación del producto o solución a entregar. Estos objetivos deben ser medibles, específicos, claros, concisos, consistentes y realistas.

101

• Beneficios a obtener con el proyecto: entre los beneficios a considerar tenemos los beneficios económicos, mejorar la competitividad de la Defensoría, mejoras en la calidad del servicio a los clientes de la Defensoría, a los clientes internos, en la funcionalidad del área o áreas que utilizarán la solución y cualesquiera otros que se determinen.

• Determinar los factores críticos de éxito, los supuestos y restricciones bajo los cuales se desarrollará el proyecto. El Líder y el Administrador de Proyectos deberán ser muy cuidadosos en la identificación de estos elementos, porque si durante la ejecución del proyecto no se cumplen estos elementos pueden convertirse en riesgos o problemas que pueden afectar el alcance del proyecto, el tiempo estimado, el presupuesto estimado o la calidad del producto a entregar.

• Solución conceptual: Establecer la solución conceptual general desde el punto de vista del Negocio o de Operaciones, describiendo en forma general sus funciones principales.

• Establecer los aspectos tecnológicos más importantes que pueda tener la solución en términos de mantenibilidad, reusabilidad, seguridad, portabilidad, confiabilidad, interoperabilidad y auditabilidad.

• Arquitectura de la posible solución.

• Requerimientos de hardware y software.

• Identificar los recursos para el desarrollo del proyecto: humanos, tecnológicos, infraestructura, espacio físico, etc.

• Estimación inicial del tiempo requerido para el proyecto: Considerando desde la planificación, ejecución y cierre del proyecto.

• Principales riesgos. En el Plan de Gestión de Riesgos se describen los conceptos para la identificación y categorización de los riesgos. En esta etapa de conceptualización se buscará identificar los riesgos de mayor probabilidad o impacto que puedan afectar el resultado del proyecto, y que, deberán ser valorados para determinar si se continúa o no con el mismo.

• Procedimiento a seguir para el control de cambios, sea éste en los alcances, en el costo, en el tiempo de entrega.

• Presupuesto del proyecto, que debe considerar los elementos y recursos requeridos para el proyecto

102

Esta documentación se plasmará en la plantilla del documento de Enunciado del Alcance del

Proyecto Preliminar (CON-EAPP-03).

4.1.7.5. APROBACIÓN DEL PROYECTO (ELABORACIÓN DEL DOCUMENTO ACTA DE CONSTITUCIÓN DEL PROYECTO Y DEL DOCUMENTO MATRIZ DE INVOLUCRADOS DEL PROYECTO).

Para obtenerse la aprobación del proyecto basado en el documento Enunciado del Alcance del

Proyecto Preliminar es necesario seguir los pasos que se describen a continuación:

1. El Comité Interno Informático recibe el documento Enunciado del Alcance del Proyecto

Preliminar, lo evalúa, hace sus observaciones y puede solicitar modificaciones al documento. Las modificaciones son realizadas al documento por el Líder y el Administrador del Proyecto y se vuelve a enviar al Comité Interno Informático para su aprobación.

2. El Comité Interno Informático remite el documento Enunciado del Alcance del Proyecto

Preliminar al Líder del Proyecto y al Patrocinador con sus criterios y observaciones.

3. El Patrocinador del proyecto remite el documento Enunciado del Alcance del Proyecto

Preliminar al Comité Interno Informático según corresponda, para que se dé la aprobación para presentar el proyecto al Comité Director Informático.

4. Si se aprueba la presentación al Comité Director Informático, el Patrocinador junto con el

Líder del proyecto y con la participación del Administrador del Proyecto realizan la presentación de la propuesta del proyecto, su estrategia para la administración del cambio y del plan de divulgación a nivel institucional ante el Comité Director Informático.

103

5. El Comité Director Informático vela por las prioridades institucionales y mide el impacto de cada proyecto del resto de iniciativas ya en proceso.

En este punto el Comité puede decidir no continuar con la iniciativa, hacer las variaciones o bien aprobar el proyecto. El Comité Director Informático aprueba el documento Enunciado

del Alcance del Proyecto Preliminar. También dependiendo de la naturaleza del proyecto y de las disposiciones existentes, se determina si la aprobación del mismo corresponde al Despacho del Defensor/a (a través de las recomendaciones del Comité Director Informático) o bien el Consejo de Directores, en cuyo caso se instruye lo correspondiente al Patrocinador para que realice la presentación del proyecto ante el Consejo de Directores, junto con el Administrador del Proyectos.

6. El Consejo de Directores conoce el proyecto, valora la disposición legal o importancia

institucional que el mismo contiene y decide si aprueba o no el proyecto, en ambos casos el Consejo de Directores comunica por medio de acuerdos.

7. El Director Informático comunica mediante oficio la decisión tomada y en los casos que el

proyecto sea rechazado, detalla las razones del rechazo.

8. Si el proyecto es aprobado, el Patrocinador o el Líder del Proyecto mediante oficio remite los resultados de la discusión de los alcances llevado a cabo en el Comité Director Informático a las diferentes unidades participantes a fin de validar y afinar el detalle de los requerimientos identificados y preparar el plan detallado del proyecto.

9. El Comité Director Informático debe incluir dentro de sus observaciones si la solución debe

darse con recursos internos o si se debe iniciar un proceso de contratación externa para su desarrollo, siendo la contratación externa el caso el Comité Interno Informático mediante oficio envía el Enunciado del Alcance de Proyecto Preliminar al Departamento de

104

Proveeduría y Servicios Generales para que formen parte de los términos de referencia que serán usados en el proceso de publicación del cartel de licitación y durante todo el periodo de contratación.

10. Si el proyecto aprobado se realizará con recursos internos de la organización, el Comité

Director Informático procede a realizar el Acta de Constitución del Proyecto, el cual es el documento que confiere al Administrador y Líder de Proyectos la autoridad para aplicar recursos de la Organización a las actividades del proyecto. El contenido de este documento se resume en la plantilla Acta de Constitución del Proyecto (CON-ACP-04).

11. El acto de aprobación del Acta de Constitución del Proyecto se realiza mediante una

reunión, la cual sigue el formato indicado en la Guía de Reuniones. El Presidente de la reunión hace uso de la Lista de Verificación – Comprobación de la Reunión de Aprobación

del Proyecto (CON-LVCRAP-06), la cual resalta aquellos temas que deben tomarse en cuenta antes, durante y después de una reunión de aprobación de proyectos.

12. El objetivo de la reunión de aprobación del proyecto es obtener la decisión de aprobación o

rechazo de los asistentes. La aprobación se basa no sólo en el contenido del Enunciado del

Alcance del Proyecto Preliminar, sino también en si la organización tiene (o puede obtener) o no los recursos necesarios y tiene unas previsiones razonables con respecto a que se pueden cumplir ciertos compromisos iniciales.

13. El Líder de Proyectos realiza una identificación de todos los involucrados en el proyecto,

este procedimiento se realiza haciendo uso de la plantilla del documento Matriz de

Involucrados del Proyecto (CON-MIP-05).

14. El Líder de Proyecto conforma el Archivo del Proyecto, el cual deberá contener los siguientes documentos:

105

a. Solicitud de Propuesta de Proyecto aprobada b. Análisis de Requerimientos Preliminar c. Resultados (Productos) de las Reuniones del Análisis de Requerimientos Preliminar d. Enunciado del Alcance del Proyecto Preliminar aprobado e. Acta de Constitución del Proyecto aprobado f. Matriz de Involucrados del proyecto identificados g. En el caso de que el proyecto sea ejecutado por contratación externa se debe incluir

una copia del contrato con la empresa proveedora.

4.2. PROCEDIMIENTO GENERAL DE GESTIÓN DE PROYECTOS INFORMÁTICOS.

4.2.1. OBJETIVO. Mediante la aplicación de este procedimiento se garantiza que todos los proyectos se inician, ejecutan y finalizan de forma ordenada y metódica, para que sus resultados se entreguen a tiempo, dentro del presupuesto y cumplan los requisitos del cliente.

4.2.2. ÁMBITO. Este procedimiento debe seguirse en forma obligatoria para cada proyecto de desarrollo de sistemas de información de la Defensoría de los Habitantes, independientemente del tamaño, coste y duración del mismo.

4.2.3. METODOLOGÍA. Este Procedimiento refleja el contenido de la Metodología PMI, y recoge los procesos de gestión en las fases del ciclo la vida del proyecto. Se aplica a todos los proyectos informáticos desarrollados en la Defensoría de los Habitantes.

106

4.2.4. PUESTA EN PRÁCTICA DE LA METODOLOGÍA.

• La Metodología PMI se aplicará a toda clase de proyecto de tecnologías de información desarrollado en la Defensoría de los Habitantes. Se establece los siguientes tipos de proyectos en la que es aplicable:

- Adquisición e implantación de un nuevo paquete de software. En este rubro se considerarán también aquellas soluciones que involucren componentes de tecnologías de información que por primera vez utiliza la Defensoría y que estén orientados a satisfacer las necesidades de un área.

- Desarrollo interno de un nuevo sistema de información que requiera de más de tres meses calendario y de al menos tres analistas de sistemas.

- Una mejora sustancial o desarrollo de un nuevo módulo en un sistema existente que por su complejidad requiera de más de tres meses calendario e involucre más de tres analistas de sistemas.

- Cambios en la infraestructura de tecnologías de información que por su complejidad requieran de tres o más meses para su desarrollo.

4.2.5. REFERENCIAS.

Nombre del Archivo Título del Documento No Incluido Procedimiento Ingeniería de Desarrollo de Software No Incluido Procedimiento de Gestión de Emergencias/Problemas No Incluido Procedimiento Gestión de la Configuración No Incluido Procedimiento Gestión de Cambios AP-GR-03 Guía de Reuniones No Incluido Procedimiento Gestión de Pruebas de Aceptación del Producto No Incluido Procedimiento Gestión de Implantación del Producto No Incluido Procedimiento Gestión de la Capacitación de Usuarios Finales PLA-PGT-03 Procedimiento Gestión del Tiempo

107

4.2.6. FUNCIONES Y RESPONSABILIDADES.

En este procedimiento se identifican los siguientes perfiles funcionales y responsabilidades:

Administrador del Proyecto Es responsable de asignar recursos materiales y humanos para la ejecución del proyecto, y nominar a los componentes de la Defensoría en la Directiva del Proyecto.

Líder del Proyecto Es responsable de gestionar el proyecto a lo largo de todo su ciclo de vida.

Equipo de Planificación Es responsable de ayudar al Líder de Proyecto con las actividades de planificación y gestión del proyecto a lo largo de la duración de éste.

Directiva del Proyecto Es responsable de aprobar todos los planes del proyecto y de supervisar el progreso del mismo. En el caso de no existir una Directiva de Proyecto, esta función será asumida por el Líder de Proyecto.

Responsable de Calidad Es responsable de definir el Procedimiento General de Gestión de Proyectos de la empresa, y aprobar las variaciones en dicha gestión propuestas por las distintas líneas de producción. Es responsable de asesorar al Líder del Proyecto sobre la realización de tareas y objetivos relativos a la calidad, según el Procedimiento de Gestión de la Calidad. Esta función podrá ser asumida por una persona del equipo de gestión del proyecto.

Equipo del Proyecto Encargado de la ejecución del proyecto, de reportar cambios y de informar sobre el estado de las acciones.

108

4.2.7. ENTRADAS. Se considera que los siguientes elementos estarán presentes como factores de entrada para la gestión del proyecto: Específicos del proyecto:

• Solicitud de Propuesta de Proyecto aprobada

• Enunciado del Alcance del Proyecto Preliminar aprobado

• Acta de Constitución del Proyecto aprobado

• Matriz de Identificación de Involucrados

• Contrato con el proveedor (siempre que sea aplicable)

• Análisis de Requisitos Preliminar

• Resultados (Productos) de las Reuniones del Análisis de Requerimientos Preliminar

De carácter general:

• Políticas de Organización para la Administración de Proyectos de la Defensoría de los Habitantes.

• Políticas de Conceptualización de Proyectos de la Defensoría de los Habitantes.

• Procedimiento Ingeniería de Desarrollo de Software de la Defensoría de los Habitantes.

• La Intranet – Metodología de Gestión de Proyectos, con los documentos de ayuda para el desarrollo de los distintos procesos de gestión (Fuera del alcance de esta tesis)

109

4.2.8. SALIDAS. Al seguir el presente Procedimiento General de Gestión de Proyectos Informáticos se generarán los siguientes documentos y/o productos de gestión del proyecto:

• Plan de Gestión del Proyecto.

• Obsérvese que los siguientes documentos pueden ser independientes o pueden ser simplemente secciones separadas del Plan de Gestión del Proyecto.

- Plan de Ingeniería de Desarrollo de Software (Fuera del alcance de esta tesis).

- Plan de Gestión del Alcance (Fuera del alcance de esta tesis).

- Plan de Gestión del Tiempo (PLA-PGT-03).

- Plan de Gestión de Costes (Fuera del alcance de esta tesis).

- Plan de Gestión de Calidad (Fuera del alcance de esta tesis).

- Plan de Gestión del Personal (Fuera del alcance de esta tesis).

- Plan de Gestión de las Comunicaciones (Fuera del alcance de esta tesis).

- Plan de Gestión de Riesgos (Fuera del alcance de esta tesis).

- Plan de Gestión de las Adquisiciones (Fuera del alcance de esta tesis).

- Plan de Gestión de Configuración (Fuera del alcance de esta tesis).

- Plan de Gestión de Cambios (Fuera del alcance de esta tesis).

- Plan de Pruebas de Aceptación del Producto (Fuera del alcance de esta tesis)

- Plan de Implantación del Producto (Fuera del alcance de esta tesis).

- Plan de Capacitación de Usuarios Finales (Fuera del alcance de esta tesis).

• Identificación de Entregables y Criterios de aceptación del cliente.

• Informes sobre el Progreso del Proyecto.

110

• Informes sobre Emergencias/Problemas del Proyecto, según sea necesario.

• Solicitudes de Cambios, según sea necesario.

• Informe de Revisión Cierre de Proyecto.

• Archivo de Proyecto (recopilación de todo el material del proyecto)

4.2.9. MECANISMOS DE CONTROL.

• Los Planes de Gestión de Proyecto (el Plan de Gestión del Proyecto y los otros planes de gestión) son aprobados por la Directiva del Proyecto.

• Se realizarán reuniones de seguimiento y control del proyecto según lo establecido en la Guía de Reuniones, (AP-GR-03).

• Los Informes de Progreso son revisados por la Directiva del Proyecto.

• Se celebrarán reuniones de aceptación de fases/etapas de proyectos al menos al final de cada fase y/o etapa.

• Las variaciones en los procesos de Gestión de Calidad deberán ser aprobadas por el Responsable de Calidad y la Directiva del Proyecto.

4.2.10. DESCRIPCIÓN DEL PROCEDIMIENTO.

4.2.10.1. INICIACIÓN DEL PROYECTO.

• El Auditor Interno procede a realizar una verificación formal del proceso del proyecto antes de que se inicie su ejecución. El Auditor Interno utiliza la Lista de Verificación – Fase Inicio

del proyecto (INI-LVFIP-01), para recolectar la información requerida. En el caso de que todo este correcto se sigue el proceso normalmente, de lo contrario realiza y envía un informe mediante oficio al Administrador de Proyectos y al Comité Director Informático detallando los problemas encontrados para que se subsanen inmediatamente.

111

• El Líder del Proyecto identifica los documentos del proceso de conceptualización y prepara los recursos (equipo de proyecto, materiales, contratos, físicos, etc.), las herramientas, metodologías, políticas y procedimientos necesarios para elaborar el documento Plan de Gestión del Proyecto. Es obligatorio elaborar este documento para todos los proyectos informáticos de la Defensoría de los Habitantes.

• El Administrador del Proyecto por petición del Líder del Proyecto designa al equipo de

planificación y gestión del proyecto (si es necesario) y a los componentes de la Directiva del Proyecto.

• Para la gestión de proyectos informáticos se recomienda que la Directiva del Proyecto esté

formada al menos por las siguientes personas:

- El Líder del Proyecto.

- El Administrador de Proyectos.

- Un representante del Área Usuaria.

• El Administrador de Proyectos, el Líder de Proyecto y el representante(s) del Área Usuaria

definen los Entregables y los Criterios de Aceptación de los productos al cierre del proyecto, según lo indicado en el Procedimiento Gestión del Alcance del Proyecto (Fuera del alcance de esta tesis).

• El Líder de Proyecto, con la colaboración del Administrador de Proyectos, establece un

archivo de proyecto y archiva: los documentos de la fase de Conceptualización, los Entregables y los Criterios de Aceptación del Proyecto.

112

4.2.10.2. PLANIFICACIÓN DEL PROYECTO.

4.2.10.2.1. ORGANIZACIÓN DEL PROYECTO.

• El Líder del Proyecto puede decidir si dividir el proyecto en una jerarquía de subproyectos más pequeños. Por ejemplo, en el caso de proyectos amplios, pueden crearse dos (o más) subproyectos separados, uno para realizar la gestión general del proyecto y otro (o más) para gestionar el desarrollo y puesta en marcha de los entregables del mismo. Los subproyectos de la jerarquía se gestionan como proyectos separados desde el punto de vista del proceso de gestión del proyecto. Esta división queda reflejada en el Plan de

Gestión del Proyecto.

• El Líder del Proyecto y el equipo de planificación y gestión seleccionan el o los ciclos de

Ingeniería de Desarrollo de Software (Fuera del Alcance de esta Tesis) apropiado para el proyecto (por ej., incremental, prototipos, etc.), pudiendo acogerse al estándar o por el contrario realizar cambios o diseñar uno nuevo según sea necesario con respecto al proyecto en cuestión. Los nuevos ciclos de Ingeniería de Desarrollo de Software o cambios a los estándares de la Defensoría de los Habitantes, deberán ser aprobados por el correspondiente Responsable de Calidad en el proyecto (siguiendo el proceso definido en el Procedimiento Ingeniería de Desarrollo de Software (Fuera del Alcance de esta Tesis)).

• Los ciclos de Ingeniería de Desarrollo de Software se estructuran en fases, que se pueden

dividir en etapas y, si es necesario, se identifican las actividades y, para cada una de ellas, se identifican tareas (véase la Figura Nº: 5 Jerarquía de Análisis de Trabajo del Proyecto).

113

Proyecto

Fases

Etapas

Actividades

Tareas(diseñar para

paquetes de trabajo(WP))

Por ej., Especificación de Requisitos,diseño de Configuración, DiseñoDetallado, etc.

Por ej., Repetición1, Repetición2, etc.

Por ej., gestión, desarrollo, QA, CM,documentación, formación, etc.

Por ej., Crear Cuestión 1 deEspecificación de Requisitos,Especificación, Código & Unidad ,Prueba X, etc.

Figura N° 5: Jerarquía de Estructura de Trabajo (WBS) de Proyecto

4.2.10.2.2. PROCESOS DE GESTIÓN DE PROYECTOS.

• El Líder de Proyecto revisa los procesos establecidos en los ciclos de Ingeniería de

Desarrollo de Software de la Defensoría de los Habitantes, y puede definir variaciones según lo especifica el Procedimiento Ingeniería de Desarrollo de Software (Fuera del Alcance de esta Tesis).

114

• En función del tipo de proyecto desarrollado, el Líder de Proyecto selecciona el flujograma con actividad de gestión aplicable al proyecto.

• Si es necesario realizar variaciones con respecto a los procesos de gestión, el Líder de Proyecto deberá revisarlas, proporcionar justificaciones y documentarlas en el Plan de

Gestión del Proyecto. El Líder de Proyecto deberá obtener la aprobación del Responsable de Calidad (en el proyecto) y del Administrador de Proyectos para realizar dichas variaciones.

• Para cada fase de la Estructura Detallada de Trabajo se identifican y documentan los procedimientos, métodos o normas aplicables (por ej., Procedimientos de Diseño Orientados al Objeto, Normas de Codificación para Visual Basic, etc.)

4.2.10.2.3. ELABORACIÓN DEL PLAN DE GESTIÓN DEL PROYECTO.

• El Líder de Proyecto, en colaboración con el equipo de planificación y gestión, elabora un Plan de Gestión del Proyecto para cumplir con los compromisos adquiridos con el Área Usuaria.

• Si el análisis del trabajo del proyecto es complejo (es decir, si está dividido en una serie de fases y etapas), se recomienda lo siguiente:

1. Elaborar un plan de un nivel alto para el proyecto completo que incluya las fases y etapas, sus entregables y todas las interdependencias.

2. Elaborar un plan por fase/etapa. Incluyen las actividades detalladas, los entregables e interdependencias que se deberán realizar a lo largo de la fase/etapa.

• Los criterios de entrada y salida para cada fase del Plan de Gestión del Proyecto, podrán obtenerse del documento correspondiente al ciclo de Ingeniería de Desarrollo de Software

estándar de la Defensoría de los Habitantes seleccionado para el proyecto. Si por el contrario ha sido necesario diseñar un ciclo específico para el proyecto deberán definirse los criterios de entrada y salida para cada una de las fases de la Estructura Detallada de

115

Trabajo. Los criterios de entrada especifican lo que debe haber antes de comenzar una fase/etapa; los criterios de salida especifican lo que hay que tener o lo que debe haber antes de aceptar la finalización de una fase/etapa.

• En el Plan de Gestión del Proyecto se explica cómo se tratarán las emergencias/problemas, según lo indicado en el Procedimiento de Gestión de Emergencias/Problemas del Proyecto (Fuera del Alcance de esta Tesis).

• El Líder de Proyecto y su equipo de planificación elaboran un Plan de Gestión del Alcance, según el Procedimiento de Gestión del Alcance del Proyecto (Fuera del Alcance de esta Tesis). La Estructura Detallada de Trabajo, la definición de los entregables del proyecto y los Criterios de Aceptación de los productos al cierre del proyecto son los productos principales de este plan.

• El Líder de Proyecto y su equipo de planificación elaboran un Plan de Gestión del Tiempo, según el Procedimiento de Gestión del Tiempo del Proyecto. El Cronograma de Trabajo y la Línea Base del Tiempo son los productos principales de este plan. Para obtener una plantilla del Plan de Gestión del Tiempo ver la plantilla (PLA-PGT-03) desarrollada en esta Tesis.

• El Líder de Proyecto y su equipo de planificación elaboran un Plan de Gestión de Costes, según el Procedimiento de Gestión del Costes del Proyecto (Fuera del Alcance de esta Tesis). La Línea Base de Costes (Presupuesto) es uno de los productos principales de este plan.

• El Líder de Proyecto y su equipo de planificación elaboran un Plan de Gestión de Calidad, según el Procedimiento de Gestión de la Calidad del Proyecto (Fuera del Alcance de esta Tesis). La Línea Base de Calidad es uno de los productos principales de este plan.

• El Líder de Proyecto y su equipo de planificación elaboran un Plan de Gestión del Personal, según el Procedimiento de Gestión del Personal del Proyecto (Fuera del Alcance de esta Tesis). Los Roles y Responsabilidades, los Organigramas de Proyecto son unos de los productos principales de este plan.

116

• El Líder de Proyecto y su equipo de planificación elaboran un Plan de Gestión de las

Comunicaciones, según el Procedimiento de Gestión de las Comunicaciones del Proyecto (Fuera del Alcance de esta Tesis). Los Informes de Rendimiento, Proyecciones, como se gestionaran los Cambios, las Polémicas y las Acciones Correctivas son algunos de los aspectos a resolver en este plan.

• El Líder del Proyecto y su equipo de planificación identifican y valoran los riesgos y elaboran un Plan de Gestión de Riesgos, según el Procedimiento de Gestión de Riesgos del Proyecto

(Fuera del Alcance de esta Tesis). Un Registro de Riesgos categorizados y priorizados según su probabilidad e impacto en los objetivos del Proyecto es uno de los productos principales de este plan.

• El Líder de Proyecto y su equipo de planificación elaboran un Plan de Gestión de las

Adquisiciones, según el Procedimiento de Gestión de las Adquisiciones del Proyecto (Fuera del Alcance de esta Tesis). Cómo se creará y gestionarán los contratos del Proyecto es uno de los objetivos principales de este plan.

• El Líder de Proyecto y su equipo de planificación deberán crear los siguientes planes subsidiarios:

- Se crea un Plan de Pruebas de Aceptación según el Procedimiento Gestión de Pruebas

de Aceptación del Producto (Fuera del alcance de esta tesis).

- Se crea un Plan de Implantación según el Procedimiento Gestión de Implantación del

Producto (Fuera del alcance de esta tesis).

- Se crea un Plan de Capacitación según el Procedimiento Gestión de la Capacitación de

Usuarios Finales (Fuera del alcance de esta tesis).

• El Líder de Proyecto facilita el Plan de Gestión del Proyecto para que el Equipo del Proyecto, el Responsable de Calidad, el Administrador de Proyectos, los grupos afectados y otras personas que designe el Líder de Proyecto realicen una revisión conjunta, según la Lista de

Verificación del Plan de Gestión del Proyecto. Véase asimismo la plantilla Lista de Verificación - Reunión de Aceptación del Plan de Gestión del Proyecto (PLA-LVRAPGP-02).

117

• Después de tratar las cuestiones de acción que surjan de la revisión del Plan de Gestión del

Proyecto, el Líder de Proyecto transmitirá el Plan de Gestión del Proyecto a la Directiva del Proyecto para obtener su aprobación.

• A lo largo del proyecto, el Líder de Proyecto se responsabilizará de mantener actualizado el Plan de Gestión del Proyecto.

• Para obtener una plantilla del Plan de Gestión de Proyectos véase Plan de Gestión del

Proyecto (PLA-PGP-01).

4.2.10.2.4. OTRAS ACTIVIDADES DE PLANIFICACIÓN.

• La gestión de contrato y la planificación de contratos tienen lugar según se define en el Procedimiento de Gestión de las Adquisiciones (Fuera del Alcance de esta Tesis). El Líder de Proyecto obtiene el compromiso escrito de organizaciones externas con respecto a las interdependencias relevantes.

• Dependiendo de la complejidad y requerimientos del proyecto, se pueden crear documentos de planificación independientes para las siguientes actividades o bien dichas actividades pueden estar incluidas como apartados en el propio documento del Plan de Gestión del

Proyecto:

- Se crea un Plan de Gestión de Configuración del Proyecto según el Procedimiento de

Gestión de la Configuración del Proyecto (Fuera del alcance de esta tesis).

- Se crea un Plan de Gestión de Cambios según el Procedimiento de Gestión de los

Cambios del Proyecto (Fuera del alcance de esta tesis).

- Se crea un Plan de Gestión de Emergencias/Problemas según el Procedimiento de

Gestión de Emergencias/Problemas del Proyecto (Fuera del alcance de esta tesis).

118

• El Líder de Proyecto archiva los documentos de gestión y planificación del proyecto aprobados en el Archivo del Proyecto. Todos los documentos de planificación de proyecto son controlados según el Procedimiento de Gestión de Configuración (Fuera del Alcance de esta Tesis).

4.2.10.3. SEGUIMIENTO Y CONTROL DEL PROYECTO.

• El responsable de Calidad procede a realizar una verificación formal del proceso del proyecto antes de que se inicie su ejecución. El Responsable de Calidad utiliza la Lista de

Verificación – Seguimiento y Control del Proyecto (SEG-LVSCP-01), para resaltar aquellos asuntos que deben tenerse en cuenta antes de iniciar la ejecución del proyecto y por tanto el seguimiento y control del proyecto (los “criterios de entrada”), durante la ejecución el seguimiento y control del proyecto (las “actividades en activo”) y antes de que se considere finalizado el seguimiento y control del proyecto (los “criterios de salida”).

• El Líder del Proyecto mide el progreso del proyecto en comparación con el Plan de Gestión

del Proyecto asegurándose de que los miembros del equipo aportan informes de estado de forma regular, utilizando la Plantilla - Informe Actividad del Equipo de Proyecto (SEG-PIAEP-02), así como las Plantillas – Informe Semanal del Progreso del Proyecto (SEG-PISPP-03), y Plantilla - Informe Mensual del Avance del proyecto (SEG-PIMAP-04). A continuación, el Líder del Proyecto revisa y actualiza el Plan de Gestión del Proyecto.

• El Líder del Proyecto celebra Reuniones de Equipo del Proyecto para revisar el progreso del proyecto e identificar, solucionar y seguir las emergencias y los riesgos. El Líder del Proyecto decide quién debe asistir a dichas reuniones. La frecuencia de las reuniones, los asistentes y el método empleado para realizar un seguimiento de las acciones del proyecto

119

están definidos en el Plan de Gestión de las Comunicaciones del Proyecto, según el Procedimiento Gestión de las Comunicaciones del Proyecto (Fuera del Alcance de esta Tesis) que forma parte del Plan de Gestión del Proyecto. La Guía de Reuniones (AP-GR-03), se utilizará como formato alternativo para controlar estas reuniones.

• El Líder del Proyecto celebra Reuniones de Aceptación de Fases/Etapas al final de cada una de ellas para valorar el proyecto en comparación con los criterios de entrada/salida de las fases/etapas. La aceptación se registra por medio de la Plantilla - Reunión de Aceptación de

Fases/Etapas del Proyecto, (SEG-PRAFEP-05). A ellas podrán asistir la Directiva del Proyecto, y el Responsable de Calidad. La Directiva del Proyecto deberá aprobar la asistencia de otras personas.

• El Responsable de Calidad procede a realizar una verificación formal del proceso de aceptación de entregables del proyecto antes, durante y después de la reunión de aceptación de Fases/Etapas del proyecto. El Responsable de Calidad utiliza la Lista de

Verificación – Reunión de Aceptación de Fases/Etapas del Proyecto (SEG-LVRAFEP-06), para verificar los requisitos relevantes.

• También, el Líder del Proyecto revisa el progreso en comparación con los objetivos de calidad definidos en el Plan de Gestión del Proyecto. Esto se hará garantizando que las pruebas y revisiones programadas se están llevando a cabo y que los resultados son satisfactorios y cuentan con la aprobación del Responsable de Calidad.

• El Líder del Proyecto identifica cualquier desviación importante que pueda afectar a los entregables del Plan de Gestión del Proyecto, los objetivos de calidad o al plan de entregas. Estas excepciones se documentarán en la Plantilla - Informe de Emergencias/Problemas del

120

Proyecto, (SEG-PIEPP-07). Se presenta un Informe de Emergencias/Problemas a la Directiva del Proyecto para obtener su aprobación a la solución propuesta.

• Todos los cambios significativos a los objetivos, al alcance o de los entregables del proyecto deberán ser documentados, valorados y aprobados por el Líder del Proyecto y por la Directiva del Proyecto, utilizando la Plantilla - Solicitud de Cambios del Proyecto, (SEG-PSCP-08). Cualquier cambio que conlleve ampliación del presupuesto del Proyecto, modificación en los compromisos contractuales firmados, con el cliente deberá ser notificado al Comité Director Informático.

• El Líder del Proyecto celebra reuniones para entregar productos del proyecto, las entregas pueden ser de productos parciales (Manual de Usuario, Manual de Operaciones, etc.) o bien productos finales (El Sistema de Información en producción). La aceptación de entregables se registra por medio de la Plantilla – Acta de Recepción de Productos del Proyecto, (SEG-ARPP-09). A ellas deben asistir el cliente (Área Usuaria), la Directiva del Proyecto, y el Responsable de Calidad. La Directiva del Proyecto deberá aprobar la asistencia de otras personas.

• El Líder del Proyecto, con la ayuda de los Administradores de Proyectos, mantiene el Archivo de Proyecto. Garantiza que el Equipo del Proyecto ha recibido copias actuales de toda la documentación relevante del proyecto.

• Los riesgos identificados en el proyecto, se documentan en el Plan de Gestión de Riesgos, son revisados periódicamente por el Líder del Proyecto (según el Procedimiento de Gestión

de Riesgos del Proyecto desarrollado en esta Tesis) y son actualizados en el Plan de

Gestión de Riesgos. Todos los riesgos significativos son registrados en los Informes de

121

Progreso del Proyecto o en los Informes de Emergencias/Problemas del Proyecto y se tratan en colaboración con el Administrador de Proyectos y la Directiva del Proyecto.

4.2.10.3.1. EL ARCHIVO DEL PROYECTO.

Un archivo de proyecto debe contener, al menos, los siguientes datos ordenados cronológicamente:

1. Solicitud de Propuesta de Proyecto aprobada

2. Enunciado del Alcance del Proyecto Preliminar aprobado

3. Acta de Constitución del Proyecto aprobado

4. Matriz de Identificación de Involucrados

5. Oferta/Contrato con el proveedor (siempre que sea aplicable)

6. Análisis de Requisitos Preliminar

7. Resultados (Productos) de las Reuniones (Minutas, Acuerdos, Etc.)

8. Plan de Gestión del Proyecto (todas las versiones)

a. Plan de Ingeniería de Desarrollo de Software (Fuera del alcance de esta tesis)

b. Plan de Gestión del Alcance (Fuera del alcance de esta tesis)

c. Plan de Gestión del Tiempo (PLA-PGT-03)

d. Plan de Gestión de Costes (Fuera del alcance de esta tesis)

e. Plan de Gestión de Calidad (Fuera del alcance de esta tesis)

f. Plan de Gestión del Personal (Fuera del alcance de esta tesis)

g. Plan de Gestión de las Comunicaciones (Fuera del alcance de esta tesis)

h. Plan de Gestión de Riesgos (Fuera del alcance de esta tesis)

122

i. Plan de Gestión de las Adquisiciones (Fuera del alcance de esta tesis)

j. Plan de Gestión de Configuración (Fuera del alcance de esta tesis)

k. Plan de Gestión de Cambios (Fuera del alcance de esta tesis)

l. Plan de Pruebas de Aceptación del Producto (Fuera del alcance de esta tesis)

m. Plan de Implantación del Producto (Fuera del alcance de esta tesis)

n. Plan de Capacitación de Usuarios Finales (Fuera del alcance de esta tesis)

9. Actas de reuniones (proyecto y cliente).

10. Documentación del cliente (correspondencia, contrato, etc.).

11. Documentación del proyecto (especificaciones, planes de pruebas, resultados de pruebas, etc.).

12. Correspondencia del proyecto (comunicaciones internas, correspondencia con contratistas, etc.).

13. Documentación de control de cambios (solicitudes de cambios, etc.)

14. Información de configuración (registros de configuración, control de configuración, etc.).

15. Informes (trabajos realizados por el equipo, progreso del proyecto, aceptación de fases/etapas, revisión de proyecto, etc.)

El Líder del Proyecto es responsable de garantizar la integridad y accesibilidad del Archivo del Proyecto, para lo que cuenta con la colaboración de los Administradores de Proyecto.

4.2.10.3.2. ELABORACIÓN DE INFORMES SOBRE EL PROYECTO.

El Líder del Proyecto se encarga de elaborar los siguientes informes y de enviarlos a las personas de la organización designadas por él mismo. A continuación y en el Plan de Gestión del Proyecto se

123

define una distribución adicional que pone de relieve, concretamente, los informes de gestión de proyecto que deben ser enviados a los interesados del proyecto.

4.2.10.3.3. INFORMES SOBRE EL PROGRESO DEL PROYECTO. Regularmente se elaboran Informes de Progreso y se envían a la Directiva del Proyecto. La frecuencia está definida en el Plan de Gestión del Proyecto; se recomienda producir un informe cada semana (Equipo de Proyecto y Líder de Proyecto) y uno mensual (Líder de Proyecto). Véanse las Plantillas - Informe Actividad del Equipo de Proyecto (SEG-PIAEP-02), – Informe Semanal del

Progreso del Proyecto (SEG-PISPP-03), y Informe Mensual del Avance del proyecto (SEG-PIMAP-04), para obtener las plantillas.

4.2.10.3.4. INFORME DE REUNIONES DE ACEPTACIÓN DE FASES/ETAPAS.

Los Informes de Aceptación de Fases/Etapas se producen al final de cada etapa y se envían a la Directiva del Proyecto. Véase Reunión de Aceptación de Fases/Etapas del Proyecto (SEG-PRAFEP-05), para obtener una plantilla.

4.2.10.3.5. INFORMES SOBRE EMERGENCIAS/PROBLEMAS.

Los Informes sobre Emergencias/Problemas se producen siempre que surja algún problema importante que tenga efecto sobre el Plan del Proyecto. Se envían a la Directiva del Proyecto. Véase el Informe de Emergencias/Problemas del Proyecto (SEG-PIEPP-07), para obtener una plantilla.

4.2.10.3.6. INFORMES SOBRE SOLICITUDES DE CAMBIO. Las Solicitudes de Cambio del Proyecto se producen siempre que se requiera un cambio significativo del ámbito del proyecto o de los productos entregables al cliente. El Líder del Proyecto solicita al equipo técnico del proyecto, un análisis del alcance del cambio y su impacto económico en el

124

presupuesto del proyecto, y si procede lo envía a la Directiva del Proyecto para obtener su aprobación para el desarrollo del cambio. Véase el Solicitud de Cambio del Proyecto (SEG-PSCP-08), para obtener una plantilla. Cualquier cambio que conlleve ampliación del presupuesto del proyecto o modificación en los compromisos contractuales firmados con un proveedor deberá ser notificado al Comité Director Informático, para gestionar las ampliaciones correspondientes del presupuesto del proyecto.

4.2.10.3.7. INFORME DE REVISIÓN CIERRE DEL PROYECTO. Al finalizar cada proyecto se produce un Informe de Revisión y Cierre de Proyecto según lo indicado en la Procedimiento de Revisión y Cierre de Proyecto (Fuera del Alcance de esta Tesis). La finalidad de este informe es permitir que la organización adquiera conocimientos a partir de la experiencia aportada por el proyecto. Este informe también se envía a la Directiva del Proyecto. Véase asimismo la Informe Revisión y Cierre del Proyecto, FIN-PIRCP-02), para obtener una plantilla.

4.2.10.4. FINALIZACIÓN (CIERRE) DEL PROYECTO.

• Al finalizar la ejecución del proyecto y antes de realizar el cierre de este, el responsable de Calidad debe conducir una evaluación al usuario final, con respecto al producto y proceso desarrollado. Esta evaluación será conducida, mediante entrevista utilizando la plantilla Evaluación al Usuario (FIN-PEU-06).

• La fase de Cierre del proyecto se realiza según lo indicado en el Procedimiento Revisión y

Cierre del Proyecto (Fuera del Alcance de esta Tesis).

• Al finalizar el proyecto, el Líder del Proyecto celebra una Reunión de Revisión de Proyecto según el Procedimiento de Revisión y Cierre del Proyecto (Fuera del Alcance de esta Tesis).

125

El Líder del Proyecto se encarga de decidir quiénes asistirán a la reunión y, entre ellos, podrán asistir: el Responsable de Calidad, el Equipo del Proyecto y la Directiva del Proyecto.

• El Responsable de Calidad procede a realizar una verificación formal de asuntos que deben tenerse en cuenta antes, durante y después de la reunión de cierre del proyecto. El Responsable de Calidad utiliza la Lista de Verificación – Reunión Revisión y Cierre del

Proyecto (FIN-LVRRCP-01).

• Los objetivos de una reunión de revisión del cierre del proyecto son los siguientes:

- Reconocer públicamente la finalización de un proyecto, agradecer su trabajo a los participantes del proyecto y reconocer sus contribuciones

- Conseguir las opiniones de los participantes de la reunión independientemente de los éxitos, errores y dificultades encontradas durante el ciclo de vida de un proyecto para mejorar proyectos futuros.

• El presidente de la reunión de revisión será normalmente el Líder del proyecto o el Responsable de calidad. El presidente debe asegurar que los asistentes están seguros de sus opiniones y que no se sienten “amenazados” o “en silencio” durante la reunión. La información obtenida en la reunión de revisión del proyecto se escribirá en un informe de revisión del cierre del proyecto. Véase la Informe Revisión y Cierre del Proyecto, (FIN-PIRCP-02), para obtener una plantilla.

• El Líder del Proyecto elabora un Informe de Revisión y Cierre de Proyecto (utilizando en parte el material obtenido de la Reunión de Cierre de Proyecto). Este documento recoge una descripción general de los objetivos y alcance, el enfoque de la solución técnica planteada y

126

las actuaciones y problemas más relevantes del proyecto, con la finalidad de archivar dicho Informe en la Base de Datos de referencias del Departamento de Informática de la Defensoría.

• También se elaborará un Informe de Oportunidades de Mejoras al Proceso, (FIN-PIOMP-03), en el que se recojan aspectos técnicos y funcionales que puedan aportar nuevos beneficios al negocio del cliente.

• El Responsable de Calidad en el proyecto, decide si alguna de las recomendaciones para futuros proyectos contenidas en el Informe Revisión y Cierre del Proyecto requieren el inicio de acciones correctivas. Si ése es el caso, el Responsable de Calidad solicitará al Líder de Proyecto que rellene la Plantilla de Acciones Correctivas, (FIN-PAC-04), según el Procedimiento de Acción Correctiva y Preventiva (Fuera del Alcance de esta Tesis).

• El Responsable de Calidad procede a realizar una verificación formal de asuntos que deben tenerse al cierre de un proyecto. El Responsable de Calidad utiliza la Lista de Verificación –

Cierre del Proyecto (FIN-LVCP-05), para cumplir con este objetivo.

• El responsable de Calidad debe proceder a efectuar la última revisión formal del producto, al darlo por finalizado y entregado al usuario. Esta evaluación se realizará utilizando la plantilla Evaluación Técnica del Producto (FIN-PETP-07).

• El Líder del Proyecto garantiza que el Archivo del Proyecto está completo y archivado. Toda la correspondencia con los involucrados se conserva con las versiones finales de toda la documentación del proyecto.

127

• El Líder del Proyecto garantiza que los cálculos realizados en el proyecto (por ej., tamaño, esfuerzo, planificación, recursos humanos, etc.) se añaden a la base de datos históricos de proyectos del Departamento de Informático de la Defensoría para que contribuyan a los cálculos realizados en futuros proyectos.

4.2.11. PLANTILLAS Y LISTAS DE VERIFICACIÓN ASOCIADOS.

Nombre del Archivo Título del DocumentoPLA-PGP-01 Plantilla - Plan de Gestión del Proyecto PLA-LVRAPGP-02 Lista de Verificación - Reunión de Aceptación del Plan del Proyecto SEG-LVSCP-01 Lista de Verificación – Seguimiento y Control del Proyecto SEG-PIAEP-02 Plantilla - Informe Actividad del Equipo de Proyecto SEG-PISPP-03 Plantilla – Informe Semanal del Progreso del Proyecto SEG-PIMAP-04 Plantilla Informe Mensual del Avance del proyecto SEG-PRAFEP-05 Plantilla - Reunión de Aceptación de Fases/Etapas del Proyecto SEG-LVRAFEP-06 Lista de Verificación – Reunión de Aceptación de Fases/Etapas del SEG-PIEPP-07 Plantilla - Informe de Emergencias/Problemas del Proyecto SEG-PSCP-08 Plantilla - Solicitud de Cambios del Proyecto SEG-PARPP-09 Plantilla – Acta de Recepción de Productos del Proyecto FIN-LVRRCP-01 Lista de Verificación – Reunión Revisión y Cierre del Proyecto FIN-PIRCP-02 Plantilla - Informe Revisión y Cierre del Proyecto FIN-PIOMP-03 Plantilla - Informe de Oportunidades de Mejoras al Proceso FIN-PAC-04 Plantilla - Acciones Correctivas FIN-LVCP-05 Lista de Verificación – Cierre del Proyecto FIN-PEU-06 Plantilla – Evaluación al Usuario FIN-PETP-07 Plantilla – Evaluación Técnica del Producto PLA-PGT-03 Plantilla – Plan de Gestión del Tiempo PLA-PRP-3 Plantilla – Recursos del Proyecto PLA-PCRP-04 Plantilla – Calendario de Recursos del Proyecto

FIN DEL PROCEDIMIENTO.

128

4.3. PLANTILLAS Y HERRAMIENTAS DE LA GESTIÓN DE PROYECTOS.

4.3.1. PLANTILLAS DE LA GESTIÓN DE PROYECTOS Este apartado contiene el diseño y formato de todas las plantillas creadas de gestión de proyectos que dan soporte al procedimiento desarrollado en esta tesis, están divididas según las fases del ciclo de vida de un proyecto y su cronograma de uso. Las plantillas desarrolladas son las siguientes: Plantillas de Conceptualización de Proyectos

• (CON-SPP-01) Solicitud de Propuesta de Proyecto

• (CON-ARP-02) Análisis de Requerimientos Preliminar

• (CON-EAPP-03) Enunciado del Alcance del Proyecto Preliminar

• (CON-ACP-04) Acta de Constitución del Proyecto

• (CON-MIP-05) Matriz de Involucrados del Proyecto

• (CON-LVCRAP-06) Lista de Verificación – Comprobación de la Reunión de Aprobación del Proyecto

Plantillas de Inicio de Proyectos

• (INI-LVFIP-01) Lista de Verificación – Fase Inicio del proyecto Plantillas de Planificación de Proyectos

• (PLA-PGP-01) Plan de Gestión del Proyecto

• (PLA-LVRAPGP-02) Lista de Verificación - Reunión de Aceptación del Plan de Gestión del Proyecto.

• (PLA-PGT-03) Plan de Gestión del Tiempo

• (PLA-PDA-04) Plantilla - Definición de Actividades

• (PLA-PRP-05) Plantilla - Recursos del Proyecto

• (PLA-PCRP-06) Plantilla - Calendario de Recursos

129

• (PLA-PWBSI-07) Plantilla – WBS Incremental

• (PLA-PWBSE-08) Plantilla – WBS Evolutivo

• (PLA-PWBSC-09) Plantilla – WBS Cascada Plantillas de Seguimiento y Control de Proyectos

• (SEG-LVSCP-01) Lista de Verificación – Seguimiento y Control del Proyecto

• SEG-PIAEP-02 Plantilla - Informe Actividad del Equipo de Proyecto

• (SEG-PISPP-03) Plantilla – Informe Semanal del Progreso del Proyecto

• (SEG-PIMAP-04) Plantilla - Informe Mensual del Avance del proyecto

• (SEG-PRAFEP-05) Plantilla - Reunión de Aceptación de Fases/Etapas del Proyecto

• (SEG-LVRAFEP-06) Lista de Verificación – Reunión de Aceptación de Fases/Etapas del Proyecto.

• (SEG-PIEPP-07) Plantilla - Informe de Emergencias/Problemas del Proyecto

• (SEG-PSCP-08) Plantilla - Solicitud de Cambios del Proyecto

• (SEG-PARPP-09) Plantilla – Acta de Recepción de Productos del Proyecto Plantillas de Cierre de Proyectos

• (FIN-LVRRCP-01) Lista de Verificación – Reunión Revisión y Cierre del Proyecto

• (FIN-PIRCP-02) Plantilla - Informe Revisión y Cierre del Proyecto

• (FIN-PIOMP-03) Plantilla - Informe de Oportunidades de Mejoras al Proceso

• (FIN-PAC-04) Plantilla - Acciones Correctivas

• (FIN-LVCP-05) Lista de Verificación – Cierre del Proyecto

• (FIN-PEU-06) Plantilla - Evaluación al Usuario

• (FIN-PETP-07) Plantilla - Evaluación Técnica Producto A continuación se presenta el diseño detallado de cada una de las plantillas anteriormente mencionadas, según el orden ya descrito.

130

4.3.1.1. PLANTILLAS DE CONCEPTUALIZACIÓN DE PROYECTOS

131

4.3.1.1.1. (CON-SPP-01) SOLICITUD DE PROPUESTA DE PROYECTO

DEFENSORÍA DE LOS HABITANTES DE LA REPÚBLICA

DEPARTAMENTO DE INFORMÁTICA ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS

SOLICITUD DE PROPUESTA DE PROYECTO (CON-SPP-01)

TÍTULO <BREVE DESCRIPCIÓN DE LA PROPUESTA DE DESARROLLO>

Versión

Autor:

Mes, año

132

SSOOLLIICCIITTUUDD DDEE PPRROOPPUUEESSTTAA DDEELL PPRROOYYEECCTTOO << NNOOMMBBRREE DDEE PPRROOYYEECCTTOO >> Fecha

Hora

TABLA DE CONTENIDOS

1. Introducción ........................................................................................................... 4

2. Nombre del Proyecto ............................................................................................... 4

3. Oportunidad de Mejora del Nuevo Producto o Servicio ................................................. 4

4. Objetivo Estratégico ................................................................................................ 4

5. Objetivos del Proyecto ............................................................................................. 4

6. Análisis Costo / Beneficio......................................................................................... 4

7. Descripción del Producto ......................................................................................... 4

8. Requerimientos del Nuevo Producto o Servicio ........................................................... 4

9. Necesidad del Proyecto............................................................................................ 4

10. Justificación del Impacto ........................................................................................ 5

11. Restricciones ........................................................................................................ 5

12. Identificación de Grupos de Interés .......................................................................... 5

CON-SPP-01 Solicitud de Propuesta del Proyecto, V1.0 Página 2 de 6

133


Hora

CONTROL DE VERSIONES

Fecha Versión Actualizado por Información de los cambios realizados


134


Hora

1. Introducción. <Definición y descripción del propósito del documento.>

2. Nombre del Proyecto. <Indicar el nombre del proyecto, la fecha de inicio y finalización estimada.>

3. Oportunidad de Mejora del Nuevo Producto o Servicio. < Describir en forma detallada en qué consiste la mejora planteada y que área de la Defensoría de los Habitantes (gerencial, operativa o administrativa) pretende soportar. Además, debe indicar los beneficios cuantitativos y cualitativos, de corto, mediano y largo plazo que se obtendrán, así como la necesidad o problema que se busca solventar.>

4. Objetivo Estratégico. <La iniciativa debe relacionarse con el alcance de alguna de las metas propuestas, objetivos o prioridades de la Institución; o si es para cumplir reglamentaciones de entes fiscalizadores o leyes; para mejorar el servicio al cliente interno o externo; o bien para mejorar la toma de decisiones institucional. Definir su correspondencia con el Plan Estratégico Institucional o con el Plan Operativo Anual del Departamento de Informática.>

5. Objetivos del Proyecto.

<Definir el objetivo general y los objetivos específicos del proyecto.> 6. Análisis Costo / Beneficio.

< En este punto debe indicarse una estimación de los costos relacionados con la operación o prestación cotidiana del servicio y su balance con los beneficios esperados. Interesa saber cómo se va a preparar la Defensoría de los Habitantes administrativamente para soportar esta iniciativa cuando se concrete. Se relaciona con la eventual estrategia de administración del cambio que deberá ser conocida y aprobada por el Comité Gerencial Informático.>

7. Descripción del Producto.

<Describir los productos y entregables del proyecto> 8. Requerimientos del Nuevo Producto o Servicio.

< Aquí se responde a la pregunta qué necesito tener o de qué necesito disponer para contar con la mejora. Los requerimientos deben definirse en forma clara y concisa. Debe indicarse el proveedor interno y externo de cada uno de los requerimientos.>

9. Necesidad del Proyecto.

<Definición y descripción del propósito del documento.>


135


Hora

10. Justificación del Impacto. <Definición y descripción del propósito del documento.>

11. Restricciones.

<Definición y descripción del propósito del documento.>

12. Identificación de Grupos de Interés. <Definir los stakeholders del proyecto) (clientes directos e indirectos).>


136


Hora

Dpto. / Área / Dirección / Comité Nombre Firma

Aprobación del Documento

Nombre:

Preparado Firma: Fecha: Nombre:

Revisado Firma: Fecha: Nombre:

Aprobado Firma: Fecha: Nombre:

Aprobado Firma: Fecha:

Espacio de Uso Exclusivo para el Comité Informático Comentario:

Resolución: Aprobado Pendiente Definir Rechazado Fecha de

Resolución


137

138

4.3.1.1.2. (CON-ARP-02) ANÁLISIS DE REQUERIMIENTOS PRELIMINAR



ANÁLISIS DE REQUISITOS PRELIMINAR (CON-ARP-02)

Versión

<Nombre del proyecto>

Autor:

Mes, año

139

AANNÁÁLLIISSIISS DDEE RREEQQUUIISSIITTOOSS PPRREELLIIMMIINNAARR<< NNOOMMBBRREE DDEE PPRROOYYEECCTTOO >> FFEECCHHAA

HHOORRAA

TABLA DE CONTENIDOS

1. OBJETIVOS ................................................................................................................................ 4

2. ÁMBITO....................................................................................................................................... 4

3. REFERENCIAS ........................................................................................................................... 4

4. DESCRIPCIÓN DEL PRODUCTO O SISTEMA.......................................................................... 4

5. REQUISITOS DEFINIDOS POR EL CLIENTE............................................................................ 4 5.1 FUNCIONALIDAD ..................................................................................................................... 4

5.1.1 Funcionalidad del sistema ............................................................................................... 4 5.1.2 Interfaz humana............................................................................................................... 5 5.1.3 Entidades de datos .......................................................................................................... 5 5.1.4 Estructuras de control ...................................................................................................... 5 5.1.5 Entorno de desarrollo de la aplicación ............................................................................. 5 5.1.6 Hardware ......................................................................................................................... 5 5.1.7 Software........................................................................................................................... 5

5.2 CARACTERÍSTICAS.................................................................................................................. 5 6. GLOSARIO.................................................................................................................................. 6

CON-ARP-02 Análisis Requisitos Preliminar, V1.0 Pág. 2 de 7

140


HHOORRAA

CONTROL DE VERSIONES Fecha Versión Actualizado por Información de los Cambios Realizados


141


HHOORRAA

ESPECIFICACIÓN DE REQUISITOS DEL CLIENTE

1. Objetivos. Este documento presenta la especificación de requisitos para el proyecto <Nombre del Proyecto>.

2. Ámbito. Este documento presenta sólo requisitos generales del proyecto.

3. Referencias. Nombre del Fichero Título del Documento

4. Descripción del producto o sistema. <Proporcionar una breve introducción al producto o sistema que incluye esta especificación.> <Incluir un diagrama de contexto que ayudará al lector a ubicarse en el producto o sistema.> <Deben hacerse referencias a documentos asociados cuando corresponda.>

5. Requisitos definidos por el cliente.

5.1 Funcionalidad.

5.1.1 Funcionalidad del sistema. <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una descripción detallada de alguna funcionalidad de la aplicación.>


142


HHOORRAA

5.1.2 Interfaz humana. <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una descripción detallada de estructuras de menúes, diseños de ventana o pantalla, esquemas de presentación y otras interfaces para operarios y/o supervisores.>

5.1.3 Entidades de datos. <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: un tipo de datos que debe estar disponible para el cliente, mediante el uso de herramientas de desarrollo de aplicaciones o mediante el uso de formularios, pantallas, informes y material impreso.>

5.1.4 Estructuras de control. <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una estructura de control que debe estar disponible para el cliente o que éste la utilice.>

5.1.5 Entorno de desarrollo de la aplicación. <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: un componente del producto o sistema que está disponible para que lo utilice el cliente en el desarrollo de aplicaciones.>

5.1.6 Hardware. <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: un requisito de hardware que existe por una necesidad del cliente.>

5.1.7 Software. <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: un requisito de software que existe por una necesidad del cliente.>

5.2 Características. El cliente ha especificado las siguientes características del producto o sistema:


143


HHOORRAA

Tipo de característica

Características

Preoperativa <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

Funcionalidad <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

Fiabilidad <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

Facilidades de uso <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

Rendimiento <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

Mantenimiento <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

Portabilidad <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

Documentación <Id. de requisito> (<Obligatorio/Necesario/Recomendado>): <Texto necesario: una característica específica del cliente.>

6. Glosario. A continuación, se presenta un glosario de términos y abreviaturas utilizadas en la especificación de requisitos:

Término o abreviatura Definición


144


HHOORRAA



Nombre:






Espacio de Uso Exclusivo para el Comité Director Informático Comentario:

Resolución: Aprobado Pendiente definir Rechazado Fecha de Resolución


145

146

4.3.1.1.3. (CON-EAPP-03) ENUNCIADO DEL ALCANCE DEL PROYECTO

PRELIMINAR



DECLARACIÓN DEL ALCANCE DEL PROYECTO PRELIMINAR (CON-EAPP-03)

Versión


Autor:

Mes, año

147

DDEECCLLAARRAACCIIÓÓNN DDEELL AALLCCAANNCCEE DDEELL PPRROOYYEECCTTOO PPRREELLIIMMIINNAARR

<< NNOOMMBBRREE DDEELL PPRROOYYEECCTTOO >> Fecha Hora

TABLA DE CONTENIDOS

1. Resumen Ejecutivo. ................................................................................... 4

2. Nombre del Proyecto. ................................................................................ 4

3. Definición del Problema............................................................................. 4

4. Visión del Proyecto. ................................................................................... 4

5. Objetivos del Proyecto............................................................................... 4

6. Alcances...................................................................................................... 4

7. Producto Principal del Proyecto. .............................................................. 4

8. Beneficios. .................................................................................................. 4

9. Equipo Inicial del Proyecto........................................................................ 5

10. Solución Conceptual. ............................................................................. 5

10.1. Consideraciones Generales. ................................................................. 5

10.2. Arquitectura de la Solución. .................................................................. 5

10.3. Requerimientos de Productos de Hardware y Software........................ 5

10.4. Otros Recursos necesarios. .................................................................. 5

11. Desarrollo del Proyecto.......................................................................... 5

11.1. Requerimientos Físicos......................................................................... 5

11.2. Requerimientos Humanos..................................................................... 5

11.3. Tiempos Estimados............................................................................... 6

11.4. Factores Críticos de Éxito. .................................................................... 6

11.5. Aspectos de Control. ............................................................................. 6

11.6. Principales Riesgos............................................................................... 6

12. Presupuesto del Proyecto...................................................................... 6

13. Operación de la Solución....................................................................... 6

14. Anexos..................................................................................................... 7

CON-EAPP-03 Declaración del Alcance del Proyecto Preliminar, V1.0 Pág. 2 de 8

148




Fecha Versión Actualizado por Información de los Cambios Realizados


149



1. Resumen Ejecutivo. <Propósito del documento, generalidades del proyecto (Número de proyecto, departamento, área o dirección al que pertenece, Administrador, fecha estimada de inicio y finalización), incluye además una breve descripción de lo que se espera lograr con el desarrollo de la solución, beneficios y limitaciones.>

2. Nombre del Proyecto. <Nombre con el cual se conocerá el proyecto.>

3. Definición del Problema. <Establecer claramente que motiva la iniciación del proyecto. Puede establecerse como un problema o como un objetivo a alcanzar>

4. Visión del Proyecto.

<En esta sección se define claramente cual es la visión del proyecto. La visión es definida tomando en consideración el problema, los cambios con la nueva solución, el contexto de la solución, el plazo y las interrelaciones con otras funcionalidades dentro de la institución. La visión debe ser especifica, medible, alcanzable y orientada en el tiempo.>

5. Objetivos del Proyecto. <Describir el objetivo general y los objetivos específicos del proyecto.>

6. Alcances. <Definir y detallar que se debe hacer para apoyar la visión, considerando las características del requerimiento del solicitante, los recursos y el tiempo. Define que se va hacer y que no en el proyecto y los procesos requeridos para asegurar que el proyecto incluye todo trabajo requerido, y solo el trabajo requerido, para que sea completado exitosamente.>

7. Producto Principal del Proyecto. <Definir los entregables mayores necesarios para cumplir con los requerimientos del proyecto.>

8. Beneficios.

<Describir los beneficios esperado del proyecto de acuerdo a la solución propuesta.>


150



9. Equipo Inicial del Proyecto.

Nombre Cargo Rol en Proyecto Patrocinador del proyecto Líder del proyecto Administrador del proyecto

10. Solución Conceptual.

10.1. Consideraciones Generales. <En esta sección describa las premisas en cuanto a mantenibilidad; reusablilidad; seguridad; portabilidad; confiabilidad; interoperabilidad y auditabilidad que sustenta el diseño propuesto y que se derivan de la visión planteada por el equipo de trabajo. Cada una de estas premisas debe estar asociada a la solución propuesta>.

10.2. Arquitectura de la Solución.

<En esta sección se debe describir la arquitectura lógica de los componentes de software; hardware y comunicación que son requeridos en la solución.; es decir la plataforma tecnológica que se soportará la solución>

10.3. Requerimientos de Productos de Hardware y Software.

<En esta sección se identifican los recursos tecnológicos que se necesitan en el proyecto. Se incluyen en esta sección los requerimientos de telecomunicaciones>

10.4. Otros Recursos necesarios.

< Detallar otras necesidades para el desarrollo y operación de la solución. >

11. Desarrollo del Proyecto.

11.1. Requerimientos Físicos. <Indicar en forma general los requerimientos físicos (espacio, equipo de oficina, mobiliario, laboratorios) necesarios para el desarrollo del proyecto>

11.2. Requerimientos Humanos. <Definición de roles y responsabilidades requeridos para formar el equipo del proyecto.>


151



Rol Funciones Nivel de Autoridad Patrocinador Líder del proyecto Administrador del proyecto Líder funcional Líder técnico Responsable de calidad Auditor

11.3. Tiempos Estimados.

<En esta sección incluya una Grafica de Gantt preliminar >

11.4. Factores Críticos de Éxito. <Describir los factores que se consideran determinantes en el éxito del proyecto >

11.5. Aspectos de Control.

<Describa los mecanismos de control que regirán en el proyecto: minutas, reuniones, planes>

11.6. Principales Riesgos.

<Describir los principales riesgos identificados hasta el momento que podría enfrentar el proyecto, su análisis y respuesta>

12. Presupuesto del Proyecto.

<Describa las necesidades o recursos presupuestarios que requiere el proyecto para su desarrollo. Tome en cuenta todos aquellos aspectos hardware, software, comunicación u otros que sean requeridos y que permitan establecer el costo estimado del proyecto.>

13. Operación de la Solución.

< Se define las condiciones necesarias que deben ser tomadas en cuenta antes de poner la solución en producción en cuanto a: procedimientos, aspectos de seguridad, normativa externa, mantenimiento; respaldos; personal técnico especializado. Esto con el propósito que la solución pueda operar sin problemas. >


152



14. Anexos <Se incluye: el Análisis de Requisitos Preliminar, en caso de haber realizado estudio de factibilidad, se incorpora también dentro de esta sección>


153




Aprobación del Documento Nombre:






Espacio de uso exclusivo para el Comité Director Informático Comentario:



154

155

4.3.1.1.4. (CON-ACP-04) ACTA DE CONSTITUCIÓN DEL PROYECTO

ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS

ACTA DE CONSTITUCIÓN DEL PROYECTO

Página:

1/3

CON-ACP-04 Acta de Constitución del Proyecto, V1.0 Pág. 1 de 3

PERFIL DEL PROYECTO Fecha de elaboración del Acta <dd/mm/aaaa>

Código del Proyecto <Escriba el código correspondiente>

INFORMACIÓN GENERAL DEL PROYECTO Nombre del Proyecto <Nombre con el cual se conocerá el Proyecto> Área Funcional <Área (s) solicitante (s) de la organización que proponen la idea del proyecto>

Nombre del Solicitante <Escriba el nombre completo de la persona>

Nombre del Líder del Proyecto <Persona responsable de la administración de proyecto, su responsabilidad consiste en la implementación del Plan del Proyecto (si se ha nombrado)>

ENFOQUE DEL PROYECTO Provee una visión a nivel ejecutivo del Plan de Proyecto: identifica la necesidad o el problema de

negocio o de la organización a resolver Descripción del Proyecto <Breve descripción del propósito del proyecto a través de su ciclo de vida> Problema o Necesidad de Negocio u Organizacional a resolver <Breve descripcion de la necesidad o problemática que enfrenta la organización y que justifica el proyecto> Objetivos Estratégicos <¿Cuáles son los objetivos estratégicos de la organización ligados con el proyecto?> Objetivo del Proyecto <Criterios enfocados a la entrega del proyecto, (Acción del Verbo en infinitivo + Entrega principal del proyecto + Marco de Tiempo (para el / antes del dd/mm/aaaa) + Costo (horas o colones, dolares)>

ABORDAJE DEL PROYECTO Describe la estrategia para desarrollar el proyecto

Entregas 1. <Definir los entregables mayores necesarios para cumplir con los requerimientos del proyecto> 2. <Definir los entregables mayores necesarios para cumplir con los requerimientos del proyecto>

156



Página:

2/3


Medidas 1. <Califican el rendimiento de la entrega, miden el desempeño, no el costo o duración del proyecto> 2. <Califican el rendimiento de la entrega, miden el desempeño, no el costo o duración del proyecto> Exclusiones 1. <Elementos que no se van a entregar como resultado del proyecto> 2. <Elementos que no se van a entregar como resultado del proyecto> Supuestos 1. <Factores que serán considerados reales o ciertos para el proyecto> 2. <Factores que serán considerados reales o ciertos para el proyecto> Restricciones o Limitaciones 1. <Factores que limitan las opciones disponibles para el equipo del proyecto, por ejemplo,

presupuesto, asignacion de personal y tiempo> Asuntos, Riesgos y Problemas <Indentificar los posibles Asuntos, Riesgos y Problemas>

OTROS PROYECTOS RELACIONADOS Proyectos Precedentes: <Crean las condiciones necesarias para la ejecución de algún otro

proyecto> Proyectos Siguientes: <Suceden a un proyecto el cual ha creado las condiciones necesarias

para sus ejecuciones> FIRMA DE PARTICIPANTES

Participante <Nombre y firma>










157



Página:

3/3


AUTORIZACIÓN PARA EL PROYECTO

Patrocinador <Nombre completo>

Firma <Nombre completo>

Fecha <dd/mm/aaaa>

Administrador del Proyecto

<Nombre completo>


Fecha <dd/mm/aaaa>

Líder del Proyecto <Nombre completo>


Fecha <dd/mm/aaaa>

Comité Interno Informático <Nombre completo>


Fecha <dd/mm/aaaa>

Comité Director Informático

<Nombre completo>


Fecha <dd/mm/aaaa>

Defensor/a de los Habitantes

<Nombre completo>


Fecha <dd/mm/aaaa>

158

159

4.3.1.1.5. (CON-MIP-05) MATRIZ DE INVOLUCRADOS DEL PROYECTO

Administración de Proyectos Informáticos Página 1 de 1

:

Matriz de Identificación de Involucrados del ProyectoNOMBRE DEL PROYECTO:DIRECTOR DEL PROYECTOPATROCINADOR:

Nombre Organizacion y dependencia Clasificacion Funcion en el

proyectoCriterio de éxito

de la personaNúmeros de

teléfonoCorreo

Electrónico

<Nombre completo><Organizacion y dependencia> <Rol> <Criterio de exito> <### - ####> < *** @ ***** >











CON-MIP-05 Matriz de Involucrados del Proyecto, V 1.0 1 de 1

160

161

4.3.1.1.6. (CON-LVCRAP-06) LISTA DE VERIFICACIÓN – COMPROBACIÓN DE LA REUNIÓN DE APROBACIÓN DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos Lista de Verificación Comprobación de la Reunión de Aprobación del Proyecto Referencia: CON-LVCRAP-06 Versión: 1.0

CON-LVCRAP-06 LV Comprobacion Reunion Aprobacion Proyecto, v1.0 Página: 1 de 1

COMPROBACIÓN DE LA REUNIÓN DE APROBACIÓN DEL PROYECTO

Esta lista de comprobación resalta aquellos temas que deben tenerse en cuenta antes, durante y después de una reunión de aprobación del proyecto.

Antes de la Reunión ¿Se ha escrito, revisado y aprobado el Enunciado del Alcance del Proyecto Preliminar? ¿Se ha invitado a la reunión a todas las personas que deben aprobar el proyecto y pueden

asistir todas? Entre los asistentes debe incluirse a representantes de responsabilidad de nivel superior y a todos los grupos que tendrán que comprometer recursos en caso de que se apruebe el proyecto (por ejemplo, Áreas Usuarias, Financiero, Proveeduría, etc.)

¿Se ha proporcionado a todos los asistentes una copia del Enunciado del Alcance del Proyecto Preliminar? y ¿lo han leído antes de la reunión?

¿Se ha proporcionado a todos los asistentes tiempo e información de recursos suficiente con respecto a los proyectos activos y cualquiera o todos los proyectos que han sido aprobados pero aún no están activos? Es necesario que dispongan de esta información para tomar decisiones con información acerca de la capacidad actual o futura de la organización para comprometerse con este proyecto en caso de que se aprobara.

Durante la Reunión ¿Han asistido todas las personas que deben aprobar el proyecto? ¿Se han tratado todos los temas y acciones importantes en la reunión? ¿Se ha tomado una decisión de aprobación o rechazo? ¿Ha sido una decisión unánime? Si no es así, ¿por qué? Si es necesario realizar una reunión de aprobación del proyecto de seguimiento, ¿se ha

programado?

Después de la Reunión ¿Se han distribuido copias de la reunión a todos los participantes? (Se recomienda hacerlo en 1

o 2 días de la reunión) ¿Se ha archivado la copia original del contenido de la reunión? ¿Se ha facilitado una notificación de la reunión de seguimiento (si es necesaria)? ¿Se han completado, revisado y cerrado las acciones asignadas?

162

163

4.3.1.2. PLANTILLAS DE INICIO DE PROYECTOS

164

4.3.1.2.1. (INI-LVFIP-01) LISTA DE VERIFICACIÓN – FASE INICIO DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos LV Fase Inicio del Proyecto Referencia: INI-LVFIP-01 Versión: 1.0

INI-LVFIP-01 LV Fase Inicio Proyecto v1.0 Página: 1 de 1

LISTA DE VERIFICACIÓN - FASE INICIO DEL PROYECTO Esta lista de comprobación resalta aquellos asuntos que deben tenerse en cuenta antes de iniciar el proyecto (los “criterios de entrada”) y antes de que se considere finalizada la iniciación del proyecto (los “criterios de salida”).

Criterios de entrada

¿Se ha creado, revisado y aprobado la Solicitud de Propuesta de Proyecto? ¿Se ha realizado un Análisis de Requisitos Preliminar? ¿Se ha creado, revisado y aprobado el Enunciado del Alcance del Proyecto Preliminar? ¿Se ha creado, revisado y aprobado el Acta de Constitución del Proyecto? ¿Se ha celebrado una reunión interna de aprobación del proyecto ¿Se ha obtenido la aprobación formal del Defensor/o para iniciar el proyecto? ¿Se ha identificado y obtenido una Matriz de Involucrados del proyecto? ¿Están archivadas las Minutas de Reuniones y Seguimientos de Acuerdos (si fueron necesarias)

realizadas? ¿Se ha identificado y asignado un Administrador del proyecto? ¿Se ha identificado y asignado un Líder del proyecto?

Criterios de salida

¿Se ha identificado y asignado un Responsable de la Calidad del Proyecto? ¿Se ha identificado y asignado un Equipo de Planificación de Proyectos? ¿Se ha identificado y aprobado una directiva del proyecto? ¿Se han creado, revisado y aprobado los Entregables del Proyecto? ¿Se han identificado, revisado y aprobado los procesos y Criterios de Aceptación del Proyecto? ¿Se ha iniciado el archivo del proyecto? ¿Se han incluido en el archivo del proyecto copias de los contratos, el contenido de la reunión de

aprobación del proyecto, Entregables del proyecto y los Criterios de Aceptación del Proyecto?

165

166

4.3.1.3. PLANTILLAS DE PLANIFICACIÓN DE PROYECTOS

167

4.3.1.3.1. (PLA-PGP-01) PLAN DE GESTIÓN DEL PROYECTO



PLAN DE GESTIÓN DEL PROYECTO (PLA-PGP-01)

Versión


Autor:

Mes, año

168

PPLLAANN DDEE GGEESSTTIIÓÓNN DDEELL PPRROOYYEECCTTOO


TABLA DE CONTENIDOS

1. Documento.................................................................................................. 4 1.1. Objetivos ...................................................................................................... 4

1.2. Ámbito .......................................................................................................... 4

1.3. Destinatarios. ............................................................................................... 5

1.4. Glosario de Términos. .................................................................................. 5

2. Descripción general del proyecto............................................................. 5

3. Entregables del proyecto y Criterios de Aceptación............................... 5

4. Organización y responsabilidades de gestión del proyecto .................. 6

5. Dependencias externas ............................................................................. 6

6. Planes de soporte a la gestión.................................................................. 6

7. Requisitos para la ejecución del proyecto............................................... 7

8. Plan de trabajo: ciclo de producción (fases) ........................................... 8

9. Planificación detallada del proyecto....................................................... 10

10. Control de calidad (Revisiones y Pruebas)............................................ 10

11. Esfuerzo (horas hombre) en el proyecto y desviaciones ..................... 11

12. Presupuesto de Costes del Proyecto y desviaciones........................... 12

13. Seguimiento y Control del proyecto ....................................................... 13

14. Hitos de Facturación................................................................................ 13

PLA-PGP-01 Plan Gestión Proyecto, V1.0 Pág. 2 de 14

169






170



Plan de Gestión del Proyecto

1. DOCUMENTO

1.1. OBJETIVOS Este documento presenta con detalle el Plan de Gestión del Proyecto del proyecto: <Nombre del Proyecto>. El presente documento tiene como objeto recoger la planificación de la ejecución del proyecto, con la finalidad de facilitar el seguimiento y el control del mismo. Se identifican las entidades responsables y mecanismos para realizar dicho control. También se incluye la organización operativa del mismo (recursos), los productos finales, y los presupuestos de costes, así como las dependencias externas y los medios de entorno y herramientas necesarias para poder desarrollar los trabajos del proyecto.

1.2. ÁMBITO El Plan de Gestión del Proyecto se aplica a los proyectos que tienen fechas específicas de inicio y fin, y desarrollan sistemas o productos definidos. El Plan de Gestión del Proyecto es un documento “activo” y se espera su modificación a medida que cambien las circunstancias del proyecto. Por parte de la Defensoría, las entidades organizativas y usuarios que estarán influenciadas por la implantación y puesta en marcha de los resultados del mismo, son las siguientes:

Nombre de las áreas usuarias de la Defensoría afectadas por la implantación


171



1.3. DESTINATARIOS.

Son destinatarios del presente documento las personas que forman parte del equipo de gestión y ejecución del proyecto por la Defensoría de los Habitantes. También serán destinatarios los responsables de la dirección implicados en la ejecución del mismo:

Nombre Cargo Nombre Responsable Área

Nombre Responsable de ….

Nombre

1.4. GLOSARIO DE TÉRMINOS.

A continuación se relacionan las siglas y abreviaturas utilizadas en el presente documento con una breve explicación de su significado:

Sigla Descripción

2. DESCRIPCIÓN GENERAL DEL PROYECTO <Breve describir general de los objetivos y alcance del proyecto.>

3. ENTREGABLES DEL PROYECTO Y CRITERIOS DE ACEPTACIÓN

Los entregables del proyecto y los criterios de aceptación del cliente se encuentran definidos en el documento adjunto:

Código de referencia Título del documentoPLA-PGA- Plan de Gestión del Alcance <nombre del

proyecto>”,


172



4. ORGANIZACIÓN Y RESPONSABILIDADES DE GESTIÓN DEL PROYECTO

El equipo de gestión del proyecto esta constituido por las siguientes personas:

Función del proyecto Asignado a (nombre de las personas)

Cargo

Directiva del proyecto Jefe de proyecto Equipo de planificación del proyecto

Equipo de ejecución del plan de trabajo

Coordinador de pruebas Responsable de calidad Controlador de configuración Controlador de cambios

5. DEPENDENCIAS EXTERNAS

<Mostrar cualquier dependencia fuera del control del Líder del Proyecto. Deben considerarse las actividades internas y externas.> Se destacan las actividades y recursos más relevantes para el proyecto que dependen de organizaciones externas al proyecto (por ejemplo: actividades que debe realizar un cliente o un contratista).

6. PLANES DE SOPORTE A LA GESTIÓN


173



A efectos de gestionar el proyecto, además de lo recogido en el presente Plan de Gestión del Proyecto, se han desarrollado los siguientes planes de gestión (indicar los que corresponda):

Título del documento Código de referenciaPlan de Gestión del Alcance Referencia del documento

Plan de Gestión del Tiempo Referencia del documento

Plan de Gestión de Costes Referencia del documento

Plan de Gestión de Calidad Referencia del documento

Plan de Gestión del Personal Referencia del documento

Plan de Gestión de las Comunicaciones Referencia del documento

Plan de Gestión de Riesgos Referencia del documento

Plan de Gestión de las Adquisiciones Referencia del documento

Plan de Pruebas de Aceptación Referencia del documento

Plan de Implantación Referencia del documento

Plan de Capacitación Referencia del documento

Plan de Gestión de Cambios Referencia del documento

Plan de Gestión de Emergencias/Problemas Referencia del documento

Plan de Gestión de Configuración Referencia del documento

7. REQUISITOS PARA LA EJECUCIÓN DEL PROYECTO

<Se identifican los requisitos del proyecto relativos a instalaciones y recursos materiales necesarios para desarrollar los trabajos, como oficinas, instalaciones especiales, equipo informático, equipo de oficina y herramientas de apoyo. > <Identificar las personas o grupos que serán responsables de obtener o desarrollar los medios anteriores.> <Describir brevemente qué acciones se debén realizar para asegurar los medios anteriormente indicados>


174



A continuación se indican los medios necesarios (de instalaciones y recursos) para poder realizar los trabajos del proyecto. También se indicará la persona de la Defensoría de la que depende la obtención de los medios y recursos indicados:

Medios necesarios para ejecutar el proyecto (oficinas, herramientas, etc.)

Persona responsable

8. PLAN DE TRABAJO: CICLO DE PRODUCCIÓN (FASES)

A continuación se indica el esquema de bloques con las “fases” del ciclo de producción del proyecto. Para cada fase (en formulario aparte) se definirán los criterios de inicio y fin, los documentos de entrada y de salida (entregables), y las actividades de revisiones y pruebas de cada entregable. Esquema de fases: (Insertar Figura)


175



Formulario de Fase: (para cada fase incluir la ficha adjunta) FASE Nº 1: NOMBRE DE LA FASE

DESCRIPCION

Duración : (días, semanas o meses)

Objetivos: Responsable de la Fase: Responsable de la Aceptación:

Documentos

ENTRADAS: Nombre del documento 1 / Nombre del producto o sistema Nombre del documento n / Nombre del producto o sistema

SALIDAS (ENTREGABLES):

Nombre del documento 1 / Nombre del producto o sistema Nombre del documento n / Nombre del producto o sistema

Actividades de Calidad de los entregables (Revisiones y Pruebas)

NOMBRE DEL ENTREGABLE-1

Tarea 1 (de revisión o pruebas) Tarea n (de revisión o pruebas)

NOMBRE DE ENTREGABLE-N

Tarea 1 (de revisión o pruebas) Tarea n (de revisión o pruebas)

Criterios de poder iniciar o finalizar la fase

CRITERIOS PARA PODER INICIAR LA FASE

Criterio 1 Criterio n

CRITERIOS PARA PODER TERMINAR LA FASE

Criterio 1 Criterio n

Figura N° 6: Formulario fases del ciclo de producción de proyectos


176



9. PLANIFICACIÓN DETALLADA DEL PROYECTO

La planificación detallada del proyecto (Pert, Diagrama de Gantt y Cronograma) se adjunta en el siguiente documento MS Project:

Título del documento Código de referenciaWBS (MS Project) – nombre del proyecto Referencia del documento

La planificación detallada del proyecto se encuentra definida en el documento adjunto:

Código de referencia Título del documentoPLA-PGT- Plan de Gestión del Tiempo <nombre del

proyecto>”,

10. CONTROL DE CALIDAD (REVISIONES Y PRUEBAS)

<Mostrar todas las revisiones y pruebas que se realizarán durante el proyecto, incluyendo la propiedad, programación aproximada y trabajo necesario.> <Mostrar todas las revisiones de clientes. Incluir reuniones para revisar resultados de las pruebas de aceptación y conformidad con los requisitos acordados.> Las actividades de revisión y pruebas de los entregables del proyecto están recogidas en la ficha técnica de cada fase. Su ejecución se indica en el Pert del proyecto (MS Project) mencionado en el apartado anterior, y adjunto como anexo del presente Plan de Gestión del Proyecto. Las revisiones y pruebas del proyecto se encuentran definidas en el documento adjunto:

Código de referencia Título del documentoPLA-PGC- Plan de Gestión de Calidad <nombre del

proyecto>”,


177



11. ESFUERZO (HORAS HOMBRE) EN EL PROYECTO Y DESVIACIONES En base a la planificación detallada del proyecto, la estimación de recursos humanos necesarios para realizar la gestión del proyecto es la siguiente:

Perfiles de gestión del proyecto

Jornadas (Estimadas) (A)

Jornadas (En plan detallado) (B)

Desviación con respecto a lo presupuestado

Líder de Proyecto

Gestor de Cambios

Gestor de Riesgos

Gestor de Configuración

En base a la planificación detallada del proyecto, la estimación de recursos humanos necesarios para la ejecución del proyecto es la siguiente:

Fase (nombre de

la fase)

Perfiles técnicos necesarios

Jornadas (Estimadas) (A)

Jornadas (En plan detallado) (B)

Desviación con respecto a lo presupuestado (A-B)

Las estimaciones de esfuerzo y desviaciones del proyecto se encuentran definidas en el documento adjunto:

Código de referencia Título del documentoPLA-PGP- Plan de Gestión de Personal <nombre del

proyecto>”,


178



12. PRESUPUESTO DE COSTES DEL PROYECTO Y DESVIACIONES

Una vez realizada la planificación detallada del proyecto se obtiene el siguiente presupuesto de costes, y su desviación con respecto a lo presupuestado en el Enunciado del Alcance del Proyecto Preliminar (EAPP). Las desviaciones serán motivo de análisis para determinar las acciones que correspondan a efectos de conseguir el margen previsto en la oferta/contrato.

Naturaleza de coste Importe Total Plan detallado (A)

Total en EAPP (B)

Desviación A-B

Mano de Obra propia de la Defensoría

Mano de Obra contratada

Compra de equipos de red

Compra de Plataformas H/S y licencias

Otros gastos (viajes, dietas, etc.)

Las estimaciones de presupuesto y las desviaciones del proyecto se encuentran definidas en el documento adjunto:

Código de referencia Título del documentoPLA-PGC- Plan de Gestión de Costes <nombre del

proyecto>”,


179



13. SEGUIMIENTO Y CONTROL DEL PROYECTO

• <Especificar el tipo y frecuencia de producción de los diferentes informes de proyecto.> • <Especificar la frecuencia y asistentes de las reuniones del equipo de proyecto.> • <Especificar la frecuencia de las reuniones de revisión del proyecto con el cliente.> • <Mostrar los criterios para emitir una versión revisada del plan del proyecto.>

El seguimiento y control del proyecto se encuentra definido en el documento adjunto:

Código de referencia Título del documentoPLA-PGC- Plan de Gestión de las Comunicaciones

<nombre del proyecto>”,

14. HITOS DE FACTURACIÓN El total a facturar del proyecto, asciende a la cantidad de: El plan de facturación del proyecto, tal y como se recoge en la oferta es el siguiente:

Condiciones de facturación % a facturar Importe

Fin del documento.


180










Espacio de uso exclusivo para la Directiva del Proyecto Comentario:



181

182

4.3.1.3.2. (PLA-LVRAPGP-02) LISTA DE VERIFICACIÓN - REUNIÓN DE

ACEPTACIÓN DEL PLAN DE GESTIÓN DEL PROYECTO.

Defensoría de los Habitantes Administración de Proyectos Informáticos PLA-LVRAPGP-02 LV Reunion Aceptacion Plan Gestion Proyecto Referencia: PLA-LVRAPGP-02 Versión: 1.0

PLA-LVRAPGP-02 LV Reunion Aceptacion Plan Gestion Proyecto v1.0 Página 1 de 2

LISTA DE VERIFICACIÓN REUNIÓN DE ACEPTACIÓN DEL PLAN DE PROYECTO

Esta lista de verificación hace énfasis en los aspectos que deben ser considerados antes, durante y después de la reunión de Aceptación del Plan de Proyecto. El objetivo de la reunión es obtener ya sea una decisión de aprobación o de rechazo del Plan de proyecto por parte de los participantes.

Antes de la reunion

¿Han sido invitadas a la reunión todas las personas que deben aprobar el Plan de Proyecto y pueden todas asistir?

¿Se le ha entregado un programa de la reunión a todos los participantes? ¿Se ha realizado, revisado y aprobado el Charter del Proyecto? ¿Tienen todos los participantes

una copia del Charter del Proyecto, y la han leído antes de la reunión? ¿Se ha distribuido una copia del Plan de Proyecto a todos los participantes y ha sido leída antes

de la reunión? Hay una expectativa razonable de que realizar la reunión de aceptación del Plan de Proyecto en

la fecha programada dará como resultado su aprobación? No realice la reunión si existe algún asunto o problema importante que genere dudas sobre la aprobación.

Durante la reunion

¿Se encuentran presentes todas las personas que deben aprobar el Plan de Proyecto? Si no es así, ¿su ausencia perjudica la capacidad de obtener la aprobación? (De ser así, se debe reprogramar la reunión.)

¿Han sido anotadas en la minuta de reunión todas las discusiones importantes y los puntos de acción?

¿Han sido revisados por los participantes todos los puntos de acción acordados antes de completar la reunión?

¿Se ha tomado una decisión de aprobación o rechazo? Si no se obtiene la aprobación, se han acordado todas las acciones necesarias para conseguirla

y se ha programado una próxima reunión de Aprobación del Plan de Proyecto?

183

Defensoría de los Habitantes Administración de Proyectos Informáticos PLA-LVRAPGP-02 LV Reunion Aceptacion Plan Gestion Proyecto Referencia: PLA-LVRAPGP-02 Versión: 1.0

PLA-LVRAPGP-02 LV Reunion Aceptacion Plan Gestion Proyecto v1.0 Página 2 de 2

Después de la reunion

¿Se han distribuido copias de la minuta de reunión a todos los participantes? (Es recomendable realizarlo en un plazo no mayor a 2 días después de la reunión)

¿Ha sido colocada la copia original de la minuta de reunión en el Archivo de Proyecto? ¿Se han enviado notificaciones de la próxima reunión (Si es requerida)? ¿Se han completado, revisado y cerrado los puntos de acción asignados?

184

185

4.3.1.3.3. (PLA-PGT-03) PLAN DE GESTIÓN DEL TIEMPO



PLAN DE GESTIÓN DEL TIEMPO (PLA-PGT-03)

Versión


Autor:

Mes, año

186

Defensoría de los Habitantes

Administración de Proyectos Informáticos Plan de Gestión del Tiempo Referencia: PLA-PGT-03

Versión: 1.0

PLA-PGT-03 Plan Gestión Tiempo, V1.0 Página 2 de 25

TABLA DE CONTENIDOS 1. Objetivos........................................................................................................................... 4 2. Ámbito............................................................................................................................... 4 3. Referencias ....................................................................................................................... 4 4. Funciones y Responsabilidades..................................................................................... 5 5. Entradas............................................................................................................................ 5 6. Salidas............................................................................................................................... 6 6.1. Del Proyecto....................................................................................................................... 6 6.2. De la Metodología .............................................................................................................. 6 7. Mecanismos de Control ................................................................................................... 7 8. Procedimiento .................................................................................................................. 7 8.1. Planificación del Proyecto............................................................................................... 8

8.1.1. Definición de las Actividades.............................................................................................. 8 8.1.2. Establecer la secuencia de las actividades ...................................................................... 10 8.1.3. Estimación de los recursos de las actividades ................................................................. 11 8.1.4. Estimación de la duración de las actividades ................................................................... 12 8.1.5. Desarrollar el cronograma................................................................................................ 13 8.2. Seguimiento y Control del Proyecto............................................................................. 15

8.2.1. Control del Cronograma ................................................................................................... 15 9. Herramientas y técnicas ................................................................................................ 18 9.1. EDT .................................................................................................................................. 18 9.2. Pert – CPM....................................................................................................................... 19 9.3. Diagrama de Gantt ........................................................................................................... 21 9.4. Estructura de Desglose de Recursos (RBS) .................................................................... 21 9.5. Técnicas de Estimación.................................................................................................... 23 10. Sistemas de Información relacionados ........................................................................ 23 11. Plantillas y Listas de Verificación Asociados.............................................................. 24

187



Versión: 1.0


CONTROL DE VERSIONES Fecha Versión Actualizado por Información de los Cambios Realizados

188



Versión: 1.0


PROCEDIMIENTO PLAN DE GESTIÓN DEL TIEMPO

1. Objetivos

Mediante la aplicación de este procedimiento se garantiza que todos los proyectos se inician, ejecutan y finalizan de forma ordenada y metódica para que los resultados se entreguen a tiempo (de acuerdo al Cronograma).

2. Ámbito

Este procedimiento debe seguirse en cada proyecto, independientemente del tamaño y duración del mismo.

3. Referencias

Nombre Archivo Título del Documento

Desarrollado en la Tesis Procedimiento General de Gestión de Proyectos Informáticos

No Incluido Procedimiento Ingeniería de Desarrollo de Software

PLA-PGP-01 Plan de Gestión del Proyecto

AP-GHT-01 Guía de Herramientas y Técnicas

AP-GTE-02 Guía de Técnicas de Estimación

189



Versión: 1.0


4. Funciones y Responsabilidades

Equipo de Planificación Es responsable de crear el Plan de Gestión del Tiempo, de establecer la Línea Base del Cronograma, de supervisar, controlar y documentar los cambios en el cronograma, de establecer, dar seguimiento y analizar el comportamiento de la ruta crítica a lo largo de todo el ciclo de vida del proyecto.

Equipo de Proyecto Es responsable de ejecutar la Línea Base del Cronograma, de brindar informes de avance, y de solicitar los cambios que se presenten.

Administrador de Proyectos Responsable de identificar, evaluar e implementar cambios en el Procedimiento del Plan de Gestión del Tiempo. Responsable de analizar los cambios en el cronograma.

5. Entradas

Se considera que los siguientes elementos estarán presentes como factores de entrada para el Procedimiento de Gestión del Tiempo:

• Enunciado del Alcance del Proyecto Detallado aprobado

• Estructura de Desglose del Trabajo (EDT)

• Diccionario de la EDT

• Plan de Ingeniería de Desarrollo de Software

190



Versión: 1.0


6. Salidas

6.1. Del Proyecto

Al seguir el Procedimiento de Gestión del Tiempo y en función del ciclo de vida de ingeniería de software que se seleccione, se generarán los siguientes elementos:

• WBS a nivel de paquetes de trabajo

• Lista de hitos del cronograma

• Diagrama de red del proyecto

• Estructura de desglose de Recursos (RBS)

• Recursos del Proyecto

• Calendario de Recursos

• Cronograma del proyecto – Ruta Crítica

6.2. De la Metodología

Cómo resultado de seguir el Procedimiento de Gestión del Tiempo esta metodología genera la siguiente herramienta:

• Plantilla - WBS Versión Evolutiva

• Plantilla - WBS Versión Incremental

• Plantilla - WBS Versión Cascada

191



Versión: 1.0


• Plantilla – Definición de las Actividades

• Plantilla – Recursos del Proyecto

• Plantilla – Calendario de Recursos del Proyecto

• Plantilla – Informe de Avance Semanal del proyecto

• Plantilla – Informe de Avance Mensual del Proyecto

7. Mecanismos de Control

• La Directiva del Proyecto aprueba el Programa de proyecto.

• La Directiva del Proyecto revisa los informes de Progreso del Programa, con información sobre las duraciones reales del proyecto.

8. Procedimiento

Las tareas para realizar el Plan de Gestión del Tiempo deberán concordar estrictamente con el ciclo de ingeniería de software que se seleccione (Cascada, Evolutivo, Incremental) para el proyecto, se utilizarán como insumo principal en su elaboración Procedimiento Ingeniería de Desarrollo de

Software (Fuera del alcance de esta tesis) y las Estructuras Detalladas de Trabajo (EDT) desarrolladas: Plantilla WBS – Versión Incremental (PLA-PWBSI-07), Plantilla WBS – Versión Evolutivo (PLA-PWBSE-08) y Plantilla WBS – Versión Cascada (PLA-PWBSC-09).

192



Versión: 1.0


El Plan de Ingeniería de Desarrollo de software (Fuera del alcance de esta tesis) del Proyecto, debe ser desarrollado con anterioridad a este plan, y considerará lo dispuesto en el Procedimiento de

Ingeniería de Desarrollo de Software (Fuera del alcance de esta tesis).

8.1. Planificación del Proyecto

8.1.1. Definición de las Actividades

Consiste es especificar el desglose de las labores que son necesarias para lograr los objetivos fijados. Este desglose debe efectuarse de manera particionada, bajo el esquema Top-Down, primero definiendo las actividades macro necesarias, luego las tareas incluidas dentro de cada actividad. La herramienta que mejor se acopla al desarrollo de esta sección del proceso de planificación es la que se conoce como Estructura del Desglose del Trabajo (WBS), la cual será descrita en la Guía de Herramientas y Técnicas (AP-GHT-01) de Administración de Proyectos bajo el nombre de WBS.| Las tareas que se definan deben corresponder a paquetes de trabajo que no superen los 10 días – persona, de lo contrario se corre el riesgo que la función de control del proyecto no logre detectar desviaciones o atrasos en el proyecto de manera oportuna. Este desglose de tareas debe efectuarse de manera que no se establezca el orden de ejecución de las mismas ni condicionamientos por determinados tipos de recursos, ya que estas dos características limitarían la efectividad del proceso.

193



Versión: 1.0


Al desarrollar esta sección, se debe tener presente mantener un balance en el grado de detalle de la planificación. Si el desglose de tareas:

Es muy general, aportará muy poco al proyecto y dificultará el control. Por otra parte, si el plan es demasiado detallado, complicará su confección y la

labor de mantenimiento del mismo. Para llegar a completar este desglose de tareas, se puede requerir utilizar los lineamientos que establece el Procedimiento General de Gestión de Proyectos Informáticos, descrito en esta tesis, seleccionando de esta las actividades y tareas que sean necesarias. Además, eventualmente puede ser necesario incluir o modificar una tarea del esquema metodológico, dadas las características particulares de un proyecto. En la etapa inicial, es difícil poder visualizar de manera categórica las tareas requeridas para el final del proyecto, por lo que el nivel de detalle es variable dentro del mismo plan. Lo anterior, justifica la necesidad de la actividad de planificación durante prácticamente toda la vida del proyecto en que constantemente se estará adecuando el plan conforme se tenga mayor conocimiento para poder proyectar las necesidades para el resto del desarrollo. Otro aspecto que debe ser considerado para este paso de la planificación, es que las tareas que se estipulen no sólo corresponden a aspectos técnicos. Se deben identificar todas las tareas que les correspondan a todas las áreas involucradas, así como cualquier otra entidad externa. Cada una de las tareas detectadas debe ser analizada con los ejecutores correspondientes.

194



Versión: 1.0


Al especificar este desglose de tareas, se deben identificar aquellos momentos críticos para la obtención de los resultados esperados del proyecto. Por lo general estos momentos críticos están relacionados directamente con los entregables del proyecto. El objetivo de ubicar estos momentos, conocidos como Hitos (Puntos de Control), es indicar al Líder de Proyecto y al Equipo de Proyecto cuando se deben efectuar revisiones exhaustivas de los productos intermedios, y poder aplicar las acciones correctivas que correspondan. Para estas revisiones se deben utilizar los esquemas que se describan en el Plan de Gestión de Calidad (Fuera del alcance de esta tesis).

La documentación de las actividades, los puntos de control, las entradas y salidas se realizará mediante la utilización de la Plantilla Definición de Actividades, (PLA-PDA-04).

8.1.2. Establecer la secuencia de las actividades

Teniendo el panorama completo de las tareas por efectuar, el siguiente paso es establecer las relaciones entre las diferentes tareas identificadas. Las relaciones pueden ser de cuatro tipos:

• Inicio – Inicio: Son aquellas tareas que deben iniciar necesariamente al mismo tiempo.

• Final – Inicio: Las tareas A y B tienen una relación de este tipo cuando es necesario que A concluya para que pueda iniciar la tarea B.

• Final – Final: Sucede cuando dos o más tareas deben concluir de manera simultánea.

195



Versión: 1.0


• Inicio – Fin: La finalización de la actividad sucesora depende del inicio de la actividad predecesora.

Al establecer las relaciones entre todas las tareas, automáticamente estamos obteniendo el diagrama de red de las tareas, que se explica en la Guía de Herramientas y Técnicas (AP-GHT-01) de Administración de Proyectos bajo el nombre de PERT.

8.1.3. Estimación de los recursos de las actividades

La estimación de los recursos de las actividades del cronograma involucra determinar cuáles son los recursos (personas, materiales, o equipos) y que cantidad de cada recurso se utilizará, y cuándo estará disponible cada recurso para realizar las actividades del proyecto. Los requisitos de las actividades son identificados y descritos, según el tipo y las cantidades necesarias para cada actividad del cronograma de un paquete de trabajo. Al sumarse los requisitos se obtienen los recursos estimados para cada paquete de trabajo. La documentación de los requisitos de recursos para cada actividad del cronograma se realizará mediante la utilización de la Plantilla Recursos del Proyecto (PLA-PRP-05). La documentación de la identificación de recursos humanos y materiales se realizará mediante la utilización en forma complementaria de la Plantilla Definición de Actividades, (PLA-PDA-04). Se deberá obtener la Estructura de Desglose de Recursos (RBS) la cual es una estructura jerárquica de los recursos identificados por categoría y tipo de Recurso, para conocer mejor

196



Versión: 1.0


el uso de esta herramienta referirse al punto número 9.4 de esta guía en la que se explica con detalles los objetivos y forma de implementar de esta técnica.. Cómo complemento al RBS se deberá realizar un calendario de recursos, para documentar los días laborables y no laborables que determinan aquellas fechas en las que cada recurso específico, ya sea una persona o un material, puede estar activo u ocioso, con el objetivo de identificar la cantidad disponible de cada recurso durante cada periodo de disponibilidad. La documentación del calendario de recursos del cronograma se realizará mediante la utilización de la Plantilla Calendario de Recursos, (PLA-PCRP-06).

8.1.4. Estimación de la duración de las actividades

Con el diagrama de red construida, se procede a establecer las estimaciones de tiempo en días – persona, semanas – persona o meses – persona para cada una de las tareas identificadas. Estas estimaciones se deben efectuar basados en recursos catalogados como normales, así como considerando las restricciones y condiciones de la Defensoría de los Habitantes. Es conveniente que se establezcan comparaciones con los datos estimados y reales de proyectos anteriores. Las estimaciones deben efectuarse en días – persona. En la Guía de Técnicas de Estimación (AP-GTE-02), de Proyectos Informáticos se indican algunas técnicas que pueden utilizar el Líder de Proyecto y el Equipo de Planificación para estimar las duraciones de las tareas.

197



Versión: 1.0


Al obtener el cronograma de trabajo se obtendrá la estimación de la duración total del proyecto, que servirá como insumo para el cálculo del presupuesto del proyecto. La estimación de tiempo que se realice debe ser lo más aproximada y real posible, dado que será utilizada como una de las métricas para medir el éxito del proyecto. La documentación de la estimación del tiempo de duración de las actividades se realizará mediante la utilización en forma complementaria de la Plantilla Definición de Actividades, (PLA-PDA-04). Debe de obtenerse la ruta y actividades críticas (CPM) del proyecto, cómo determinar la ruta crítica se explica en la Guía de Herramientas y Técnicas (AP-GTH-01) de Administración de Proyectos bajo el nombre de CPM.

8.1.5. Desarrollar el cronograma

El cronograma del proyecto incluye, una fecha de inicio planificada y una fecha de finalización planificada para cada actividad del cronograma. Si la planificación de recursos se realiza en una etapa temprana, el cronograma del proyecto permanecerá con carácter de preliminar hasta que las asignaciones de recursos hayan sido confirmadas, y se establezcan las fechas de inicio y de finalización planificadas.

Desarrollar el cronograma tiene como objetivo establecer la línea base del cronograma, que es una versión determinada del cronograma del proyecto desarrollada a partir del análisis de la red del cronograma del modelo de cronograma. El equipo de dirección del proyecto la

198



Versión: 1.0


acepta y la aprueba como la línea base del cronograma con fechas de inicio de línea base y fechas de finalización de línea base. La presentación del cronograma de trabajo se realizará en forma gráfica usando los siguientes formatos:

• Diagramas de red del cronograma del proyecto: Estos diagramas, con información de la fecha de la actividad, generalmente muestran tanto la lógica de la red del proyecto como las actividades del cronograma del camino crítico del proyecto. También muestra cómo se planifica cada paquete de trabajo como una serie de actividades del cronograma relacionadas. La documentación del diagrama de red del cronograma del proyecto se realizará mediante la utilización de la plantilla que corresponda al tipo de ciclo de vida de desarrollo de software que se seleccione (Incremental, Evolutivo, Cascada), Plantilla WBS – Versión Incremental (PLA-WBSI-07), Plantilla WBS – Versión Evolutivo (PLA-WBSE-08) y Plantilla WBS – Versión

Cascada (PLA-WBSC-09).

• Diagramas de Gantt: Estos diagramas, en los que unas barras representan las actividades, muestran las fechas de inicio y finalización de las actividades, así como las duraciones esperadas. Los diagramas de barras son relativamente fáciles de leer y son los que se usan más frecuentemente. La documentación del diagrama de Gantt del cronograma del proyecto se realizará mediante la utilización de la plantilla que corresponda al tipo de ciclo de vida de desarrollo de software que se seleccione (Incremental, Evolutivo, Cascada), Plantilla WBS – Versión Incremental (PLA-WBSI-07), Plantilla WBS – Versión Evolutivo (PLA-WBSE-08) y Plantilla WBS – Versión

Cascada (PLA-WBSC-09).

199



Versión: 1.0


• Diagramas de hitos: Estos diagramas son similares a los diagramas de barras, pero sólo identifican el inicio o la finalización programada de los productos entregables más importantes y las interfaces externas clave. La documentación del diagrama de Gantt del cronograma del proyecto se realizará mediante la utilización de la plantilla que corresponda al tipo de ciclo de vida de desarrollo de software que se seleccione (Incremental, Evolutivo, Cascada), Plantilla WBS – Versión

Incremental (PLA-WBSI-07), Plantilla WBS – Versión Evolutivo (PLA-WBSE-08) y Plantilla WBS – Versión Cascada (PLA-WBSC-09).

• Ruta Crítica (CPM): Debe de obtenerse un diagrama de la ruta y actividades críticas del proyecto, cómo determinar la ruta crítica se explica en la Guía de

Herramientas y Técnicas de Administración de Proyectos bajo el nombre de CPM. La documentación del diagrama de Gantt del cronograma del proyecto se realizará mediante la utilización de la plantilla que corresponda al tipo de ciclo de vida de desarrollo de software que se seleccione (Incremental, Evolutivo, Cascada), Plantilla

WBS – Versión Incremental (PLA-WBSI-07), Plantilla WBS – Versión Evolutivo

(PLA-WBSE-08) y Plantilla WBS – Versión Cascada (PLA-WBSC-09).

8.2. Seguimiento y Control del Proyecto

8.2.1. Control del Cronograma

El control del cronograma implica:

• Determinar el estado actual del cronograma de proyecto

• Influir sobre los factores que crean cambios en el cronograma

200



Versión: 1.0


• Determinar que el cronograma del proyecto ha cambiado

• Gestionar los cambios reales a medida que suceden.

El control del cronograma tiene como entrada la línea base del cronograma, que se usa para controlar el cronograma del proyecto aprobado. Proporciona la base para medir e informar el rendimiento del cronograma como parte de la línea base para la medición del rendimiento. Para determinar el estado real del proyecto se realizan informes de avance y del estado actual del cronograma, donde se incluye información sobre las fechas de inicio y finalización reales, y las duraciones restantes para las actividades del cronograma no completadas. Si se usa una medición del avance como por ejemplo, el valor ganado, también podrá incluirse el porcentaje completado de las actividades en curso del cronograma. Para facilitar el informe periódico (Diario, Semanal o Mensual) del avance del proyecto, se puede usarán plantillas creadas para un uso homogéneo a través de los diversos componentes de la organización del proyecto durante todo el ciclo de vida del proyecto, las plantillas son: Informe Actividad del Equipo de Proyecto (SEG-PIAEP-02), así como las plantillas Informe

Semanal del Progreso del Proyecto (SEG-PISPP-03), y Informe Mensual del Avance del

proyecto (SEG-PIMAP-04).

El sistema de control de cambios del cronograma define los procedimientos mediante los cuales se puede modificar el cronograma del proyecto. Incluye las plantillas, sistemas de seguimiento y niveles de aprobación necesarios para autorizar los cambios. El sistema de control de cambios del cronograma funciona bajo el Procedimiento de Gestión de Cambios, (Fuera del alcance de esta tesis). Los cambios serán documentados haciendo uso de la plantilla Solicitud de Cambios del Proyecto, (SEG-PSCP-08).

201



Versión: 1.0


La realización del análisis de variación del cronograma durante el proceso de seguimiento del cronograma constituye una función clave del control del cronograma. La comparación de las fechas del cronograma objetivo con las fechas de inicio y finalización reales / pronosticadas proporciona información útil para la detección de desviaciones y para la implementación de acciones correctivas en caso de retrasos. La variación de la holgura total es también un componente esencial de la planificación para evaluar el rendimiento del proyecto en el tiempo. El análisis de variación se puede realizar utilizando la técnica PERT – CPM descrita en la Guía de Herramientas y Técnicas (AP-GHT-01), de Administración de Proyectos donde se explica con detalle la técnica PERT – CPM.

Especial atención debe recibir la implementación de una acción correctiva, que es todo aquello que se hace para alinear el rendimiento futuro esperado del cronograma del proyecto con la línea base del cronograma del proyecto aprobada. Las acciones correctivas en el área de gestión del tiempo a menudo implican aceleraciones, que incluyen acciones especiales que se toman para asegurar la finalización de una actividad del cronograma a tiempo o con el menor retraso posible. La acción correctiva a menudo requiere un análisis causal para identificar la causa de la variación. El análisis puede contemplar actividades del cronograma distintas de la actividad del cronograma que realmente produce la desviación. Por lo tanto, se puede planificar y ejecutar la recuperación del cronograma a partir de la variación, usando actividades del cronograma delineadas con posterioridad en el cronograma del proyecto. Las acciones correctivas serán documentadas utilizando la plantilla de Acciones Correctivas (FIN-PAC-04), Para facilitar el análisis del avance del cronograma, se recomienda usar un diagrama de barras comparativo, que muestra dos barras para cada actividad del cronograma. Una barra muestra el estado real actual y la otra muestra el estado de la línea base aprobada del

202



Versión: 1.0


cronograma del proyecto. Esto muestra gráficamente dónde el cronograma ha avanzado según lo previsto o dónde se ha producido un retraso. Sistemas de Información de gestión de proyectos como Microsoft Project proporcionan vistas de este tipo con resultados muy positivos.

9. Herramientas y técnicas

9.1. EDT

La Estructura Detallada de Trabajo es una herramienta, popularmente conocida como WBS, está basada en el particionamiento Top-Down de un trabajo. Representa las actividades de todo tipo que comprende un proyecto, indicando primero actividades macro y particionando cada una de ellas hasta llegar al concepto de Paquetes de Trabajo. Por Paquetes de Trabajo se definen las unidades de trabajo que poseen entradas y salidas claras, y que por lo general no superan los 10 días –hombre. Cada paquete de estos tiene recursos, entradas, salidas y tiempo claramente identificables. La estructura del desglose del trabajo por lo general se representa de manera gráfica en una especie de organigrama, no obstante se podría encontrar también en una lista utilizando niveles de indentación. Las principales características de esta herramienta son las siguientes:

a) Particionamiento natural de un trabajo o producto. b) Los primeros niveles de la estructura por lo general son estándar.

203



Versión: 1.0


c) Es el primer paso que debe efectuar el planificador para lograr un conocimiento adecuado del proyecto y su magnitud, para así dar bases sólidas al plan.

d) Según sea la necesidad, la estructura se puede orientar al producto o al proceso de elaboración.

e) Facilita la comunicación de alcances del proyecto al equipo de trabajo y los usuarios. f) No refleja de manera directa interrelaciones entre actividades, ni la calendarización de las

mismas.

Esta herramienta es de mucha ayuda en la conceptualización de proyectos de grandes dimensiones, así como cuando existe incertidumbre sobre las tareas que deben ser ejecutadas. En la Guía de Herramientas y Técnicas (AP-GHT-01), de Administración de Proyectos se muestra la forma de uso bajo el nombre de WBS.

9.2. Pert – CPM

La herramienta PERT (Program Evaluation and Review Technique), tiene como objetivo la representación de manera gráfica de las actividades necesarias para realizar un proyecto, enfatizando en las relaciones o dependencias existentes entre cada una de estas tareas. En otras palabras, esta herramienta permite visualizar que debe ser realizado, en que orden y el tiempo que tomará el proyecto completo. El resultado es el diagrama de red del proyecto. El diagrama de red refleja claramente uno de los elementos más importantes en la administración de un proyecto, el cual se conoce con el nombre de Ruta Crítica. Este elemento se define como el camino más largo (en duración) desde el inicio del proyecto hasta su finalización. La importancia de identificar la ruta crítica radica en que, cualquier alteración en las tareas incluidas en esta ruta tiene implicaciones directas en la duración del proyecto.

204



Versión: 1.0


Desde el punto de vista del control del proyecto, el diagrama de red es una herramienta de mucho valor, pues permite visualizar de manera completa un proyecto y poder ensayar diferentes escenarios para la toma de decisiones. No obstante, el PERT es más recomendado para el control macro del proyecto, para la proyección de modificaciones o decisiones importantes, no para el control del avance cotidiano. Para este último aspecto es mejor utilizar la herramienta Gantt explicada en la Guía de Herramientas y Técnicas (AP-GHT-01) de Administración de Proyectos bajo el nombre de GANTT. Las principales características de esta herramienta se resumen a continuación:

a) La ruta crítica indica cuales son las tareas, que en caso de sufrir atraso perjudicarían el proyecto en su totalidad y por complemento señala también las tareas que de sufrir un atraso controlado no afectarán la duración total del proyecto, es decir las que presentan holgura.

b) No muestra entradas y salidas entre tareas, sino su dependencia o relación lógica. c) Permite efectuar simulaciones ante variaciones de recursos, tiempo o tareas. d) No refleja, en su forma normal, la concurrencia de tareas ni el nivel de saturación de

recursos.

La elaboración y mantenimiento del diagrama de red es requisito para la planificación y seguimiento del proyecto, por lo que el Líder y el Equipo de Proyecto deben estar en constante evaluación de la misma. En los diagramas de este tipo que se desarrollen se debe identificar con claridad la ruta crítica del proyecto. En la Guía de Herramientas y Técnicas (AP-GHT-01) de Administración de Proyectos se muestra la forma de uso bajo el nombre de PERT.

205



Versión: 1.0


9.3. Diagrama de Gantt

La gráfica tipo GANTT es la herramienta más utilizada y difundida en la planificación y control de proyectos. Su principal fortaleza es la simplicidad y facilidad de elaboración. No obstante, no es recomendable su utilización para la visualización completa de proyectos grandes, ya que sus gráficos pueden tornarse muy difíciles de manejar. Su proceso de confección consiste en la determinación de las tareas por ejecutar (tomadas de la WBS) y su colocación en secuencia lógica en un gráfico de barras horizontales, con la variable de tiempo en el eje de las X. Las principales características de esta herramienta son:

a) Muestra claramente la concurrencia de actividades, con lo cual se puede evaluar fácilmente la utilización de recursos en un punto del tiempo.

b) La herramienta muestra fácilmente la planificación y el avance de forma simultánea. c) No se visualizan las entradas y salidas que requiere y genera determinada tarea.

En la Guía de Herramientas y Técnicas (AP-GHT-01) de Administración de Proyectos se muestra la forma de uso bajo el nombre de GANTT.

9.4. Estructura de Desglose de Recursos (RBS)

Resource Breakdown Structure (RBS), por sus siglas en inglés. Esta técnica de organización de proyectos software tiene por objeto representar la organización humana del proyecto, su estructura, responsabilidades, etc.; así como la estructura de recursos tecnológicos y materiales.

206



Versión: 1.0


El RBS es un árbol jerárquico que representa los recursos humanos y materiales del proyecto. Los principales objetivos del RBS son los siguientes:

1. Mostrar gráficamente la organización (humana) del proyecto (Organigrama). 2. Maximizar el uso de los conocimientos y experiencia del personal disponible. 3. Reflejar la estructura de recursos materiales necesarios para la realización del proyecto

(herramientas, plataformas, etc.), así como sus costes asociados.

Figura N° 7: Estructura de Desglose de Recursos (RBS) El RBS puede representarse de modo que se puedan observar por separado los recursos con los que cuenta la propia organización y por otro lado los recursos son los que se va contar del lado del cliente, para el cual se está llevando a cabo el proyecto.

207



Versión: 1.0


Figura N° 8: RBS de recursos propios

9.5. Técnicas de Estimación

El proceso de estimación de software esta descrito en la Guía Técnicas de Estimación (AP-GTE-02), de Administración de Proyectos donde se explica con detalles diferentes técnicas para calcular duraciones de actividades, tamaño y esfuerzo de los proyectos.

10. Sistemas de Información relacionados

• Microsoft Project: Este software, Microsoft Corporation, ayuda a crear y dar seguimiento a planes de proyecto, a administrar programas y recursos, y a analizar eficientemente la información del Proyecto.

208



Versión: 1.0


• WBS Chart Pro: Este software de Critical Tools, ayuda a elaborar el WBS en forma gráfica, se le pueden incluir costos y duraciones, además la interfase con el Microsoft Project permite elaborar el programa.

11. Plantillas y Listas de Verificación Asociados

Nombre del Archivo Título del Documento

PLA-PWBSI-07 Plantilla – WBS Versión Incremental

PLA-PWBSE-08 Plantilla – WBS Versión Evolutiva

PLA-PWBSC-09 Plantilla – WBS Versión Cascada

PLA-PDA-04 Plantilla – Definición de las Actividades

PLA-PRP-05 Plantilla - Recursos del Proyecto

PLA-PCRP-06 Plantilla - Calendario de Recursos del Proyecto

SEG-PIAEP-02 Plantilla - Informe Actividad del Equipo de Proyecto

SEG-PISPP-03 Plantilla - Informe de Avance Semanal del proyecto

SEG-PIMAP-04 Plantilla - Informe de Avance Mensual del Proyecto

SEG-PSCP-08 Plantilla - Solicitud de Cambios del Proyecto

FIN-PAC-04 Plantilla - Acciones Correctivas

Fin del Documento

209



Versión: 1.0









210

211

4.3.1.3.4. (PLA-PDA-04) PLANTILLA - DEFINICIÓN DE ACTIVIDADES

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla – Definición de las Actividades Referencia: PLA-PDA-04 Versión: 1.0

PLA-PDA-04 Definición de las Actividades, V1.0 Página 1 de 1

DEFINICIÓN DE ACTIVIDADES DE LA EDT

Esta plantilla deberá ser completada en forma complementaria por las actividades del Plan de Gestión del Tiempo:

1. Definición de actividades

2. Estimación de los recursos de las actividades

3. Estimación de la duración de las actividades

Definición de actividades de la Estructura Detallada de Trabajo (EDT) Información General de la actividad Id: <número> EDT #: <Número del

esquema>

Nombre de la actividad: <Escribir el nombre de la actividad>

Descripción: <Indicar en que consiste la actividad>

Entradas: <Indicar cuales son los productos requeridos para iniciar>

Salidas: <Indicar cuales son los productos al terminar>

Puntos de control: <Indicar como verificara el avance>

Responsable (s): <Nombre(s) apellido (s) 1 apellido (s) 2>

Recursos Materiales: <Indicar cuales son los recursos materiales necesarios>

Sub-contrataciones: <indicar si existe alguna subcontratacion>

Estimaciones de la actividad

Trabajo <Horas Hombre> Costo Final: <Escribir en dólares, colones o en horas>

Duración: <Dias, mes, etc>

Fecha Inicio:

<dd/mm/aaaa> Fecha Término:

<dd/mm/aaaa>

Líder del Proyecto:

___________________________________

Firma y fecha

Proyecto: <Nombre del Proyecto>

212

213

4.3.1.3.5. (PLA-PRP-05) PLANTILLA - RECURSOS DEL PROYECTO

Administración de Proyectos Informáticos Página 1 de 1

:

Plantilla Recursos del ProyectoNOMBRE DEL PROYECTO:DIRECTOR DEL PROYECTOPATROCINADOR:

Paquete de Trabajo Nombre del Recurso Clasificacion Funcion en el proyecto

Criterio de éxito de la persona Cantidad Disponibilidad

<Nombre Actividad><Nombre del

Recurso> <Rol> <Criterio de exito> <#######> < %>





















PLA-PRP-05 Plantilla Recursos del Proyecto, V 1.0 1 de 1

214

215

4.3.1.3.6. (PLA-PCRP-06) PLANTILLA - CALENDARIO DE RECURSOS

Calendario de Recursos del Proyecto Página 1 de 2

Celdas AZUL = celdas para datos de entrada Noviembre Diciembre Enero Febrero

EDT Tareas RH Cantidad Inicio Plan Fin Plan Dias Hrs. 11/1 11/8 11/15 11/22 11/29 12/6 12/13 12/20 12/27 1/3 1/10 1/17 1/24 1/31 2/7 2/14 2/21 2/28

1 Nombre del proyecto 67361,1 Plan y supervision1.1.1 Supervision An. 9 30-Oct-04 30-Oct-05 240 1920 1 1 1 1 1 1 1 1 1 11.1.2 Plan - fase 1 Prog. 8 01-Nov-04 01-Dic-04 10 80 1 11.1.3 Plan - fase 2 Adm. 7 01-Nov-04 02-Nov-04 15 120 1 1 11.1.4 Control del costo Ofic. 5 02-Nov-04 03-Nov-04 215 1720 1 1 1 1 11.1.5 Aesoria Prog. 4 03-Nov-04 04-Nov-04 20 160 1 1 1 11.1.6 Admon de entregas An. 2 04-Nov-04 05-Nov-04 60 480 1 11,2 Siguiente Entrega del EDT 0

Ejemplo tarea A 125 1000Ejemplo tarea B 85 680Ejemplo tarea C 45 360Tarea 1 8Tarea 1 8

Siguiente Entrega del EDTTarea 1 8Tarea 1 8Tarea 1 8Tarea 1 8Tarea 1 8





Las barras muestran la disponibilidad de los recursos

PLA-PCRP-06 Calendario de Recursos del Proyecto 22/11/2007 Versión 1.0

216

Oz

Tachado

217

4.3.1.3.7. (PLA-PWBSI-07) PLANTILLA – WBS INCREMENTAL

PLA-PWBSI-07 WBS Incremental Proyecto Aprobado Inicio y Planificación

Crear Charter del ProyectoAprobar Charter del ProyectoDefinir Criterios de Aceptación del ProyectoAprobar Criterios de Aceptación del ProyectoCrear Plan de ProyectoReunión de Aceptación del Plan de ProyectoOtras Actividades deInicio y PlaneaciónReunión de Aceptación de fase

Especificación deRequerimientos

Análisis de RequerimientosPrototipoCrear Documento de Especificación de RequerimientosAprobar Especificación de RequerimientosCrear Plan de Pruebas de Integración (PI)Aprobar Plan de PIReunión de Aceptación de Fase

DiseñoArquitectónico

Crear Especificaciones de Diseño Arquit.Aprobar Espeficaciones de Diseño Arquit.Reunión de Aceptación de Fase

Iteracción 1

Diseño Detallado

Crear Especificaciones de Diseño DetalladoAprobar Diseño DetalladoReunión de Aceptación de Fase

Pruebas deCodificación (CD) y

Unitarias (UT)

CD and UT Unidad 1Aprobar Undiad 1CD and UT Unidad 2Aprobar Undiad 2Reunión de Aceptación de Fase

Pruebas deIntegración

Completar Plan de Pruebas de IntegraciónDirigir Pruebas de IntegraciónReunión de Aceptación de Fase

Instalación y Entrega

Prueba de AceptaciónInstalaciónFirma de Aceptación de la Iteracción Reunión de Aceptación de Fase

Iteracción 2

Diseño detallado

Actualizar Especificaciones de Diseño DetalladoAprobar Diseño Detalladoreunión de Aceptación de Fase

Pruebas deCodificación (CD) y

Unitarias (UT)

CD and UT Unidad 3Aprobar Unidad 3CD and UT Unidad 4Aprobar Unidad 4Reunión de Aceptación de Fase




Pruebas de AceptaciónInstalaciónFirma de Aceptación del ProyectoReunión de Aceptación de Fase

Cierre de Proyecto

Reunión de Revisiónde ProyectoCrear Reporte de Revisión de ProyectoAprobar Reporte de Revisión de ProyectoOtras Actividades deCierre

Proyecto Completado

Administración deProyectos

Actividades de Ejecución

Aseguramiento de laCalidad

Actividades de PlanificaciónActividades de EecuciónOtras Activiadades de Cierre

Administración de laConfiguración

Actividades de PlanificaciónActividades de EjecuciónActividades de Cierre

218

219

4.3.1.3.8. (PLA-PWBSE-08) PLANTILLA – WBS EVOLUTIVO

PLA-PWBSE-08 WBS EvolutivoProyecto Aprobado Inicio y Planeación

Crear Charter de ProyectoAprobar Charter de ProyectoDefinir Criterios de Aceptación del proyectoAprobar Criterios de AceptaciónCrear Plan de ProyectoReunión de Aceptación de Plan de ProyectoOtras Actividades de Inicio y PlanificaciónReunión de Aceptación de Fase

Iteracción 1


Análisis de RequerimientosPrototipoCrear Documento de Especif. De RequerimientosAprobar Especificación de RequerimientosCrear Plan de Pruebas de Integración (PI)Aprobar Plan de PIReunión de Aceptación de Fase


Crear Especificaciones de Diseño Arquit.Aprobar Especificaciones de Diseño Arquit.Reunión de Aceptación de Fase

Diseño Detallado

Crear Especificaciones de Diseño DetalladoAprobar Diseño DetalladoReunión de Aceptación de Fase

Pruebas de Código(CD) y Unitarias (UT)

CD and UT Unidad 1Aprobar Unidad 1CD and UT Unidad 2Aprbar Undiad 2Reunión de Aceptación de Fase



Instalación yEntrega

Pruebas de AceptaciónInstalaciónFirma de Aceptación de la IteracciónReunión de Aceptación de Fase

Iteracción 2


Análisis de RequerimientosPrototipoActualizar Doc. de Espefic. de Requerimient.Aprobar Especificación de RequerimientosActualizar Plan de Pruebas de Integración (PI)Aprobar Plan de PIReunión de Aceptación de Fase


Actualizar Especificaciones de Diseño Arquit.Aprobar Especificaciones de Diseño Arquit.Reunión de Aceptación de Fase

Diseño Detallado

Actualizar Especificaciones de Diseño DetalladoAprobar Diseño DetalladoReunión de Aceptación de Fase

Pruebas de Código(CD) y Unitarias (UT)




Instalación yEntrega

Pruebas de AceptaciónInstalaciónFirma de Aceptación de ProyectoReunión de Aceptación de Fase

Cierre de Proyecto

Reunión de Revisión de ProyectoCrear Reporte de Revisión de ProyectoAprobar Reporte de Revisión de ProyectoOtras Actividades de Cierre

Proyecto Completado




Planificación de ActividadesActividades de EjecuciónActividades de Cierre


Planificación de ActividadesActividades de EjecuciónActividades de Cierre

220

221

4.3.1.3.9. (PLA-PWBSC-09) PLANTILLA – WBS CASCADA

PLA-PWBSC-09 WBS CascadaProyecto Aprobado Inicio y Planeación

Crear Charter de ProyectoAprobar Charter de ProyectoDefinir Criterios de Aceptación del ProyectoAprobar Criterios de Aceptación del ProyectoCrear Plan de ProyectoReunión de Aceptación del Plan de ProyectoOtras Actividades de Inicio y PlaneaciónReunión de Aceptación de Fase


Analisis de RequerimientosPrototipoCrear Documento de Especif. De RequerimientosAprobar Especificación de RequerimientosCerar Plan de Pruebas de Integración (PI)Aprobar Plan de PIReunión de Aceptación de Fase


Crear especificaciones de Diseño Arquit.Aprobar Especificaciones de Diseño Arquit.Reunión de Aceptación de Fase

Diseño Detallado

Crear Especificaciones de Diseño DetalaldoAprobar Diseño DetalladoReunión de Aceptación de Fase

Pruebas de Codigo(CD) y Unitarias (UT)


Prubas deIntegración



Pruebas de AceptaciónInstalaciónFirma de Aceptación de ProyectoReunión de Aceptación de Fase

Cierre de Proyecto

Reunión de Revisión de ProyectoCrear Reporte de Revisión de ProyectoAprobar Reporte de Revisión de ProyectoOtras Actividades de Cierre

Proyecto Completado




Actividades de PlaneaciónActividades de EjecuciónCierre de Actividades


Actividades de PlaneamientoActividades de EjecuciónCierre de Actividades

222

223

4.3.1.4. PLANTILLAS DE SEGUIMIENTO Y CONTROL DE PROYECTOS

224

4.3.1.4.1. (SEG-LVSCP-01) LISTA DE VERIFICACIÓN – SEGUIMIENTO Y CONTROL DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos Lista de Verificación – Seguimiento y Control del Proyecto Referencia: SEG-LVSCP-01 Versión: 1.0

SEG-LVSCP-01 LV Seguimiento Control Proyecto, v1.0 Página: 1 de 2

LISTA DE VERIFICACIÓN - SEGUIMIENTO Y CONTROL DEL PROYECTO Esta lista de Verificación resalta aquellos asuntos que deben tenerse en cuenta antes de iniciar la ejecución del proyecto y por tanto el seguimiento y control del proyecto (los “criterios de entrada”), durante la ejecución el seguimiento y control del proyecto (las “actividades en activo”) y antes de que se considere finalizado el seguimiento y control del proyecto (los “criterios de salida”).

Criterios de entrada (a la ejecución)

¿Existe una versión completa, revisada y aprobada del Plan de Gestión del Proyecto (incluyendo las estimaciones de trabajo, programación y personal) y cualquier plan asociado (por ejemplo: Plan de de Gestión de Riesgos, Plan de Gestión del Alcance, Plan de Gestión de Costes, etc.)?

¿Se ha identificado y asignado los miembros del equipo del proyecto? Si no se han asignado algunos recursos, ¿hay un plan preparado para conseguirlos antes de que sean necesarios?

¿Se han identificado y asignado personas o equipos de soporte (por ejemplo, control de calidad, gestión de configuración, comprobación, documentación, administración, etc.)? Si no se han asignado algunos recursos, ¿existe un plan para conseguirlos antes de que sean necesarios?

¿Se ha establecido y comunicado a todos los miembros del equipo el proceso y método de imputación y contabilización de los tiempos asignados del proyecto?

¿Se ha establecido y comunicado a todos los miembros del equipo el proceso y método y la periodicidad de envío de los informes de “estado” al Líder del Proyecto?

¿El Líder de Proyecto ha establecido y comunicado a la Directiva del proyecto el proceso y método de envío y distribución de los informes de progreso del proyecto?

Actividades en activo (control y seguimiento)

¿Envían los miembros del equipo las hojas de tiempo semanales correctamente según el proceso de imputación del tiempo del proyecto y las revisa el responsable del proyecto puntualmente?

¿Envían todos los miembros de equipo correctamente los informes de estado semanales y los revisa el Líder del proyecto puntualmente?

¿Se celebran reuniones del equipo del proyecto regularmente (por ejemplo, semanalmente) para revisar el progreso del proyecto e identificar problemas y riesgos?

¿Se envían informes de progreso del proyecto a la Directiva del proyecto regularmente y los revisa la directiva del proyecto puntualmente?

225

Defensoría de los Habitantes Administración de Proyectos Informáticos Lista de Verificación – Seguimiento y Control del Proyecto Referencia: SEG-LVSCP-01 Versión: 1.0

SEG-LVSCP-01 LV Seguimiento Control Proyecto, v1.0 Página: 2 de 2

¿Se realiza un seguimiento del trabajo, programación, coste y recursos críticos del proyecto y se informa de forma precisa en cada informe de progreso del proyecto?

¿Se generan, evalúan y aprueban informes de problemas cuando sea necesario de acuerdo con el Procedimiento de Gestión de Emergencias y Problemas? (Fuera del Alcance de esta Tesis) ¿Se realizan las acciones apropiadas con respecto a estos problemas del proyecto y se cierran puntualmente?

¿Se generan, evalúan y aprueban solicitudes de cambio cuando sea necesario de acuerdo con el Procedimiento de Gestión de Cambios? (Fuera del Alcance de esta Tesis) ¿Se realizan las acciones apropiadas con respecto a estas solicitudes de cambio y se cierran puntualmente?

Al final de cada fase, ¿se celebra una reunión de aceptación de fase para asegurar el proyecto con respecto a los criterios de entrada o salida de la fase y para aceptar y aprobar formalmente los productos generados y/o entregables de la fase?

¿Revisa periódicamente el Líder del proyecto los riesgos del proyecto? ¿Se informa a la Directiva del proyecto de cualquier cambio (bueno o mal) de la “lista de riesgos” del proyecto en los informes de progreso del proyecto?

¿Está volviendo a calcular el responsable del proyecto, con la ayuda de los miembros del equipo, el proyecto en los puntos planificados previamente en la programación del proyecto o según sea necesario cuando se produzca un cambio?

¿Realiza actualizaciones el Líder del proyecto según el Plan de Gestión del Proyecto para la revisión y aprobación por parte de la Directiva del proyecto siempre que se cumplan los criterios de planificación del proyecto?

¿Realiza el Responsable de calidad regularmente una auditoría de la gestión del proyecto y de las actividades de ingeniería y prueba los productos para verificar que cumplen las condiciones de la gestión del proyecto de la Defensoría y de los procesos de desarrollo de software? ¿Se informa de cualquier cumplimiento o problema de calidad al Líder del proyecto?

¿Se mantiene actualizado el archivo del proyecto?

Criterios de salida (final de la ejecución)

¿Se han completado todos los productos entregables del proyecto y están controlado en la biblioteca de la configuración? ¿los ha aceptado el cliente formalmente? y ¿se han enviado el producto o sistema al Área Usuaria?

¿Se han incluido en el archivo del proyecto copias de todos los informes y documentos? Esto incluye todos los informes de progreso, actualizaciones oficiales del Plan de Gestión del Proyecto, informes de problemas, solicitudes de cambio, formularios del contenido de la reunión y cualquier documento generado como parte del trabajo del proyecto.

226

227

4.3.1.4.2. SEG-PIAEP-02 PLANTILLA - INFORME ACTIVIDAD DEL EQUIPO DE PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos Informe de Actividad del Equipo de Proyecto Referencia: SEG-PIAEP-02 Versión: 1.0

SEG-PIAEP-02 Informe Actividad Equipo Proyecto, v1.0 Página 1 de 1

INFORME DE ACTIVIDAD DEL EQUIPO DE PROYECTO

El Informe Actividad del Equipo de Proyecto se utiliza para registrar el progreso de la semana actual y el plan de actividad para la siguiente semana. Cada persona del equipo realizará su informe.

Nombre del proyecto:

Nombre del miembro:

Fecha:

Realizado esta semana:

<Mostrar las tareas completadas esta semana.>

Planificado, pero no realizado:

<Mostrar las tareas planificadas para esta semana, pero que no se pudieron realizar.>

Planificado para la próxima semana:

<Mostrar las tareas planificadas para la próxima semana.>

Problemas / comentarios:

<Especificar cualquier problema que pudiera evitar que se completaran las tareas planificadas para la semana siguiente.>

228

229

4.3.1.4.3. (SEG-PISPP-03) PLANTILLA – INFORME SEMANAL DEL PROGRESO DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Informe Semanal del Progreso del Proyecto Referencia: SEG-PISPP-03 Versión: 1.0

SEG-PISPP-03 Informe Semanal Progreso Proyecto, V1.0 Página 1 de 3 Proyecto: <Nombre del Proyecto>

INFORME SEMANAL DEL PROGRESO DEL PROYECTO

El presente informe recoge los avances alcanzados en el proyecto de referencia durante el periodo de tiempo indicado:

Líder del Proyecto (nombre )

Fecha (A) del Informe


Cuenta de Gastos:

Periodo del informe:

De: Hasta:

Realizaciones <Mostrar los logros del proyecto durante el periodo del informe.>

Objetivos para el siguiente periodo del informe <Mostrar los objetivos del proyecto para el siguiente periodo.>

230



Problemas Problemas dentro del control del Líder del Proyecto <Especificar los temas encontrados que están bajo el control del Líder del Proyecto.>

Problemas fuera del control del Líder de proyecto <Especificar los problemas encontrados que están fuera del control del Líder del Proyecto.>

Resumen del progreso hasta la fecha (A): dd/mm/aa

Trabajo Nombre de la Fase % Estimado en plan % realizado % Variación

Plan (nivel proyecto)

Fecha de inicio previsto

Fecha de inicio revisada

Fecha final prevista

Fecha final

revisada

Estado (en ejecución, parado, pendiente de aceptación de

entregables)

231



CONTROL ECONÓMICO

Resumen a la fecha (A) de: (dd/mm/aa)

Partida básica de la Oferta

Importe de coste según planificación

inicial (Plan Proyecto), a la fecha (A).

Importe de coste real

imputados a la fecha (A)

Desviación a la fecha (A)

Mano de Obra propia de la Defensoría

Compras de materiales de equipamiento de redes

Compra de plataformas Hardware/Software y licencias Software

Compras de servicios realizados por otras empresas

Gastos varios (viajes, viáticos, etc)

TOTALES

(1): Estimación de costes obtenido del Plan de Gestión del Proyecto (planificación inicial), en relación a la fecha (A) de emitir informe de avance.

Líder del Proyecto:

___________________________________

Firma y fecha

---------------- Fin del Informe ----------------------

232

233

4.3.1.4.4. (SEG-PIMAP-04) PLANTILLA - INFORME MENSUAL DEL AVANCE DEL PROYECTO

IINNFFOORRMMEE MMEENNSSUUAALL DDEE AAVVAANNCCEE DDEELL <<DDDD//MMMM//AAAA>> AALL <<DDDD//MMMM//AAAA>> PPRROOYYEECCTTOO <<NNOOMMBBRREE DDEELL PPRROOYYEECCTTOO>>

SEG-PIMAP-04 Informe Mensual de Avance del proyecto, V1.0 Página. 1 de 3

El presente informe semanal representa el estado actual del proyecto xxxx, contempla los logros o hitos alcanzados y los problemas presentados durante la ejecución en el período comprendido entre el dd/mm/aa y el dd/mm/aa. Preparado por:

Rol Nombre Firma Fecha Líder del proyecto Administrador del proyecto

ESTE DOCUMENTO SE DISTRIBUYE A:

Nombre Área Puesto

1. Información general y estado del proyecto

Fecha de inicio: dd/mm/aa Fecha base de finalización dd/mm/aa Fecha estimada actual de finalización dd/mm/aa Estado del proyecto <Color>

Verde: No existen desviaciones en la ejecución de las actividades, ni problemas ni riesgos que impacten la finalización a tiempo del proyecto. Amarillo: Se han dado desviaciones o presentado problemas o riesgos que pueden impactar la finalización. Se pueden tomar acciones para no impactar la fecha de finalización. Rojo: Se presentaron desviaciones en el plan de trabajo, o se materializaron riesgos que impactan la fecha de finalización.

234



2. Avance del proyecto en el período reportado (Describir en detalle el estado actual del proyecto con sus principales logros obtenidos, hitos concluidos y actividades concluidas.) 3. Logros Obtenidos Durante el Período Reportado 3.1 Actividades y tareas concluidas en el período reportado: WBS Actividad /

Tarea Fecha base Inicio

Fecha real

inicio

Fecha base finalización

Fecha real finalización

Desfase días

hábiles

Responsable Comentarios

3.2 Hitos finalizados en el período reportado:

Entregable Fecha estimada aceptación

Fecha real aceptación

Desfase días hábiles

Comentarios

3.3 Problemas o riesgos resueltos en el período reportado:

ID Problema/Riesgo Fecha Resolución Comentarios

3.4 Otros logros obtenidos en el período reportado (opcional):

Logro Fecha Logro

Comentarios

4. Problemas Presentados en el Período Reportado

Problema Responsable Impacto (días) Acción Estado

235



5. Descripción de Riesgos del Proyecto A continuación se incluyen los principales 10 riesgos del proyecto.

ID Estado Fecha

Ident. Descripción riesgo Dueño Acción Propuesta Impacto (días)

Fecha Cierre

006 Amarillo 001 Verde

Verde: Riesgo que a la fecha del presente informe se mantiene bajo control. Amarillo: Es un riesgo que requiere atención y podría afectar al proyecto, debiéndose activar las acciones de mitigación. Rojo: Es un riesgo que se dio y se requiere ejecutar las acciones de contingencia de inmediato.

6. Actividades en Proceso al Cierre del Período Reportado

WBS Actividad Base Inicial

Base Final Inicio Real

Final Proyectado

Responsable %

7. Objetivos para el Próximo Período a Reportar 7.1 Actividades y tareas a ser concluidas en el próximo período:

WBS Actividad/Tarea Responsable Fecha Finalización

Estimada

Estado Comentarios

7.2 Hitos a entregar en el próximo período:

Entregable Responsable Fecha Estimada Aceptación

Estado Comentarios

7.3 Problemas o riesgos a ser resueltos en el próximo período:

ID Problema/Riesgo Responsable Fecha Finalización Estado Comentarios

8. Anexo Cronograma actualizado del Proyecto

236

237

4.3.1.4.5. (SEG-PRAFEP-05) PLANTILLA - REUNIÓN DE ACEPTACIÓN DE FASES/ETAPAS DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Reunión de Aceptación de Fases/Etapas del Proyecto Referencia: SEG-PRAFEP-05 Versión: 1.0

SEG-PRAFEP-05 Reunion Aceptacion Fases Etapas Proyecto, v1.0 Página: 1 de 2

SEG-PRAFEP-05 REUNIÓN DE ACEPTACIÓN DE FASES/ETAPAS DEL PROYECTO/ETAPAS DEL PROYECTO

El Formulario de la Reunión de Aceptación de Fases/Etapas se utiliza para registrar el contenido de la reunión y las decisiones de aceptación para las revisiones de aceptación de fases del proyecto.


Fase o etapa de revisión:

Fecha y hora de la reunión:

Lugar de la reunión:

Resultado de la revisión:

��Aprobado ��Aprobado condicional ��Aplazado Comentarios:

Material Revisado <Especificar los materiales revisados.>

Comité de revisión Moderador: Acta de la reunión, realizada por: Asistentes por Proyecto: <Escribir los nombres de los asistentes.>

Asistentes por Área Usuaria: <Escribir los nombres de los asistentes.>

238

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Reunión de Aceptación de Fases/Etapas del Proyecto Referencia: SEG-PRAFEP-05 Versión: 1.0

SEG-PRAFEP-05 Reunion Aceptacion Fases Etapas Proyecto, v1.0 Página: 2 de 2

Actas de la reunión de revisión

Notas/elementos de acción Asignado a: Fecha fin de ejecución

Cerrado

239

240

4.3.1.4.6. (SEG-LVRAFEP-06) LISTA DE VERIFICACIÓN – REUNIÓN DE ACEPTACIÓN DE FASES/ETAPAS DEL PROYECTO.

Defensoría de los Habitantes Administración de Proyectos Informáticos LV Reunión de Aceptación de Fases/Etapas del Proyecto Referencia: SEG-LVRAFEP-06 Versión: 1.0

SEG-LVRAFEP-06 LV Reunion Aceptacion Fases Etapas Proyecto, v1.0 Página: 1 de 2

SEG-LVRAFEP-06 LV REUNIÓN DE ACEPTACIÓN FASES/ETAPAS PROYECTOS/ETAPAS DEL PROYECTO

Esta lista de comprobación resalta aquellos elementos que deben tenerse en cuenta antes, durante y después de una reunión de aceptación de fase. El objetivo de una reunión de aceptación de fase es verificar y confirmar que se cumplen todos los criterios de salida de la fase, tal y como se especifican en el ciclo de producción seleccionado o el Plan de Gestión del Proyecto y, por tanto que se puede considerar finalizada la fase.

Antes de la reunión

¿Se ha invitado a la reunión a todas las personas que deben aceptar la finalización de la fase? Entre los asistentes se debe incluir al Líder de proyecto, la Directiva del proyecto (en la que podrá estar incluido el Área usuaria) y el Responsable de calidad.

¿Se ha facilitado una agenda de la reunión a todos los asistentes? ¿Se ha facilitado a todos los asistentes antes de la reunión una copia de los criterios de entrada

o salida de la fase? ¿Se han facilitado a todos los asistentes copias de los productos generados y/o entregables de

la fase (cuando corresponda) o al menos un resumen de los productos de la fase y su estado? ¿Han leído los asistentes el material proporcionado antes de la reunión?

¿Se ha facilitado a todos los asistentes antes de la reunión información actualizada acerca de la lista de riesgos, presupuesto, planificación y registro de problemas para revisar?

¿Existe una expectación razonable de que se aceptará la celebración de la reunión de aceptación de fase en la fecha prevista? No debe celebrarse la reunión si se producen problemas extraordinarios en cuanto a la aceptación.

Durante la reunión

¿Están presentes todas las personas que deben aceptar la fase? Si no es así, ¿su ausencia va a poner en peligro la posibilidad de conseguir la aceptación? (Si es así, se debe volver a programar la reunión).

¿Ha revisado el Líder del Proyecto los criterios de entrada o salida con los asistentes? y ¿se ha acordado que se cumple cada elemento de los criterios de salida (o se puede cumplir si se tratan los elementos de acción documentados)?

¿Se han revisado y discutido la lista de riesgos actuales, presupuesto y registro de problemas?

241

Defensoría de los Habitantes Administración de Proyectos Informáticos LV Reunión de Aceptación de Fases/Etapas del Proyecto Referencia: SEG-LVRAFEP-06 Versión: 1.0

SEG-LVRAFEP-06 LV Reunion Aceptacion Fases Etapas Proyecto, v1.0 Página: 2 de 2

¿Se han tratado durante la reunión todos los temas y acciones importantes? ¿Han revisado los asistentes los elementos de acción registrado antes de finalizar la reunión? ¿se ha tomado una decisión de aceptación y se ha registrado en el Formulario de la Reunión de

Aceptación de la Fases/Etapas del Proyecto? Si no se obtiene la aceptación, ¿se han registrado las acciones necesarias y se ha programado

una reunión de aceptación de fase de seguimiento?

Después de la reunión

¿Se han distribuido a todos los asistentes copias del contenido de la reunión (mediante el Formulario de Reunión de Aceptación de Fases/Etapas del proyecto)? (Se recomienda hacerlo en el primer o segundo día de la reunión.)

¿Se ha incluido la copia original del contenido de la reunión en el Archivo del Proyecto? ¿Se ha informado de la reunión de seguimiento (si corresponde)? ¿Se han finalizado, revisado y cerrado los elementos de acción asignados?

242

243

4.3.1.4.7. (SEG-PIEPP-07) PLANTILLA - INFORME DE EMERGENCIAS/PROBLEMAS DEL PROYECTO

Nota Nº Fecha :

Administración de Proyectos Informáticos

Informe de Emergencia/Problema del

Proyecto

Autor :

SEG-PIEPP-07 Informe Emergencias/Problemas Proyecto, v1.0 Página 1 de 3

Código del problema:

Referencia: <Explicar brevemente el problema, anotar los principales temas implicados.>

Versión:

Localización del problema:

<Describir el entorno en el que se produjo el problema.>

Descripción del problema: <Describir el problema de forma detallada.>

Solución recomendada por el autor: <Describir los pasos recomendados para solucionar el problema.>

Gravedad:

Baja Media Alta

Conocimiento del problema: Fecha: <Recomendaciones de la Directiva del Proyecto sobre el problema.>

244

Nota Nº Fecha :



Proyecto

Autor :


Responsable del problema:

Fecha de asignación: Involucra cambios: Sí No Proceso afectado:

Urgencia:

___________________________ _______________________________

Líder del Proyecto Aprobación de Directiva del proyecto Seguimiento del problema: Acción correctiva realizada <Especificar qué se ha hecho para corregir el problema.>

Cambios realizados <Describir qué cambios se han realizado para corregir el problema.>

245

Nota Nº Fecha :



Proyecto

Autor :


Resolución del problema: <Describir los pasos efectivos que se realizaron para solucionar el problema.>

Módulos cambiados: Tablas cambiadas: Documentos cambiados:

Entorno de prueba cambiado:

Cierre del Problema: Fecha:

___________________________ _______________________________

Líder del Proyecto Responsable del Problema

Estado del Problema: CERRAR SEGUIR ACCION

246

247

4.3.1.4.8. (SEG-PSCP-08) PLANTILLA - SOLICITUD DE CAMBIOS DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Solicitud de Cambio del Proyecto Referencia: SEG-PSCP-08 Versión: 1.0

SEG-PSCP-08 Solicitud Cambio Proyecto, v1.0 Página: 1 de 4 Proyecto: <nombre del proyecto>

SEG-PSCP-08 SOLICITUD DE CAMBIO DEL PROYECTO DEL PROYECTO

El Formulario de Cambio del Proyecto se utiliza para registrar, evaluar, aceptar y hacer un seguimiento del estado de una petición de cambio de alcance en el proyecto.

Nombre del Áreas Usuaria:


Número de CR (Petición de Cambio):

Descripción de la Petición de cambio Autor de la Petición:

Área implicada:

<Especificar el área de proyecto general afectada por el cambio solicitado.>

Prioridad de la solicitud: Alta Media Baja

Categoría de la solicitud: Adaptación Perfección Corrección

Descripción del cambio: <Especificar qué debe cambiarse y por qué.>

248



Estado de la Petición de cambio

Estado Fecha Autor

Abierta y registrada Devuelta al autor para clarificación Rechazada Evaluada Aceptada Rechazada Asignada Cambios completamente verificados Cerrada

249



Análisis de la Petición de cambio

Productos del proyecto implicados y afectados: <Especificar qué productos del proyecto (por ejemplo, documentación, código, etc.) deben cambiarse.>

Estimación de trabajo de desarrollo e implantación del cambio: <Especificar la estimación de trabajo y cualquier información o supuesto de soporte.>

Impacto estimado en la programación del proyecto:

<Especificar qué impacto, si existe, tienen los cambios en la programación del proyecto.> Impacto estimado en los costes del proyecto:

<Especificar qué impacto, si existe, tienen los cambios en los costes presupuestados del proyecto.> Verificación: <Especificar cómo se comprobará o verificará este cambio.>

Otros comentarios:

250



Autorización para el cambio

Autorización del cambio: <Escribir el nombre de la persona del Área Usuaria con responsabilidad en autorizar cambios.> Cargo:

Aceptado Fecha: Sí No Referencia de la corrección del

contrato: (si corresponde)

Verificación del cambio

(Una vez realizado el cambio por la Directiva del proyecto y verificadas su correcto funcionamiento por medio de los resultados de las pruebas de aceptación definidas por Área Usuaria).

Nombre del responsable del Área Usuaria

Fecha:

Nombre del responsable del Proyecto:

Fecha:

251

252

4.3.1.4.9. (SEG-PARPP-09) PLANTILLA – ACTA DE RECEPCIÓN DE PRODUCTOS DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos Acta de Recepción de Productos del Proyecto Referencia: SEG-PARPP-09 Versión: 1.0

SEG-PARPP-09 Acta Recepcion Productos Proyecto, v1.0 Página: 1 de 1

ACTA DE RECEPCIÓN DE PRODUCTOS DEL PROYECTO

Referencia : Proyecto : Cliente :

Entrega de : Fecha :

Parcial Final

Elementos entregados:

Pruebas realizadas:

El Cliente certifica que la totalidad de los productos en la presente acta de recepción han sido entregados/terminados y que, habiendo sido sometidos a las pruebas de validación y aceptación indicadas, están de acuerdo con las especificaciones formales y demás requisitos contractualmente convenidos y establecidos entre las partes, con las siguientes observaciones :

Por el Cliente: Firma : Fecha :

Por el Proyecto: Firma : Fecha :

253

254

4.3.1.5. PLANTILLAS DE CIERRE DE PROYECTOS

255

4.3.1.5.1. (FIN-LVRRCP-01) LISTA DE VERIFICACIÓN – REUNIÓN REVISIÓN Y CIERRE DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos LV Reunión de Revisión y Cierre del Proyecto Referencia: FIN-LVRRCP-01 Versión: 1.0

FIN-LVRRCP-01 LV Reunion Revision Cierre Proyecto, v1.0 Página: 1 de 2

LISTA DE VERIFICACIÓN - REUNIÓN DE REVISIÓN Y CIERRE DEL PROYECTO

Esta lista de Verificación resalta aquellos asuntos que deben tenerse en cuenta antes, durante y después de una reunión de revisión del cierre del proyecto. La información obtenida en la reunión de revisión del proyecto se escribirá en un Informe de Revisión y Cierre del Proyecto.

Antes de la reunión

¿Se ha invitado a la reunión a todas las personas que deben estar presentes en la revisión del proyecto y pueden asistir? Entre los asistentes se debe incluir al Líder del proyecto, el Responsable de calidad, todo el equipo del proyecto (o tantos como sea posible), los departamentos de la Defensoría de los Habitantes que participen y otros interesados en el proyecto.

¿Se ha facilitado a todos los invitados una agenda de la reunión? ¿Se ha pedido a los invitados que estén preparados para considerar éxitos, debilidades y

recomendaciones de mejora del proyecto?

Durante la reunión

¿Están presentes en la revisión del proyecto todas las personas que deben? Si no es así, ¿aquellas personas que faltan van a proporcionar información de alguna forma indirecta o en otra reunión independiente?

¿Ha presentado el Líder del Proyecto un resumen del proyecto? El resumen debe incluir trabajo, coste y programación final, defectos extraordinarios, satisfacción del cliente y las métricas clave obtenidas en el desarrollo del proyecto.

¿Ha reconocido el Líder del Proyecto o un responsable de nivel superior la finalización con éxito del proyecto y las contribuciones de cada uno de los asistentes a la reunión?

¿Se ha solicitado a todos los asistentes información acerca de los puntos fuertes y débiles del proyecto o proceso, así como ideas para la mejora?

¿Se ha realizado todas las explicaciones y discusiones del contenido de la reunión? ¿Son unánimes las opiniones? En caso contrario, ¿por qué no? ¿Se han recogido todas las

opiniones en contra en las actas de la reunión? ¿Han podido expresar todos los asistentes su opinión?

Después de la reunión

256

Defensoría de los Habitantes Administración de Proyectos Informáticos LV Reunión de Revisión y Cierre del Proyecto Referencia: FIN-LVRRCP-01 Versión: 1.0

FIN-LVRRCP-01 LV Reunion Revision Cierre Proyecto, v1.0 Página: 2 de 2

¿Se han distribuido copias del contenido de la reunión a todos los asistentes? (Se recomienda hacerlo el primer o segundo día de la reunión).

¿Se ha incluido una copia de la reunión en el archivo del proyecto? ¿Se han incluido en el Informe de Revisión y Cierre del Proyecto todos los asuntos y opiniones

expresados durante la reunión de revisión?

257

258

4.3.1.5.2. (FIN-PIRCP-02) PLANTILLA - INFORME REVISIÓN Y CIERRE DEL PROYECTO



INFORME REVISIÓN Y CIERRE DEL PROYECTO (FIN-PIRCP-02)

Versión


Autor:

Mes, año

259

IINNFFOORRMMEE DDEE RREEVVIISSIIÓÓNN YY CCIIEERRRREE DDEELL PPRROOYYEECCTTOO


FIN-PIRCP-02 Informe Revisión y Cierre del Proyecto, V1.0 Pág. 2 de 7

Tabla de contenidos 1. Objetivo. ................................................................................................................ 4

2. Ámbito................................................................................................................... 4

3. Referencias. ........................................................................................................... 4

4. Descripción General del Proyecto. ............................................................................. 4

5. Descripción General del Proceso. .............................................................................. 4

6. Organizaciones de Proyecto y Soporte. ...................................................................... 5

7.Entorno Técnico de ejecución. ................................................................................... 5

8. Productos. ............................................................................................................. 5

9. Mediciones. ............................................................................................................ 5

10. Contrataciones de servicios. ................................................................................... 6

11. Emergencias/Problemas. ........................................................................................ 6

12. Recomendaciones de Mejora del Proceso. ................................................................ 6

13. Formularios y Listas de Verificación Asociados. ........................................................ 6

260




Control de versiones


261




RESUMEN DEL INFORME DE REVISIÓN Y CIERRE DEL PROYECTO

1. Objetivo. <Breve descripción de la finalidad del Informe Revisión y Cierre del Proyecto.>

2. Ámbito.

<Breve descripción de las cuestiones a las que se aplica el Informe Revisión y Cierre del Proyecto y las que resultan afectadas o influenciadas por el Plan de Gestión del Proyecto. El Informe Revisión y Cierre del Proyecto resume los resultados del mismo, indicando el estado final del proyecto, los conocimientos adquiridos y las emergencias y problemas destacados.>

3. Referencias. <Lista de la identificación de los archivos (Nombre del Archivo) de documentos y de los títulos completos de todos los documentos mencionados en la versión actual del Informe Revisión Cierre y del Proyecto.>

Nombre del Archivo Nombre del documento

4. Descripción General del Proyecto. <Breve descripción del proyecto, cliente(s) y productos.>

5. Descripción General del Proceso. <Breve descripción de los procesos de gestión de proyecto y de desarrollo de software que se utilizan, así como las opciones y/o las variaciones tomadas de los procesos documentados de Telefónica Sistemas. Se incluyen las opiniones sobre el grado óptimo en que se siguieron los procesos, su nivel de efectividad y qué problemas surgieron, si los hubo.>

262




6. Organizaciones de Proyecto y Soporte. <Breve descripción de la estructura organizativa de gestión del proyecto (estructura de informes, equipos, número de personas). Se incluyen opiniones sobre su grado de funcionamiento y los problemas que surgieron, si los hubo.> <Breve descripción de la organización(es) de desarrollo, ejecución y soporte o utilizada por el proyecto. Se incluyen opiniones sobre el grado de colaboración con el equipo del proyecto y los problemas que surgieron, si los hubo.>

7. Entorno Técnico de ejecución. <Breve descripción de las herramientas hardware y software empleados para gestionar el proyecto y de las plataformas empleadas para desarrollar y probar los productos entregables al cliente.> <Se incluyen opiniones sobre su grado de utilidad y los problemas que surgieron, si los hubo.>

8. Productos. <Resumen de los productos entregables de gestión del proyecto (documentación, software, hardware, formación, soporte de instalación) y de los productos entregados al cliente.> <Podrán incluirse opiniones relativas a la calidad, al grado de mantenimiento, etc.> <En esta sección se puede incluir una lista de posibles mejoras futuras.>

9. Mediciones. <Resumen de cálculos presupuestados frente a datos reales imputados correspondientes al tamaño, esfuerzos estimados, calendario ejecución, tamaño de plantilla recursos humanos propios, servicios subcontratados, compras de materiales, y costes. Se incluyen opiniones sobre el grado de funcionamiento del proceso de cálculo y las principales razones de las diferencias entre los cálculos y los datos reales.> <Si se obtuvieron mediciones adicionales del proyecto, también deben resumirse aquí.>

263




10. Contrataciones de servicios. <Resumen de los subcontratistas a los que se recurrió y los tipos de productos y servicios implicados. Se incluyen opiniones sobre el grado de colaboración con los contratistas y los problemas que surgieron, si los hubo.>

11. Emergencias/Problemas. <Resumen de las emergencias o problemas que surgieron durante el proyecto (examinar el Registro de Emergencias/Problemas para obtener material). Se explica cómo se trataron (con o sin éxito) y se enumeran las emergencias y problemas destacados en el momento de finalizar el proyecto (el equipo de mantenimiento deberá hacerse cargo de ellos si se finaliza el proyecto sin resolverlos).>

12. Recomendaciones de Mejora del Proceso. <Lista de “conocimientos adquiridos” o recomendaciones de mejora para beneficio de futuros proyectos. Deben darse razones para cada recomendación. > <Esta sección puede hacer simplemente referencia a otro documento si se redacta un Informe de

Oportunidades de Mejoras al Proceso (FIN-IOMP-03), por separado.>

13. Formularios y Listas de Verificación Asociados.

ID del fichero Título del documento Plantilla… Plantilla…

Plantilla…

264











Fin del Documento

265

266

4.3.1.5.3. (FIN-PIOMP-03) PLANTILLA - INFORME DE OPORTUNIDADES DE MEJORAS AL PROCESO



INFORME DE OPORTUNIDADES DE MEJORAS AL PROCESO

(FIN-PIOMP-03)

Versión


Autor:

Mes, año

267

IINNFFOORRMMEE DDEE OOPPOORRTTUUNNIIDDAADDEESS DDEE MMEEJJOORRAASS AALL PPRROOCCEESSOO


FIN-PIOMP-03 Informe de Oportunidades de Mejoras al Proceso, V1.0 Pág. 2 de 6

Tabla de contenidos 1. Introducción ..................................................................................................................................... 4 2. Alcance............................................................................................................................................ 4 3. Resumen Ejecutivo.......................................................................................................................... 4 4. Metodología de trabajo .................................................................................................................... 4 5. Evaluación al usuario sobre el producto y el proceso ejecutado ..................................................... 4 6. Actualización de métricas del proyecto............................................................................................ 4 7. Evaluación técnica del producto ...................................................................................................... 4 8. Análisis del Logro de los Objetivos Propuestos ............................................................................... 4 9. Análisis de Estimaciones de Tiempo contra Tiempos Reales.......................................................... 5 10. Análisis de Riesgos Materializados durante el Desarrollo ............................................................. 5 11. Análisis de Control de Cambio y su Impacto ................................................................................. 5 12. Análisis de la Efectividad de la Estrategia Utilizada en el Proyecto ............................................... 5 13. Especificación de Mejoras Potenciales.......................................................................................... 5 14. Recomendaciones para el Aprovechamiento de la Solución ......................................................... 5 15. Aprobaciones................................................................................................................................. 5 16. Anexos........................................................................................................................................... 5

268




Control de versiones


269




1. Introducción

<Definición y descripción del propósito del documento, resumen de los contenidos> 2. Alcance

<Comprende la aceptación del patrocinador del proyecto, la recopilación de registros, la entrega de versiones finales, la evaluación al usuario sobre el producto y el proceso ejecutado, la liberación de los recursos, actualización de métricas, evaluación técnica del producto y la elaboración del documento post implantación>

3. Resumen Ejecutivo

<Describir de manera general los objetivos alcanzados con la puesta de la aplicación, grado de acierto en los plazos estimados, los riesgos materializados, análisis de la efectividad de la estrategia utilizada, mejoras potenciales, recomendaciones.>

4. Metodología de trabajo

<Indica la metodología seguida para el desarrollo y control del proyecto (Planes, informes, reuniones).>

5. Evaluación al usuario sobre el producto y el proceso ejecutado

<Incluir y analizar los resultados obtenidos al aplicar la evaluación al usuario sobre el producto y el proceso ejecutado según la plantilla Evaluación del Usuario (FIN-PEU-06).

6. Actualización de métricas del proyecto

<Describe y establece las métricas finales del proceso, las métricas no deben incluir solamente el cálculo, sino también su interpretación para el proyecto>

7. Evaluación técnica del producto

<Incluir y analizar los resultados obtenidos al aplicar la evaluación técnica del producto, para esto utilizar la plantilla Evaluación Técnica del Producto (FIN-ETP-07).

8. Análisis del Logro de los Objetivos Propuestos

<Detallar cuales objetivos fueron logrados contra los objetivos pendientes y analizar el impacto>

270




9. Análisis de Estimaciones de Tiempo contra Tiempos Reales

<Establecer las comparaciones entre los tiempos propuestos contra tiempos reales de las diferentes actividades en el proyecto >

10. Análisis de Riesgos Materializados durante el Desarrollo

<Realizar un análisis de la etapa de desarrollo, considerar tiempos, atrasos y su justificación, errores comunes, cambio de recursos y cualquier otro factor que se considere de relevancia. >

11. Análisis de Control de Cambio y su Impacto

<Realizar un análisis de los cambios realizados, la cantidad de cambios que se generaron, así como los encargados de realizar los cambios, detallar que impacto produjeron en el proyecto >

12. Análisis de la Efectividad de la Estrategia Utilizada en el Proyecto

<Analizar y establecer los resultados obtenidos de acuerdo a los objetivos propuestos según la estrategia utilizada >

13. Especificación de Mejoras Potenciales

<Esta sección incluye aquellas mejoras que se hayan definido para el proyecto> 14. Recomendaciones para el Aprovechamiento de la Solución

<Se deben establecen las recomendaciones necesarias para tener un mejor aprovechamiento de la solución implantada >

15. Aprobaciones

<Definir los responsables correspondientes de la aprobación y aceptación del documento de Post- Implantación >

16. Anexos

<Incluir en esta sección todos los formularios que serán utilizados y aquellos que se consideren necesarios>

271











Fin del Documento

272

273

4.3.1.5.4. (FIN-PAC-04) PLANTILLA - ACCIONES CORRECTIVAS

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla de Acciones Correctivas Referencia: FIN-PAC-04 Versión: 1.0

FIN-PAC-04 Acciones Correctivas, v1.0 Página: 1 de 3

ACCIÓNES CORRECTIVAS Este formulario debe completarse siempre que se identifique un problema con la forma de administrar los proyectos informáticos de la Defensoría de los Habitantes. El formulario se utiliza también para registrar reclamaciones de clientes, sugerencias del personal y acciones que provengan de auditorias internas. Las primeras secciones del formulario hasta “Descripción del problema” incluida las cumplimenta el autor. A continuación, el formulario se traslada al Líder del Proyecto para su procesamiento de acuerdo con el Procedimiento de Acción Correctiva y Preventiva.

Emisor del problema:

Nº de referencia de registro:

Fecha de solicitud:


Código del Cliente:

Nombre del Cliente:

Código del proyecto:

Líder del Proyecto

Clientes afectados: <Identificar el cliente o clientes afectados por el problema >

Material de referencia: <Referencia cualquier material que sea relevante para documentar el problema o para documentar la acción correctiva a desarrollar. Ej.: Planes, especiificaciones, pruebas, etc.>

Descripción del problema: <Recoge una precisa dscripción del problema>

Impacto: <Describe el impacto que ha producido el problema.>

274



Causa original: <Describe la causa o causas del origen del problema> Si se identifica durante una auditoría: Problema mayor Problema menor

Acciones correctivas inmediatas: <Describe las acciones inmediatas o urgentes que se han tomado> Responsable: Previsión de

respuesta:

Acciones de corrección preventiva: <Describe las acciones preventivas y correctivas que van a tomarse> Responsable: Previsión de

respuesta:

Análisis de acción correctiva:

Riesgos implicados: <Identifica los riesgos asociados a cada acción correctiva> Costes estimados: <Especifica los costes estimados de cada acción correctiva>

Resultados: <Breve descrpción del resultado obtenido al aplicar cada acción correctiva>

Beneficios obtenidos:

275



<Describe los beneficios obtenidos por la acción correctiva>

Ahorro de costes: >Especifica los costes ahorrados como consecuencia de aplicar la acción correctiva>

Verificado por: Fecha:

Firmas de aceptación: Autor:

Fecha:

Responsable de calidad:

Fecha:

Auditor:

Fecha:

276

277

4.3.1.5.5. (FIN-LVCP-05) LISTA DE VERIFICACIÓN – CIERRE DEL PROYECTO

Defensoría de los Habitantes Administración de Proyectos Informáticos LV Cierre del Proyecto Referencia: FIN-LVCP-05 Versión: 1.0

FIN-LVCP-05 LV Cierre Proyecto, v1.0 Página: 1 de 1

LISTA DE VERIFICACIÓN - CIERRE DEL PROYECTO

Esta lista de comprobación resalta aquellos elementos que deben tenerse en cuenta antes de que se inicie el tramite para realizar el cierre técnico del proyecto (los “criterios de entrada”) y antes de que se considere definitivamente realizado el cierre del proyecto (los “criterios de salida”).

Criterios de entrada

¿Se han completado todos los productos y se han registrado bajo control de configuración? ¿Se ha completado la prueba de aceptación y obtenido la aprobación del representante del

cliente y el responsable del proyecto? ¿Se ha entregado el sistema o producto al cliente? (la “entrega” puede ser desde un simple

envío del material de instalación al cliente, hasta una instalación in situ, comprobación y aceptación por parte del cliente y de los miembros del equipo del proyecto).

¿Se ha celebrado la reunión de aceptación del proyecto y se ha obtenido la aceptación formal por parte de los representantes del cliente?

Criterios de salida

¿Se ha entregado al cliente todo el material necesario del sistema o producto (por ejemplo, documentación, software, etc.) y se ha informado a los equipos de soporte (por ejemplo, operaciones, mantenimiento, soporte al cliente)?

¿Se ha celebrado al menos una reunión de Revisión de Cierre del proyecto? ¿Se ha creado, revisado y aprobado el informe de Revisión del proyecto? ¿Ha revisado el responsable de calidad las mejoras recomendadas (si existen) en la Revisión

Cierre del proyecto y se han completado los formularios de acción correctiva si es necesario? ¿Se han realizado revisiones de final del proyecto con miembros del equipo de proyecto

(empleados asignados a tiempo completo al proyecto y con contratistas)? ¿Se ha asegurado el Líder del Proyecto de que se ha completado el archivo del proyecto? ¿Se ha finalizado el archivo del proyecto? ¿Se han añadido a la base de histórica de proyectos del Departamento de Informática, los datos

de métrica obtenidos en el proyecto para su uso en estimaciones de proyectos futuros?

278

279

4.3.1.5.6. (FIN-PEU-06) PLANTILLA - EVALUACIÓN AL USUARIO

FFOORRMMUULLAARRIIOO DDEE EEVVAALLUUAACCIIÓÓNN AALL UUSSUUAARRIIOO


FIN-PEU-06 Evaluación al Usuario, V1.0 Página 1 de 1

EVALUACIÓN AL USUARIO Fecha de evaluación: <dd/mm/aa en que se realiza la evaluación>

Proyecto evaluado: <nombre del proyecto que se esta evaluando>

Periodo en que fue desarrollado: <dd/mm/aa en que se inicia y en se finaliza>

Tipo de proyecto: <tipo de proyecto que se realizó

Áreas de la Defensoría a que brinda servicio el producto: <nombre de las áreas que utilizan el producto desarrollado> Líder técnico del Proyecto: <nombre del líder técnico>

Líder funcional del proyecto: <nombre del líder funcional>

Análisis del grado de cumplimiento en los alcances y objetivos del producto: <alcances del producto y el grado de cumplimiento de estos > Análisis de la conveniencia de la estrategia de la administración utilizada: <análisis de la estrategia que fue utilizada para administrar el proyecto> Análisis del grado de acierto en los plazos estimados: <análisis de la comparación entre los plazos estimados y los plazos reales y las causas de estos > Análisis de acierto en la estructura organizacional del proyecto: <Análisis de los roles y responsabilidades del equipo del proyecto en función del desempeño de los mismos> Recomendaciones para próximos desarrollos: <indicar aquellas opciones de mejora para próximos desarrollos > Análisis de la gestión de Aseguramiento de la calidad: <análisis de la gestión de aseguramiento d la calidad durante el proceso de ejecución del proyecto> Observaciones: Evaluado por: <nombre del responsable de conducir la evaluación al usuario>

Usuario Evaluado: <nombre y firma del usuario que realiza la evaluación>

280

281

4.3.1.5.7. (FIN-PETP-07) PLANTILLA - EVALUACIÓN TÉCNICA PRODUCTO

Áreas de la Defensoría a las que brinda servicio el producto:

5 4 3 2 1 NA

1

2

3

4

5

6

7

8

9

Página 1 de 1

Grado de cumplimiento de los objetivos propuestos inicialmente

8 7

Grado de estandarización de la documentación y del producto

Producto evaluado:Fecha de evaluación:

Líder funcional:Líder técnico del proyecto:

Observaciones

I. EVALUACION DE LA ACTIVIDAD

Posibilidad de reutilizar código generado en el proyecto

Nivel de esfuerzo requerido para operar la solución

Nivel de seguridad ante accesos no autorizados

9 610

FIN-PETP-07, Evaluación Técnica del Producto, v1.0

Evaluación Técnica del Producto

Tipo de proyecto:

10 corresponde a la máxima calificación y 1 a la mínima

Nivel de apego entre la documentación y el producto

Calidad de la documentación interna

Nivel de reutilización de código que presenta el producto

Grado de ocurrencia de errores en el producto

Periodo en que fue desarrollado:

¡Muchas gracias por su colaboración!

282

283

4.3.2. HERRAMIENTAS Y TÉCNICAS DE LA GESTIÓN DE PROYECTOS

4.3.2.1. GUÍA DE HERRAMIENTAS Y TÉCNICAS. Este apartado hace referencia a aquellas herramientas y técnicas de uso general y obligatorio en lo que a administrar proyectos de tecnologías de información concierne. Es una primera versión dado que existen muchas otras herramientas igual de importantes y necesarias. La guía hace uso de un caso de ejemplo, que sirve como datos de referencia a lo largo de todo el desarrollo. Las herramientas aquí descritas son:

• EDT (WBS)

• PERT

• Gráfica de Gantt

• CPM. El desarrollo completo de esta herramienta está descrito en la Guía de Herramientas y Técnicas (AP-GHT-01), el cual se detalla en el siguiente apartado:

Mes, año

Autor:


Versión

GUÍA DE HERRAMIENTAS Y TÉCNICAS (AP-GHT-01)

ADMINISTRACIÓN DE PROYECTOS INFORMÁTICOS DEPARTAMENTO DE INFORMÁTICA


284


Administración de Proyectos Informáticos Guía de Herramientas y Técnicas Referencia: AP-GHT-01

Versión: 1.0

AP-GHT-01 Guía Herramientas y Técnicas, V1.0 Página 2 de 40

TABLA DE CONTENIDOS

1. Objetivos........................................................................................................................... 4 2. Ámbito............................................................................................................................... 4 3. Referencias ....................................................................................................................... 4 4. Funciones y Responsabilidades..................................................................................... 5 5. Guía ................................................................................................................................... 5 5.1. Definiciones y acrónimos.................................................................................................... 5 5.2. Selección del caso de estudio ............................................................................................ 7 5.2.1. Datos del Proyecto ............................................................................................................. 7 5.2.2. Procedimiento .................................................................................................................... 8 5.3. Conclusiones.................................................................................................................... 37 5.4. Sistemas de Información relacionados............................................................................. 39 6. Plantillas y Listas de Verificación Asociados.............................................................. 39

285



Versión: 1.0




286



Versión: 1.0


GUÍA DE HERRAMIENTAS Y TÉCNICAS PARA ADMINISTRACIÓN DE PROYECTOS

1. Objetivos

Guiar al equipo de planificación en la definición y aplicación de herramientas y técnicas de Administración de Proyectos necesarias para planificar, ejecutar y controlar los proyectos informáticos de la Defensoría de los Habitantes.

2. Ámbito

Esta guía es material de referencia obligatoria durante la planificación, ejecución, seguimiento y control de los proyectos informáticos de la Defensoría de los Habitantes. Si no se utiliza, el Administrador de Proyectos deberá asegurarse de que el Líder de Proyectos y el Equipo de Planificación conocen y aplican éstas herramientas y técnicas en forma apropiada.

3. Referencias





PLA-PGT-02 Plan de Gestión del Tiempo

287



Versión: 1.0



Administrador del Proyecto Es responsable de actualizar e identificar herramientas y técnicas para la administración de proyectos, estas deberán contribuir en la gestión eficiente de los recursos utilizados en la planificación, ejecución, seguimiento y control del proyecto.

Líder del Proyecto Es responsable de proponer los planteamientos a resolver con el uso de herramientas y técnicas, así como de tomar las decisiones requeridas para el proyecto en base a los resultados obtenidos.

Equipo de Planificación Son responsables de utilizar las herramientas y técnicas descritas en forma eficaz y eficiente, a lo largo de toda la duración del proyecto.

5. Guía

5.1. Definiciones y acrónimos

PERT: Siglas de Program Evaluation Review Technique (Técnicas de revisión y evaluación de programas), método para programar y controlar programas. CPM: Siglas de Critical Path Method (método de la ruta crítica), usado para programar y controlar proyectos. Actividad: Trabajo que se debe realizar como parte de un proyecto, simbolizado mediante una rama de la red PERT. Evento: Conclusión de todas las actividades que entran a un nodo de la red PERT. Nodo: Círculo de una red PERT que indica la conclusión de ciertas actividades y la iniciación de otras.

288



Versión: 1.0


Rama: Línea de la red PERT que designa una actividad. Ruta: Sucesión de actividades que van de un nodo a otro. Ruta crítica: Sucesión de actividades que determinan la ruta más larga a través de la red PERT y que produce el tiempo mínimo en el que el proyecto se puede concluir. Predecesoras: Actividades que deben concluir inmediatamente antes de que empiece la actividad en cuestión. Lista de actividades: Lista de los trabajos de un proyecto, de sus predecesoras, de los tiempos esperados y de los recursos requeridos. Diagrama de Red: Método gráfico de representar un proyecto mediante arcos y nodos. Actividad ficticia: Actividad imaginaria que no requiere tiempo y que se usa, o bien para mantener la relación adecuada de precedencia en el diagrama de red PERT, o bien cuando se requiere en algunos programas de computadora en el que hay dos o más actividades que salen de un nodo y que tienen precedencias diferentes. Tiempo más temprano de inicio (ES): En una red PERT, el momento más temprano en el que puede iniciarse una actividad. Tiempo más tarde de inicio (LS): En una red PERT, el momento más tardío en el que puede comenzar una actividad sin retrasar la finalización del proyecto global. Tiempo más temprano de finalización (EF): El tiempo más temprano en que puede terminar una actividad. Tiempo más tarde de finalización (LF): El tiempo más tarde en que puede terminar una actividad, sin retrasar la finalización del proyecto global. Holgura: Tiempo en el que se puede retrasar el inicio de una actividad sin retrasar la finalización del proyecto global. Tiempo optimista: El tiempo requerido para completar una actividad cuando todo marcha a la perfección. Tiempo más probable: Tiempo requerido para concluir una actividad en circunstancias normales.

289



Versión: 1.0


Tiempo pesimista: Tiempo requerido para completar una actividad bajo las condiciones más desfavorables. Distribución Beta: Distribución de la probabilidad, que se usa como modelo en los tiempos de actividad PERT. Compresión: Término del método CPM que describe el proceso de reducir el tiempo requerido para terminar una actividad. PERT/Costo: Sistema para determinar los recorridos factibles del flujo de efectivo durante un proyecto. Tiempo normal: En CPM, el tiempo máximo para la conclusión de una actividad, correspondiente al uso mismo del recurso. Tiempo comprimido: En CPM, el tiempo mínimo posible para la conclusión de una actividad, correspondiente a la concentración máxima de recursos.

5.2. Selección del caso de estudio

La complejidad de este caso de estudio a nivel de ejemplo, no se puede comparar con los problemas que se presentan en la construcción de grandes proyectos, pero proporciona una guía de forma fácil y sencilla del uso de las técnicas WBS, PERT, Gráfica de Gantt y CPM.

5.2.1. Datos del Proyecto

• Nombre: Proyecto Alfa

• Plazo requerido: 22 semanas

• Situaciones a resolver:

1. ¿Cuál es la fecha de terminación del proyecto?

290



Versión: 1.0


2. ¿Cuál es la variabilidad probable de este dato?

3. ¿Cuales son las fechas programadas del principio y terminación de cada

actividad específica?

4. ¿Cuales actividades son críticas en el sentido de que deben terminar con exactitud como fueron programadas para llegar a la meta de la terminación del proyecto total?

5. ¿Cuánto se pueden demorar las actividades no críticas antes de provocar un

retraso en la fecha de conclusión del proyecto total?

6. ¿Cómo se puede encontrar en forma efectiva los recursos y actividades, con el objeto de acelerar la terminación del proyecto?

7. ¿Qué controles se deben ejercer en el flujo de los recursos financieros para las

diversas actividades durante el proyecto, para poder apegarse al proyecto total?

5.2.2. Procedimiento

El primer paso del proceso consiste en definir las actividades del proyecto y establecer las relaciones de precedencia entre ellas. Para definir las actividades de un proyecto la mejor técnica a utilizar es la Estructura Detallada de Trabajo (WBS).

291



Versión: 1.0


Esta herramienta, popularmente conocida como WBS, está basada en el particionamiento Top-Down de un trabajo. Representa las actividades de todo tipo que comprende un proyecto, indicando primero actividades macro y particionando cada una de ellas hasta llegar al concepto de Paquetes de Trabajo.

Por Paquetes de Trabajo se definen las unidades de trabajo que poseen entradas y salidas claras, y que por lo general no superan los 10 días-hombre. Cada paquete de estos tiene recursos, entradas, salidas y tiempo claramente identificables.

La estructura del desglose del trabajo por lo general se representa de manera gráfica en una especie de organigrama, no obstante se podría encontrar también en una lista utilizando niveles de indentación. Las principales características de esta herramienta son las siguientes:

a) Particionamiento natural de un trabajo o producto. b) Los primeros niveles de la estructura por lo general son estándar. c) Es el primer paso que debe efectuar el planificador para lograr un conocimiento adecuado

del proyecto y su magnitud, para así dar bases sólidas al plan. d) Según sea la necesidad, la estructura se puede orientar al producto o al proceso de

elaboración. e) Facilita la comunicación de alcances del proyecto al equipo de trabajo y los usuarios. f) No refleja de manera directa interrelaciones entre actividades, ni la calendarización de las

mismas.

292



Versión: 1.0


Esta herramienta es de mucha ayuda en la conceptualización de proyectos de grandes dimensiones, así como cuando existe incertidumbre sobre las tareas que deben ser ejecutadas. El cuadro 1 contiene la EDT de las actividades propuestas: Cuadro N° 1: EDT de las Actividades propuestas.

Tareas Descripción Predecesoras Duración

A Elegir modelo de desarrollo de software - 3 Sem.

B Crear plan de proyecto - 5 Sem.

C Especificaciones de requerimientos B 3 Sem.

D Diseñar el sistema A, C 4 Sem.

E Codificar el sistema D 8 Sem.

F Verificar los requerimientos C 2 Sem.

G Probar el sistema F 4 Sem.

H Reparar errores del sistema F 2 Sem.

I Implantar el sistema B 5 Sem.

J Entrenar Personal H, E, G 3 Sem.

Las actividades predecesoras son aquellas que deben ser iniciadas o ejecutadas con anterioridad al inicio de la actividad en cuestión. Por ejemplo: la tarea Especificaciones de requerimientos no se puede comenzar mientras no se efectúe la tarea Crear plan de proyecto. De la misma manera la tarea Probar sistema no puede comenzar sin que termine la tarea Verificar los requerimientos. La lista de tareas con sus predecesoras y los tiempos estimados proporcionarán los insumos esenciales para las cinco primeras preguntas de las situaciones a resolver. La figura 9 es una gráfica de Gantt que representa en el eje vertical las actividades del proyecto y en eje horizontal el tiempo que cada una de ellas necesita para ejecutarse completamente

293



Versión: 1.0


Act.

Tareas S1 S2 S3 S4 S5 S6 S7 S8 S9 S10

S11

S12

S13

S14

S15

S16

S17

S18

S19

S20

S21

S22

A Elegir modelo de desarrollo de software

B Crear plan de proyecto

C Especificaciones de requerimientos

D Diseñar el sistema

E Codificar el sistema

F Verificar los requerimientos

G Probar el sistema

H Reparar errores del sistema

I Implantar el sistema

J Entrenar Personal.

0 5 10 15 20 22

Figura N° 9: Gráfica GANTT del proyecto propuesto.

294



Versión: 1.0


La gráfica de Gantt indica el tiempo de inicio más temprano posible para cada actividad, por ejemplo, la tarea Especificaciones de requerimientos no puede comenzar antes de la quinta semana ya que primero se debe completar la tarea Crear plan de proyecto; cuando cada actividad se completa o se ejecuta parte de ella en la barra se sombrea de acuerdo con el porcentaje de ejecución realizado, por lo tanto, en cualquier momento puede verse con claridad cuales tareas están a tiempo y cuales están retrasadas. La gráfica de Gantt muestra, por ejemplo, que para la semana 13 las tareas D, E y H van retrasadas, mientras que la actividad G ya ha sido completada totalmente, por lo tanto está adelantada. Este ejemplo muestra que la gráfica de Gantt se usa sobre todo como un registro para llevar el seguimiento de la progresión en el tiempo de las actividades de un proyecto. En la gráfica podemos ver cuales tareas individuales están a “tiempo o retrasadas”. Parece importante señalar en este punto que la frase “a tiempo” significa “se ha completado” en el plazo señalado. Así la gráfica muestra que la actividad D y H debían haber concluido, sí mucho, en la semana 12. Puesto que en la semana 13 no ha terminado, en este sentido, “está retrasada”. Como se puede notar, es un concepto simple el de si va “a tiempo” o no. El punto de vista adecuado deberá de ser si el proyecto total está siendo demorado o no en términos de una fecha de terminación como objetivo. La gráfica de Gantt falla en revelar información importante que se necesita para abordar esta cuestión. Por ejemplo, la gráfica de Gantt no revela que actividades son predecesoras de otras, es este tipo de información sobre predecesoras lo que se debe usar para deducir el efecto del tiempo de conclusión sobre el proyecto total. Este último tipo de información es de evidente importancia para el administrador. La debilidad fundamental de la gráfica de Gantt se refleja en su inutilidad para apoyar tales interferencias. El siguiente paso es construir un diagrama de red para resolver el problema de las precedencias. En un diagrama de red PERT cada actividad se representa mediante una flecha llamada arco o rama. El

295



Versión: 1.0


principio y el fin de cada actividad se representa mediante un circulo llamado nodo. También se usa el término evento en conjunción con los nodos. Un evento representa la conclusión de las actividades que se listan en la gráfica, vemos que la tarea Elegir modelo de desarrollo de software

se designa como actividad A. Cuando se completa esta actividad, ocurre el evento “se seleccionó un

modelo de desarrollo de software”.

1

2

3

4

A

B C

Figura N° 10: Diagrama PERT de las actividades A, B y C. La figura 10 presenta un diagrama de red PERT para las actividades A, B y C. Se subraya que los números asignados a los nodos son arbitrarios. Se usan solo para identificar eventos y nada indican sobre relaciones de precedencias. En realidad se vuelve a numerar el nodo en el que termina la actividad C varias veces, conforme se desarrolle el diagrama de red del proyecto, pero siempre se conservará la relación correcta de precedencia. En el diagrama de red cada actividad debe empezar en el nodo en que termina su predecesora. Por ejemplo, en el diagrama anterior la actividad C comienza en el nodo 3 porque ahí termina su predecesora, la cual es la actividad B. Sin embargo surgen complicaciones al tratar de agregar la actividad D al diagrama de red. En vista que la actividad A y C son antecesores inmediatos de D, y dado que se requiere que cada actividad como D aparezca solo una vez en el diagrama, se debe combinar el nodo 2 y el nodo 4 de la figura xx,

296



Versión: 1.0


para que D empiece en ese nuevo nodo. La actividad E como solo tiene como predecesora a la actividad D puede agregarse sin ninguna dificultad.

3

A

B

C1

2

4 5D E Figura N° 11: Diagrama PERT de las actividades A, B, C, D y E. La actividad F representa un problema para agregarla a la red, debido que a que la actividad F tiene como predecesora a la actividad C, por lo tanto debería comenzar en el nodo 3, pero en el nodo 3 también termina la actividad A, y esto implica que la actividad F no puede agregarse a este nodo. Este problema de diagramación se resuelve introduciendo una actividad ficticia que se representa mediante una línea punteada en el diagrama de red de la figura número 11. Esta actividad ficticia en el sentido de que no requiere tiempo ni recursos. Solo proporciona un artificio pedagógico que permite dibujar la representación reticular que conserva correctamente la relación de precedencia adecuada. Así la figura 9 indica que la actividad D solo puede comenzar una vez que han concluido tanto la actividad A como las C. En forma similar, la actividad F puede iniciarse cuando haya terminado la actividad C.

297



Versión: 1.0


2A

B

C

1

3

5 7 D E

4 6F

Figura N° 12: Diagrama PERT de las actividades A, B, C, D, E y F. Las actividades G y H empiezan ambas en el nodo 6 y terminan en el nodo 7, esto no presenta problema al dibujar las relaciones de precedencia apropiada.

2A

B

C

1

3

5

7

D E

4 6F

G

H

Figura N° 13: Diagrama PERT de las actividades A, B, C, D, E, G, H y F. La actividad J comienza en el nodo 7. Sin embargo, si la agregamos al diagrama de la figura 13, se podrían causar problemas en ciertos programas de computación que se usan para resolver modelos PERT y CPM.

298



Versión: 1.0


En algunos de estos programas se identifica cada actividad por el número de sus nodos de iniciación y conclusión. Si se usa uno de tales programas, la representación de G y H provocaría que la computadora considerase que son la misma actividad. Esto sería incorrecto, ya que en realidad, las actividades G y H no son lo mismo. Se puede usar una actividad ficticia para remediar esta situación. En la figura 13 se ilustra el procedimiento, puesto que las actividades ficticias no tiene duración, se conserva el tiempo correcto y la relación de precedencia:

2 A

B

C

1

3

5

7

D E

4 6F

G

H 8

9J

I

Figura N° 14: Diagrama PERT de las actividades A, B, C, D, E, F, G, H, I e J. La actividad I se agrega al diagrama sin problema alguno. La figura 14 representa el PERT del proyecto Alfa. La lista de actividades y un diagrama de red apropiado son artificios útiles para representar las relaciones de precedencia entre las actividades de un proyecto. Se debe recordar que existe un plazo improrrogable de 22 semanas para que concluya el proyecto en su totalidad.

299



Versión: 1.0


El procedimiento PERT - CPM necesita que el Líder de Proyectos obtenga una estimación del tiempo esperado que cada actividad de la lista tarde en concluir. Se supone que en el Proyecto Alfa se ha trabajado con los departamentos idóneos de la empresa para calcular estimaciones del tiempo esperado (en semanas) como la de la lista de actividades. Cuadro N° 2: Lista de actividades del proyecto con duraciones estimadas.

TAREAS ACTIVIDADES PREDECESORAS DURACIÓN (SEMANAS)

A Elegir modelo de desarrollo de software - 3

B Crear plan de proyecto - 5

C Especificaciones de requerimientos B 3

D Diseñar el sistema A, C 4

E Codificar el sistema D 8

F Verificar los requerimientos C 2

G Probar el sistema F 4

H Reparar errores del sistema F 2

I Implantar el sistema B 5

J Entrenar Personal H, E, G 3

Diagrama de red PERT con tiempos de actividad esperados para el Proyecto Alfa:

300



Versión: 1.0


A (3)

B (5)

Figura N° 15: Diagrama PERT del proyecto con tiempos estimados. En el cuadro 2 se pueden notar los tiempos esperados de cada actividad y si se suman se obtendrá el tiempo total de trabajo que se necesita para terminar el proyecto el cual sería de 39 semanas. No obstante, claro está que el tiempo total requerido para completar el proyecto puede ser menos de 39 semanas, porque se pueden realizar al mismo tiempo muchas actividades. Por ejemplo; en el diagrama de red anterior se puede ver que las actividades A y B se inician en forma simultánea. La actividad A requiere 3 semanas de trabajo, mientras que la actividad B necesita 5 semanas. Para obtener una estimación del tiempo mínimo requerido de la duración del proyecto se debe calcular lo que se denomina la ruta crítica de la red. Se puede definir una ruta como una secuencia de actividades conectadas desde el nodo inicial (1) hasta el nodo final (9). Por ejemplo; la ruta formada por las actividades B e I necesita 10 semanas para ejecutarse. La ruta A, D, E, J necesita 18 semanas. La ruta B, C, D, E, J necesita 23 semanas. Se pueden identificar muchas rutas en el diagrama anterior. Para que el proyecto termine deben ejecutarse todas las actividades de todas las rutas.

2 5D (4) E (8)

1

3

74 6F (2) G (4)

H (2)

9

8

J (3)

C (3)

I (5)

301



Versión: 1.0


Hasta este momento, se puede notar que el proyecto tomará como mínimo 23 semanas para ser ejecutado. El trabajo a realizar consiste en analizar el tiempo total que se necesita para ejecutar el proyecto, por lo tanto se debe determinar la ruta más larga que vaya del inicio del proyecto hasta el final, esta ruta; la más larga, se denomina ruta crítica. Esta ruta determina la duración total del proyecto. Si las actividades de la ruta más larga se demoran el proyecto se demora, por esta razón las tareas de la ruta crítica también se llaman actividades críticas del proyecto. Esta es la ruta que debe mantenerse “a tiempo”. Se especificaran los pasos que se usan para encontrar la ruta crítica. Será fundamental en este proceso el tiempo más temprano de inicio de cada actividad. Para ilustrar esta idea, se considerará la actividad D, Diseñar sistema. Se debe suponer que el proyecto comienza en el momento (0) y se debe de preguntar: ¿Cuál es el

momento más temprano en el que se puede comenzar la actividad D? Esta claro que no se puede comenzar hasta que se haya terminado la tarea A. Por lo tanto no puede comenzar antes de la semana 3, ya que esta es el tiempo que necesita esta actividad para ser ejecutada. Pero la actividad D no solo depende de la actividad A, la actividad D también depende de la actividad C. Así que la actividad D no puede comenzar antes que la actividad C termine. Por lo tanto, se debe determinar si la actividad A termina después de la actividad C o si la actividad C termina después de la actividad A. Se sabe que la actividad A necesita 3 semanas para ejecutarse. Ahora, se debe ver que tiempo necesita la actividad C para ejecutarse. Para que la actividad C se ejecute primero se debe ejecutar la actividad B, y la actividad B requiere 5 semanas para realizarse completamente, si sumamos el tiempo de la actividad B y el tiempo de la actividad C tenemos un total de 8 semanas. Con esto se concluye que el tiempo más temprano de inicio de la actividad D es de 8 semanas. Otro concepto importante es el tiempo más temprano de conclusión de cada actividad.

302



Versión: 1.0


• ES = Tiempo de inicio más temprano

• EF = Tiempo de Finalización más temprano

• t = Duración esperada de la actividad

Para calcular el tiempo más temprano de conclusión de cualquier actividad se debe utilizar la siguiente fórmula:

• EF = ES + t

Por ejemplo; para calcular el tiempo más temprano de conclusión de la actividad D, se tendría:

• EF = 8 semanas + 4 semanas

• EF = 12 semanas

Se debe recordar que cada actividad comienza en un nodo. Se sabe que una actividad que comience en un nodo no puede iniciarse antes que todas las actividades que se dirijan a ese nodo hayan terminado. Esta observación da la siguiente regla:

Regla del tiempo de inicio más temprano:

El tiempo ES para cualquier actividad que comience en un nodo es el mayor de los tiempos EF de todas las actividades que desembocan en el nodo.

La figura 16 muestra Gráfica del Tiempo de inicio más temprano:

303



Versión: 1.0


2

A (0,3)

B (0,5) C

1

3

D

4F (8,10)

I (5,10)

Figura N° 16: Gráfica del Tiempo de inicio más temprano: Se aplicará esta regla a la red del Proyecto Alfa, tal y como lo muestra la figura 17: A

B

Figura N° 17: Gráfica del Tiempo de inicio más temprano aplicada al Proyecto Alfa. En el diagrama de red, se debe notar que el tiempo más temprano de conclusión de J, la cual es la última actividad del proyecto, es de 23 semanas.

2 5D E

1

3

74 6F G

H

9

8

J

C

I (5,10)

304



Versión: 1.0


Se debe proceder ahora con el algoritmo, para encontrar la ruta crítica. Cruzando a lo largo del recorrido progresivo anterior, el siguiente paso consiste en realizar el recorrido inverso. El recorrido inverso comienza en el último nodo (9), se traza hacia atrás a lo largo de la red para calcular el llamado el tiempo de inicio más tarde y el tiempo de finalización más tarde de cada actividad. En símbolos se tiene:

• LS = Tiempo de inicio más tarde

• LF = Tiempo de finalización más tarde La relación entre esas cantidades es:

• LS = LF – t Para la actividad J, el tiempo de finalización más tarde viene a ser el mismo que el Tiempo de finalización más tarde total que es de 23. Por lo tanto, para la actividad J sería: LS = LF – t =>LS = 23 – 3 =>LS = 20

Regla del tiempo de finalización más temprano:

El tiempo LF para cualquier actividad que entre a un nodo es el menor de los tiempos LS de todas las actividades que entren en el nodo.

305



Versión: 1.0


Para la actividad H, se aplica la regla al nodo en el cual termina esta actividad, el cual es el nodo (7), luego se tiene que:

• LS = LF – t => LS = 20 – 2 => LS = 18 La figura 18 muestra el diagrama de red con los tiempos LS y LF. A

B

Figura N° 18: Diagrama de red con los tiempos LS y LF. Basándose en el diagrama de la figura número, el siguiente paso consiste en identificar otro valor importante, la holgura o el tiempo de libertad asociado a cada actividad. La holgura es la cantidad de tiempo que se puede demorar una actividad sin afectar la fecha de finalización del proyecto, la holgura se calcula utilizando la siguiente fórmula:

• Holgura = LS – ES o Holgura = LF – EF

2 5D E

(5,8)

1

3

74 6F G

H 8

9J

(5,8)

(8,12) (12,20)

(14,16 G (20,23)

C

(18,20)I (5,10)(0,5)

)

(18,23)

306



Versión: 1.0


Por Ejemplo, para la holgura para la actividad G es:

• Holgura de G = LS de G - ES de G

• Holgura de G = 16 - 10

• Holgura de G = 6 Es lo mismo si se procede de la siguiente manera:

• Holgura de G = LF de G - EF de G


• Holgura de G = 6 Significa lo anterior que se puede demorar la actividad G hasta en 6 semanas después de su tiempo de inicio más temprano sin retrasar el proyecto total. Para la actividad C, la holgura sería la siguiente:

• Holgura de G = LS de C - ES de C


• Holgura de G = 0 Por lo tanto, la actividad C carece de holgura, lo que quiere decir que la actividad C debe comenzar conforme se ha programado en el proyecto, esto es en la semana 5, la actividad C es una actividad crítica y si se afecta el proyecto se afectará. Las actividades críticas son aquellas cuya holgura es igual a cero o nula.

307



Versión: 1.0


El cuadro 3 muestra la lista de actividades con los cálculos necesarios para un poder determinar la ruta crítica del proyecto.

Cuadro N° 3: Lista de actividades para cálculo de ruta crítica del Proyecto Alfa

Tareas Descripción

Tiempo de inicio

más Temprano

(ES)

Tiempo de Finalización

más Temprana

(EF)

Tiempo de Inicio

más Tarde

(LS)

Tiempo de Finalización más Tarde

(LF)

Holgura

(LS – ES)

A Elegir modelo de desarrollo de software 0 3 5 8 5

B Crear plan de proyecto 0 5 0 5 -

C Especificaciones de requerimientos 5 8 5 8 -

D Diseñar el sistema 8 12 8 12 -

E Codificar el sistema 12 20 12 20 -

F Verificar los requerimientos 8 10 14 16 6

G Probar el sistema 10 14 16 20 6

H Reparar errores del sistema 10 12 18 20 8

I Implantar el sistema 5 10 18 23 13

J Entrenar Personal 20 23 20 23 -

Según la tabla anterior podemos observar que las actividades sin holgura (actividades críticas) son B, C, D, E, J. En el diagrama de red, de la figura 19 se tendría:

308



Versión: 1.0


Figura N° 19: Ruta crítica Proyecto Alfa

1. ¿Cuál es la fecha de terminación del proyecto?

• Respuesta: 23 semanas

2. ¿Cuales son las fechas programadas del principio y terminación de cada actividad específica?

• Respuesta: Se puede programar una actividad para que comience entre el “inicio más temprano” y el “inicio más tarde”. La fecha programada de finalización será igual a la “fecha de inicio más temprana” más el “tiempo esperado” de la actividad. Por ejemplo; la actividad G puede ser programada para empezar en cualquier momento entre la semana 10 y la semana 16. Como se ve en la tabla anterior el tiempo esperado de la actividad G es de 4 semanas, por lo tanto la fecha programada de finalización será “fecha de inicio” más tiempo esperado.

2 A 5D E

1

B 3

76F G

H

4

8

J

C

9

I

309



Versión: 1.0


3. ¿Cuales actividades son críticas en el sentido de que deben terminar con exactitud como fueron programadas para llegar a la meta de la terminación del proyecto total?

• Respuesta: Las actividades de la ruta crítica son B, C, D, E, J.

4. ¿Cuánto se pueden demorar las actividades no críticas antes de provocar un retraso en la fecha de conclusión del proyecto total?

• Respuesta: Cualquier actividad no crítica puede demorarse hasta el “comienzo más tarde” sin retrasar la finalización del proyecto total.

Se debe dar respuesta a tres preguntas aún, la pregunta 2, 6 y 7. Pero antes de seguir adelante, se debe recordar que el plazo establecido para la realización del proyecto es de 22 semanas, pero el Proyecto Alfa necesita 23 semanas, con esto se puede ver que el proyecto debe ser reformulado para lograr las expectativas de realizarlo en el plazo de 22 semanas. Existen dos formas básicas de proceder:

1. Análisis estratégico:

En este tipo de análisis, surge la siguiente pregunta, ¿Tiene que desarrollarse el proyecto en la forma como está programado? En concreto ¿Se pueden hacer cambios para en la ejecución de las actividades para disminuir el tiempo total del proyecto?

310



Versión: 1.0


2. Análisis táctico: En este método el Líder de proyecto presupone que el diagrama propuesto es el adecuado y trabaja para reducir el tiempo de ciertas actividades de la ruta crítica asignándoles más recursos. Por ejemplo; los tiempos esperados en curso presuponen cierta asignación de recursos. Las 8 semanas para la actividad E suponen jornadas regulares de 8 horas. Esta actividad se podría terminar antes si se trabajan horas extras, claro está si no importa un incremento en el costo del proyecto. En el Proyecto Alfa se realiza un análisis estratégico, para ver si puede mantener el costo del proyecto propuesto. Después de algunos estudios se dan cuenta que la red de actividades propuesta presupone que la actividad J (Entrenar personal) debe realizarse en las nuevas oficinas de la empresa, este entrenamiento comenzaría su ejecución después de finalizar la actividad E (Codificar el sistema) y después que se hayan trasladado a un centro de capacitación. Después de reconsiderarlo, en el Proyecto Alfa se piensa que se pueden cambiar estos requerimientos. En primer lugar, se puede realizar la actividad J independientemente de la actividad H. La especificación anterior de que la actividad H deba ser una tarea predecesora puede ser incorrecta, se puede ver que, si se comienza a entrenar el personal en las instalaciones actuales de la empresa y tenerlos listos para comenzar a trabajar en el momento en que se termine la codificación del sistema, se podrían ganar algunos días y así poder reducir el tiempo total del proyecto. Esto implica tener que agregar una nueva actividad en el proyecto. La nueva tabla, cuadro 4 quedaría así:

311



Versión: 1.0


Cuadro N° 4: Lista de actividades del Proyecto Alfa

Tareas Descripción Predecesoras Tiempo

(semanas)

A Elegir modelo de desarrollo de software - 3

B Crear plan de proyecto - 5

C Especificaciones de requerimientos B 3

D Diseñar el sistema A, C 4

E Codificar el sistema D 8

F Verificar los requerimientos C 2

G Probar el sistema F 4

H Reparar errores del sistema F 2

I Implantar el sistema B 5

J Entrenar Personal H, G, K 3

K Asegurar entrenamiento F 3

El diagrama de red, figura 20 quedaría de la siguiente forma:

Figura N° 20: Diagrama de red del Proyecto Alfa

2 A

B

5D E

1

3

7 4 6F G

K 8

9J

C

I (5,10)

H (12,20) (5,8) (8,12)

(17,20)

(5,8)

(0,5)

312



Versión: 1.0


El diagrama de red anterior es útil, pero para el proyecto reformulado, es mejor una tabla, cuadro 5, en la que se permita ver la holgura de las actividades del proyecto reformulado: Cuadro N° 5: Lista de actividades del Proyecto Alfa reformulado

Tareas Descripción Duración

Tiempo de inicio más

Temprano (ES)

Tiempo de Inicio más

Tarde (LS)


más Temprana

(EF)


más Tarde

(LF)

Holgura (LS – ES)

A Elegir modelo de desarrollo de software

3 0 5 3 8 5

B Crear plan de proyecto 5 0 0 5 5 -

C Especificaciones de requerimientos

3 5 5 8 8 -

D Diseñar el sistema 4 8 8 12 12 -

E Codificar el sistema 8 12 12 20 20 -

F Verificar los requerimientos

2 8 11 10 13 3

G Probar el sistema 4 10 13 14 17 3

H Reparar errores del sistema

2 10 15 12 17 5

I Implantar el sistema 5 5 15 10 20 10

J Entrenar Personal 3 14 17 17 20 3

K Asegurar entrenamiento

3 10 14 13 17 4

313



Versión: 1.0


La nueva ruta crítica del proyecto, figura número 21, según los nuevos cálculos realizados en la tabla anterior:

Figura N° 21: Diagrama de Red del Proyecto Alfa reformulado Hasta este momento se ha actuado como si los tiempos de las actividades y los valores calculados para la ruta crítica (ES, LS, EF, LF) fuesen deterministas. Esto puede no ser estrictamente correcto, porque en la realidad los tiempos de las actividades regularmente no se conocen por adelantado con exactitud. Por esto la PERT emplea una fórmula especial para estimar los tiempos de actividad. El sistema PERT para estimar el tiempo de una actividad requiere de alguien que conozca muy bien la actividad a calcularle el tiempo estimado de ejecución, para poder indicar tres tiempos estimados de la actividad:

2 A (3) 5D (4) E (8)

B (5)

1

3

74 6F (2) G (4)

K (3) 8

9J (3)

C (3)

I (5)

H (2)

314



Versión: 1.0


1. Tiempo optimista: (se denota por la letra a), el tiempo mínimo. Todo tiene que marchar a la perfección para lograr este tiempo.

2. Tiempo más probable: (se denota por la letra m), el tiempo normal. El que se necesita en

circunstancias ordinarias.

3. Tiempo pesimista: (denotado por la letra b), el tiempo máximo. Una versión de la Ley de Murphy dice que si algo puede salir mal, así ocurrirá. El tiempo pesimista es el que se necesita cuando se cumple la ley de Murphy.

Por ejemplo, considerar la actividad E (Codificar el sistema). El Proyecto Alfa examina con cuidado el proyecto de y llega a las siguientes estimaciones para esta tarea:

• a = 4, m = 7, b = 16 El valor relativamente grande de b se debe a la posibilidad de demora en la entrega de un computar necesario para comenzar la operación. Si esta unidad demora, la actividad entera se retrasa. Más aún, ya que la actividad E se encuentra en la ruta crítica.

La estimación del tiempo de actividad esperado se basa en el supuesto de que ese tiempo es una variable aleatoria cuya probabilidad tiene una distribución beta unimodal. No es necesario entrar en detalles con respecto a esta distribución; en vez de ello, se debe concentrar en el procedimiento de distribución.

315



Versión: 1.0


4

a

7

m

16

t = Tiempo esperado

64 bma ++

=

b 8

t

616)7(44 ++

=

6b4ma + +t =

86

614(7)4t =++

=

Figura N° 22: Distribución Normal de los tiempos esperados.

• el tiempo estimado optimista, a, es la cota inferior del tiempo de actividad.

• el tiempo estimado pesimista, b, es la cota superior del tiempo de actividad.

• el tiempo estimado más probable, m, es la moda de esta distribución, representa el tiempo con mayor probabilidad de ocurrir.

Cuando el tiempo esperado de actividad tiene distribución beta de probabilidad, el tiempo esperado se puede calcular de la siguiente forma:

• Tiempo esperado de actividad Luego el tiempo esperado de la actividad E sería el siguiente:

• Tiempo esperado para la actividad E = 8

316



Versión: 1.0


Trabajando con el personal idóneo, el Proyecto Alfa utiliza la fórmula PERT para calcular los tiempos más probables de cada actividad, cuadro número 6: Cuadro N° 6: Lista de actividades del Proyecto Alfa con distribución normal de las duraciones.

Actividad a m b (a + 4m + b) / 6 Valor esperado

(b - a) / 6 Desv. Típica

[(b – a) / 6] 2

Varianza

A 1 3 5 3 2/3 4/9

B 3 4,5 9 5 1 1

C 2 3 4 3 1/3 1/9

D 2 4 6 4 2/3 4/9

E 4 7 16 8 2 4

F 1 1,5 5 2 2/3 4/9

G 2,5 3,5 7,5 4 5/6 25/36

H 1 2 3 2 1/3 1/9

I 4 5 6 5 1/3 1/9

J 1,5 3 4,5 3 1/2 1/9

K 1 3 5 3 2/3 4/9

La Varianza no es más que el cuadrado de la desviación típica. Es útil registrar la Varianza de cada actividad ya que se utiliza para hablar de la probabilidad de terminar el proyecto total a la fecha dada.

El hecho de que los tiempos de actividad sean variables aleatorias implica que el tiempo de finalización del proyecto sea también una variable aleatoria. Es decir, hay una variabilidad potencial

317



Versión: 1.0


en el tiempo de conclusión total. Aún cuando el Proyecto Alfa es de 20 semanas, esto no garantiza que en realidad se termine en ese tiempo. Si por casualidad varias actividades duran más que su tiempo esperado, el proyecto podría no terminar en las 22 semanas esperadas. En general resulta útil conocer la probabilidad de que el proyecto de que el proyecto se termine dentro de un tiempo especificado. En particular al Proyecto Alfa, necesita saber la probabilidad de que el proyecto se lleve al cabo en el tiempo estimado.

El análisis procede de la siguiente forma:

1. Sea T el tiempo total que durarán las actividades de la ruta crítica. 2. Encuéntrese la probabilidad de que el valor de T resulte menor o igual que cualquier valor

específico de interés. En particular, para el proyecto Alfase usará una probabilidad de

P{T≤22}. Una buena aproximación de esta probabilidad se encuentra con facilidad

aceptando dos supuestos:

a. Los tiempos de actividad son variables aleatorias independientes. Esta suposición es válida para la mayoría de las redes PERT y parece razonable para el problema del Proyecto Alfa.

b. La variable aleatoria T tiene una distribución aproximadamente normal. Esta conjetura se basa en el teorema del límite central que a grandes rasgos establece que la suma de variables aleatorias independientes tiene una distribución aproximada a la normal.

Se debe recordar que la meta es encontrar P{T≤22}, donde T es el tiempo a lo largo de la ruta

crítica; se debe convertir T a una variable aleatoria normal estandarizada, para lo cual se utiliza la tabla de ÁREAS PARA LA DISTRIBUCIÓN NORMAL ESTÁNDAR.

318



Versión: 1.0


El primer paso del proceso consiste en encontrar la desviación típica de T. Para hacerlo, se necesita la Varianza de T. Se sabe que la Varianza del tiempo total a lo largo de la ruta crítica es igual a la suma de la Varianza de los tiempos de las actividades de la ruta crítica cuando los tiempos de la actividad son independientes, luego:

• Var. T = (Var. B) + (Var. C) + (Var. D) + (Var. E) Utilizando los valores de la tabla anterior tenemos:

• Var. T = (1) + (1/9) + (4/9) + (4)

• Var. T = 50/9 Una vez obtenida la Varianza total se procede a calcular la Desviación Estándar de T, utilizando la fórmula:

).(var t=1. Desviación Estándar T

)9/50(=2. Desviación Estándar T

2,357=3. Desviación Estándar T Se procede a convertir T en variable aleatoria normal estandarizada en la forma habitual. Se recuerda que la medida es de 20 semanas (o sea el tiempo esperado de finalización), se nota que la distancia de la media a 22 semanas es:

4. (22 - 20)/2,357 = 0,8485

319



Versión: 1.0


Si se consulta la tabla de ÁREAS PARA LA DISTRIBUCIÓN NORMAL ESTÁNDAR, el área de la curva normal desde la cola del lado izquierdo hasta el punto 0.8485 desviaciones típicas, arriba de la media, se encuentra que la respuesta es de alrededor de 0.80, entonces, habrá un 80% de probabilidad de que la ruta crítica se complete en menos de 22 semanas.

Este análisis muestra como aclarar la segunda pregunta formulada al principio del presente manual, muestra como encontrar la probabilidad de que la ruta crítica termine en un tiempo dado cualquiera. El análisis del proyecto Alfa indica que al usar el tiempo esperado como “predicción de la realidad”, la duración esperada del proyecto será de 20 semanas y que, de ser así, terminará 2 semanas antes de la fecha deseada. El análisis de incertidumbre anterior ilustra más esta estimación. Ofrece una probabilidad significativa (o sea, 0.2 = 1 – 0.8) de que la ruta crítica no sea concluida en la fecha deseada. La implicación de hay por lo menos una probabilidad de 0.2 de que el proyecto termine en la fecha deseada. El modificador “al menos” se debe a las implicaciones es que siguen. Por causa de la aleatoriedad, algunas otras rutas, consideradas como críticas, pudieran tomar en realidad un tiempo mayor para concluir que el de la ruta crítica propuesta.

5.3. Conclusiones

En resumen al usar el método PERT el Líder de Proyecto debe proporcionar los siguientes datos de entrada:

1. Una lista de las actividades que integran el proyecto. 2. Las actividades predecesoras de cada actividad. 3. La duración esperada de cada actividad [t=(a+4m+b)/6]. 4. La desviación típica de la duración de cada actividad [t=(b-a)/6].

320



Versión: 1.0


• El procedimiento de estimación pesimista, la más probable y la optimista del tiempo de la actividad para obtener el valor esperado y la desviación típica de cada actividad. La desviación típica se necesita solo si el analista desea conocer inferencias probables relativas a la finalización del proyecto en una fecha determinada. El análisis usa los datos de ingreso anteriores para:

1. Calcular la ruta crítica. 2. Calcular el tiempo mínimo esperado en el que se puede concluir cada tarea. 3. Presentar los valores de holgura de cada actividad, junto con el tiempo esperado

más tardío en el que una actividad cualquiera puede empezar (o terminar) sin retrasar el proyecto.

4. Si se proporcionan estimaciones de la desviación típica, el analista puede calcular la probabilidad de que la ruta crítica en curso termine en una fecha dada.

• Si el proyecto no puede ser concluido (o es probable que así sea) en la fecha deseada, debe ser redefinido, ya sea mediante:

1. Análisis estratégico, en el que la red del proyecto se modifique introduciendo nuevas

actividades o cambiando las relaciones entre las existentes. 2. Análisis táctico, en el que se cambien los tiempos de actividades mediante la aplicación

de recursos adicionales.

• PERT no es solo un sistema de planeación, la identificación de la ruta crítica y el reporte puntual, dan al administrador del proyecto una poderosa herramienta para trabajar con el difícil problema de expresar en un programa un proyecto complicado.

321



Versión: 1.0


5.4. Sistemas de Información relacionados

• Microsoft Project: Este software de Microsoft Corporation, ayuda a crear y dar seguimiento a planes de proyecto, a administrar programas y recursos, y a analizar eficientemente la información del Proyecto.

• WBS Chart Pro: Software de Critical Tools, ayuda a elaborar el WBS en forma gráfica, se le pueden incluir costos y duraciones, además la interfase con el Microsoft Project permite elaborar el programa.

• @ Risk for Project: De Palisade Corporation, es una herramienta que funciona en conjunto con el Microsoft Project y permite el análisis de riesgo y simulación a través del método Monte Carlo. Provee diferentes escenarios para hacer un análisis e identificar situaciones críticas que pueden influir en el proyecto.

6. Plantillas y Listas de Verificación Asociados


AP-GTE-02 Guía de Técnicas de Estimación

Fin del Documento.

322



Versión: 1.0




Nombre:

Preparado Firma: Fecha:

Nombre:


Nombre:

Revisado Firma: Fecha:

Nombre:


Nombre:


323

324

4.3.2.2. GUÍA DE TÉCNICAS DE ESTIMACIÓN. Esta guía es un material de referencia obligatoria durante la planificación, ejecución, seguimiento y control de los proyectos informáticos de la Defensoría de los Habitantes. Si no se utiliza, el Administrador de Proyectos deberá asegurarse de que el Líder de Proyectos y el Equipo de Planificación conocen y aplican éstas herramientas y técnicas en forma apropiada. Su objetivo es guiar al equipo de planificación en la definición y aplicación de herramientas y técnicas de Administración de Proyectos necesarias para estimar métrica y objetivamente la duración de los proyectos informáticos de la Defensoría de los Habitantes. El desarrollo completo de esta herramienta está descrito en la Guía Técnicas de Estimación (AP-GTE-02), detallado en adelante:



GUÍA DE TÉCNICAS DE ESTIMACIÓN (AP-GTE-02)

Versión


Autor:

Mes, año

325


Administración de Proyectos Informáticos Guía de Técnicas de Estimación Referencia: AP-GTE-02

Versión: 1.0

AP-GTE-02 Guía Técnicas de Estimación, V1.0 Página 2 de 20

TABLA DE CONTENIDOS

1. OBJETIVOS.......................................................................................... 4

2. ÁMBITO ................................................................................................ 4

3. REFERENCIAS..................................................................................... 4

4. FUNCIONES Y RESPONSABILIDADES ............................................. 5

5. GUÍA ..................................................................................................... 5

5.1. PROCESO DE ESTIMACIÓN............................................................... 5

5.2. TÉCNICAS DE ESTIMACIÓN............................................................... 6

5.2.1. Método de Juicio Experto...................................................................... 7

5.2.2. Método de Puntos de Función. ............................................................. 9

5.2.3. Método de estimación basado en transacciones. ............................... 15

5.3. AFINAMIENTO DE LA TÉCNICA DE ESTIMACIÓN. ........................ 17

5.4. Sistemas de Información relacionados........................................... 18

6. Plantillas y Listas de Verificación Asociados................................. 19

326



Versión: 1.0




327



Versión: 1.0


TÉCNICAS DE ESTIMACIÓN PARA PROYECTOS INFORMÁTICOS

1. OBJETIVOS

Guiar al equipo de planificación en la definición y aplicación de herramientas y técnicas de Administración de Proyectos necesarias para estimar métrica y objetivamente la duración de los proyectos informáticos de la Defensoría de los Habitantes.

2. ÁMBITO

Esta guía es material de referencia obligatoria durante la planificación, ejecución, seguimiento y control de los proyectos informáticos de la Defensoría de los Habitantes. Si no se utiliza, el Administrador de Proyectos deberá asegurarse de que el Líder de Proyectos y el Equipo de Planificación conocen y aplican éstas herramientas y técnicas en forma apropiada.

3. REFERENCIAS

Nombre Archivo Título del Documento




AP-GHT-01 Guía de Herramientas y Técnicas

328



Versión: 1.0


PLA-PGT-02 Plan de Gestión del Tiempo

4. FUNCIONES Y RESPONSABILIDADES

Administrador del Proyecto El Administrador del proyecto es responsable por la elaboración de las métricas correspondientes y por comprobar que efectivamente las mismas sean completadas al finalizar cada proyecto

Líder del Proyecto Es responsable de proponer los planteamientos a resolver con el uso de estas técnicas, así como de tomar las decisiones requeridas para el proyecto en base a los resultados obtenidos.

Equipo de Planificación Son responsables de utilizar las herramientas y técnicas descritas en forma eficaz y eficiente, a lo largo de toda la duración del proyecto.

5. GUÍA

5.1. PROCESO DE ESTIMACIÓN.

La generación de estimados confiables ha sido uno de los principales problemas que ha enfrentado la administración de proyectos y en sí el desarrollo de cualquier tipo de proyecto informático desde sus inicios. No ha existido una disciplina real, a pesar que existe la teoría suficiente, que permita establecer medidas confiables sobre los procesos productivos en tecnologías de información, además de las características de la rápida evolución de la industria y de trabajar en una gran proporción con productos intangibles o poco cuantificables.

329



Versión: 1.0


Por lo general las estimaciones para los proyectos, son muy vulnerables y poco defendibles por sus creadores, en buena parte debido a que son producto de estudios superficiales, basadas en datos prematuros y sin un proceso real de retroalimentación de la efectividad de las mismas. Se requiere una dosis considerable de constancia en la aplicación de procedimientos sistemáticos para la estimación y su evolución, los resultados no se obtienen en el plazo inmediato ni es un proceso con una finalización definida. El proceso de estimación presenta el manejo de un nivel de probabilidad y de riesgo, al ejercitarse para proyectar variables del tiempo presente, a un futuro no muy claro. La identificación de los factores de riesgo, su ocurrencia y mitigación se señalan en el capítulo seis de este documento. Es vital para el proceso de estimación la utilización y generación de información histórica sobre el desempeño y desviaciones en proyectos anteriores, de tal forma que la misma le facilite a los estimadores el establecer correlaciones respecto al proyecto que están evaluando. Al respecto, en el punto 1.3 se especifica la información básica que puede ser utilizada para formar la base de conocimiento necesaria para mejorar los procesos de estimación, así como para el cálculo de métricas que son de utilidad para la formulación de proyectos.

5.2. TÉCNICAS DE ESTIMACIÓN.

Seguidamente se detallan los métodos sugeridos para realizar las estimaciones en los proyectos informáticos de la Defensoría de los Habitantes, como regla general deben ser utilizados al menos dos de estos métodos al confeccionar la estimación de cualquier proyecto. Estos procesos de estimación están en constante evolución, por lo que antes de utilizar las métricas y tablas mostradas en cada método, se debe verificar que correspondan a las últimas versiones, así como la retroalimentación con otros equipos de trabajo que anteriormente utilizaron estos esquemas. Al

330



Versión: 1.0


respecto, el control de estas herramientas y su evolución es una de las responsabilidades que le son asignadas al Administrador de Proyectos de la Defensoría de los Habitantes.

5.2.1. MÉTODO DE JUICIO EXPERTO.

Uno de los métodos más sencillos de aplicar para mejorar nuestras estimaciones corresponde al denominado Juicio Experto o Método Delphi. El procedimiento para aplicarlo consta de los siguientes pasos:

I. Especificar la base para estimaciones.

El encargado de la estimación define claramente en un documento las características del proyecto que se desea estimar, esta información incluye alcances de la aplicación, la clasificación de riesgos, la estrategia propuesta para el desarrollo, la estructura organizacional propuesta y la tecnología a utilizar. Es muy importante que en esta información no se muestren tendencias ni juicios personales.

II. Distribución de bases para estimación.

Se eligen entre tres y cinco personas que posean conocimientos del área en estudio y con suficiente experiencia en el desarrollo de proyectos. Estas personas no deben conocer cuales son sus compañeros del equipo de estimación, para así minimizar el efecto de la influencia de una persona a otra, de lo contrario se perdería parte de la efectividad del método. Estos estimadores deben ser elegidos por el Administrador de Proyectos designado.

331



Versión: 1.0


III. Estimaciones iniciales.

Las personas elegidas especifican, por separado, sus estimaciones para el proyecto en lo que respecta a actividades, tiempo y recursos, así como los comentarios que se consideren pertinentes. Estas estimaciones son evaluadas para determinar coincidencias y diferencias. En esta parte del trabajo, interesan más las diferencias, por lo que se le solicita a cada miembro que justifique aquellos puntos donde presentó mayor diferencia con el resto de estimadores. Nuevamente esta justificación es desarrollada por separado por cada estimador.

IV. Análisis final.

Con las estimaciones y justificaciones individuales, se realiza una sesión de discusión de las estimaciones correspondientes. El objetivo de este análisis final es buscar el consenso en las estimaciones, no obstante, de no lograrlo se utilizarán los valores en que más coincidencia exista. Esta última sesión, de preferencia, no debe extenderse por más allá de una hora, ya que de lo contrario se podría volver en un proceso muy costoso.

Este método es recomendable cuando se enfrenten situaciones novedosas, de las cuales existe poca experiencia documentada, donde además sea poco factible aplicar procedimientos largos y costosos. Estudios de factibilidad y justificaciones son campos de aplicación de este método. La aplicación de este método también puede ser parcial, indicándoles a los expertos que sólo estimen una porción del proyecto, con lo cual se logra por lo general un mayor grado de detalle y precisión. Con la porción del proyecto estimada se aplican relaciones respecto de

332



Versión: 1.0


otros proyectos ejecutados en la Defensoría, para así poder proyectar la duración completa del proyecto. Las estimaciones que realicen los expertos deben estar sobre la misma base de requerimientos, recursos, plataforma tecnológica y herramientas. Estas variables le deben ser especificadas claramente a cada uno de los estimadores participantes, de lo contrario la técnica no generará resultados que sean realmente utilizables.

5.2.2. MÉTODO DE PUNTOS DE FUNCIÓN.

El método de Puntos de Función esta basado en la visión de utilidad o funcionalidad que se tiene de una aplicación, por lo que de alguna manera se obtiene algún nivel de independencia de aspectos puramente técnicos. Una de las ventajas más importantes de este método es que el conocimiento necesario para llevar a cabo el proceso de estimación se puede obtener desde las primeras etapas del proyecto, por lo que no es necesaria una inversión sustancial en su aplicación. El método tiene su fundamento en la identificación de los elementos denominados Dominios de la Información, que comúnmente son agrupados en las siguientes categorías:

a) Entradas de Información.

Son aquellas entradas de información que proceden desde fuera de los límites automatizados y que provocan cambios en los datos internos del Sistema.

b) Salidas de Información.

Son todas aquellas salidas de información que rebasan los límites del Sistema y que además son únicas en formato y proceso.

333



Versión: 1.0


c) Peticiones de Información.

Son todas aquellas salidas que resultan de la interacción en línea entre el usuario y el Sistema, lo que comúnmente llamamos consultas.

d) Cantidad de Archivos Lógicos.

Son todas aquellas agrupaciones de datos que se detecten en el Sistema. No necesariamente estos deben corresponder con archivos físicos, pues es poco probable encontrar estas definiciones al inicio de un proyecto.

e) Cantidad de Interfaces Externas.

Son todas aquellas interfaces electrónicas que existan con otros sistemas de la Institución.

Para cada uno de estos elementos del dominio se establece una valoración de puntos de función según la complejidad del mismo, como tabla de partida se establece la siguiente: Cuadro N° 7: Método de Puntos de Función.

Dominio de Información

Ponderación Simple

Ponderación Mediana

Ponderación Compleja

Núm. Entradas 3 4 6

Núm. Salidas 4 5 7

Núm. Consultas 3 4 6

Núm. Archivos 6 7 10

Núm. Interfaces 5 7 10

El procedimiento para su utilización sigue los siguientes pasos principales:

334



Versión: 1.0


I. Con el resultado del estudio preliminar se realiza un conteo de los dominios de información anteriormente señalados, indicando para cada uno cuantos elementos son simples, de mediana complejidad o complejos. Esta sección incluye cierto nivel de subjetividad, no obstante para estandarizar la identificación de la complejidad se deben considerar los datos y las características del proceso asociado a cada elemento. Por ejemplo, salidas que contengan cuatro o menos elementos de datos son simples, de cinco a diez son mediana y más de diez son complejas. Este mismo principio se debe aplicar para cada uno de los dominios de información indicados.

II. Se debe completar la tabla de totales de cada dominio, multiplicando el factor de ponderación correspondiente por la cantidad de dominios de ese tipo detectados en el Sistema. La tabla sería similar a la siguiente:

Cuadro N° 8: Ponderación del método de puntos de función

Dominio de Información

Totales Ponderación Simple

Totales Ponderación Mediana

Totales Ponderación Compleja

TOTAL

Núm. Entradas

Número de Entradas Simples * 3

Número de Entradas Medianas * 4

Número de Entradas Complejas * 6

Núm. Salidas

Número de Salidas Simples * 4

Número de Salidas Medianas * 5

Número de Salidas Complejas * 7

Núm. Consultas Número Consultas Simples * 3

Número Consultas Medianas * 4

Número Consultas Complejas * 6

Núm. Archivos

Número de Archivos Simples * 6

Número de Archivos Medianos * 7

Número de Archivos Complejos * 10

Núm. Interfaces Número Interfaces Simples * 5

Número Interfaces Medianas * 7

Número Interfaces Complejas * 10

335



Versión: 1.0


III. La suma total de los datos anteriores debe ser ajustada por medio de la siguiente fórmula:

Puntos de Función = Suma Total x (0,65 + 0,01 x SUM (Factores de Ajuste))

Donde los factores de ajuste corresponden a la calificación de la respuesta a las siguientes catorce consideraciones:

a) ¿Requiere el sistema copias de seguridad y de recuperación fiables? b) ¿Se requiere comunicación de datos? c) ¿Existen funciones de procesamiento distribuido? d) ¿Es crítico el rendimiento? e) ¿Será ejecutado el proyecto en un entorno operativo existente y fuertemente

utilizado? f) ¿Requiere el sistema de entrada de datos interactiva? g) ¿Requiere la entrada de datos interactiva de múltiples pantallas para su

captura? h) ¿Se actualizan los maestros de manera interactiva? i) ¿Son complejas las entradas, salidas, los archivos o las consultas? j) ¿Es complejo el procesamiento interno? k) ¿Se ha diseñado el código o se planea el mismo para ser reutilizable? l) ¿Están incluidas en el plan del proyecto la conversión y la instalación? m) ¿Será el sistema utilizado tanto de manera interna como externa a la

Defensoría? n) ¿Es necesaria la participación de empresas o entidades externas a la

Defensoría para lograr el desarrollo?

La respuesta a cada pregunta anterior debe ser cuantificada según la siguiente calificación:

Calificación Influencia Sin influencia 0

Accidental 1

336



Versión: 1.0


Calificación Influencia Moderado 2

Medio 3

Significativo 4

Esencial 5

IV. En este momento ya se tiene el total de puntos de función que posee el Sistema, por lo

que se pueden utilizar métricas anteriores para estimar el esfuerzo necesario para llevar a cabo el proyecto. Así, para cada plataforma que se utilice en la Defensoría se debe especificar cuantas horas-persona son requeridas para desarrollar un punto funcional, la cantidad de líneas de documentación por punto de función o el costo por cada punto de función. De esta forma, y de acuerdo a la experiencia generada en desarrollos en lenguajes de cuarta generación, se estima que por cada punto de función en una plataforma determinada se requieren dos horas de programación, por lo que el número total de puntos de función multiplicado por dos horas dará el tiempo total (en horas-persona) que debe ser invertido para completar la programación. Este tiempo en horas se debe convertir a días-persona, dividiéndolo entre seis horas efectivas por día. Si además se requiere el cálculo por mes-persona, se debe dividir la cantidad de días-hombre entre veinte, asumiendo esta cantidad de días hábiles por cada mes.

V. El siguiente paso es proyectar el resultado del punto anterior para obtener la duración total del proyecto. Esto se logra dividiendo el número de días-persona o meses-persona entre la cantidad de programadores que se utilizarán en el proyecto, esto dará el tiempo

337



Versión: 1.0


total de programación. Este tiempo de programación se debe analizar con respecto a la siguiente tabla de distribución de esfuerzo normal:

Cuadro N° 9: Tabla de distribución de esfuerzo normal

ETAPA DE DESARROLLO PORCENTAJE DEL TOTAL DEL PROYECTO

Estudio de Factibilidad 4% - 7%

Estudio de Requerimientos 12% - 17%

Diseño Conceptual 15% - 20%

Diseño Físico 12% - 17%

Programación 17% - 22%

Pruebas e Integración 18% - 23%

Implantación 8% - 12%

Al aplicar el tiempo resultante para la programación en la tabla anterior, es factible obtener estimados para el resto de las etapas del ciclo de desarrollo. Por ejemplo, si el cálculo de puntos de función señala que la actividad de programación requiere de tres meses, esto representa aproximadamente un 20% del tiempo total del proyecto, por lo que la duración total debe estar cercana los quince meses. Los estimados de esfuerzo de la tabla anterior están basados en observaciones sobre desarrollos utilizando una metodología tradicional en plataformas de cuarta generación y esquemas relacionales, por lo que es necesario considerar variantes a los porcentajes cuando se utilizan técnicas de apoyo como prototipos o cuando se utilizan plataformas diferentes.

338



Versión: 1.0


En caso que lo deseado sea calcular la cantidad de recursos requeridos, se debe estipular el tiempo en que se desea o se debe tener la solución, extraer el tiempo correspondiente a la etapa de programación (aproximadamente un 20% del total). Dividiendo el total de días-persona o meses-persona resultantes del cálculo de puntos de función, entre el tiempo de programación, se obtiene la cantidad de recursos de programación que son necesarios para cumplir con esta actividad del ciclo de desarrollo. Como puede ser deducido del procedimiento anterior, se requiere de un proceso previo de generación de puntos de función en una cantidad representativa de proyectos para lograr construir una base sólida para la estimación de los proyectos venideros en la Defensoría. De la misma forma, los factores de ajuste, las ponderaciones de los dominios de información, la cantidad de horas de programación por cada punto de función y la distribución de porcentajes de tiempo para cada actividad del ciclo de desarrollo, deberán ser ajustados paulatinamente según la experiencia propia de la Defensoría. Esta evolución del método sólo es posible si existe la disciplina y el convencimiento en la recolección de métricas del comportamiento histórico, ya que este es el único camino seguro para mejorar la efectividad en las estimaciones.

5.2.3. MÉTODO DE ESTIMACIÓN BASADO EN TRANSACCIONES.

Uno de los métodos intuitivos más sencillos y de más fácil interpretación por parte del personal técnico, son las estimaciones basadas en transacciones. Este método consiste en la identificación y clasificación de las transacciones que se considera tendrá el sistema, y clasificarlas según su nivel

339



Versión: 1.0


estimado de complejidad. Luego de efectuar las tareas correspondientes al Análisis Preliminar y Estudio de Requerimientos se debe completar la siguiente tabla resumen de transacciones: Cuadro N° 10: Método de estimación basado en transacciones.

TIPO TRANSACCIÓN

COMPLEJIDAD CANTIDAD DURACIÓN BASE

TOTALES

Pantallas Baja 99 3horas 99

Media 99 5horas 99

Alta 99 8horas 99

Reportes Baja 99 4horas 99

Media 99 6horas 99

Alta 99 10horas 99

Actualización Baja 99 5horas 99

Media 99 8horas 99

Alta 99 12horas 99

Totales 99999

En esta tabla se indica la duración que en promedio se tarda confeccionando (programación y pruebas de unidad) cada tipo de transacción, según la complejidad que presente la misma. Posteriormente se colocan las cantidades totales de transacciones de cada tipo y se multiplican por las horas necesarias para su confección, con lo que se obtiene la última columna correspondiente a totales. Debe tomarse en cuenta que las horas estipuladas bajo la columna de duración base corresponden a horas-persona utilizando un lenguaje de cuarta generación con base de datos relacionales, por lo

340



Versión: 1.0


que los datos finales deben ser ajustados según sea la cantidad de recursos que participarán en el desarrollo, la experiencia técnica con que se cuente, el nivel de reutilización que se utilice y a los cambios en la plataforma de desarrollo. Nuevamente, este método brinda una estimación del tiempo necesario para la programación, el cual debe ser proyectado a todo el ciclo de desarrollo según la tabla de distribución porcentual que se mostró en la sección anterior. Por lo general, y ante lo prematuro de la estimación de transacciones, se recomienda utilizar un porcentaje de desviación sobre el resultado obtenido en la tabla resumen. Este porcentaje debe ser calculado en función del dominio del área, el tamaño de la aplicación, el tamaño del equipo de trabajo y la plataforma de desarrollo. No obstante, ningún porcentaje de desviación podrá ser superior al 20%, ya que aplicar factores superiores estará denotando que los estudios previos para la formulación de las estimaciones requieren de mayor profundidad. El mismo principio utilizado por este método puede ser utilizado para estimar basados en entidades, donde luego de identificar las entidades más importantes, estas se clasifican por complejidad según sea la cantidad y dificultad de los procesos que cada una estas entidades tenga asociados.

5.3. AFINAMIENTO DE LA TÉCNICA DE ESTIMACIÓN.

Cualquier método de estimación es vaga especulación, si no esta fundamentado en experiencias anteriores. Por lo que es necesario que cada proyecto que se emprenda desarrolle y alimente las métricas de planificación correspondientes, y al finalizar el mismo se calculen las métricas específicas sobre el trabajo desarrollado.

341



Versión: 1.0


El poder contar con los datos sobre las métricas correspondientes, una vez terminado cada proyecto, permitirá que en siguientes desarrollos se cuente con información real sobre el comportamiento del proceso de desarrollo en la Defensoría de los Habitantes. El Administrador del proyecto es responsable por la elaboración de las métricas correspondientes y por comprobar que efectivamente las mismas sean completadas al finalizar cada proyecto. Para tal efecto, es importante que se complete un formato con la siguiente información básica al finalizar cada proyecto:

a) Identificación del Proyecto. b) Área Usuaria atendida. c) Plataforma de desarrollo. d) Administrador del proyecto e) Fechas en que fue desarrollado. f) Cantidad de Recursos Humanos Técnicos que participaron. g) Cantidad de Usuarios que participaron. h) Breve descripción del Proyecto. i) Línea base del proyecto. j) Duración real del proyecto y de cada una de sus actividades. k) Documentación del desfase en cada actividad l) Supuestos, dependencias y restricciones que no se cumplieron.

5.4. SISTEMAS DE INFORMACIÓN RELACIONADOS

• Microsoft Project: Este software de Microsoft Corporation, ayuda a crear y dar seguimiento a planes de proyecto, a administrar programas y recursos, y a analizar eficientemente la información del Proyecto.

342



Versión: 1.0


• WBS Chart Pro: Software de Critical Tools, ayuda a elaborar el WBS en forma gráfica, se le pueden incluir costos y duraciones, además la interfase con el Microsoft Project permite elaborar el programa.

• @ Risk for Project: De Palisade Corporation, es una herramienta que funciona en conjunto con el Microsoft Project y permite el análisis de riesgo y simulación a través del método Monte Carlo. Provee diferentes escenarios para hacer un análisis e identificar situaciones críticas que pueden influir en el proyecto.

6. PLANTILLAS Y LISTAS DE VERIFICACIÓN ASOCIADOS


Fin del Documento.

343



Versión: 1.0




Nombre:


Nombre:


Nombre:

Revisado Firma: Fecha:

Nombre:


Nombre:


344

345

4.3.2.3. GUÍA DE REUNIONES. Esta guía de reuniones del personal de proyectos (por ej., reuniones de personal, reuniones de estado, reuniones de entrega o revisión de productos) y de calidad (por ej., revisiones, inspecciones) es un instrumento de ayuda para garantizar que todas las sesiones de trabajo de los proyectos informáticos de la Defensoría de los Habitantes se programan y transcurren de forma eficiente y resultan efectivas a la hora de conseguir sus objetivos propuestos. Esta guía puede utilizarse para cualquier otro tipo de reunión de la Defensoría de los Habitantes. Si no se utiliza, el Presidente de la reunión deberá asegurarse de que se establecen controles equivalentes y apropiados. Contiene este desarrollo una serie de plantillas de utilidad que dan soporte a la guía, estas son:

• (APGR-PCR-04) Plantilla Convocatoria de Reunión • (APGR-PCA-05) Plantilla Control de Audiencia • (APGR-PAR-06) Plantilla Acta de Reunión • (APGR-PSA-07) Plantilla Seguimiento de Acuerdos • (APGR-PMR-08) Plantilla Minuta de Reunión • (APGR-PIEA-09) Plantilla Informe Estado de Acciones

El desarrollo completo de esta herramienta está descrito en la Guía de Reuniones (AP-GR-03), que a continuación se detalla:



GUÍA DE REUNIONES (AP-GR-03)

Versión


Autor:

Mes, año

346


Administración de Proyectos Informáticos Guía de Reuniones Referencia: AP-GR-01

Versión: 1.0

AP-GR-01 Guía de Reuniones, V1.0 Página 2 de 9

TABLA DE CONTENIDOS

1. Objetivos ................................................................................................. 4 2. Ámbito ..................................................................................................... 4 3. Referencias ............................................................................................. 4 4. Funciones y Responsabilidades ........................................................... 4 5. Guía.......................................................................................................... 5 5.1. Programación de la Reunión .................................................................... 5

5.2. Durante la Reunión ................................................................................... 5

5.3. Tras la Reunión ........................................................................................ 7

6. Formularios y Listas de Verificación Asociados ................................. 8

347



Versión: 1.0




348



Versión: 1.0


GUÍA DE REUNIONES

1. Objetivos Garantizar que todas las reuniones de los proyectos informáticos de la Defensoría de los Habitantes se programan y transcurren de forma eficiente y resultan efectivas a la hora de conseguir sus objetivos propuestos.

2. Ámbito Todas las reuniones de personal (por ej., reuniones de personal, reuniones de estado, reuniones de entrega o revisión de productos) y de calidad (por ej., revisiones, inspecciones) deben seguir esta guía. Esta guía puede utilizarse para cualquier otro tipo de reunión de la Defensoría de los Habitantes. Si no se utiliza, el Presidente de la reunión deberá asegurarse de que se establecen controles equivalentes y apropiados.

3. Referencias Ninguna.


Presidente Es responsable de programar y participar en la reunión, identificando el resultado esperado, así como de finalizar las unidades de acción resultantes de la reunión.

Participantes Son responsables de prepararse para la reunión y de completar las unidades de acción que se les asignen.

349



Versión: 1.0


5. Guía

5.1. Programación de la Reunión El Presidente programa la reunión:

a. Identificando los participantes necesarios. b. Acordando con estos participantes la utilidad de una reunión. c. Enviando un aviso de la reunión a los participantes, empleando la plantilla Convocatoria de

Reunión (APGR-PCR-04), que contiene lo siguiente: • objetivos de la reunión • fecha, horas de inicio y fin y ubicación de la reunión • programa de la reunión • requisitos de preparación, si los hubiere.

Se recomienda que el programa incluya lo siguiente:

• revisión de los objetivos y programa de la reunión • revisión del estado de las unidades de acción destacables • contenidos de la reunión • revisión de las unidades de acción que surjan de la reunión • fecha de la siguiente reunión, si es necesario.

d. Los participantes informan al Presidente si les es posible asistir a la reunión y completar la preparación necesaria antes de la celebración de la misma.

5.2. Durante la Reunión

a. Los participantes registran su participación en la entrada del lugar de celebración firmando el documento Control de Audiencia, (APGR-PCA-05), antes de que inicie la misma.

350



Versión: 1.0


b. El Presidente verifica que se tienen los formularios necesarios de acuerdo al tipo de reunión,

y que son requeridos como instrumentos de verificación u aprobación.

c. El Presidente dirige la reunión, controla el ritmo de la misma y garantiza que se cumplen sus objetivos.

d. El Presidente tiene la opción de cancelar la reunión si los participantes principales no asisten

a ella.

e. El Presidente se asegura de que se designa a un participante comos secretario para que registre las actas de la reunión, utilizando la plantilla Acta de Reunión (APGR-PAR-06).

f. El Presidente procederá a hacer una revisión del estado de acuerdos anteriores. Estos

acuerdos deben ser registrados en el documento Seguimiento de Acuerdos (APGR-PSA-07).

g. El Presidente desarrolla y ejecuta el programa de reunión.

h. Si el tiempo permitido para la celebración de la reunión es insuficiente, el Presidente

solicitará a los participantes que voten para decidir si desean que se prolongue, si desean programar una reunión de seguimiento o modificar los objetivos de la reunión.

i. Durante la reunión, pueden presentarse unidades de acción. Éstas deberán asignarse a un

miembro del personal (con su consentimiento) y una fecha objetivo establecida para su finalización.

351



Versión: 1.0


5.3. Tras la Reunión

a. El Presidente procede a registrar los nuevos acuerdos en el documento Seguimiento de

Acuerdos (APGR-PSA-07). b. Uno ó dos días después de la reunión, el participante designado publica las minutas de

reunión. Las Minutas incluyen: 1. fecha, hora y objetivos de la reunión 2. asistentes a la reunión y “justificaciones” (invitados que no asisten) 3. resumen del resultado de la reunión 4. unidades de acción que surgen de la reunión, así como la persona responsable

de la acción y la fecha de finalización de objetivo 5. fecha de la siguiente reunión, si es necesario.

c. Las Minutas de la Reunión son registradas en el documento Minuta de Reunión (APGR-PMR-08).

d. Las Minutas de Reunión se distribuyen entre los participantes y el Presidente se asegura de que se archiva una copia en el Archivo del Proyecto.

e. El Presidente supervisa el progreso de las unidades de acción resultantes y se asegura de que se han completado todas.

f. Si las unidades de acción se programan para su finalización más de un mes después de la fecha de la reunión, el Presidente publica un informe de estado de acción mensual hasta que se completen todas las unidades de acción. Este informe de estado se envía a los participantes y se introduce una copia en el archivo correspondiente.

g. El informe de estado de acciones se registra en el documento Informe Estado de Acciones (APGR-PIEA-09).

h. El Presidente verifica que todos los formularios utilizados en la reunión fueron observados y aprobados.

352



Versión: 1.0


6. Formularios y Listas de Verificación Asociados

Nombre del Archivo Título del Documento APGR-PCR-04 Plantilla Convocatoria de Reunión

APGR-PCA-05 Plantilla Control de Audiencia

APGR-PAR-06 Plantilla Acta de Reunión APGR-PSA-07 Plantilla Seguimiento de Acuerdos APGR-PMR-08 Plantilla Minuta de Reunión

APGR-PIEA-09 Plantilla Informe Estado de Acciones

CON-LVCRAP-06 Lista de Verificación Comprobación de la Reunión de Aprobación del Proyecto

PLA-LVRAPGP-02 Lista de Verificación Reunión de Aceptación del Plan de Gestión del Proyecto

SEG-PRAFEP-05 Plantilla Reunión de Aceptación de Fases/Etapas del Proyecto

SEG-LVRAFEP-06 Lista de Verificación Reunión de Aceptación de Fases/Etapas del Proyecto

FIN-LVRRCP-01 Lista de Verificación Reunión Revisión y Cierre del Proyecto

Fin del Documento.

353



Versión: 1.0









354

355

4.3.2.3.1. (APGR-PCR-04) PLANTILLA CONVOCATORIA DE REUNIÓN

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Convocatoria de Reunión Referencia: APGR-PCR-04 Versión: 1.0

APGR-PCR-04 Convocatoria de Reuniones, V1.0 Página 1 de 1

CONVOCATORIA DE REUNIÓN

PROYECTO: REFERENCIA: REUNION: HORA INICIO:

LUGAR: HORA FIN: FECHA:

CONVOCADOS NOMBRE RECIBIDO NOMBRE RECIBIDO

OBJETIVOS DE LA REUNIÓN:

# OBJETIVOS … … … … … … … …

PROGRAMA DE LA REUNIÓN:

HORA ASUNTO / PERSONA … … … … … …

REQUISITOS DE PREPARACIÓN:

HORA ASUNTO / PERSONA … … … … … …

356

357

4.3.2.3.2. (APGR-PCA-05) PLANTILLA CONTROL DE AUDIENCIA


Administración de Proyectos Informáticos Plantilla Control de Audiencia Referencia: APGR-PCA-05

Versión: 1.0

APGR-PCA-05 Control Audiencia, V1.0 Página 1 de 1

Actividad: <Se anota el nombre y una descripción breve de la actividad a realizar >

Responsable: <Nombre del responsable de la actividad>

Fecha: <Fecha de realización>

Hora de inicio: <Hora en que inicia la actividad> Hora de finalización:

<Hora en que finaliza la actividad>

Hora de ingreso Nombre del participante Firma del participante 1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

Observaciones: <Cualquier comentario adicional u observación referente a la actividad>

358

359

4.3.2.3.3. (APGR-PAR-06) PLANTILLA ACTA DE REUNIÓN

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Acta de Reunión Referencia: APGR-PAR-06 Versión: 1.0

APGR-PAR-06 Acta de Reunión, V1.0 Página 1 de 2

ACTA DE REUNIÓN REUNIÓN N°:

OBJETO:

PROYECTO: REFERENCIA:

FECHA: HORA: LUGAR:

ASISTENTES A LA REUNION

NOMBRE PARTE DE CARGO 1. INTRODUCCION ------------- ------------- ------------- 2. TEMAS TRATADOS EN LA REUNION ------------- ------------- ------------- 3. CONCLUSIONES ------------- ------------- ------------- 4. ACUERDOS Y ACTIVIDADES FUTURAS ------------- ------------- -------------

360

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Acta de Reunión Referencia: APGR-PAR-06 Versión: 1.0

APGR-PAR-06 Acta de Reunión, V1.0 Página 2 de 2

5. REGISTRO DE ACCIONES

ACCIÓN Nº Responsable Fecha

DESCRIPCIÓN

361

362

4.3.2.3.4. (APGR-PSA-07) PLANTILLA SEGUIMIENTO DE ACUERDOS

Fecha revisión:

Nº Minuta Nº Acuerdo Descripción del Acuerdo

Fecha de Compromiso Responsable Fecha de

Cumplimiento Estado Observaciones

SEGUIMIENTO DE ACUERDOS DEL PROYECTO <NOMBRE DEL PROYECTO>

APGR-PSA-07 Seguimiento de Acuerdos, V 1.0 Página 1 de 1

Revisado por:<dd/mm/aa en que se realiza elseguimiento><Responsable del seguimiento>

363

364

4.3.2.3.5. (APGR-PMR-08) PLANTILLA MINUTA DE REUNIÓN


Administración de Proyectos Informáticos Plantilla Minuta de Reunión Referencia: APGR-PMR-08

Versión: 1.0

APGR-PMR-08 Minuta Reunión, V1.0 Página 1 de 2

<<NNOOMMBBRREE DDEELL PPRROOYYEECCTTOO>> MMIINNUUTTAA << SSIIGGLLAASS DDEELL PPRROOYYEECCTTOO >>NN°° XXXX –– AAÑÑOO ((220000XX--220000XX))

Fecha: <Fecha de realización> Lugar: <Lugar donde se lleva a cabo la actividad>

Hora de Inicio: <Hora en que inicia la

actividad> Hora Final: <Hora en que finaliza la actividad>

Asistentes a la reunión

Nombre Puesto o rol, Empresa 1.

2.

3.

Ausentes a la reunión Nombre Puesto o rol, Empresa

1.

2.

3.

Objetivos de la reunión <Texto descriptivo breve del objetivo de la reunión>

365


Administración de Proyectos Informáticos Plantilla Minuta de Reunión Referencia: APGR-PMR-08

Versión: 1.0

APGR-PMR-08 Minuta Reunión, V1.0 Página 2 de 2

Agenda de la reunión

1. Introducción sobre el objetivo de la reunión 2. Lectura y firma de la minuta anterior 3. Seguimiento de acuerdos anteriores 4. Puntos específicos a tratar 5. Resumen de acuerdos 6. Cierre de la reunión.

1. Puntos específicos tratados <Tantos como puntos se trataron. Cada punto se incluye en una tabla individual con sus respectivos acuerdos > Asunto: <Texto descriptivo de lo hablado > Acuerdos a los que se llega: Responsable: Fecha de compromiso: <Detalle de los acuerdos tomados> <Nombre del responsable del

acuerdo> <dd/mm/aa>

Firmas de los presentes

Responsable Rol Empresa o dependencia

Firma Fecha

1. 2. 3.

Nombre y firma

Nombre y firma

Nombre y firma

< Rol >

< Rol>

< Rol >

366

367

4.3.2.3.6. (APGR-PIEA-09) PLANTILLA INFORME ESTADO DE ACCIONES

Defensoría de los Habitantes Administración de Proyectos Informáticos Plantilla Estado de las Acciones Referencia: APGR-PEA-09 Versión: 1.0

APGR-PEA-09 Estado Acciones, V1.0 Página 1 de 1

ESTADO DE LAS ACCIONES CONSIGNADAS Proyecto: Referencia:

FECHA MINUTAS ACCION DESCRIPCION RESPONSABLE ESTADO FECHA

COM Completado REV A revisar PEN Pendiente ? Desconocido CUR En curso - - Otros

368

369

4.3.2.4. FLUJOGRAMA DE APLICACIÓN DE LA METODOLOGÍA. El flujograma de aplicación es una herramienta gráfica, la cual consiste en una propuesta para implementar el estándar modelo desarrollado en este proyecto. El flujograma hace referencia a elementos que están fuera del alcance de esta tesis (a incluir en nuevas versiones) que complementan el marco global de la metodología de administración de proyectos. El desarrollo completo de esta herramienta está descrito en la Guía Flujograma de Aplicación de la Metodología (AP-GFAM-10), el cual se muestra en adelante:

Departamento de InformáticaAdministración de Proyectos Informáticos

Flujograma de Aplicación de la Metodología

Referencia: AP-GFAM-10Versión: 1.0

370

2

LV - Lista de Verificación (Checklist) del proceso

Documento “obligatorio” de gestión del proyecto

Archivar el resultado (documento, software, etc..)

Procedimiento Metodología de Gestión

Principales actividades a realizar

SIMBOLOS UTILIZADOS EN LA REPRESENTACIÓN GRAFICA

Aplicación informática de la Defensoría

Proceso o subproceso a realizar

Informe “de control y seguimiento” del proyecto

IR - Informe de Revisión del documento

Documento “opcional” de gestión del proyecto

Documento de Calidad de la DefensoríaPlantilla y/o Guía del documento o Formulario

Procedimientos y Lista de verificación Productos de Gestión y Calidad de la Defensoría

Otros

Entregables al cliente (documentos, software, hardware)

371

3

Inicio

Acta de Constitución del Proyecto

LV. Fin de Fase de Inicio Proyecto

PROCESOS DE GESTIPROCESOS DE GESTIÓÓNNADMINISTRACIADMINISTRACIÓÓN DE PROYECTOS INFORMN DE PROYECTOS INFORMÁÁTICOSTICOS

Lanzamiento del Proyecto

“Ficha de Proyecto”

En la Ficha de Proyecto:• Ciclo de firmas autorización del Comité Informático• Asignar Líder del Proyecto.• Asignar Ciclo de Ingeniería de Desarrollo de Software

Verificar que:• Existe capacidad tecnológica para ejecutar el proyecto• Existen Recursos en el equipo de proyecto• Esta elaborado el documento Enunciado del Alcance del Proyecto• Están identificados los entregables y definidos los Criterios Aceptación del

cliente

Requerimientos del proyecto (Términos de referencia).• Requerimientos del cliente, entregables , plazos, condiciones

facturación, plan de compras y subcontratación.

• Solicitud de Propuesta de

Proyecto• Análisis de Requerimientos

Preliminar• Enunciado del Alcance del

Proyecto Preliminar

Datos de entradaal inicio del proyecto

Guía de Reuniones

Guía de Herramientas y Técnicas

• Asignar Directiva del Proyecto (con representante del cliente)• El Líder de Proyecto elabora documento Resumen del Proyecto.• Elabora Criterios de Aceptación del proyecto

PLANIFICACIÓN

• Documento con los Entregables y sus Criterios de Aceptación del proyecto (firmado por el cliente)Guía de Técnicas de Estimación

Procedimiento General - Gestión del Proyecto

LV. Inicio de Fase

Directorio de Aplicación de las Plantillas

372

4

• Solicitud de Propuesta de Proyecto

• Análisis de Requerimientos Preliminar

• Enunciado del Alcance del Proyecto Preliminar

• Matriz de Involucrados del Proyecto

• Acta de Constitución del Proyecto

• LV Comprobación de la Reunión de Aprobación del Proyecto

Datos de entrada a la Planificación Planificación

Dependiendo de tamaño y complejidad serán planes

independientes o estarán integrados con el Plan de Gestión del Proyecto

IR. Plan

de Proyecto

Acta Aceptar Plan Proyecto

Plan de Gestión del Proyecto

Plan Gestión del Alcance

Plan Gestión del Tiempo

Plan Gestión de Riesgos

Plan Ingeniería Desarrollo de Software

Plan …

Lista Riesgos“Top 10”

EDTLista Ítems Entregables

• Elaborar la planificación detallada del proyecto• Asignar recursos ejecución• Asignar equipo gestión del proyecto


Procedimiento – Ing. Desarrollo de Soft.

Procedimiento - Plan de Gestión Alcance

Procedimiento - Plan de …

LV. Reunión Aceptar Plan Proyecto

LV. Planificación(Inicio)

LV. Planificación(Fin)

PRE - EJECUCIÓN

Cronograma del Proyecto

PROCESOS DE GESTIPROCESOS DE GESTIÓÓNNADMINISTRACIADMINISTRACIÓÓN DE PROYECTOS INFORMN DE PROYECTOS INFORMÁÁTICOSTICOS

Guía de Reuniones

Guía de Herramientas y Técnicas

Guía de Técnicas de Estimación

Directorio de Aplicación de las Plantillas

373

5

Pre - Ejecución - Requisitos (detallados)

IR. Requisitos

Elaborar Especificación de Requisitos

• Elaborar documento con los Requisitos funcionales y técnicos de la solución propuesta

• Verificar cambios y mejoras en relación a los requisitos contractuales

Procedimiento - Definición de Requisitos Software

• Planes del Proyecto• Acta aceptación Planes de

Proyecto• Especificaciones de

Requisitos Preliminares

Datos de entrada a la Planificación

SI

NO

¿ Existe documentoEspecificaciones de Requisitos ?

Acta de Recepción y Conformidad

del cliente

NO Conformidad

EJECUCIÓN

Análisis yNegociación de

Cambios Cambios

NO afectaal alcance:Actualizar documento Requisitos

SI afectaal Plan Proyecto

PLANIFICACIÓN

AMPLIACIÓNCONTRATO

SI afectaal Contrato

Entrega al cliente

PROCESOS DE GESTIPROCESOS DE GESTIÓÓNNADMINISTRACIADMINISTRACIÓÓN DE PROYECTOS INFORMN DE PROYECTOS INFORMÁÁTICOSTICOS 374

6

Ejecución - Seguimiento y entregables

• Planes del Proyecto• Acta aceptación Planes de

Proyecto

Datos de entrada a la Planificación

PlanProyecto

PlanRiesgos

PlanConfiguración

GestiónCambio

Petición de Cambio

Informes progreso

InformeRiesgos

Informes de problemas

Informetrabajos

por persona

• Control avance y desviaciones del plan de proyecto (plazos y costes)

• Control y gestión de los riesgos• Control Configuración de entregables• Control y gestión de los cambios• Evaluar % grado de avance

LV Control y

SeguimientoProyecto

% grado avance

“Ficha de Proyecto”Informes Seguimiento del proyecto

Procedimiento - Plan de Riesgos

Procedimiento - Plan de Cambios

Procedimiento - Plan de Configuración

Procedimiento - Gestión de problemas


PROYECTO Clase A PROYECTO Clase A -- PROCESOS DE GESTIPROCESOS DE GESTIÓÓNN

PartesActividad

Procedimiento - Aceptar (Entregables) del Proyecto

FASE (con entregables)

LV final defase

Certificados Entregas

EncuestaSatisfacción

cliente

Entregables al cliente

PlantiíllaAceptación Fase

Formulario Aceptación fin fase anterior

Acta de Recepción y ConformidadNO Conformidad

• Control Final de cada Fase• Control de entregables• Acta de Conformidad del cliente• Acta de NO conformidad• Encuestas de satisfacción del cliente Propuesta de facturación”

Fin de entregables

CIERRE


7

Cierre

Fin Ejecución del Proyecto

Cierre “técnico” Proyecto

• Actas de recepción y aceptación de los entregables por el cliente

• Encuesta satisfacción del cliente

Datos de entrada alcierre del proyecto

LV - Reunión Fin ejecución del proyecto

LV - Cierre “técnico”del proyecto

“Ficha de Proyecto”

Cierretécnico

• Verificar que han sido terminados los entregables del proyecto

• Reunión con el cliente para aceptar final del proyecto (Acta de Aceptación)

• Elaborar el documento Diagnóstico Final del Proyecto

• Reunión del equipo de proyecto y responsables del área usuaria para Verificar que puede darse el cierre “técnico” del proyecto.

• Entrada de datos de cierre en aplicación “Ficha de Proyecto”

InformeCierre y

OportunidadesMejoras

Procedimiento General- Gestión del Proyecto

Procedimiento Revisión y Cierre Proyecto

Acta Aceptaciónpor el cliente

Propuestafacturación final

LV - Reunión Aceptar

entregables del proyecto

Paso a BD -Conocimiento

Procedimiento - Aceptar (Entregables) del Proyecto


377

4.3.2.5. DIRECTORIO DE APLICACIÓN DE LAS PLANTILLAS. El directorio de aplicación descrito es un documento guía que contiene todas las plantillas desarrolladas en esta tesis. Es una representación gráfica y ordenada del uso y ubicación de las herramientas de trabajo principales para gestionar proyectos de Tecnologías de Información. El desarrollo completo de esta herramienta está descrito en la Guía Directorio de Aplicación de las Plantillas (AP-GDAP-11), que se detalla a continuación:

Defensoría de los Habitantes Administración de Proyectos Informáticos Guía Directorio de Aplicación de las Plantillas Referencia: AP-GDAP-11 Versión: 1.0

AP-GDAP-11 Directorio de Aplicación de las Plantillas, V1.0 Página 1 de 3

MAPA DE LOS DOCUMENTOS DE GESTIÓN DE PROYECTOS

FASE PROCESOS DE GESTIÓN Procedimiento Guía Plantilla Lista de Verificación

Cronograma (MS Project)

General Proceso General de la Gestión del Proyecto X Conceptualización X Solicitud de Propuesta de Proyecto CON-SPP-01 X Análisis de Requerimientos Preliminar CON-ARP-02 X Enunciado del Alcance del Proyecto Preliminar CON-EAPP-03 X Acta de Constitución del Proyecto CON-ACP-04 X Matriz de Involucrados del Proyecto CON-MIP-05 X Comprobación de la Reunión de Aprobación del

Proyecto CON-LVCRAP-06 X

Inicio Inicio del Proyecto INI-LVFIP-01 x Planificación Plan de Gestión del Proyecto X PLA-PGP-01 X Reunión de Aceptación del Plan de Gestión del

Proyecto PLA-LVRAPGP-02 X

Plan de Gestión del Tiempo X PLA-PGT-03 X

378



Definición de Actividades PLA-PDA-04 X Recursos del Proyecto PLA-PRP-05 X Calendario de Recursos PLA-PCRP-06 X Desarrollo Software WBS - Incremental PLA-PWBSI-07 X X Desarrollo Software WBS - Evolutivo PLA-PWBSE-08 X X Desarrollo Software WBS - Cascada PLA-PWBSC-09 X X Seguimiento y Control

Seguimiento y Control del Proyecto SEG-LVSCP-01 X Informe Actividad del Equipo de Proyecto SEG-PIAEP-02 X Informe Semanal del Progreso del Proyecto SEG-PISPP-03 X Informe Mensual del Avance del proyecto SEG-PIMAP-04 X Reunión de Aceptación de Fases/Etapas del Proyecto SEG-PRAFEP-05 X Reunión de Aceptación de Fases/Etapas del Proyecto SEG-LVRAFEP-06 X Informe de Emergencias/Problemas del Proyecto SEG-PIEPP-07 X Solicitud de Cambios del Proyecto SEG-PSCP-08 X Acta de Recepción de Productos del Proyecto SEG-PARPP-09 X Cierre del Proyecto Reunión Revisión y Cierre del Proyecto FIN-LVRRCP-01 X Informe Revisión y Cierre del Proyecto FIN-PIRCP-02 X

379



Informe de Oportunidades de Mejoras al Proceso FIN-PIOMP-03 X Acciones Correctivas FIN-PAC-04 X Cierre del Proyecto FIN-LVCP-05 X Evaluación al Usuario FIN-PEU-06 X Evaluación Técnica Producto FIN-PETP-07 X Herramientas y Técnicas

Guía de Herramientas y Técnicas X AP-GHT-01

Guía de Técnicas de Estimación X AP-GTE-02

Guía de Reuniones X AP-GR-03

Convocatoria de Reunión APGR-PCR-04 X

Control de Audiencia APGR-PCA-05 X

Acta de Reunión APGR-PAR-06 X

Seguimiento de Acuerdos APGR-PSA-07 X

Minuta de Reunión APGR-PMR-08 X

Informe Estado de Acciones APGR-PIEA-09 X

Flujograma de Aplicación de la Metodología X AP-GFAM-10

Directorio de Aplicación de las Plantillas X AP-GDAP-11

380

381

5. CONCLUSIONES

5.1. ESPECÌFICAS SOBRE EL ESTÁNDAR MODELO DE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN DE LA DEFENSORÍA DE LOS HABITANTES (VERSIÓN 1.0).

El estándar modelo de administración de Proyectos de Tecnologías de Información de la Defensoría de los Habitantes (Versión 1.0) provee a la organización de un marco de referencia inicial que deberá ser complementado y completado con nuevas versiones que permitan un control integral de la gestión de proyectos institucional. Las políticas en administración de proyectos crean la estructura organizacional que soporta los procedimientos y herramientas, impulsan el cambio de cultura, mantienen dirección y control en la gestión de proyectos. Los procedimientos deben ser creados de acuerdo con las necesidades y estructuras organizacionales, en instituciones que no tienen cultura de proyectos, como lo son las públicas, estos deben de ajustarse en la medida de lo posible al proceso normal de trabajo, de lo contrario la resistencia al cambio es muy fuerte, y en ocasiones difícil de conseguir. Las plantillas y herramientas de trabajo son guías de trabajo, que proporcionan orden, dirección, control y objetividad al proceso de gestión de proyectos. Las plantillas deben contener toda la información necesaria que permita tomar decisiones sin omisión de datos. La mejora continua de las políticas, procedimientos y plantillas de trabajo debe ser parte de la cultura organizacional de una institución que desee administrar proyectos de una forma profesional.

5.2. ESPECÍFICAS SOBRE EL PROCESO DE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN.

382

El ciclo de administración de proyectos contiene puntos de transición que deben ser identificados y administrados. El ciclo de vida de un proyecto contiene varios elementos que se solapan entre una actividad o fase y otra. Esta situación requiere de un plan de proyecto integrado que asegure la continuidad y consistencia de estas fases.

5.2.1. INICIO

En esta fase se obtiene el compromiso de la organización para iniciar el proyecto. En esta fase se debe justificar la necesidad del proyecto e identificar el valor del mismo en término de costos y beneficios.

5.2.2. PLANIFICACIÓN La planificación se extiende durante prácticamente todo el proyecto, sin embargo su mayor énfasis se da al inicio del proyecto, que es cuando se determina qué, cómo, cuándo, dónde y cuánto. La planificación está orientado a obtener un plan de proyecto que permita administrar proactivamente el proyecto, para evitar que las circunstancias y eventos sean las que administran el proyecto al tener que adoptar un enfoque reactivo de administración. La planificación se ve principalmente reflejada en el plan de proyecto desarrollado y en sus posteriores actualizaciones, y entre sus objetivos se encuentran:

a) Identificación de los objetivos y alcances del proyecto. b) Visualización de las actividades y tareas a realizar, secuencia en que se ejecutarán, tiempo

estimado de cada una y duración del proyecto, para alcanzar exitosamente los objetivos del mismo.

c) Determinación de los recursos requeridos: humanos y de otra índole. d) Determinación del costo del proyecto.

383

e) Determinación de la organización del equipo de proyecto, definiendo roles y responsabilidades.

f) Establecer los supuestos, condiciones y restricciones que rigen las actividades de desarrollo del proyecto.

g) Anticipación a los hechos, sean estos amenazas u oportunidades, que pueden afectar el desarrollo del proyecto.

h) Identificación temprana de los riesgos y determinación de mecanismos para evitarlos o mitigarlos.

i) Visualización de la capacitación del equipo de proyecto. j) Visualización de la capacitación y entrenamiento a quienes utilizarán la solución, tanto desde

el punto de vista operativo como tecnológico. k) Identificar las actividades a realizar para transferir la solución del proyecto al control y

operación de las áreas correspondientes. l) Estrategia para la puesta en producción de la solución.

Todo proyecto siempre tendrá un nivel de incertidumbre en cuanto a lograr exitosamente sus objetivos y alcances, al inicio del proyecto este nivel de incertidumbre e irá disminuyendo conforme se avance en el desarrollo del mismo; esta incertidumbre incide directamente en la planificación del proyecto. La planificación inicialmente podrá establecer con mayor exactitud y detalle las actividades más cercanas en tiempo, no así las actividades que estén más lejanas en tiempo y que dependan del comportamiento y resultados obtenidos de las primeras actividades. Esta situación debe ser administrada y controlada por el administrador de proyecto, quien constantemente deberá estar revisando y ajustando la planificación del proyecto.

5.2.3. EJECUCIÓN, SEGUIMIENTO Y CONTROL

384

La fase de ejecución, seguimiento y control está orientada al desarrollo del plan de proyecto y a controlar cualquier desviación del plan. Conforme los cambios se den, se materialicen o identifiquen nuevos riesgos o surjan problemas se evaluará el impacto de los mismos y deberán tomarse decisiones que aseguren un resultado favorable para el proyecto y sus objetivos. El control se extiende a lo largo de todo el proyecto, desde el momento en que el plan es aprobado hasta que se completa con el último entregable del proyecto. Como objetivos del control se identifican:

a) Determinación de los desvíos que se generan respecto de los planes y el análisis correspondiente de las causas.

b) Ajuste oportuno en las actividades y tareas de cada proyecto, de forma tal que se logren los objetivos fijados o modificados para el mismo.

c) Generación progresiva de la información histórica que aporta el proyecto. d) Control de los cambios en alcances,, prioridades, rotación de personal u otras condiciones

del proyecto, especificando para cada uno su impacto en el proyecto. e) Identificación oportuna de la materialización de un riesgo. f) Identificación de nuevos riesgos. g) Control de que se mantengan los supuestos y condiciones del proyecto. h) Identificación y comunicación oportuna de los problemas que surjan. i) Control del costo del proyecto.

5.2.4. CIERRE

El cierre de un proyecto está orientado a asegurar que se han alcanzado los objetivos del mismo y que a partir de ese momento, la solución objetivo será entregada a las áreas operativas de la organización y el equipo de proyecto concluye sus actividades y responsabilidades.

385

Esta es una fase sumamente importante en el ciclo de vida de un proyecto, porque es el período en que se da la transición de trasladar la responsabilidad del uso y operación de la solución o producto a las áreas operativas de la organización. Esta transición o entrega debe haber queda plasmada en las etapas de planificación y ejecución o control, de tal forma que las áreas operativas estén debidamente capacitadas y entrenadas para asumir la operación de la solución. El cierre de proyectos es por lo general una de las facetas olvidadas del proceso de administración de proyecto, ya sea por aspectos de recursos, tiempo o desconocimiento. No obstante, es en esta fase donde se logra la consolidación de la experiencia adquirida y donde se genera la documentación que viene a enriquecer la cultura de proyectos, los aspectos metodológicos y en sí los resultados institucionales en el desarrollo de sistemas de información. Como objetivos de la finalización de proyectos se encuentran:

a) Evaluación de los alcances obtenidos comparados con los alcances planteados. b) Comparación de la fecha estimada y la fecha real del proyecto. c) Comparación del costo estimado y el costo real del proyecto. d) Comparación de los beneficios planteados y beneficios reales obtenidos. e) Evaluación de la calidad de la solución entregada, tanto a nivel de usuario como técnicos. f) Recopilación y documentación de las lecciones aprendidas, que sirvan de referencia para la

ejecución de otros proyectos. En general, y a la luz de lo estipulado anteriormente, la administración de proyectos se puede definir como el conjunto de procedimientos, herramientas, técnicas y estrategias para llegar a obtener proyectos exitosos, y por lo tanto productos de alta calidad.

386

Al aplicar la metodología aquí descrita, puede quedar la sensación de algún tipo de sacrificio de recursos en aspectos no relacionados directamente con el proceso productivo, lo cual podría ser cierto si los desarrollos se enfrentan con un enfoque al corto plazo y sin la perspectiva de evolución y mejoramiento. Cada proyecto debe ser enfrentado con la seriedad que corresponde, como parte que es de una larga cadena en lo que respecta a la generación de experiencia y mejoramiento de esta función en la Defensoría de los Habitantes.

387

6. RECOMENDACIONES

6.1. ESPECÍFICAS SOBRE EL ESTÁNDAR MODELO DE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE INFORMACIÓN DE LA DEFENSORÍA DE LOS HABITANTES (VERSIÓN 1.0).

Es importante que un corto plazo la Defensoría de los Habitantes emprenda acciones orientadas a complementar el trabajo iniciado en el estándar modelo de administración de Proyectos de Tecnologías de Información (Versión 1.0). Específicamente se recomienda lo siguiente:

• Desarrollar el estándar para las áreas de administración de proyectos que se indicaron en esta tesis como fuera del alcance, la versión 2.0 deberá incluir el desarrollo del estándar que permitan la gestión de los siguientes planes:

- Plan de Ingeniería de Desarrollo de Software

- Plan de Gestión del Alcance

- Plan de Gestión de Costes

- Plan de Gestión de Calidad

- Plan de Gestión del Personal

- Plan de Gestión de las Comunicaciones

- Plan de Gestión de Riesgos

- Plan de Gestión de las Adquisiciones

- Plan de Gestión de Configuración

- Plan de Gestión de Cambios

388

- Plan de Gestión de Emergencias/Problemas

- Plan de Pruebas de Aceptación del Producto

- Plan de Implantación del Producto

- Plan de Capacitación de Usuarios Finales.

• Investigar e instaurar el uso de nuevas herramientas y técnicas aplicables a la administración de Proyectos, de acuerdo con el área de aplicación requerida.

• El Departamento de Informática de la Defensoría de los Habitantes debe coadyuvar e impulsar un cambio en la cultura organizacional que permita al resto de la institución la instauración de la gestión profesional de los diferentes proyectos que se emprendan.

• Crear una Oficina de Proyectos (PMO) que se encargue de gestionar los proyectos de la Defensoría de los Habitantes, así como de crear nuevos estándares de administración de proyectos, y de actualizar y mejorar los existentes.

6.2. ESPECÍFICAS SOBRE ADMINISTRACIÓN DE PROYECTOS DE TECNOLOGÍAS DE

INFORMACIÓN. El éxito de los proyectos de Tecnologías de Información no depende exclusivamente de tener un estándar de administración de proyectos eficaz y eficiente, existen una serie de consideraciones adicionales que son fundamentales para que los resultados reales sean los esperados de acuerdo con los objetivos planeados.

389

Existen una serie de prácticas que se comenten muy frecuentemente en la gestión de proyectos de tecnologías de información que hacen que contribuyen en gran medida que los resultados reales sean muy diferentes de los propuestos. El desarrollo de software es una actividad complicada. Un proyecto de software típico puede presentar más oportunidades para aprender de los errores que las planteadas a algunas personas en toda su vida. Las siguientes recomendaciones están dirigidas a los miembros de equipos de proyectos, directivos clientes e interesados en la gestión de proyectos. Son prácticas no recomendadas y se agrupan de acuerdo a las siguientes dimensiones o áreas que afectan el de desarrollo de software:

• Personas

• Proceso

• Producto

• Tecnología

6.2.1. PERSONAS

Prácticas no recomendadas en relación con las personas:

6.2.1.1. MOTIVACIÓN DÉBIL. Estudio tras estudio se ha mostrado que la motivación probablemente tiene mayor efecto sobre la productividad y la calidad que ningún otro factor (Boehm, 1981). Algunos veces, los directivos toman a lo largo de todo el proyecto medidas que minan la moral: como dar ánimos a diario al principio para pedir horas extras en la mitad, y como irse de vacaciones mientras el equipo estaba trabajando incluso los días de fiesta, para dar recompensas al final del proyecto que resultaron ser de menos de un dólar por cada hora extra.

390

6.2.1.2. PERSONAL MEDIOCRE.

Después de la motivación, la capacidad individual de los miembros del equipo, así como sus relaciones como equipo, probablemente tienen la mayor influencia en la productividad (Boehm, 1981; Lakhanpal, 1993). La selección del personal no se debe realizar buscando quién podría contratarse más rápido en vez de quién realizaría la mayoría del trabajo durante la vida del proyecto. Esta técnica consigue un inicio rápido del proyecto, pero no determina un final exitoso.

6.2.1.3. EMPLEADOS PROBLEMÁTICOS INCONTROLADOS. Un fallo al tratar con personal problemático también amenaza el éxito de un proyecto. Es un problema habitual, y se ha comprendido bien, al menos desde que Gerald Weinberg publicó Pschologv of Computer Prograrnrning en 1971. Un fallo al tomar una decisión cuando se trata con un empleado problemático es una de las quejas más comunes que tienen los miembros del equipo respecto de sus responsables (Larson, C. E. y LAFASTO, F. M. J. , 1989).

6.2.1.4. HAZAÑAS. Algunos desarrolladores de software ponen un gran énfasis en la realización de hazañas en los proyectos (Bach, 1995). Pero lo que hacen tiene más de malo que de bueno. El énfasis en los comportamientos heroicos fomenta correr un riesgo extremo, e impide la cooperación entre los múltiples elementos que contribuyen al proceso de desarrollo del software. Algunos directivos fomentan el comportamiento heroico cuando se concentran con demasiada firmeza en actitudes “ser capaz de”. Elevando estas actitudes por encima de informes de estados exactos y a veces pesimistas, los directivos de estos proyectos coartan su capacidad de tomar medidas correctivas. Ni siquiera saben que tienen que emprender acciones correctoras hasta que el

391

daño ya está hecho. Como dijo Tom DeMarco, las actitudes “ser capaz de” convierten pequeños contratiempos en auténticos desastres (DeMarco, 1979).

6.2.1.5. AÑADIR MÁS PERSONAL A UN PROYECTO RETRASADO. Ésta es quizás la más clásica de las prácticas no deseadas. Cuando un proyecto se alarga, añadir más gente puede quitar más productividad a los miembros del equipo existente de la que añaden los nuevos miembros. Fred Brooks compara añadir gente a un proyecto retrasado con echar gasolina en un fuego (Brooks, 1975).

6.2.1.6. OFICINAS REPLETAS Y RUIDOSAS. La mayoría de los desarrolladores consideran sus condiciones de trabajo como insatisfactorias. Alrededor del 60 por 100 indican que no tienen suficiente silencio ni privacidad (De Marco et al., 1987). Los trabajadores que están en oficinas silenciosas y privadas tienden a funcionar significativamente mejor que aquellos que ocupan cubículos en salas ruidosas y repletas. Los entornos repletos y ruidosos alargan los planes de desarrollo.

6.2.1.7. FRICCIONES ENTRE LOS CLIENTES Y DESARROLLADORES. Las fricciones entre los clientes y los desarrolladores pueden presentarse de distintas formas. A los clientes puede parecerles que los desarrolladores no cooperan cuando rehúsan comprometerse con el plan de desarrollo que desean los clientes o cuando fallan al entregar lo prometido. A los desarrolladores puede parecerles que los clientes no son razonables porque insisten en planes irreales o cambios en los requerimientos después de que éstos hayan sido fijados. Pueden ser simplemente conflictos de personalidad entre dos grupos.

392

El principal efecto de esta fricción es la mala comunicación, y los efectos secundarios de la mala comunicación incluyen el pobre entendimiento de los requerimientos, pobre diseño de la interfaz de usuario y, en el peor caso, el rechazo del cliente a aceptar el producto acabado. En el caso medio, las fricciones entre clientes y desarrolladores de software llegan a ser tan severas que ambas partes consideran la cancelación del proyecto (Jones, 1994). Para remediar estas fricciones se consume tiempo, y distraen tanto a desarrolladores como a clientes del trabajo real en el proyecto.

6.2.1.8. EXPECTATIVAS POCO REALISTAS. Una de las causas más comunes de fricciones entre los desarrolladores y sus clientes o los directivos son las expectativas poco realistas. En otros casos, los directivos o los desarrolladores de un proyecto se buscan problemas al pedir fondos basándose en estimaciones de planificación demasiado optimistas. A veces prometen un conjunto de funciones tan altas como la Luna. Aunque por sí mismas las expectativas irreales no alargaran el plan, contribuyen a la percepción de que el plan de desarrollo es demasiado largo, y de que puede ser malo. Una inspección de Standish Group marcó las expectativas realistas como uno de los cinco factores principales necesarios para asegurar el éxito de los proyectos internos de software de gestión (Standish Group, 1994).

6.2.1.9. FALTA DE UN PROMOTOR EFECTIVO DEL PROYECTO. Para soportar muchos de los aspectos del desarrollo exitoso es necesario un promotor del proyecto de alto nivel, incluyendo una planificación realista, el control de cambios y la introducción de nuevos métodos de desarrollo. Sin un promotor ejecutivo efectivo, el resto del personal de alto nivel de la organización puede forzar a que se acepten fechas de entrega irreales o hacer cambios que debiliten el proyecto. El consultor australiano Rob Thomsett afirma que la falta de un promotor efectivo garantiza virtualmente el fracaso del proyecto (Thomsett, 1995).

393

6.2.1.10. FALTA DE PARTICIPACIÓN DE LOS IMPLICADOS.

Todos los principales participantes del esfuerzo de desarrollo de software deben implicarse en el proyecto. Incluyendo a los promotores, ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios finales, clientes y cualquiera que se juegue algo con el proyecto. La cooperación estrecha sólo se produce si se han implicado todos los participantes, permitiendo una coordinación precisa del esfuerzo para el desarrollo rápido, que es imposible conseguir sin una buena participación.

6.2.1.11. FALTA DE PARTICIPACIÓN DEL USUARIO. La inspección de Standish Group descubrió que la razón número uno de que los proyectos de Sistemas de Información tuviesen éxito es la implicación del usuario (Standish Group, 1994). Los proyectos que no implican al usuario desde el principio corren el riesgo de que no se comprendan los requerimientos del proyecto, y son vulnerables a que se consuma tiempo en prestaciones que más tarde retrasarán el proyecto.

6.2.1.12. POLÍTICA ANTES QUE DESARROLLO. Larry Constantine indicó que si hay cuatro equipos hay cuatro tipos diferentes de orientaciones políticas (Constantine, 1995). Los “políticos” están especializados en la “gestión”, centrándose en las relaciones con sus directivos. Los “investigadores” se centran en explorar y reunir información. Los “aislacionistas” están solos, creando fronteras para el proyecto que mantienen cerradas a los que no son miembros del equipo. Los “generalistas” hacen un poco de todo: establecen relaciones con sus directivos, realizan investigaciones y exploran actividades, y se coordinan con otros equipos como parte de su modo de trabajo.

394

Constantine indicó que inicialmente los equipos políticos y generalistas están bien vistos por los directivos de alto nivel. Pero después de un año y medio, los equipos políticos llegan a la muerte súbita. Primar la política en vez de los resultados es fatal para el desarrollo de proyectos exitosos.

6.2.1.13. ILUSIONES. Muchos de los problemas del desarrollo del software se deben a la ilusión. Muchas veces se escuchan cosas como éstas a distintas personas: “Ninguno de los miembros del proyecto cree realmente que pueda completarse el proyecto de acuerdo con el plan que tienen, pero piensan que quizás si trabajan duro, y nada va mal, y tienen un poco de suerte, serán capaces de concluir con éxito”. “Nuestro equipo no hace mucho trabajo para la coordinación de las interfaces entre las distintas partes del producto, pero tenemos una buena comunicación para otras cosas, y las interfaces son relativamente simples, así que probablemente sólo necesitaremos un día o dos para eliminar los errores”. “Sabemos que contamos con un desarrollador externo de poco talento para el subsistema de la base de datos, y que es difícil ver cómo va a acabar el trabajo con los niveles de personal que ha especificado en su propuesta. No tienen tanta experiencia como algunos de los demás desarrolladores externos, pero puede que compensen con energía lo que les falta en experiencia. Probablemente acaben a tiempo”. “No necesitamos reflejar la última lista de cambios en el prototipo para el cliente. Estoy seguro de que por ahora sabemos lo que quiere”.

395

“El equipo está diciendo que realizará un esfuerzo extraordinario para cumplir con la fecha de entrega, y que no han llegado a su primer hito por pocos días, pero creo que alcanzarán éste a tiempo”. Las ilusiones no son sólo optimismo. Realmente consisten en cerrar los ojos y esperar que todo funcione cuando no se tienen las bases razonables para pensar que será así. Las ilusiones al comienzo del proyecto llevan a grandes explosiones al final. Impiden llevar a cabo una planificación coherente y pueden ser la raíz de más problemas en el software que todas las otras causas combinadas.

6.2.2. PROCESO.

Prácticas no recomendadas en relación con el proceso:

6.2.2.1. PLANIFICACIÓN EXCESIVAMENTE OPTIMISTA. Los retos a los que se enfrenta alguien que desarrolla una aplicación en tres meses son muy diferentes de aquellos a los que se enfrenta alguien que desarrolla una aplicación que necesita un año. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, minando la planificación efectiva, y reduciendo las actividades críticas para el desarrollo, como el análisis de requerimientos o el diseño. También supone una excesiva presión para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad.

6.2.2.2. GESTIÓN DE RIESGOS INSUFICIENTE. Algunos errores no son lo suficientemente habituales como para considerarlos prácticas no deseadas. Son los llamados “riesgos”. Como con los errores clásicos, si no se ejerce una gestión activa de los riesgos, con que sólo vaya mal una cosa se pasará de tener un proyecto con un desarrollo rápido a uno con un desarrollo lento.

396

El fallo de no gestionar uno solo de estos riesgos es una práctica no deseada.

6.2.2.3. FALLOS DE LOS CONTRATADOS. Las organizaciones a veces contratan la realización de partes de un proyecto cuando tienen demasiada prisa para hacer el trabajo en casa. Pero los contratados frecuentemente entregan su trabajo tarde, con una calidad inaceptable o que falla al no coincidir con la especificación (Boehm, 1989). Riesgos como requerimientos inestables o interfaces mal definidas pueden ser enormes cuando un contratado entra en escena. Si las relaciones con los contratados no se gestionan cuidadosamente, la utilización de desarrolladores externos puede ralentizar el proyecto en vez de acelerarlo.

6.2.2.4. PLANIFICACIÓN INSUFICIENTE. Si no se planifica para conseguir un proyecto exitoso, no se puede esperar obtenerlo.

6.2.2.5. ABANDONO DE LA PLANIFICACIÓN BAJO PRESIÓN. Los equipos de desarrollo hacen planes y rutinariamente los abandonan cuando se tropiezan con un problema en la planificación (Humphrey, 1989). El problema no está en el abandono del plan, sino más bien en fallar al no crear un plan alternativo, y caer entonces en el modo de trabajo de codificar y corregir. Por ejemplo, no se debe abandona un plan después de fallar en la primera entrega, y esto es lo habitual. A partir de este punto, el trabajo no tiene coordinación ni elegancia.

6.2.2.6. PÉRDIDA DE TIEMPO EN EL INICIO DIFUSO. El “inicio difuso” es el tiempo que transcurre antes de que comience el proyecto; este tiempo normalmente se pierde en el proceso de aprobar y hacer el presupuesto. No es poco común que un

397

proyecto desperdicie meses o años en un inicio difuso, y entonces se está a las puertas de un plan agresivo. Es mucho más fácil y barato y menos arriesgado suprimir unas pocas semanas o meses del inicio difuso en vez de comprimir el plan de desarrollo en ese mismo tiempo.

6.2.2.7. ESCATIMAR EN LAS ACTIVIDADES INICIALES. Los proyectos que se aceleran intentando acortar las actividades no esenciales, y puesto que el análisis de requerimientos, la arquitectura y el diseño no producen código directamente, son los candidatos fáciles.. Los proyectos que normalmente escatiman en sus actividades iniciales tendrán que hacer ese trabajo en otro momento, con un coste de 10 a 100 veces superior a haberlo hecho bien inicialmente (Fagan, 1976; Boehm B. W. y Papaccio, P. N., 1988). Si no se pueden encontrar cinco horas para hacer el trabajo correctamente la primera vez, ¿cómo se van a encontrar 50 para hacerlo correctamente más tarde?

6.2.2.8. DISEÑO INADECUADO. Un caso especial de escatimar en las actividades iniciales es el diseño inadecuado. Proyectos acelerados generan un diseño indeterminado, no asignando suficiente tiempo para él y originando un entorno de alta presión que hace difícil la posibilidad de considerar alternativas en el diseño. El énfasis en el diseño está más orientado a la conveniencia que a la calidad, por lo que necesitará varios ciclos de diseño antes de poder finalizar completamente el sistema.

6.2.2.9. ESCATIMAR EN EL CONTROL DE LA CALIDAD. En los proyectos que se hacen con prisa se suele cortar por lo sano eliminando las revisiones del diseño y del código, eliminando la planificación de las pruebas y realizando sólo pruebas superficiales. Si se eliminan limpiamente, por ejemplo, las revisiones del diseño y del código para conseguir una ganancia considerable en el plan, al final, cuando el proyecto alcance su hito de plena funcionalidad puede darse el caso de que tenga demasiados errores y se retrase unos meses más.

398

Este resultado es típico. Acortar en un día las actividades de control de calidad al comienzo del proyecto probablemente supondrá de 3 a 10 días de actividades finales (Jones, 1994). Esta reducción va contra la velocidad de desarrollo.

6.2.2.10. CONTROL INSUFICIENTE DE LA DIRECTIVA. La directiva debe efectuar el control suficiente para detectar a tiempo los signos de posibles retrasos en el plan, y que no se abandonen los controles definidos cuando el proyecto empiece a tener problemas. Antes de encarrilar en primer lugar se debe tener la capacidad de decir si va por buen camino.

6.2.2.11. CONVERGENCIA PREMATURA O EXCESIVAMENTE FRECUENTE. Bastante antes de que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, mejorar el rendimiento del producto, imprimir la documentación final, incorporar entradas en el sistema final de ayuda, pulir el programa de instalación, eliminar las funciones que no van a estar listas a tiempo y demás. En proyectos hechos con prisa, hay una tendencia a forzar prematuramente la convergencia. Puesto que no es posible forzar la convergencia del producto cuando se desea, algunos proyectos de desarrollo rápido intentan forzar la convergencia media docena de veces o más antes de que finalmente se produzca. Los intentos adicionales de convergencia no benefician al producto. Sólo son una pérdida de tiempo y prolongan el plan.

6.2.2.12. OMITIR TAREAS NECESARIAS EN LA ESTIMACIÓN. Si la gente no guarda cuidadosamente datos de proyectos anteriores, olvida las tareas menos visibles, pero son tareas que se han de añadir. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 por 100 (Van Genuchten, 1991).

399

6.2.2.13. PLANIFICAR PONERSE AL DÍA MÁS ADELANTE.

Un tipo de reestimación es responder inapropiadamente al retraso del plan. Si se ha trabajado en un proyecto durante 6 meses, y se ha empleado tres meses en llegar al hito correspondiente a los dos meses, ¿qué hacer? En muchos proyectos simplemente se plantea recuperar el retraso más tarde, pero nunca se hace. Se aprenderá más del producto conforme se esté construyendo, incluyendo más sobre lo que se ha de llevar construirlo. Estos conocimientos necesitan reflejarse en la reestimación del plan. Otro tipo de error en la reestimación se debe a cambios en el producto. Si el producto que se construye cambia, la cantidad de tiempo necesaria para construirlo cambiará también.

6.2.2.14. PROGRAMACIÓN A DESTAJO. Algunas organizaciones creen que la codificación rápida, libre, tal como salga, es el camino hacia el desarrollo rápido de un proyecto. Piensan que si los desarrolladores están lo suficientemente motivados, pueden solventar cualquier obstáculo. Este enfoque muchas veces se presenta como un enfoque «empresarial» al desarrollo de software, pero realmente es sólo la envoltura del viejo paradigma a destajo combinado con una planificación ambiciosa, y esta combinación raras veces funciona. Es un ejemplo de que dos negaciones no constituyen una verdad.

6.2.3. PRODUCTO.

Prácticas no recomendadas en relación con el producto:

6.2.3.1. EXCESO DE REQUERIMIENTOS. Algunos proyectos tienen más requerimientos de los que necesitan, desde el mismo inicio. La eficiencia se fija como requisito más a menudo de lo que es necesario, y puede generar una

400

planificación del software innecesariamente larga. Los usuarios tienden a interesarse menos en las prestaciones complejas que en las de las secciones de mercadeo o de desarrollo, y las prestaciones complejas alargan desproporcionadamente el plan de desarrollo.

6.2.3.2. CAMBIO DE LAS PRESTACIONES. Incluso si se ha evitado con éxito los requerimientos excesivos, los proyectos sufren como media sobre un 25 por 100 de cambios en los requerimientos a lo largo de su vida (Jones, 1994). Un cambio de este calibre puede producir un aumento en el plan de al menos un 25 por 100, lo que puede ser fatal para los proyectos de desarrollo rápido.

6.2.3.3. DESARROLLADORES METICULOSOS. Los desarrolladores encuentran fascinante una nueva tecnología, y a veces están ansiosos por probar nuevas prestaciones de su lenguaje o entorno, o por crear su propia implementación de una utilidad bonita que han visto en otro producto, la necesite o no su producto. El esfuerzo requerido para diseñar, implementar probar, documentar o mantener estas prestaciones innecesarias alarga el plan.

6.2.3.4. TIRAS Y AFLOJAS EN LA NEGOCIACIÓN. Cuando un directivo aprueba un retraso en el plan de un proyecto que progresa más lento de lo esperado, y entonces añade tareas completamente nuevas después de un cambio en el plan, se produce una situación curiosa. La razón subyacente de esto es difícil de localizar, puesto que el directivo que aprueba el retraso en el plan lo hace sabiendo implícitamente que el plan estaba equivocado. Pero una vez que se corrige, la misma persona realiza acciones explícitas para volver a equivocarse. Esto sólo puede ir en contra del plan.

401

6.2.3.5. DESARROLLO ORIENTADO A LA INVESTIGACIÓN. Muchos proyectos software deben aprender la lección de no intentar sobrepasar los límites de la ingeniería en más de dos áreas a la vez, porque el riesgo de un fallo es demasiado alto. Si el proyecto fuerza los límites de la informática porque necesita la creación de nuevos algoritmos o de nuevas técnicas de computación, no se esta desarrollando software, se está investigando en software. Los planes de desarrollo de software son razonablemente predecibles; los planes en la investigación sobre software ni siquiera son predecibles teóricamente. Si el producto tiene objetivos que pretenden aumentar los conocimientos existentes, como algoritmos, velocidad, utilización de la memoria y demás, se debe asumir que la planificación es altamente especulativa. Si quiere mejorar el estado del arte y se tiene algún otro punto débil en el proyecto, recortes de personal, debilidades en el personal, requerimientos vagos, interfaces inestables con contratados externos. etc., se puede tirar por la ventana la planificación prevista. Si se quiere superar el estado del arte por todos los medios, se puede realizar. ¡Pero no se debe esperar hacerlo rápidamente!

6.2.4. TECNOLOGÍA Prácticas no recomendadas en relación con la tecnología:

6.2.4.1. SÍNDROME DE LA PANACEA. No se debe confiar demasiado en las ventajas proclamadas de tecnologías que nos e han usado antes, y mucho menos si no se tiene información sobre los buenas que serían en un entorno de desarrollo concreto. Cuando un equipo de proyecto se aferra solo a una nueva técnica, una nueva

402

tecnología o u proceso rígido, y espera resolver con ello los problemas de planificación, está inevitablemente equivocado.

6.2.4.2. SOBREESTIMACIÓN DE LAS VENTAJAS DEL EMPLEO DE NUEVAS HERRAMIENTAS O MÉTODOS.

Las organizaciones mejoran raramente su productividad a grandes saltos, sin importar cuántas nuevas herramientas o métodos empleen o los buenos que sean. Los beneficios de las nuevas técnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas, y aprender a utilizar nuevas técnicas par aprovecharlas al máximo lleva su tiempo. Las nuevas técnicas también suponen nuevos riesgos, que solo se descubrirán usándolas. Más bien se experimentan mejoras lentas y continuas en un pequeño porcentaje por proyecto en lugar de grandes saltos. Un caso especial de sobreestimaciones de las mejoras se produce cunado se reutiliza código de proyectos anteriores. Este tipo de reutilización puede ser una técnica muy efectiva, pero el tiempo que se gana no es tan grande como el que se espera.

6.2.4.3. CAMBIAR DE HERRAMIENTAS A MITAD DE PROYECTO. Es un viejo recurso que funciona raramente. Algunas veces tiene sentido, pero cuando se está a la mitad de un proyecto, la curva de aprendizaje, rehacer el trabajo y los inevitables errores cometidos con una herramienta totalmente nueva, normalmente anula cualquier posible beneficio.

6.2.4.4. FALTA DE CONTROL AUTOMÁTICO DEL CÓDIGO FUENTE. Un fallo en la utilización del control automático del código fuente expone a los proyectos a riesgos innecesarios. Sin él, si dos desarrolladores están trabajando en la misma parte del programa, deben coordinar su trabajo manualmente.

403

Deben ponerse de acuerdo para poner la última versión de cada archivo en el directorio maestro y verificarlos con los demás antes de copiarlos en este directorio. Alguno puede sobrescribir el trabajo del otro. Se desarrolla nuevo código con interfases desfasadas, y después se tiene que rediseñar el código al descubrirse que se ha utilizado una versión equivocada de la interfaz. Los usuarios avisan de errores que no se pueden reproducir porque no hay forma de volver a crear los elementos que han utilizado.

404

7. BIBLIOGRAFÍA BACH, J. Enough About Process: What We Need Are Heroes. Vol. 12, No. 2: IEEE Software, 1995. 98 p. BOEHM, B. W. Software Engineering Economics. Englewood Cliffs, New Jersey: Prentice Hall, 1981. 751 p. BOEHM, B. W. Software Risk Management. Washintong, D. C.: IEEE Computer Society Press, 1989. 496 p. BOHEM, B. W.; PAPACCIO, P. N. Understanding and Controlling Software Costs. IEEE Transactions on Software Engineering, vol. 14, núm. 10. (Octubre), 1988. 97 p. BROOKS, F. P. JR. The Mytical Man-Month. Reading, Massachusetts: Addison – Wesley, 1975. 322 p. CHAMOUN, Y. Administración Profesional de Proyectos. Una Guía Práctica para Programar el Éxito de sus Proyectos. Mexico: McGraw Hill Interamericana, 2002. 268 p. CONSTANTINE, L. Constantine on Peopleware. Englewood Cliffs, New Jersey: Yourdon Press, 1995. 219 p. DEMARCO, T. Structured Analysis and System Specification. Tools and Techniques. Englewood Cliffs, New Jersey: Prentice Hall, 1979. 352 p. DEMARCO, T.; LISTER, T. Peopleware: Productives Projects and Teams. New York: Dorset House, 1987. 319 p.

405

DHR. Acerca de la Defensoría. Página Interna. Disponible en: www.dhr.go.cr. Consultada en: 15 de Mayo del 2006. EYSSAUTIER, M. Metodología de la Investigación. Quinta Edición. México: Thomson Learning, 2002. 316 p. FAGAN, M. E. Design and Code Inspections to Reduce Errors in Program Development. IBM System Journal: Vol. 15, núm 3, 1976. 68 p. HERNÁNDEZ, R.; FERNÁDEZ C.; BAPTISTA P. Metodología de la Investigación. Segunda Edición. Mexico: Mc Graw Hill, 1998. 453 p. HUMPREY, W.S. Managing the Software Process. Reading, Massachusetts: Addison – Wesley, 1989. 210 p. JONES, C. Assesment and Control of Software Risks. Englewood Cliffs, New Jersey: Yourdon Press, 1994. 256 p. JURADO, Y. Técnicas de Investigación Documental. México: Thomson International, 2003. 256 p. KENDALL, K. KENDALL, J. Análisis y Diseño de Sistemas. Mexico: Prentice Hall, 1991. 881 p. LAKHANPAL, B. Understanding the Factors Influencing the Performance of Software Development Groups: An Exporatory Group - Level Analysis. Information and Software Technology, 1993. 215 p. LARSON, C. E.; LAFASTO, F. M. J. Teamwork: What Must Go Right; What Can Go Wrong. Newbury Park, California: Sage, 1989. 245 p.

http://www.dhr.go.cr/

406

McLeod, R. Sistemas de Información Gerencial. Septima Edición. Mexico: 2000 Prentice Hall Hispanoamericana S.A. 688 p. PMI. Project Management Institute. Guía de los Fundamentos de la Dirección de Proyectos. Tercera Edición. Guía del PMBOOK. Tercera Edición. Newton Square, Pennsylvania, E.U.A: Project Management Inc., 2004. 392 p. PRESSMAN, R. Ingeniería del Software. Un Enfoque Práctico. Cuarta Edición. Mexico: McGraw Hill, 1998. 581 p. SENN, J. Análisis y Diseño de Sistemas de Información. Segunda Edición. Mexico: McGraw Hill, 1992. 942 p. STANDISH GROUP, T. Charting the Seas of Information Technology. Dennis, Massachusetts. The Standish Group, 1994. 215 p. THOMSETT, R. Project Pathology: A Study of Project Failures. American Programmer, Julio: 1995. 57 p. VAN GENUCHTEN, M. Why is Software Late? An Empirical Study of Reasons for Delay in Software Development. IEEE Transactions on Software Engineering: vol. 17, núm. 6. (Junio), 1991. 125 p.

407

8. ANEXOS

8.1. ANEXO A: CHARTER DEL PROYECTO FINAL DE GRADUACIÓN

MAESTRIA EN ADMINISTRACIÓN DE PROYECTOS

CHARTER (ACTA) DEL PROYECTO Página:

1/3

CHARTER DEL PROYECTO

INFORMACIÓN PRINCIPAL Y AUTORIZACIÓN DE PROYECTO Fecha: 17 de mayo de 2007

Nombre de Proyecto: Estándar Modelo de Administración de Proyectos de Tecnologías de Información para la Defensoría de Habitantes de la República (versión 1.0).

Área de conocimiento: Gestión de la Integración del Proyecto

Área de aplicación: Tecnologías de Información

Fecha de inicio del proyecto: 17 de mayo de 2007

Fecha tentativa de finalización del proyecto: 15 de septiembre del 2007

Objetivos del proyecto: Objetivo General: Desarrollar un Estándar Modelo de Administración de Proyectos de Tecnologías de Información para la Defensoría de Habitantes de la República (versión 1.0). Objetivos Específicos:




Descripción del Producto: • Primer Producto: Políticas generales para la gestión de proyectos de Tecnologías de Información

de la Defensoría de los Habitantes, referentes a: o Organización de Tecnologías de Información en la Defensoría de los Habitantes. o Principales participantes y su papel. o Funciones del Administrador de Proyectos. o Funciones del Director de Proyectos. o Esquemas organizativos de proyectos. o Criterios para la organización de proyectos. o Conceptualización de proyectos.

• Segundo Producto: Procedimiento general administrar los proyectos de Tecnologías de Información de la Defensoría de los Habitantes, que considera:

408



2/3


o Conceptualización de Proyectos. o Iniciación de proyectos. o Planificación de proyectos. o Seguimiento y Control de Proyectos o Cierre de Proyectos.

• Tercer Producto: Herramientas de Trabajo (Plantillas) para gestionar los proyectos de Tecnologías de Información de la Defensoría de los Habitantes, que incluye:

o Plantillas para la conceptualización de Proyectos. o Plantillas para la Iniciación de proyectos. o Plantillas para la planificación de proyectos. o Plantillas para el seguimiento y control de los Proyectos. o Plantillas para cierre de Proyectos. o Guía de reuniones (Incluye plantillas). o Guía de Herramientas y Técnicas. o Flujograma de Aplicación del Modelo propuesto. o Directorio de aplicación de las Plantillas.

Necesidad del proyecto: El proyecto surge como parte de la estrategia institucional de dotar a la Defensoría de los Habitantes de la República con las tecnologías de información necesarias que le permitan brindar un servicio eficiente, eficaz y con la mejor calidad a la ciudadanía Costarricense. La institución debe garantizar que los recursos invertidos en la adquisición de nuevas tecnologías serán ejecutados correctamente, pero carece de un marco que le permita administrar, controlar y auditar el nuevo esquema institucional que supone dependerá en gran parte de estos nuevos servicios de información. En la actualidad la Defensoría de los Habitantes carece de políticas, procedimientos y herramientas que le ayuden a construir un marco que permita la gobernabilidad, el control y la auditoria de las Tecnologías de Información, la experiencia de los años reflejan una debilidad institucional en el manejo de una cantidad importante de proyectos sin éxito, llevados a cabo con prácticas al azar que han atentado contra los presupuestos, los plazos y sobre todo la calidad de los mismos. El desarrollo de un estándar modelo responde a la necesidad que tiene la institución de tener “buenas practicas” que ayuden a optimizar las inversiones en información. Es un primer paso institucional para implantar la cultura de proyectos, y la base para desarrollar una metodología de gestión de proyectos de sistemas de información completa, eficiente y eficaz. El modelo propuesto esta basado en el estándar metodológico del Project Management Institute (PMBOOK, 2004).

409



3/3


Justificación del impacto: El desarrollo de un Estándar Modelo de Administración de Proyectos le permitirá a la Defensoría de los Habitantes contar con un marco general para la administración de Proyectos de Tecnologías de Información que responde a las necesidades que tiene la organización de solventar la criticidad de los siguientes puntos:

• El aumento de la dependencia de la información y de los sistemas que lo proveen; • La escala y los costos de las inversiones actuales y futuras en información y en sistemas de

información; y • El potencial que poseen las tecnologías para cambiar drásticamente las organizaciones y las

prácticas de negocio, crear nuevas oportunidades y reducir costos. Restricciones: Presupuesto Institucional, Recurso Humano, Cultura Organizacional, Cambios en la Alta Gerencia Identificación de grupos de interés (stakeholders): Despacho de Defensor y Defensor Adjunto, Áreas de Tecnologías de Información, Instituciones Públicas Cliente(s) directo(s): Área de Tecnologías de Información, Área de Auditoria, Área de Proveeduría Clientes indirectos: Proveedores Aprobado por: Ing. Miguel Vallejo

Firma:

410

411

8.2. ANEXO B: DECLARACIÓN DEL ALCANCE DEL PROYECTO FINAL DE GRADUACIÓN


DECLARACIÓN DEL ALCANCE DEL PROYECTO

Página:

1/3

Declaración del Alcance del Proyecto

INFORMACIÓN DEL PROYECTO Fecha: 17 de mayo de 2007

Nombre de Proyecto: Estándar Modelo de Administración de Proyectos de Tecnologías de Información para la Defensoría de Habitantes de la República (versión 1.0).

Planteo del problema (necesidad, oportunidad) y justificación del proyecto: Necesidad: El proyecto surge como parte de la estrategia institucional de dotar a la Defensoría de los Habitantes de la República con las tecnologías de información necesarias que le permitan brindar un servicio eficiente, eficaz y con la mejor calidad a la ciudadanía Costarricense. La institución debe garantizar que los recursos invertidos en la adquisición de nuevas tecnologías serán ejecutados correctamente, pero carece de un marco que le permita administrar, controlar y auditar el nuevo esquema institucional que supone dependerá en gran parte de estos nuevos servicios de información. En la actualidad la Defensoría de los Habitantes carece de políticas, procedimientos y herramientas que le ayuden a construir un marco que permita la gobernabilidad, el control y la auditoria de las Tecnologías de Información, la experiencia de los años reflejan una debilidad institucional en el manejo de una cantidad importante de proyectos sin éxito, llevados a cabo con prácticas al azar que han atentado contra los presupuestos, los plazos y sobre todo la calidad de los mismos. El desarrollo de un estándar modelo responde a la necesidad que tiene la institución de tener “buenas practicas” que ayuden a optimizar las inversiones en información. Es un primer paso institucional para implantar la cultura de proyectos, y la base para desarrollar una metodología de gestión de proyectos de sistemas de información completa, eficiente y eficaz. El modelo propuesto esta basado en el estándar metodológico del Project Management Institute (PMBOOK, 2004). Justificación: El desarrollo de un Estándar Modelo de Administración de Proyectos le permitirá a la Defensoría de los Habitantes contar con un marco general para la administración de Proyectos de Tecnologías de Información que responde a las necesidades que tiene la organización de solventar la criticidad de los siguientes puntos:

• El aumento de la dependencia de la información y de los sistemas que lo proveen; • La escala y los costos de las inversiones actuales y futuras en información y en sistemas de

información; y • El potencial que poseen las tecnologías para cambiar drásticamente las organizaciones y las

prácticas de negocio, crear nuevas oportunidades y reducir costos.

412


DECLARACIÓN DEL ALCANCE DEL PROYECTO Página:

2/3


Objetivos del proyecto: Objetivo General: Desarrollar un Estándar Modelo de Administración de Proyectos de Tecnologías de Información para la Defensoría de Habitantes de la República (versión 1.0). Objetivos Específicos:




Producto Principal del Proyecto: Estándar Modelo de Administración de Proyectos de Tecnologías de Información para la Defensoría de Habitantes de la República (versión 1.0). Entregables del Proyecto:

• Primer Producto: Políticas generales para la gestión de proyectos de Tecnologías de Información de la Defensoría de los Habitantes, referentes a:

o Organización de Tecnologías de Información en la Defensoría de los Habitantes. o Principales participantes y su papel. o Funciones del Administrador de Proyectos. o Funciones del Director de Proyectos. o Esquemas organizativos de proyectos. o Criterios para la organización de proyectos. o Conceptualización de proyectos.

• Segundo Producto: Procedimiento general administrar los proyectos de Tecnologías de Información de la Defensoría de los Habitantes, que considera:

o Conceptualización de Proyectos. o Iniciación de proyectos. o Planificación de proyectos. o Seguimiento y Control del Proyectos o Cierre de Proyectos.

• Tercer Producto: Herramientas de Trabajo (Plantillas) para gestionar los proyectos de Tecnologías de Información de la Defensoría de los Habitantes, que incluye:

413


DECLARACIÓN DEL ALCANCE DEL PROYECTO Página:

3/3


o Plantillas para la conceptualización de Proyectos. o Plantillas para la Iniciación de proyectos. o Plantillas para la planificación de proyectos. o Plantillas para el seguimiento y control de los Proyectos. o Plantillas para cierre de Proyectos. o Guía de reuniones (Incluye plantillas). o Guía de Herramientas y Técnicas. o Flujograma de Aplicación del Modelo propuesto. o Directorio de aplicación de las Plantillas.

414

415

8.3. ANEXO C: EDT – WBS

Proyecto Final de Graduación

Fase deFormalización

Matrícula del PFGSesión inicial con profesor tutor

Desarrollo delEstándar en AP

Definir las Políticas de APRevisión de los resultados por el tutorAprobación del resultado (producto)Procedimiento General de Gestión de ProyectosRevisión de los resultados por el tutorAprobación del resultado (producto)Desarrollo de las Plantillas del estándar de APRevisión de los resultados por el tutorAprobación del resultado (producto)Desarrollo de Herramientas para la APRevisión de los resultados por el tutorAprobación del resultado (producto)

Fin de Proyecto

Preparación de documento finalLectura del documento finalCorrecciones al documento finalPlanificación de la presentación con el tutorAprobación de presentaciónPlanificación de sustentaciónSustentación final

416

417

8.4. ANEXO D: DESARROLLO DEL CRONOGRAMA DEL PROYECTO FINAL DE GRADUACIÓN

Id Nombre de tarea Duración Comienzo0 Proyecto Final de Graduación 83,75 días? jue 24/05/071 Fase de Formalización 3 días jue 24/05/07

2 Matrícula del PFG 1 día jue 24/05/07

3 Sesión inicial con profesor tutor 1 día lun 28/05/07

4 Desarrollo del Estándar en AP 62,75 días? mar 29/05/07

5 Definir las Políticas de AP 7,75 días mar 29/05/07

6 Revisión de los resultados por el tutor 1,75 días vie 08/06/07

7 Aprobación del resultado (producto) 1,75 días mié 13/06/07

8 Procedimiento General de Gestión de Proyectos 11,75 días? vie 15/06/07

9 Revisión de los resultados por el tutor 4,75 días mar 03/07/07

10 Aprobación del resultado (producto) 2,75 días mar 10/07/07

11 Desarrollo de las Plantillas del estándar de AP 9,75 días vie 13/07/07


13 Aprobación del resultado (producto) 2,75 días mié 01/08/07

14 Desarrollo de Herramientas para la AP 1 día? mié 15/08/07


16 Aprobación del resultado (producto) 2,75 días mar 21/08/07

17 Fin de Proyecto 17,75 días? vie 24/08/07

18 Preparación de documento final 1,75 días vie 24/08/07

19 Lectura del documento final 10 días? lun 27/08/07

20 Correcciones al documento final 2,75 días? lun 10/09/07

21 Planificación de la presentación con el tutor 1 día? mié 12/09/07

22 Aprobación de presentación 1 día? jue 13/09/07

23 Planificación de sustentación 1 día? vie 14/09/07

24 Sustentación final 0,75 días mar 18/09/07

24/05 24/05

28/05 28/05

29/05 07/06

08/06 11/06

13/06 14/06

15/06 02/07

03/07 09/07

10/07 12/07

13/07 26/07

27/07 31/07

01/08 03/08

15/08 16/08

17/08 20/08

21/08 23/08

24/08 27/08

27/08 10/09

10/09 12/09

12/09 13/09

13/09 14/09

14/09 17/09

18/09 18/09

mar 20 lun 16 a dom 13 sáb 09 j vie 06 jul jue 02 a mié 29 a mar 25 s

Tarea

Tarea crítica

Progreso

Hito

Resumen

Tarea resumida

Tarea crítica resumida

Hito resumido

Progreso resumido

División

Tareas externas

Resumen del proyecto

Agrupar por síntesis

Fecha límite

Proyecto: Proyecto Final de GraduFecha: vie 23/11/07

418

Documents

MAESTRÍA EN ADMINISTRACIÓN DE PROYECTOS · maestrÍa en administraciÓn de proyectos universidad para la cooperaciÓn internacional (uci) ... informe de revisiÓn cierre del proyecto.....124