Proyecto++informatico.desbloqueado.pdf

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

METODOLOGIA PARA ESTANDARIZACION DE LA ADMINISTRACION DE PROYECTOS INFORMATICOS DENTRO DE LA DIRECCION DE TECNOLOGIA DE INFORMACION Y COMUNICACIONES DEL BANCO NACIONAL

MARIA ALEJANDRA MORA RODRIGUEZ

PROYECTO FINAL DE GRADUCIACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACION DE PROYECTOS

San José, Costa Rica FEBRERO 2008

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

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

___________________________ Juan Carlos Navarro PROFESOR TUTOR

__________________________ Fausto Fernández Martínez LECTOR Nº 1

___________________________ Víctor Noguera Durán LECTOR Nº 2

___________________________ María Alejandra Mora Rodríguez SUSTENTANTE

i

AGRADECIMIENTO

A Dios por darme el don del entendimiento. Sin las maravillas que me regalas día a día, no podría conseguir el éxito que hasta el día de hoy he alcanzado. A Juan Carlos, por su colaboración y apoyo en este proceso.

ii

DEDICATORIA

A mi mamá, porque gracias a su esfuerzo he logrado llegar hasta aquí. A mi papá que a la distancia siempre recibo su apoyo. Y a mi abuela Rosa, aunque ya no estas aquí, siempre estarás en mi corazón, con tus oraciones llenaste mi vida de bendiciones.

iii

“Dichoso el que adquiere sabiduría y consigue prudencia. Tener sabiduría vale más que tener dinero; conseguir prudencia es mejor que conseguir oro. Ser sabio es más valioso que tener perlas y esmeraldas. No hay tesoro que iguale al tener sabiduría.” Proverbios 3,13

iv

Metodología para la Administración de Proyectos Informáticos

INDICE DE CONTENIDO CAPITULO 1

INTRODUCCION ........................................................................... 1

1.1

Antecedentes .................................................................................................... 2

1.2

Problemática ..................................................................................................... 2

1.3

Justificación del proyecto................................................................................ 3

1.4

Objetivos ........................................................................................................... 4

1.4.1

Objetivo General............................................................................................................ 4

1.4.2

Objetivos específicos..................................................................................................... 4

CAPITULO 2 2.1

MARCO TEORICO ........................................................................ 5

Marco Referencial ............................................................................................. 6

2.1.1

Banco Nacional de Costa Rica...................................................................................... 6

2.1.2

Análisis de Negocio ....................................................................................................... 9

2.2

Teoría de Administración de proyectos ........................................................ 14

2.2.1

Procesos para la Administración de Proyectos........................................................... 15

2.2.2

Áreas de Conocimiento ............................................................................................... 17

2.2.3

Metodología ................................................................................................................. 22

2.2.4

Sistemas Informáticos ................................................................................................. 23

2.2.5

Rational Unified Process ............................................................................................. 23

2.2.6

Procesos en el desarrollo de sistemas informáticos ................................................... 25

2.2.7

La administración de proyectos en sistemas informáticos.......................................... 29

CAPITULO 3 3.1

MARCO METODOLOGICO......................................................... 30

Descripción ..................................................................................................... 31

3.1.1

Tipo de investigación................................................................................................... 31

3.1.2

Fuentes de información ............................................................................................... 32

3.2

Entregables ..................................................................................................... 33

3.2.1

Análisis del proceso actual .......................................................................................... 33

3.2.2

Análisis áreas de conocimiento PMI y los procesos de TI .......................................... 34

3.2.3

Flujo de procesos para la administración de proyectos de TI..................................... 35

v

Metodología para la Administración de Proyectos Informáticos

3.2.4

Plantillas a utilizar en la administración de proyectos de TI........................................ 36

3.2.5

Metodología propuesta aplicada ................................................................................. 37

3.2.6

Plan preliminar de divulgación de la metodología....................................................... 37

CAPITULO 4 4.1

DESARROLLO ............................................................................ 38

Análisis de la situación actual ....................................................................... 39

4.1.1

Proceso de la Dirección de Análisis de Negocio......................................................... 39

4.1.2

Procesos de TI en la DCTIC........................................................................................ 41

4.1.3

Plantillas actuales de TI............................................................................................... 43

4.1.4

Metodología del BNCR................................................................................................ 45

4.1.5

Comparación de PMI y procesos de desarrollo .......................................................... 50

4.1.6

Resultados del cuestionario y entrevistas ................................................................... 51

4.2

Metodología propuesta................................................................................... 53

4.2.1

Procesos para proyectos de TI ................................................................................... 53

4.2.2

Diagramación de los procesos .................................................................................... 60

4.2.3

Plantillas para administración de proyectos de TI....................................................... 71

4.3

Validación de la metodología....................................................................... 109

4.3.1

Proyecto seleccionado .............................................................................................. 109

4.3.2

Plantillas aplicadas .................................................................................................... 109

4.4

Plan de divulgación ...................................................................................... 137

4.4.1

Objetivo...................................................................................................................... 137

4.4.2

Personal a quien va dirigido ...................................................................................... 137

4.4.3

Temario propuesto .................................................................................................... 137

4.4.4

Definición de recursos ............................................................................................... 138

4.4.5

Tareas a realizar........................................................................................................ 138

CAPITULO 5

CONCLUSIONES Y RECOMENDACIONES............................. 139

5.1

Conclusiones ................................................................................................ 140

5.2

Recomendaciones ........................................................................................ 142

BIBLIOGRAFIA .................................................................................................. 145 ANEXOS ............................................................................................................. 147 Anexo 1 Acta del proyecto....................................................................................... 148

vi

Metodología para la Administración de Proyectos Informáticos

Anexo 2 Declaración del alcance ............................................................................ 150 Anexo 3 WBS ............................................................................................................ 152 Anexo 4 Cronograma ............................................................................................... 153 Anexo 5 Resultado de las entrevistas..................................................................... 156 Anexo 7 Plantillas Metodología BNCR.................................................................... 168 Anexo 8 Formato de los documentos ..................................................................... 176 Anexo 9 Plantillas de TI ........................................................................................... 180

vii

Metodología para la Administración de Proyectos Informáticos

INDICE DE ILUSTRACIONES Figura 1. Organigrama BNCR (BNCR, 2007)_____________________________ 8 Figura 2. Organigrama DCTIC _______________________________________ 10 Figura 3. Organigrama Análisis de Negocio_____________________________ 10 Figura 4. Relación de los Grupos de Procesos (PMI, 2004) ________________ 16 Figura 5. Procesos de Gestión del alcance _____________________________ 18 Figura 6. Procesos de Gestión del Tiempo _____________________________ 19 Figura 7. Procesos de Gestión de los Recursos Humanos _________________ 19 Figura 8. Procesos de Gestión de las Comunicaciones____________________ 20 Figura 9. Procesos de Gestión de los Riesgos __________________________ 21 Figura 10. Procesos de la Gestión de la Integración ______________________ 22 Figura 11. Proceso de desarrollo iterativo. (Traducido del RUP, 2005) ________ 26 Figura 12. Macro proceso de TI ______________________________________ 41 Figura 13. Proceso de recepción de un proyecto_________________________ 54 Figura 14. Proceso de conceptualización de un proyecto __________________ 56 Figura 15. Proceso de Elaboración ___________________________________ 58 Figura 16. Proceso de cierre de un proyecto de Negocio __________________ 60 Figura 17. Diagrama proceso de recepción _____________________________ 61 Figura 18. Diagrama del proceso de Conceptualización ___________________ 62 Figura 19. Continuación Diagrama del proceso de Conceptualización ________ 63 Figura 20. Continuación Diagrama del proceso de Conceptualización ________ 64 Figura 21. Diagrama del proceso de Elaboración ________________________ 65 Figura 22. Continuación Diagrama del proceso de Elaboración _____________ 66 Figura 23. Diagrama del Proceso de Construcción y Transición _____________ 67 Figura 24. Continuación Diagrama del Proceso de Construcción y Transición __ 68 Figura 25. Diagrama de cierre _______________________________________ 69 Figura 26. Diagrama de control de cambios ____________________________ 70

viii

Metodología para la Administración de Proyectos Informáticos

INDICE DE CUADROS Cuadro 1. Cuestionarios análisis del proceso actual............................................. 33 Cuadro 2. Documentos utilizados en DCTIC......................................................... 50 Cuadro 3. Herramientas y su funcionalidad .......................................................... 72 Cuadro 4. Documentos y/o plantillas a utilizar en proyectos de TI por fases ........ 75 Cuadro 5. DANTI-03 Modelo caso de uso ............................................................ 78 Cuadro 6. DANTI-04 Lista de Insumos ................................................................. 79 Cuadro 7. DANTI-05 Acta de Inicio ....................................................................... 81 Cuadro 8. DANTI-06 Visión técnica ...................................................................... 83 Cuadro 9. DANTI-07 Modelación del negocio....................................................... 85 Cuadro 10. DANTI-08 Plan del proyecto............................................................... 86 Cuadro 11. DANTI-09 Cronograma....................................................................... 94 Cuadro 12. DANTI-10 Recursos del proyecto ....................................................... 96 Cuadro 13. DANTI-11 Matriz de comunicaciones ................................................. 97 Cuadro 14. DANTI-12 Lista de Riesgos ................................................................ 98 Cuadro 15. DANTI-13 Informe semanal................................................................ 99 Cuadro 16. DANTI-14 Informe mensual.............................................................. 100 Cuadro 17. DANTI-15 Aceptación del producto .................................................. 101 Cuadro 18. DANTI-16 Nota de cierre .................................................................. 102 Cuadro 19. DANTI-17 Recepción de entregables ............................................... 104 Cuadro 20. DANTI-18 Control de Cambios ......................................................... 105 Cuadro 21. DANTI-19 Glosario ........................................................................... 106 Cuadro 22. DANTI-20 Lecciones aprendidas...................................................... 107 Cuadro 23. Plantillas aplicadas ........................................................................... 109 Cuadro 24. Tareas por realizar ........................................................................... 138

ix

Metodología para la Administración de Proyectos Informáticos

ABREVIATURAS Y CONCEPTOS ANPS

Aplicación Normativa Prudencial SUGEF

AP

Administración de Proyectos

BNCR

Banco Nacional de Costa Rica

BUCRE

Base Única de Crédito

COVIC

Sistema para la Consolidación y verificación de Información Crediticia

DANTI

Dirección de Análisis de Negocio de Tecnología de Información Dirección

DCTIC

Corporativa

de

Tecnología

de

Información

y

Comunicaciones

DEP

Dirección de Estrategia y Proyectos

DTS

Data Transformation Services

FINESSE

Sistema de Cajas

IBM

International Business Machines

MTVAL

Módulo de Transferencia de Valores

OGC

Office of Government Commerce

Oracard

Sistema de Administración de Tarjetas de Crédito Siglas en inglés de Software para Ingeniería Orientada a Objetos

OOSE

PMBOK

(Software Object- Oriented Software Engineering) Guía de los Fundamentos de la Dirección de Proyectos del PMI

x

Metodología para la Administración de Proyectos Informáticos

PMI

Project Manager Institute (Instituto de Administración de Proyectos)

RUP

Rational Unified Process

SFB

Sistema Financiero Bancario

SIACC

Sistema Integrado de la Administración de la Cartera de Crédito

SICICC

Sistema Conciliación Información Crediticia

SICVECA

Sistema de Verificación y Carga de datos - SUGEF

SIEF

Sistema Integrador para Entidades Financieras

SIFCO

Sistema Financiero Contable

SUGEF

Superintendencia General de Entidades Financieras

TI

Tecnologías de Información

TIR

Tasa Interna de Retorno

UML

Siglas en inglés de Lenguaje de Modelamiento Unificado (Unified Modeling Language)

VAN

Valor Actual Neto

WBS- EDT

Siglas en inglés de Estructura de Desglose del Trabajo (Work Breakdown Structure)

xi

Metodología para la Administración de Proyectos Informáticos

RESUMEN EJECUTIVO

xii

Metodología para la Administración de Proyectos Informáticos

Las organizaciones han recurrido a la utilización de la tecnología de información para lograr una ventaja competitiva, como base para la toma de decisiones. Estas tecnologías deben brindar información oportuna, veraz y exacta, que les permita colaborar en el planeamiento de las estrategias de negocio y robustecer sus fortalezas internas. En su afán de cumplir las necesidades del negocio, mejorar los servicios y los tiempos de respuesta que la Dirección Corporativa de Tecnología de Información y Comunicaciones (DCTIC) brinda a las unidades de negocio, se crea la Dirección de Análisis de Negocio, cuya función es administrar los proyectos informáticos. Dada la importancia de esta dirección, el siguiente documento tiene como objetivo elaborar una Metodología para la Administración de Proyectos Informáticos dentro de la Dirección de Análisis de Negocio de la DCTIC, considerando las mejores prácticas propuestas por el PMI en el PMBOK 2004. Dentro de los objetivos específicos que se plantean en el desarrollo de este documento se encuentran: analizar el proceso de administración de proyectos de TI que realiza la Dirección de Análisis de Negocio para identificar debilidades; realizar un análisis comparativo entre las disciplinas de PMI y los procesos de proyectos de TI para relacionar ambos procesos; definir el flujo de procesos para la administración de proyectos de TI para guiar al personal; confeccionar las plantillas para el apoyo a utilizar en la administración de proyectos de TI; aplicar parcialmente la metodología propuesta para validarla; desarrollar un plan preliminar de divulgación de la metodología para hacerla del conocimiento de la Dirección de Análisis de Negocio. Para el desarrollo del documento se realizará una investigación exploratoria, con el fin de obtener los conocimientos sobre el tema y una investigación descriptiva, con lo cual se estará describiendo las características del objetivo. Además se recurrirá a los siguientes instrumentos: cuestionarios (identificar procesos y conocimiento del personal), entrevistas (analizar el proceso, retroalimentación del personal, validación de información), revisión de documentación (verificación de información) y confección de documentación. Además se consideró como estándar la Guía de los fundamentos de administración de proyectos (Guía del PMBOK) en las áreas de: alcance, tiempo, costo, recursos humanos, riesgos, comunicación e integración. La metodología desarrollada está acorde con la Metodología de Administración de Proyectos del BNCR y los procesos de la DCTIC. Como primer punto se analiza la situación actual, entorno a la administración de proyectos informáticos dentro de la DCTIC y la Metodología de Administración de Proyectos del BNCR, esto con el fin de encontrar los puntos de mejora y

xiii

Metodología para la Administración de Proyectos Informáticos

estandarizar el proceso. Considerando este análisis se realiza el planteamiento de la propuesta donde el primer punto es la definición de los procesos que se desarrollan durante un proyecto de tecnología, considerando a nivel general la participación de las direcciones pertenecientes a la DCTIC. Uno de los hallazgos es que los ejecutivos de tecnología, quienes administran los proyectos informáticos, no tienen un estándar para administrar los proyectos, cada quien considera su método de trabajo. Por tanto se desarrolla la diagramación de los procesos involucrados en la administración, estos diagramas contiene el flujo de las actividades que se deben desarrollar, indicando los documentos y/o plantillas que se deben completar, además de los responsables de realizar cada actividad y los insumos necesarios. Cabe destacar, que dentro de la metodología no se hace obligatoria la utilización de todos los documentos y/o plantillas, sino va a depender del tipo de proyecto y la duración del mismo. Otro punto importante es que la identificación de los documentos a utilizar en el desarrollo del proyecto, encajado con cada uno de los procesos de la DCTIC y la concordancia con las fases del proyecto acorde a la Metodología de Administración de Proyectos del BNCR. Estos documentos y/o plantillas contienen una guía con la información que requiere para ser desarrollada, esto para dar una guía a los ejecutivos y facilitar su desarrollo. Para evaluar la metodología propuesta se seleccionó un proyecto y se aplicaron las plantillas propuestas de la fase de conceptualización, con esto se logra analizar lo planteado y realizar las mejoras correspondientes, para facilitar su uso y desarrollo. Con el fin de dar a conocer la metodología, se desarrolló un plan de divulgación con el objetivo que los ejecutivos de tecnología conozcan la misma y la apliquen dentro de sus labores y así estandarizar el proceso actual. Para ir madurando en la administración de proyectos, es necesario mantener una forma estandarizada de realizar las tareas, por tanto, esta metodología se convierte en una guía práctica para los ejecutivos de tecnología, unificando los procesos y la documentación que se debe generar. Dado que cada proyecto es diferente, durante su desarrollo el personal va adquiriendo la experiencia. Es importante que esta experiencia se mantenga dentro de la institución, porque servirá como referencia para otros proyectos en la toma de decisiones.

xiv

Metodología para la Administración de Proyectos Informáticos

1

CAPITULO 1 INTRODUCCION

Metodología para la Administración de Proyectos Informáticos

1.1

2

Antecedentes

La utilización de la tecnología de información, se ha convertido en una ventaja competitiva para las organizaciones, dado que la información está unida a todas las funciones dentro de las instituciones y es la base para la toma de decisiones gerenciales. Una de las funciones de los sistemas de información es mejorar el desempeño de la organización, brindando información oportuna, veraz y exacta. Con los datos obtenidos de los sistemas, se realiza la toma de decisiones y colaboran en el planeamiento de las estrategias de negocio que permitan robustecer sus fortalezas internas. En su afán de mejorar los servicios y los tiempos de respuesta que la Dirección Corporativa de Tecnología de Información y Comunicaciones (DCTIC) brinda a las demás unidades de negocio en el tema de tecnología de información, se inició a principios del 2007, un proceso de reestructuración, creando con ello una dirección llamada Análisis de Negocio. Esta dirección tiene la función de administrar los proyectos informáticos que ingresen a la DCTIC asegurando que se cumplan las necesidades del negocio.

1.2

Problemática

La Dirección de Análisis de Negocio no posee una metodología que guíe la forma de administrar los proyectos de tecnología acordes a sus procesos. El Banco Nacional desde mayo de 1999 posee una metodología para la administración de proyectos la cual es de uso obligatorio para los directores de proyectos.

Metodología para la Administración de Proyectos Informáticos

3

Los ejecutivos de tecnología que laboran en la Dirección de Análisis de Negocio, utilizan ciertas plantillas de esta metodología, en otras ocasiones realizan adaptaciones al considerar que las plantillas no contemplan la información necesaria, unido a esto cada ejecutivo utiliza las plantillas a conveniencia de acuerdo a su criterio personal, lo cual ha conllevado a quejas por parte de las unidades de negocio donde indican que las formas de administrar proyectos entre los ejecutivos de tecnología son muy distintas.

1.3

Justificación del proyecto

Con el fin de fortalecer la Dirección de Análisis de Negocio y estandarizar la administración de proyectos de TI, se creará la metodología para proyectos de TI, tomando en cuenta la metodología del banco, los procesos de TI y las mejores prácticas consideradas en el PMBOK (PMI, 2004). De tal forma que las áreas de negocio se aseguren que se está utilizando un proceso estandarizado en la gestión de sus proyectos, basado en las mejores prácticas. Esta metodología permitirá a los ejecutivos de tecnología contar con una guía que le ayuden a administrar los proyectos en sus distintos procesos. La metodología para la administración de proyectos de TI se gestionará por grupos de procesos: Conceptualización, Planeación, Seguimiento y Control y Cierre. En cuanto a las áreas de administración de proyectos especificadas en el PMBOK (PMI, 2004), la metodología considera: alcance, tiempo, recursos humanos, comunicaciones, riesgos e integración. No se consideran las áreas de abastecimientos, costo y calidad.

Metodología para la Administración de Proyectos Informáticos

1.4

4

Objetivos

1.4.1 Objetivo General Elaborar una Metodología para la Administración de Proyectos Informáticos dentro de la Dirección de Análisis de Negocio de la DCTIC, considerando las mejores prácticas propuestas por el PMI en el PMBOK 2004, con el fin de estandarizar el proceso de administración de proyectos.

1.4.2 Objetivos específicos Analizar el proceso de administración de proyectos de TI que realiza la Dirección de Análisis de Negocio para identificar debilidades. Realizar un análisis comparativo entre las disciplinas de PMI y los procesos de proyectos de TI para relacionar ambos procesos. Definir el flujo de procesos para la administración de proyectos de TI para guiar al personal. Confeccionar las plantillas para el apoyo a utilizar en la administración de proyectos de TI. Aplicar parcialmente la metodología propuesta para validarla. Desarrollar un plan preliminar de divulgación de la metodología para hacerla del conocimiento de la Dirección de Análisis de Negocio.

Metodología para la Administración de Proyectos Informáticos

5

CAPITULO 2 MARCO TEORICO

Metodología para la Administración de Proyectos Informáticos

2.1

6

Marco Referencial

2.1.1 Banco Nacional de Costa Rica 2.1.1.1 Perfil El Banco Nacional de Costa Rica, en sus inicios Banco Internacional de Costa Rica, fue fundado mediante decreto número dieciséis del 09 de octubre de 1914, por la administración de don Alfredo González Flores. Dentro de las razones para su fundación se citan dos importantes (BNCR, 2007): La situación creada por la coyuntura económica del país a raíz de la primera Guerra Mundial, y la negativa de los bancos privados existentes a esa fecha de concederle dos millones de colones (¢2.000.000.00) al gobierno de don Alfredo González Flores, que le hubieran ayudado a solventar sus necesidades. La filosofía reformista de la administración de don Alfredo González Flores, la cual implicaba una ruptura ideológica con el liberalismo predominante en la época, pues consideraba que el Estado debía tener un papel protagónico, enfatizando la función social que debía cumplir en la economía del país, principalmente en lo que se refería al crédito rural que defendía al pequeño productor. Bajo estas dos premisas se fundó el Banco Internacional de Costa Rica, con carácter público, es decir, el banco pertenecía al Estado, con una emisión de cuatro millones de colones (¢4.000.000.00), garantizados con bonos del tesoro. El 5 de noviembre de 1936 se le cambió el nombre al de Banco Nacional de Costa Rica y desde entonces, se ha consolidado como un banco de desarrollo con una

Metodología para la Administración de Proyectos Informáticos

7

proyección trascendente y positiva en la vida económica, social y financiera del país. (BNCR, 2007)

2.1.1.2 Misión Ofrecer eficientemente servicios financieros universales y estandarizados que sobrepasen las expectativas de sus clientes por medio de: atención especializada por segmentos, uso de canales electrónicos, el compromiso de integridad y espíritu de servicio de sus colaboradores, para coadyuvar en la alfabetización financiera y el desarrollo socioeconómico del país. (BNCR, 2007)

2.1.1.3 Visión El Banco Nacional de Costa Rica es la principal institución financiera, del país, de propiedad estatal, que impulsa el desarrollo económico y social, ofreciendo soluciones integrales globalizadas, un servicio de alto valor para sus clientes, con un recurso humano eficiente, una plataforma tecnológica que facilite el uso intensivo de productos mediante canales electrónicos, comprometidos con la sostenibilidad del medio ambiente, con el objetivo fundamental de maximizar la rentabilidad y mantener una suficiencia patrimonial adecuada. (BNCR, 2007)

Metodología para la Administración de Proyectos Informáticos

8

2.1.1.4 Organigrama El Banco Nacional posee una estructura organizacional que favorece un alto nivel de descentralización de la responsabilidad, lo que permite una toma de decisiones más rápidas dentro de la organización. Dicha estructura se muestra a continuación en la ilustración 1.

Figura 1. Organigrama BNCR (BNCR, 2007)

Metodología para la Administración de Proyectos Informáticos

9

2.1.2 Análisis de Negocio 2.1.2.1 Misión “Administrar las solicitudes de negocio e infraestructura, siendo esto proyectos o requerimientos, de acuerdo a las mejores prácticas, controlando los riesgos y superando los obstáculos, para entregar con éxito un producto que resuelva las necesidades planteadas dentro del plazo, presupuesto y niveles de calidad estipulados por la institución en lo que corresponde al área de tecnología, manteniendo una estrecha relación con las áreas de negocio y usuario final, para cumplir con los objetivos institucionales.” (BNCR, 2007)

2.1.2.2 Visión Consolidar una dependencia especializada en la atención, administración y análisis de las necesidades del negocio que garantice la integración con la infraestructura tecnológica existente y con los objetivos institucionales. (BNCR, 2007)

Metodología para la Administración de Proyectos Informáticos

10

2.1.2.3 Organigrama La DCTIC, con el proceso de reestructuración ha implementado una organización definida por procesos de TI, tal como se muestra en el siguiente organigrama.

Figura 2. Organigrama DCTIC

Con el fin de agilizar los procesos de especializar los recursos en la atención de los clientes internos, la Dirección de Análisis de Negocio se divide en dos unidades: Unidad de Proyectos de Negocio: se encarga de los proyectos de desarrollo de software los cuales son solicitados por las áreas de negocio Unidad de Proyectos de Infraestructura: tiene la responsabilidad de los proyectos relacionados con la infraestructura tecnológica (hardware).

Figura 3. Organigrama Análisis de Negocio

11

Metodología para la Administración de Proyectos Informáticos

2.1.2.4 Objetivos generales La Dirección de Análisis de Negocio tiene como objetivos generales, los que se indican a continuación (BNCR, 2007): Asesorar a las áreas de negocio en la adopción de habilidades y técnicas que les permita modelar el negocio de acuerdo con un lenguaje común con el área tecnológica. Garantizar a través de la figura del ejecutivo de tecnología la atención de las necesidades planteadas por las áreas de negocio, desde su definición hasta la implantación de la solución tecnológica. Mantener una estrecha comunicación con las áreas involucradas en la atención de necesidades de negocio e infraestructura, administrando los cambios producto de nuevas funcionalidades que impacten el alcance, tiempo y recursos asignados.

2.1.2.5 Objetivos específicos La Dirección de Análisis de Negocio ha definido los siguientes objetivos específicos (BNCR, 2007): Apoyar a las áreas de negocio en el proceso de conceptualización de los proyectos en temas metodológicos relacionados con la Administración de Proyectos y con las herramientas tecnológicas existentes. Coordinar con las áreas de negocio para que las necesidades sean planteadas a través de un vocabulario común entre el negocio y tecnología. Administrar los requerimientos planteados que permitan garantizar su cumplimiento a lo largo de todo el proceso de desarrollo. Impulsar

la

metodología

de

administración

de

cambios

en

los

requerimientos, que permitan evaluar el impacto en tiempo, costo y alcance de los mismos.

Metodología para la Administración de Proyectos Informáticos

12

Coordinar las acciones a seguir tanto a nivel interno de la DCTIC como externo ante cambios en el alcance del proyecto. Coordinar con la Dirección de Estrategia y Proyectos la priorización de los proyectos, permitiendo planificar y organizar los recursos internos de la DCTIC para atender las solicitudes planteadas. Coordinar a nivel interno de la DCTIC la solución de las necesidades planteadas por las áreas de negocio. Establecer y consolidar el estado de resultados por área de negocio y a nivel interno de la DCTIC de forma mensual.

2.1.2.6 Perfil del personal Dentro de la Dirección Análisis de Negocio, se ha establecido el perfil del personal que labora en está dirección, considerando aspectos académicos, personales y experiencia, los cuales se detallan a continuación: Académico o Conocimiento bancario del negocio o Conocimiento bancario de infraestructura o Formación en Administración de Proyectos o Conocimiento del inglés Personal o Relaciones personales o Presentación personal o Logística y cultura de grupo o Trabajo en equipo o Liderazgo o Respeto y humildad o Capacidad de Organización o Calidad de servicio al cliente (Interno y Externo)

Metodología para la Administración de Proyectos Informáticos

13

o Creatividad y proactividad (búsqueda de soluciones y resultados) o Negociador o Disposición, puntualidad, responsabilidad, compromiso y efectividad Experiencia o Experiencia Bancaria en el área de tecnología y del negocio. o Ampliamente analítico para el negocio. o Ampliamente estratégico en cuanto a la tecnología del Banco. o Administración y tecnología de proyectos. o Administración del cambio. o Administración de riesgos (proyectos, auditoría).

Metodología para la Administración de Proyectos Informáticos

2.2

14

Teoría de Administración de proyectos

Como primer punto, es importante considerar ¿cuál es el concepto Administración de Proyectos?, dividiendo ambos elementos, se definen: Administración es la “acción de ordenar, disponer, organizar” (Real Academia Española, 2007) “Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único” (PMI, 2004). Considerando como temporal el hecho que tienen un principio y un fin determinado. Además tiene sus límites presupuestarios, para la adquisición de recursos tanto humanos como materiales. Según Gido y Clements (2003), los proyectos tienen una serie de atributos que lo definen: Tiene un objetivo Se desarrollan una serie de actividades interdependientes Se necesitan de los recursos para realizar las actividades Está enmarcado en un tiempo específico Es un esfuerzo único Tiene un cliente, quien posee la necesidad Posee incertidumbre, al darse supuestos y estimaciones Considerando ambos términos la administración de proyectos se puede definir como el proceso de organizar los recursos en un periodo determinado con el fin de obtener un resultado único. Cada proyecto posee un ciclo de vida lo cual facilita el desarrollo del mismo. Este ciclo está compuesto de fases, las cuales son definidas por el director del proyecto o en algunos por la organización. En la medida que cada unos de las fases vayan

Metodología para la Administración de Proyectos Informáticos

15

concluyendo, con lleva un crecimiento gradual al proyecto, dado que van incorporando elementos y completando la realización de tareas al proyecto. Las organizaciones con mayor madurez en el desarrollo de proyectos poseen su ciclo de vida ya definido y una metodología que les permite agilizar el proceso de desarrollo de los proyectos.

2.2.1 Procesos para la Administración de Proyectos Un proceso es un “conjunto de las fases sucesivas de un fenómeno natural o de una operación artificial” (Real Academia Española, 2007). Dentro de la administración de proyectos, “los procesos son guías para aplicar los conocimientos y habilidades apropiadas relativos a la dirección de proyectos durante el proyecto”. (PMI, 2004) PMI (2004) define cinco grupos de procesos, los cuales están relacionados al “ciclo planificar-hacer-revisar-actuar”. Eliminando los procesos de inicio y cierre, tal como lo indica Chamoun (2002), queda un proceso de mejora continua descritos por expertos en calidad. Estos grupos de procesos son: Iniciación: define y autoriza el proyecto o una fase del mismo. En este proceso se define el alcance y se obtiene el compromiso de la organización. “Es establecer la visión del proyecto, el qué”. (Chamoun, 2002) Planificación: define y refina los objetivos, se planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto, es importante que en la planificación se logre madurar el alcance del proyecto para fijar los límites del mismo. Esto significa “desarrollar un plan que nos ayude a prever el cómo”. (Chamoun, 2002)

Metodología para la Administración de Proyectos Informáticos

16

Ejecución: se realiza la integración a personas y los recursos para realizar las actividades acordes a lo planificado. Es decir, “implementar el plan, contratar, integrar, distribuir y ejecutar las acciones”. (Chamoun, 2002) Seguimiento y Control: mide y supervisa regularmente el avance, a fin de identificar las variaciones respecto del plan de gestión del proyecto, de tal forma que se tomen medidas correctivas cuando sea necesario para cumplir con los objetivos del proyecto. El control significa “comparar lo ejecutado contra lo planeado”. (Chamoun, 2002) Cierre: formaliza la aceptación del producto, servicio o resultado, y termina el proyecto o una fase del mismo. El cierre es “concluir relaciones contractuales”. (Chamoun, 2002)

Figura 4. Relación de los Grupos de Procesos (PMI, 2004)

Los grupos procesos se relacionan entre si, donde por lo general, los resultados o salidas de un proceso se convierte en las entradas para el siguiente proceso. Existen cuarenta y dos procesos organizados dentro de los grupos mencionados.

Metodología para la Administración de Proyectos Informáticos

17

Con el fin de facilitar su aprendizaje estos procesos están divididos en nueve áreas de conocimiento, las cuales son: Gestión de la Integración del Proyecto Gestión del Alcance del Proyecto Gestión del Tiempo del Proyecto Gestión de los Costes del Proyecto Gestión de la Calidad del Proyecto Gestión de los Recursos Humanos del Proyecto Gestión de las Comunicaciones del Proyecto Gestión de los Riesgos del Proyecto Gestión de las Adquisiciones del Proyecto

2.2.2 Áreas de Conocimiento En la Guía del PMBOK (PMI, 2004) se puede encontrar un detalle de cada unas de las áreas de conocimiento, con sus entradas, herramientas y salidas, sin embargo el siguiente trabajo cubrirá seis de esas áreas.

2.2.2.1 Gestión del Alcance Incluye los procesos requeridos para asegurar que el proyecto posee el trabajo requerido, para completar el proyecto exitosamente. En el alcance se define lo que incluye y no el proyecto. Además se estructura el trabajo para llevarlo después a tareas manejables. En la figura 5 se muestran los procesos de esta área.

Metodología para la Administración de Proyectos Informáticos

18

Figura 5. Procesos de Gestión del alcance La definición de su alcance se convierte en un elemento vital para que el Gerente del Proyecto o los comités respectivos puedan tomar decisiones en las etapas administrativas.

2.2.2.2 Gestión del Tiempo Incluye los procesos relacionados a la conclusión a tiempo del proyecto, es decir desarrollo de las fechas meta de inicio y finalización de los elementos identificados en el alcance, basadas en el esfuerzo requerido para completar las tareas, las relaciones entre ellas y la disponibilidad de los recursos para ejecutarlas. Dentro de esta área se incluyen los procesos indicados en la figura 6.

Metodología para la Administración de Proyectos Informáticos

19

Figura 6. Procesos de Gestión del Tiempo Es importante recordar que no todas las tareas pueden ser realizadas al mismo tiempo, por lo tanto la relación de las tareas con los recursos se convierte en un aspecto determinante.

2.2.2.3 Gestión de los Recursos Humanos Son los procesos necesarios para asegurar que se realiza el uso más efectivo del personal involucrado en el proyecto, asignándoles su rol y responsabilidades. Los procesos incluidos en esta área están especificados en la figura 7.

Figura 7. Procesos de Gestión de los Recursos Humanos

Metodología para la Administración de Proyectos Informáticos

20

Se considera que uno los recursos más difíciles de administrar son las personas, por tanto su gestión debe ser efectiva de acuerdo a su disponibilidad, capacidad, experiencia, interés y costo.

2.2.2.4 Gestión de las Comunicaciones Incluye los procesos para asegurar la generación, distribución, almacenamiento y destino de la información. Se debe determinar que tipo de información enviar, a quien mandarla, cuando o su frecuencia y el formato. Se deben monitorear continuamente las actividades de comunicación para asegurar que el proceso está establecido y es mantenido de manera efectiva. Dentro de está área se incluyen los procesos que se muestran en la figura 8.

Figura 8. Procesos de Gestión de las Comunicaciones Es una de las actividades críticas en un proyecto y fundamental en la administración de los objetivos y los beneficiarios del mismo. Las comunicaciones son la mejor forma de evitar las sorpresas, por tanto debe existir un flujo a todos los niveles del proyecto.

Metodología para la Administración de Proyectos Informáticos

21

2.2.2.5 Gestión de los Riesgos Los procesos relacionados a esta área se encargan de identificar y evaluar de manera sistemática los factores de riesgo de un proyecto y la planeación para mitigar, aceptar o transferir estos factores de riesgo. Identificar los riesgos incrementa y tener un punto de control sobre ellos, aumenta la probabilidad de éxito del proyecto. Los procesos incluidos son los enmarcados en la figura 9.

Figura 9. Procesos de Gestión de los Riesgos

2.2.2.6 Gestión de la integración Son los procesos y actividades para identificar, definir, unificar y coordinar los procesos y actividades de dirección dentro de los grupos de procesos. Con lleva tomar las decisiones acerca de donde y cuando concentrar los recursos. Los procesos que se incluyen en está área se muestran en la figura 10.

Metodología para la Administración de Proyectos Informáticos

22

Figura 10. Procesos de la Gestión de la Integración

2.2.3 Metodología Una metodología es un “conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal” (Real Academia Española, 2007). La metodología, es la parte del proceso que permite estandarizar y ordenar los métodos y técnicas para llevar a cabo la administración de proyectos. Con el fin de hacer más eficiente y eficaz la administración de proyectos, se crean las metodologías, las cuales imponen un proceso disciplinado, detallado y con la opción de reutilizar objetos (documentos, plantillas, etc.). En la Guía del PMBOK una “metodología de dirección de proyectos define un conjunto de Grupos de Procesos de Dirección de Proyectos, sus procesos relacionados, y las funciones de control relacionadas que se consolidan y combinan en un todo funcional y unificado. La metodología de dirección de proyectos puede ser o no una elaboración de una norma de dirección de

Metodología para la Administración de Proyectos Informáticos

23

proyectos. La metodología de dirección de proyectos puede ser un proceso de maduración formal o una técnica informal”. (PMI, 2004)

2.2.4 Sistemas Informáticos Un sistema se definir como un “conjunto de reglas o principios sobre una materia racionalmente enlazados entre sí” (Real Academia Española, 2007), por otro lado la informática es “conjunto de conocimientos científicos y técnicas que hacen posible el tratamiento automático de la información por medio de ordenadores”, con estos dos conceptos podemos definir como sistemas informáticos el conjunto de reglas que permiten realizar el tratamiento de la información. Con los avances tecnológicos, la información se ha convertido en un aspecto determinante para las organizaciones, es el corazón de las mismas. La información es el punto que les permite tomar las decisiones por tanto debe ser clara, concreta, segura y confiable. He ahí la importancia de los sistemas de información automatizados.

2.2.5 Rational Unified Process En el BNCR, el proceso de desarrollo está basado en el RUP “Rational Unified Process”, el cual está fundamentado en el estándar internacional UML. UML se deriva y unifica a partir de tres metodologías de análisis y diseño orientadas a objetos (Fowler y Scout, 1997): Metodología de Graddy Booch, para la descripción de conjuntos de objetos y sus relaciones. Técnica de modelado orientada a objetos de James Rumbaugh.

Metodología para la Administración de Proyectos Informáticos

24

OOSE de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case) El “Rational Unified Process” fue creado por la empresa “Rational”, la cual se “fundó en 1981, con la misión de asegurar el éxito de los clientes que dependen de su habilidad para desarrollar o producir aplicaciones de software. Ayudan a los clientes a resolver los problemas básicos inherentes en el diseño, el desarrollo, las pruebas y la administración de aplicaciones de software y habilitan su creación más rápidamente, con bajo riesgo, más calidad y fiabilidad.” 1 (Rational Software Corporation, 2007). La empresa “Rational” creó sus primeros productos a finales de 1984. En 1994 está empresa se fusiona con “Verdix Corporation” y crean la empresa “Rational Software Corporation”. (Rational Software Corporation, 2007). Desde entonces se han generado herramientas basadas en esta metodología, cuyo objetivo es colaborar en la construcción del software, el cual es como un motor de crecimiento económico mundial y como un diferenciador competitivo para las compañías, servicios y productos. IBM, empresa que se ha caracterizado por ser líder en la industria de hardware quiso expandirse al mercado del software, por tanto, en el 2004 realizó una fusión con la empresa “Rational Software Corporation”. Actualmente realiza la venta de los productos “Rational”. (Rational Software Corporation, 2007).

1

Traducción libre History Rational Software

Metodología para la Administración de Proyectos Informáticos

25

2.2.6 Procesos en el desarrollo de sistemas informáticos La ejecución de un proyecto para un sistema de información automatizado, utilizando la metodología del RUP, hace uso del desarrollo iterativo, el cual consiste en varias iteraciones2 o repeticiones de procesos dentro de cuatro fases (Fowler y Scout, 1997): Conceptualización: en ésta se especifica el alcance del proyecto, estimados de costo y tiempo, comprensión del problema, análisis de riesgos y limitaciones. Además, puede incluir cierto trabajo de análisis para tener una idea de la magnitud del proyecto. Elaboración: conlleva la definición de una arquitectura robusta, la cual pueda ayudar a realizar cambios con facilidad, es decir, se debe comprender mejor el problema, considerando que se debe saber lo que se va a construir, cómo se va a hacer y la tecnología que se empleará. En esta etapa se debe conocer como se administrarán los riesgos identificados. Construcción: concuerda con el desarrollo o programación. Es la confección del sistema a través de las iteraciones. Se realiza el análisis, diseño, codificación, pruebas y termina con una demostración al usuario. Transición: contempla las actividades que se realizan para depurar el producto, con el fin de liberarlo al usuario. Cada iteración está constituida por un ciclo secuencial de actividades, a las cuales se les llamará flujos de procesos. Existen seis flujos de procesos que son: modelación del negocio, requerimientos, análisis y diseño, implementación, pruebas y ejecución. Las iteraciones en las primeras fases, es decir, la fase de concepción y la de elaboración, se enfocan en la administración, requerimientos y actividades de 2

Una iteración es una secuencia de actividades basadas en un plan y criterios de evaluación.

Metodología para la Administración de Proyectos Informáticos

26

análisis y diseño. Por otro lado, las iteraciones correspondientes a la etapa de construcción se enfocan en implementación y pruebas y por último, la fase de transición se centran en pruebas y ejecución. (Ver figura 11)

Figura 11. Proceso de desarrollo iterativo. (Traducido del RUP, 2005)

A continuación se define los propósitos para cada flujo de proceso, según lo establecido por Rational Software Corporation.

2.2.6.1 Modelación del negocio Los propósitos de la modelación del negocio son: Entender la estructura y los procesos de la organización del sistema que será desarrollado.

Metodología para la Administración de Proyectos Informáticos

27

Entender los problemas actuales en la organización e identificar los potenciales de mejora. Asegurar que clientes, usuarios finales y diseñadores tengan una comprensión común de la organización. Derivar los requerimientos del sistema, necesitados para apoyar la organización. Lograr estas metas, describe cómo desarrollar una visión para el sistema, basado en procesos, papeles y responsabilidades de la organización, que se definen en el modelo de casos de uso.

2.2.6.2 Requerimientos Los propósitos de los requerimientos son: Establecer y mantener el acuerdo con los clientes, respecto a lo que el sistema debe hacer. Proporcionar un buen entendimiento de los requerimientos a los diseñadores del sistema. Definir los límites del sistema. Mantener una base, planeando los volúmenes técnicos de iteraciones. Mantener una base estimada de costo y tiempo, para desarrollar el sistema. Lograr estas metas, es importante, en primer lugar para entender la definición y alcance del problema que se está intentando resolver con este sistema. El modelo de casos de uso, debe servir como un medio de comunicación y puede servir como un contrato entre el cliente, los usuarios, y los diseñadores del sistema en la funcionalidad del mismo, que permite que clientes y usuarios puedan validar que el sistema sea lo que ellos esperaron y que los diseñadores del sistema construyan lo que se espera. Es necesario revisar que el documento mantiene una

Metodología para la Administración de Proyectos Informáticos

28

visión completa del sistema del software y que sirve como base contractual de los requerimientos.

2.2.6.3 Análisis y diseño Los propósitos de análisis y diseño son: Transformar los requerimientos en un diseño de lo que puede ser el sistema. Desarrollar una arquitectura robusta para el sistema. Adaptar el diseño y unirlo al ambiente de implementación, diseñado para éste.

2.2.6.4 Implementación Los propósitos de la implementación son: Definir la organización del código. Llevar a cabo clases y objetos, referido a los componentes (fuentes, ejecutables y otros). Probar los componentes desarrollados. Integrar los resultados producidos

2.2.6.5 Pruebas Las pruebas se enfocan principalmente en la evaluación de la calidad del producto, por ello se realizan varias prácticas: Encontrar y documentar los defectos en la calidad del software. Demostrar las características de acuerdo a los requerimientos. Validar que el producto de software funciona según como fue diseñado. Validar que los requerimientos se han llevado a cabo apropiadamente.

Metodología para la Administración de Proyectos Informáticos

29

2.2.6.6 Ejecución Describe las actividades asociadas para asegurar que el producto del software está disponible para los usuarios finales.

2.2.7 La administración de proyectos en sistemas informáticos El desarrollo de productos informáticos ha ido evolucionando junto con las organizaciones, en el sentido que buscan procesos que les permita ser más flexibles y así poder enfrentar el medio ambiente externo, orientado al cliente. Algunos aspectos a considerar son: En los inicios, nos preocupábamos por la evaluación costo – beneficio. Posteriormente se consideraba, verificar que el producto facilitara el cumplimiento de los objetivos de la organización. Posteriormente se ha ido a enfoque donde los productos tecnológicos son un aspecto estratégico para las mismas, ya que con base en la información que se genera se tomarán las decisiones y colabora en la innovación para la atracción de nuevos clientes. Por lo anterior, se hace necesario mantener la información de forma oportuna y veraz. Es ahí donde la administración de proyectos informáticos, debe garantizar que el producto sea eficaz y eficiente, acorde con los objetivos y estrategias, dentro de las limitaciones de recursos y de tiempo que tienen las organizaciones.

Metodología para la Administración de Proyectos Informáticos

30

CAPITULO 3 MARCO METODOLOGICO

Metodología para la Administración de Proyectos Informáticos

3.1

31

Descripción

3.1.1 Tipo de investigación Una vez, que se cuenta con un el diseño o identificación de un problema, se origina una investigación. Para el desarrollo de este documento, se utilizarán dos tipos de investigación: la investigación exploratoria y la investigación descriptiva. La investigación exploratoria se determina cuando el objetivo de la investigación es examinar un tema, utilizando la revisión de la literatura, de esta manera poder decir algo del punto de estudio (Ortiz y García, 2002). Este tipo de investigación se utiliza para conocer el problema en cuestión, con el fin de comprender, indagar, estudiar y definir los aspectos generales y específicos que permiten obtener el conocimiento sobre el problema y el medio ambiente en que se desarrolla. Como complemento se utilizará la investigación descriptiva, la cual permite especificar las características o propiedades más significativas del objeto es estudio (Ortiz y García, 2002). Al utilizar la investigación exploratoria se conoce la situación actual del problema y con la investigación descriptiva se detalla la realidad con las repercusiones que provoca en el ambiente, de manera que permita el establecimiento de soluciones y conclusiones sobre la situación. Los siguientes puntos muestran las ventajas de utilizar estos tipos de investigación: Establecer la definición del problema actual. Determina las características más importantes acerca de la situación actual. Establecer las relaciones del tema de estudio con el ambiente de desarrollo.

Metodología para la Administración de Proyectos Informáticos

32

Permite aportar recomendaciones. Elaborar las conclusiones sobre los resultados encontrados.

3.1.2 Fuentes de información Las fuentes de información son “cualquier objeto, persona, situación o fenómeno cuyas características permiten leer información en él y procesarla como conocimiento acerca de un objeto en estudio” (Gallardo, 2005). A continuación se describen los dos tipos de fuentes de información que se utilizarán para el desarrollo de esta investigación: las fuentes primarias y las fuentes secundarias.

3.1.2.1 Fuentes primarias Las fuentes primarias de información, están compuestas por todas aquellas entidades que son emisoras de la información. Las fuentes primarias a utilizar la constituyen el personal de la Dirección de Análisis de Negocios, quienes brindan información importante debido a su conocimiento sobre el área.

3.1.2.2 Fuentes secundarias Las fuentes secundarias corresponden a todas aquellas publicaciones o escritos donde terceros han plasmado el conocimiento de otras personas (fuentes primarias) o de otras fuentes secundarias. En este caso, cabe destacar que se utilizarán principalmente las siguientes: Libros Documentos personales (apuntes) Estándares del banco Sitios Web

Metodología para la Administración de Proyectos Informáticos

33

Herramientas de software

3.2

Entregables

A continuación se especifican los instrumentos y la forma en que cada uno de los entregables se desarrolló para cumplir los objetivos propuestos.

3.2.1 Análisis del proceso actual 3.2.1.1 Cuestionario Se desarrolló un cuestionario el cual tiene los siguientes objetivos: Identificar el proceso actual y sus debilidades. Determinar el conocimiento del personal. Este cuestionario se distribuyó al personal de la Dirección de Análisis de Negocio, tanto a las jefaturas como a los ejecutivos de tecnología. Cuadro 1. Cuestionarios análisis del proceso actual

Puesto

Cantidad

Director

1

Jefe

2

Ejecutivos

15

TOTAL

18

La información se analizó con la herramienta Microsoft Excel, presentando los datos en forma escrita o por medio de gráficos, con el fin de dar claridad a los resultados obtenidos.

Metodología para la Administración de Proyectos Informáticos

34

3.2.1.2 Entrevistas Se realizaron entrevistas a cuatro ejecutivos de tecnología asignados a la unidad de proyectos de negocio porque es el personal que mayormente documenta el proceso de administración. Las entrevistas se realizaron en forma individual.

3.2.1.3 Revisión de documentación Se exploró la documentación que actualmente tiene la Dirección de Análisis de Negocio, publicado en el sitio de intranet, archivos de proyectos finalizados y en proceso. En el caso de archivos de proyectos se solicitó la documentación de cuatro ejecutivos de uno de los proyectos. Se revisó en cada archivo de proyecto los documentos incluidos y el contenido de cada documento, esto con el fin de levantar un inventario de documentos.

3.2.2 Análisis áreas de conocimiento PMI y los procesos de TI 3.2.2.1 Revisión de documentación La revisión de documentación va en dos ámbitos Áreas de conocimiento del PMI (2004): se revisó el PMBOK tercera edición y otra documentación de Internet para identificar las áreas de conocimiento del PMI definidos en el PMBOK 2004 que se desean desarrollar. Procesos de TI: se examinó en la intranet los estándares que tiene TI para el desarrollo de productos. Aparte se verificó la documentación sobre lo que la institución utiliza del RUP.

Metodología para la Administración de Proyectos Informáticos

35

De ambos procesos se realizó un inventario, fusionado en un comparativo del PMI y TI.

3.2.2.2 Entrevistas Con el fin de identificar procesos que el personal esté realizando y no estén claramente estandarizados se realizaron entrevistas con el personal de TI. Las entrevistas se realizaron a personal de la Dirección de Ingeniería de Servicios de TI y la Dirección de Implantación de Servicios de TI, con el fin de identificar si existen inconsistencias entre ambos.

3.2.3 Flujo de procesos para la administración de proyectos de TI 3.2.3.1 Análisis de la información De los entregables anteriores, se realizó un análisis de la información con el fin de identificar el proceso para la administración de proyectos de TI.

3.2.3.2 Revisión de documentación Se revisó la metodología de administración de proyectos que posee el BNCR, con el fin de identificar las fases que en ella se definen y complementar la metodología que se desarrolle para TI con la metodología del BNCR.

Metodología para la Administración de Proyectos Informáticos

36

3.2.3.3 Diagrama de flujos de procesos Con la herramienta Microsoft Visio, se realizó la diagramación de los procesos identificados, con el fin de brindar una herramienta de consulta rápida que facilite la lectura de los procesos.

3.2.4 Plantillas a utilizar en la administración de proyectos de TI 3.2.4.1 Revisión de documentación Se revisó la documentación que existe actualmente en la institución: Metodología del BNCR para la Administración de Proyectos: revisión de las plantillas que presenta está metodología para identificar cuales de ellas pueden ser reutilizadas. Plantillas de TI: verificación de las plantillas existen a nivel de TI, revisión de cada uno de sus apartados y verificación de su utilidad en el proceso, de acuerdo a su uso, se definió su reutilización. Además se consultó información en Internet y libros, acerca de plantillas que puedan facilitar el proceso de administración de proyectos.

3.2.4.2 Confección de las plantillas Se utilizaron las herramientas Microsoft Word, Microsoft Excel y Microsoft Project, para la creación de las plantillas correspondientes, estas plantillas fueron desarrolladas de acuerdo a la revisión de documentación realizada, y utilizando el conocimiento en administración de proyectos.

Metodología para la Administración de Proyectos Informáticos

37

3.2.5 Metodología propuesta aplicada De los proyectos desarrollados en TI, se seleccionó un proyecto que posea un archivo de documentación, para aplicar la metodología. Este proceso se realizó con el fin de validar que las mismas sean fáciles de utilizar y funcionales.

3.2.6 Plan preliminar de divulgación de la metodología Es importante que ante la creación de una nueva metodología se haga del conocimiento del personal que se vea influenciado por la misma. Por tanto se desarrolló un plan, en el cual se definieron las actividades necesarias para hacer del conocimiento del personal que labora en la Dirección de Análisis de Negocio, la metodología propuesta.

Metodología para la Administración de Proyectos Informáticos

38

CAPITULO 4 DESARROLLO

Metodología para la Administración de Proyectos Informáticos

4.1

39

Análisis de la situación actual

4.1.1 Proceso de la Dirección de Análisis de Negocio La Dirección de Análisis de Negocio de Tecnología de Información (DANTI), lidera los proyectos de negocio relacionados al desarrollo de soluciones de software y los proyectos de infraestructura. Los proyectos relacionados a soluciones de software, deben seguir la metodología para el desarrollo de sistemas de información definidas en el del RUP (Rational Unified Process), utilizando para ello algunas plantillas. Dentro de su proceso de reestructuración la Dirección Corporativa de Tecnología de Información y Comunicaciones (DCTIC) se ha dado a la tarea de identificar los proyectos que tiene en desarrollo y dado lo anterior ha solicitado a la Dirección de Estrategias y Proyectos (DEP) que trabajen en la priorización de los mismos, para proceder con su atención.

Esta inquietud ha sido elevada por la DEP a la

Gerencia General de la institución y en conjunto iniciaron la priorización de proyectos. Por lo anterior, la DEP debe avalar los proyectos a desarrollar, esto en común acuerdo con la DCTIC, aunque esto no significa que todos los proyectos priorizados tengan un director de proyecto que permanezca a la DEP. Con la definición de estas prioridades la DANTI, ha enfocado sus esfuerzos en estos proyectos, sin dejar de lado los proyectos no priorizados pero que ya habían iniciado su ciclo de desarrollo. Todo proyecto que ingrese a DANTI, es analizado y una vez que se cuenten con los insumos correspondientes se procede a informar a las distintas áreas de la

Metodología para la Administración de Proyectos Informáticos

40

DCTIC, para definir el grupo de proyecto que estará participando. Cada uno de los miembros tiene su rol en el proyecto y su participación dependerá de la etapa en la cual se encuentre el desarrollo del producto. La Dirección de Arquitectura de TI velará por definir la arquitectura de software y hardware de la solución, contando con el aval de la Unidad de Seguridad Informática. Una vez que se tenga este modelo la Dirección de Ingeniería de Servicios de TI, procede con el diseño y construcción de la solución. Con la solución construida, el usuario es apoyado por la Dirección de Implantación de Servicios de TI, para realizar las pruebas correspondientes hasta llegar a la aprobación de la solución. Implantación de Servicios coordinará lo correspondiente con la Dirección de Servicios en Producción para llevar dicha solución a un ambiente de producción disponible al usuario. Todos estos procesos son monitoreados y controlados por los ejecutivos de la DANTI.

Metodología para la Administración de Proyectos Informáticos

41

4.1.2 Procesos de TI en la DCTIC En la figura 12 se puede observar el macro proceso que se realiza en la DCTIC para el desarrollo de un proyecto tecnológico, en el cual se detallan los entregables más relevantes de cada fase y la relación entre las distintas direcciones de la DCTIC y el usuario.

Figura 12. Macro proceso de TI

42

Metodología para la Administración de Proyectos Informáticos

A continuación se detallan las fases para el desarrollo de un proyecto tecnológico en la DCTIC y las principales entregas que se desprenden de cada una.

4.1.2.1 Conceptualización La fase de conceptualización tiene como fin entender el producto que se desea implementar Formalización del proyecto. Confección de los documentos: o Aceptación del proyecto o Definición de Riesgos o Plan de desarrollo Priorización de los requerimientos.

4.1.2.2 Elaboración La fase de elaboración toma como premisa el desarrollo de los requerimientos y análisis del producto a desarrollar, por tanto se realizan las tareas: Detalle de los requerimientos. Confección del modelo de arquitectura de hardware y de software para el nuevo producto. Estimaciones de construcción. Confección del documento de diseño de la aplicación.

4.1.2.3 Construcción La fase de construcción está focalizada en la construcción del producto: Construcción

del

producto,

documentación técnica.

pruebas

internas

de

la

aplicación

y

Metodología para la Administración de Proyectos Informáticos

43

Confección del plan de pruebas. Ejecución de las pruebas unitarias.

4.1.2.4 Transición La fase de transición está enfocada a la realización de las pruebas y la puesta en producción: Pruebas integrales. Definición de la lista de materiales. Proceso de puesta en producción de la solución. Confección del manual del usuario. Aceptación final de la aplicación.

4.1.3 Plantillas actuales de TI El ejecutivo de tecnología es la persona encargada de administrar el proyecto a lo interno de la DCTIC, para ayudar en estas tareas se han establecido algunas plantillas y/o documentos, sin embargo el personal indica que en algunos casos son difíciles de confeccionar.

4.1.3.1 Conceptualización Aceptación del proyecto: Su objetivo es servir como contrato entre el negocio y la DCTIC. En forma resumida define las necesidades y características y la importancia para el negocio. El nombre del documento tiende a confundir al negocio, sin embargo se considera necesario validar la visión que entregó el director del proyecto contra lo que el ejecutivo entendió del proyecto.

44

Metodología para la Administración de Proyectos Informáticos

Plan de Proyecto de Desarrollo de Software: este documento tiene como fin especificar el alcance del proyecto, los recursos involucrados y los entregables a través de las diferentes etapas del ciclo de vida de desarrollo. El principal inconveniente es que los ejecutivos no lo utilizan como referencia para el desarrollo del proyecto, sino como un requisito que se debe generar al inicio del proyecto. Esta situación se evidencia al no existir cambios ni controles sobre el mismo. Lista de riesgos: se detallan los riesgos técnicos que presenta el proyecto. El inconveniente es que se ha convertido en una lista de riesgos genéricos sin analizar el entorno del proyecto.

4.1.3.2 Elaboración Especificación de Casos de Uso: documento que detalla los requerimientos que el usuario necesita. Este documento se ha divulgado dentro de la organización y la mayoría de los usuarios que definen necesidades lo conocen. Este documento es validado entre el usuario y el ejecutivo. Especificaciones

suplementarias:

en

los

casos

que

lo

amerite

(especificaciones muy particulares para un producto) el ejecutivo completa los requerimientos no funcionales del producto, tales como: rendimiento, usabilidad, ambiente, compatibilidad con otro software, estándares, soporte, entre otros. Ambos documentos son insumos importantes dentro de la DCTIC, por tanto, se considera indispensable su utilización.

Metodología para la Administración de Proyectos Informáticos

45

4.1.3.3 Transición Aceptación de las pruebas: documento de certificación por parte del usuario,

que deja constancia de las pruebas realizadas, adjuntando el

material de apoyo que demuestre dicha certificación. Es importante que no se considere como un simple documento, sino una aceptación del producto tecnológico que se le está entregando.

4.1.3.4 Administración del proyecto Nombre del entregable Descripción Informe de avance: no se utiliza el documento de la metodología del BNCR, sino se creó un documento en el cual se especifica el avance real y esperado del proyecto, los logros realizados durante el periodo, tareas atrasadas con su justificación, factores críticos de éxito, situaciones por resolver. El documento ha funcionado como herramienta para informar al director sobre el avance del proyecto a nivel de la DCTIC.

4.1.4 Metodología del BNCR En el Banco Nacional existe una metodología para la administración de proyectos, la cual tiene como objetivo definir los estándares de las fases para la Administración de Proyectos dentro del Banco Nacional, la última actualización registrada es el 20 de septiembre del 2002. Consideraciones: La metodología ha llevado al banco a un ordenamiento considerable en la ejecución de sus proyectos, sin embargo esta no ha sido actualizada desde el septiembre 2002 (fecha de última revisión), por tanto, se debe considerar una revisión integral de acuerdo a la experiencia que la organización ha obtenido en los últimos años.

46

Metodología para la Administración de Proyectos Informáticos

La metodología define como debe realizar el proceso, dado que contempla el flujo de las actividades que se realizan en cada fase del proyecto, los procesos

requeridos para

iniciar la fase,

los

responsables

y la

documentación que se debe generar con una guía de cómo completarla. La metodología está desarrollada de acuerdo a cuatros fases: o Formulación de proyectos: se detalla la información requerida para identificar la necesidad mediante “Identificación del proyecto” además de su visión y alcance, lo cual debe tener el visto bueno de la Dirección Corporativa correspondiente de donde se origina la necesidad. o Planificación de proyectos: definición de la planificación del proyecto y las tareas para desarrollar el Plan del Proyecto. o Seguimiento y control: descripción del monitoreo de la ejecución del proyecto y los ajustes que se consideren necesarios para llevar a buen termina la finalización del proyecto. Sin embargo se identifica que es necesario llevar las mediciones para que de forma preventiva y correctiva el proyecto se mantenga dentro del plan definido. o Finalización de proyectos: definición de las tareas a realizar para cerrar el proyecto, esto incluye cierre por finalización o por suspensión.

4.1.4.1 Formulación En esta etapa se desprenden dos plantillas “Identificación del proyecto” y “Visión y alcance” (ver Anexo 5 Plantillas Metodología BNCR): Identificación del proyecto: su fin es definir la necesidad, el impacto dentro de la institución y las oficinas relacionadas. Este documento es completado por la oficina solicitando con el visto bueno de la dirección corporativa a la que pertenece, la cual enviará la identificación a la gerencia para su

Metodología para la Administración de Proyectos Informáticos

47

aprobación o rechazo. De ser aprobado se continua con el desarrollo del documento de visión. Visión y alcance: visión del proyecto, la factibilidad y los recursos necesarios para desarrollarlo. Cabe indicar que estos documentos son desarrollados por el patrocinador o bien por el director de proyecto. Dentro de las debilidades de estas plantillas se encuentran: Generalmente el impacto dentro del banco no es identificado. La factibilidad técnica no es realizada por la DCTIC. Dentro de la identificación de roles y responsabilidades, es identificado únicamente el director, el patrocinador y el usuario. No se considera el rol del dueño del producto, el cual, mantendrá el producto una vez implementado. Los perfiles deberían contener los días y horas disponibles de un usuario dentro del proyecto.

4.1.4.2 Planificación El entregable de esta etapa es el Plan de Proyecto, dentro de las actividades y secciones que debe contener el documento: Revisar los documentos de identificación, visión y alcance: dentro de la metodología indica que estos documentos deben estar en constante revisión y actualización, en especial cuando se aprueba un cambio. Definición de la organización: establecer la organización del equipo del proyecto. Revisión de objetivos. Identificar todos los involucrados

Metodología para la Administración de Proyectos Informáticos

48

Definiciones de planes subsidiarios Definir cronograma Revisión de costos Definir responsables de tareas Plan de comunicaciones Definir riesgos Definir plan de adquisiciones Este documento es generado por el director del proyecto. Se identifican como debilidades: Este plan no es entregado a la Dirección de Análisis de Negocio. La metodología no está actualizada con el esquema de DCTIC, por ejemplo hace referencia a la Dirección de Desarrollo de Sistemas, la cual no existe desde inicios del año 2007. Para su confección en el caso de proyectos informáticos debe existir una participación la Dirección de Análisis de Negocio representando la DCTIC.

4.1.4.3 Seguimiento y control Las plantillas definidas en esta etapa dentro de la metodología son: Minuta: tal como se puede observar en el Anexo 5, esta plantilla contiene los elementos necesarios para dejar evidencia de los temas tratados y responsabilidades asignadas, por tanto se utilizará para las minutas de reunión. Informe de avance: en forma resumida esta plantilla debe contener (Ver Anexo 5) o Lista de tareas concluidas en el periodo reportado o Lista de tareas en proceso al momento del informe (responsable y % avance)

Metodología para la Administración de Proyectos Informáticos

49

o Lista de tareas retrasadas y sus justificaciones o Lista de tareas eliminadas o suspendidas y su justificación o Lista de tareas a iniciar en el próximo periodo o Detalle de situaciones presentadas Este documento debería generarse tanto de forma semanal como mensual, donde de forma semanal se lleve un detalle y el informe mensual muestre la situación del proyecto de forma más resumida. Actualmente para los proyectos institucionales, el director debe presentar este informe mensualmente a la Dirección de Estrategia y Proyectos

4.1.4.4 Finalización Los documentos utilizados son: Informe de cancelación: o Logros alcanzados o Problemas enfrentados o Justificación de la cancelación Carta de aprobación del proyecto: el dueño final del producto confecciona una carta dirigida al comité ejecutivo del proyecto o al director, indicando que da por aceptada la finalización del proyecto porque se cumplieron los objetivos planteados. Formulario de las lecciones aprendidas: o Situación presentada o Acción administrativa realizada Las lecciones aprendidas no deben considerarse como un requisito para la finalización del proyecto sino debe ser un insumo que se genere cada vez que suceda un imprevisto o un logro dentro del proyecto.

50

Metodología para la Administración de Proyectos Informáticos

4.1.5 Comparación de PMI y procesos de desarrollo Cuadro 2. Documentos utilizados en DCTIC

Administración Proyectos Sistemas '

Inicialización

1. Identificación del Recepción Proyecto 2. Visión y alcance 1. Aceptación del Conceptualización proyecto

Elaboración

Construcción

Transición Cierre

Planificación

Ejecución

Seguimiento y Control

Cierre

1.Plan del proyecto 2. Lista de Riesgos 1. Modelo de casos de uso 2. Especificación suplementaria 3. Casos de uso 4. Documento de arquitectura 5. Documento de diseño 1. Plan de pruebas 1. Casos de uso funcionales 1. Casos de prueba

1. Minutas 2. Informes de avance

1. Minutas 2. Informes de avance 1. Minutas 2. Informes de avance 1.Nota de cierre

Metodología para la Administración de Proyectos Informáticos

51

4.1.6 Resultados del cuestionario y entrevistas Dentro de los principales problemas a los que se enfrenta la Dirección de Análisis de Negocio se encuentran: Asignación de recursos sin experiencia Calidad de los entregables Falta de definición clara de los alcances del proyecto Falta de estandarización Falta de madurez en el tema Falta de toma de decisiones de los recursos asignados Falta definición de responsabilidad de cada miembro Falta definición del perfil del ejecutivo de TI Falta priorización de proyectos Personal responde al jefe de línea, no al proyecto Personal sobre cargado Poca disponibilidad de los recursos Poca o nula experiencia de los directores asignados Poca Planificación Recursos no se comprometen con el proyecto Usuarios sin claridad En el Anexo 5, se encuentran los rubros que representan el ochenta por ciento de los problemas de acuerdo a las entrevistas realizadas. Dentro de esos problemas se encuentran la falta de metodología, la poca planificación y la falta de definición de responsabilidades de los miembros del equipo, lo cual se considera dentro del desarrollo de la metodología para estandarizar los proyectos de tecnología. Para identificar debilidades en el proceso actual y la experiencia del personal que la labora en la DANTI, se procedió con la ejecución de un cuestionario.

Metodología para la Administración de Proyectos Informáticos

52

Los resultados a nivel gráfico se pueden observar en el Anexo 6, sin embargo a continuación se detallan algunos de los hallazgos: El cuestionario fue aplicado a ejecutivos y jefes de la DANTI Todos indican conocer la Metodología de Proyectos definida en el BNCR Todos indican haber recibido capacitación en Administración de Proyectos

53

Metodología para la Administración de Proyectos Informáticos

4.2

Metodología propuesta

4.2.1 Procesos para proyectos de TI 4.2.1.1 Recepción del proyecto Los pasos a seguir para la recepción de un proyecto son los siguientes (ver figura 13): El Director de Proyectos de la DEP o del área de negocio correspondiente, envía al jefe de la Unidad de Proyectos de Negocio de la Dirección Análisis de Negocio de Tecnología de Información (DANTI), los documentos: o Identificación del Proyecto (AP-01-2002): Plantilla que contiene la siguiente información: Número y nombre del proyecto, descripción de la situación actual, tipo de necesidad a resolver, justificación, solución propuesta, objetivos generales y su unidad de medida, objetivo institucional relacionado, impacto (oficinas, servicios o sistemas

y

documentos

relacionados),

estimación

preliminar

(presupuesto y recurso humano), dirección o unidad organizativa solicitante, nombre y firma del director corporativo al que pertenece el solicitante. o Visión y alcance (AP-02-2002): Plantilla en la cual se entrega la siguiente información: número y nombre del proyecto, visión, alcances, requerimientos a nivel macro, factibilidad (técnica, operacional, económica), VAN y TIR, factores críticos de éxito, recursos (técnicos, financieros, administrativos, humanos, otros), nombre,

dedicación

administrador

del

semanal producto,

y

localización

director

del

para

los

proyecto,

roles: equipo

desarrollador, equipo capacitador, equipo de pruebas y equipo de logística, perfil de los usuarios, análisis preliminar de riesgos,

Metodología para la Administración de Proyectos Informáticos

54

consideraciones, cronograma preliminar y nombre y firma de los responsables de elaborar la justificación. o Solicitud a TI: documento donde el Director del Proyecto solicita al jefe de la Unidad de Proyectos de Negocio de la DANTI, un recurso que se encargue de llevar el proyecto a nivel de la DCTIC.

Figura 13. Proceso de recepción de un proyecto

Metodología para la Administración de Proyectos Informáticos

55

El jefe de la Unidad de Proyectos de Negocio de la DANTI, revisa los documentos y verifica que el proyecto tenga el visto bueno de la DEP. Si estos documentos están completos solicita la lista de insumos “DANTI-04”. El director de proyectos completa la lista de insumos. Con los documentos completos el jefe de DANTI genera el acta de inicio “DANTI-05” y lo envía al director y al ejecutivo para que los procesan con la firma del recibido. Con esto el ejecutivo de tecnología, inicia las conversaciones con el director del proyecto.

4.2.1.2 Conceptualización del proyecto El proceso de conceptualización tiene como objetivo entender las necesidades planteadas del proyecto y realizar su planificación (ver figura 14): Si no existe sitio de documentación para el proyecto, el ejecutivo de tecnología lo crea y publica la información recibida del proyecto. El ejecutivo de tecnología revisa la documentación. El ejecutivo de tecnología realiza una sesión con el director del proyecto y en ciertos casos con los usuarios expertos, con el fin de revisar la visión del proyecto. Posteriormente el ejecutivo de tecnología confecciona el documento de “Visión técnica”, la cual debe ser aprobada por el director del proyecto. El ejecutivo de tecnología convoca al usuario experto (puede participar el director del proyecto) para analizar el entorno del proyecto a nivel del negocio, lo cual servirá para realizar la “Modelación del Negocio”. Una vez aprobado el modelo del negocio, el ejecutivo de tecnología procede con la confección del plan de proyecto a nivel de tecnología, la confección de un plan preliminar, la matriz de comunicaciones del proyecto y una lista de riesgos.

Metodología para la Administración de Proyectos Informáticos

56

Figura 14. Proceso de conceptualización de un proyecto

Los documentos anteriores son enviados a las jefaturas de TI con el fin de que lo revisen, den su aprobación y posteriormente asignen el personal. Las jefaturas remiten la lista de personas que colaboran en el proyecto al ejecutivo de tecnología. Con esta lista el ejecutivo procede a la consolidación de recursos del proyecto. El ejecutivo confecciona el documento “Glosario” con los términos manejados hasta el momento. El ejecutivo documenta las lecciones aprendidas del proceso, pero cabe destacar que estas lecciones pueden ser documentadas en el momento que suceda un incidente o un logro importante durante el proceso.

Metodología para la Administración de Proyectos Informáticos

57

4.2.1.3 Elaboración del proyecto Una vez que se tiene la conceptualización general del proyecto a nivel de tecnología, se procede con la definición más detallada del proyecto (ver figura 15): Con las necesidades que se recopilaron en el documento de “Visión técnica” el ejecutivo de tecnología procede con la confección del Modelo de Casos de Uso. Posteriormente este modelo es revisado con los usuarios, con el fin de identificar si se dejó alguna necesidad por fuera y se procede a priorizar las mismas. El usuario detalla en el caso que no lo haya hecho, los casos de uso a nivel funcional e identifica que necesidades que no sean funcionales requiere del producto. Con esas necesidades no funcionales y otras especificaciones, el ejecutivo de tecnología inicia con la preparación del documento de “Especificaciones suplementarias”. Una vez que se cuenten con ambos documentos, los mismos son revisados y depurados hasta que se llegue a un consenso entre ambas partes. Este proceso puede considerar varias sesiones. El ejecutivo actualiza el glosario con los términos derivados en los documentos anteriores, Con los documentos aprobados, el ejecutivo de tecnología procede a realizar una presentación a la Dirección de Arquitectura, Dirección de Ingeniería, Dirección de Servicios en Producción y a la Dirección de Implantación. El arquitecto asignado de la Dirección de Arquitectura inicia la confección del “Modelo de Arquitectura de software y de hardware de la aplicación”. Este modelo con los casos de uso es remitido al ingeniero de la Dirección

Metodología para la Administración de Proyectos Informáticos

58

de Ingeniería para que proceda con el análisis y estimaciones a nivel de construcción. El arquitecto y el ingeniero remiten los riesgos que identifican para proceder con su incorporación y control. Con las estimaciones presentadas para la construcción del producto, el ejecutivo de tecnología procede con la actualización del plan.

Figura 15. Proceso de Elaboración

4.2.1.4 Construcción Una vez finalizada la fase de elaboración, inicia la construcción del producto de software, de hardware o ambos (en los casos que aplique).

Metodología para la Administración de Proyectos Informáticos

59

El ejecutivo de tecnología debe velar por el cumplimiento de cada una de las tareas calendarizadas, para lo cual estará solicitando informe de avances de cada tarea. Realizará un informe semanal del avance del proyecto. Cada mes, el ejecutivo realizará la confección del informe mensual, el cual le servirá como insumo al director del proyecto para actualizar el avance general. El equipo de trabajo de tecnología informará en los momentos que proceda la identificación de riesgos o la actualización de los existentes. El ejecutivo actualizará las lecciones aprendidas durante el proceso.

4.2.1.5 Transición Antes que el desarrollo finalice el ejecutivo de tecnología coordinará con la Dirección de Implantación de Sistemas reunirse con el usuario para la confección de los escenarios de pruebas, preparar los ambientes de pruebas, coordinar con el usuario las pruebas del producto y finalmente liberar el producto a un ambiente de producción. El ejecutivo de tecnología dará el seguimiento correspondiente, y será el llamado a buscar la solución de los imprevistos que se puedan suscitar durante el proceso. En este proceso, el ejecutivo realizará la confección del informe semanal y el mensual el cual le servirá como insumo al director del proyecto para actualizar el avance general. El equipo de trabajo de tecnología informará en los momentos que proceda la identificación de riesgos o la actualización de los existentes. El ejecutivo actualizará las lecciones aprendidas durante el proceso

Metodología para la Administración de Proyectos Informáticos

60

4.2.1.6 Cierre Una vez que el producto se encuentra implementado (ver figura 16): El usuario confecciona la nota de aceptación del producto. El ejecutivo de tecnología realiza una presentación al equipo de trabajo y sus jefaturas. El ejecutivo procede con la confección de una nota de cierre del proyecto y la envía a las jefaturas de los recursos que participaron del proyecto, dando por liberados a los mismos. Además se lo remitirá al director del proyecto para informar sobre el cierre formal por parte de la DCTIC. Es importante que el ejecutivo de tecnología recapitule con el equipo del proyecto los sucesos que no hayan sido documentados y documentarlos en las lecciones aprendidas.

Figura 16. Proceso de cierre de un proyecto de Negocio

4.2.2 Diagramación de los procesos En las figuras 17, 18, 19, 20, 21, 22, 23, 24, 25 y 26 se muestran los diagramas de los procesos con el fin de tener una guía de consulta rápida.

Metodología para la Administración de Proyectos Informáticos

Figura 17. Diagrama proceso de recepción

61

Metodología para la Administración de Proyectos Informáticos

Figura 18. Diagrama del proceso de Conceptualización

62

Metodología para la Administración de Proyectos Informáticos

Figura 19. Continuación Diagrama del proceso de Conceptualización

63

Metodología para la Administración de Proyectos Informáticos

Figura 20. Continuación Diagrama del proceso de Conceptualización

64

Metodología para la Administración de Proyectos Informáticos

Figura 21. Diagrama del proceso de Elaboración

65

Metodología para la Administración de Proyectos Informáticos

Figura 22. Continuación Diagrama del proceso de Elaboración

66

Metodología para la Administración de Proyectos Informáticos

Figura 23. Diagrama del Proceso de Construcción y Transición

67

Metodología para la Administración de Proyectos Informáticos

Figura 24. Continuación Diagrama del Proceso de Construcción y Transición

68

Metodología para la Administración de Proyectos Informáticos

Figura 25. Diagrama de cierre

69

Metodología para la Administración de Proyectos Informáticos

Figura 26. Diagrama de control de cambios

70

Metodología para la Administración de Proyectos Informáticos

71

4.2.3 Plantillas para administración de proyectos de TI En el siguiente cuadro se presenta un resumen de las herramientas a utilizar y su función dentro del proceso: Código: Identificación única para el documento. o AP: Administración de Proyectos, código de los documentos de la Metodología de Administración de Proyectos del BNCR. o DANTI: código de los documentos Dirección de Análisis de Negocio de TI. Nombre del documento: Nombre del documento. Funcionalidad: explicación de la función principal del documento Acción: se especifica “recibir” cuando es recibido de otras unidades organizativas y “generar” si debe ser desarrollado o generado dentro de la Dirección de Análisis de Negocio Categoría: Identifica si los documentos deben ser desarrollados para los de largo o corto plazo. o Proyectos de corto plazo. Los proyectos catalogados como corto plazo se especifican los proyectos menores a seis meses. o Proyectos de largo plazo. Los proyectos de largo plazo son los proyectos de seis meses o más. Dado que existen proyectos que por su naturaleza son de corta duración, no se hace necesario la generación de todos los documentos. Tipo: Especifica si es para proyectos de Negocio o para proyectos de Infraestructura.

72

Metodología para la Administración de Proyectos Informáticos Cuadro 3. Herramientas y su funcionalidad

Código AP-01-2002

Nombre Identificación Proyecto

Funcionalidad

Acción

del Generado por el solicitante de la necesidad Recibir

Categoría

Tipo

Corto,

Negocio,

Largo

Infraestructura

Generado por el director, presenta una visión Recibir

Corto,

Negocio,

inicial del proyecto y el alcance definido.

Largo

Infraestructura

Corto,

Negocio,

Largo

Infraestructura

Corto,

Negocio

donde se define la idea del proyecto para su aprobación.

AP-02-2002

AP-03-2002

Visión y alcance

Minutas

Formulario

para

documentar

acuerdos

y Generar

pendientes de las reuniones. DANTI-01

DANTI-02

Casos de uso

Documento

de

especificación

de

los Generar

requerimientos funcionales del sistema.

Largo

Especificación

Documento de especificación de requerimientos Generar

Largo

Negocio

suplementaria

no

Largo

Negocio

Aspectos que deben ser presentados por el Recibir,

Corto,

Negocio,

director del proyecto, para la DCTIC son de suma Generar

Largo

Infraestructura

Aprueba el proyecto dentro de la DCTIC y asigna Generar

Corto,

Negocio,

un ejecutivo.

Largo

Infraestructura

funcionales

(rendimiento,

tiempos

de

respuesta, presentación) del sistema. DANTI-03

Modelo de casos de uso Diagrama de los requerimientos funcionales del Generar producto.

DANTI-04

Lista de insumos

importancia. DANTI-05

Acta de inicio

73

Metodología para la Administración de Proyectos Informáticos Código DANTI-06

Nombre

Funcionalidad

Visión técnica

Acción

Guía para identificar la visión desde el punto de Generar

Categoría Largo

vista técnico de la solución. DANTI-07

Modelación del negocio

Plan del proyecto

Guía para modelar las funcionalidades desde la Generar

Largo

Guía para el desarrollo del plan de proyecto, Generar

Cronograma

Negocio, Infraestructura

Largo

formato y aspectos mínimos a considerar. DANTI-09

Negocio, Infraestructura

perspectiva del negocio. DANTI-08

Tipo

Negocio, Infraestructura

Archivo para el control de tareas, duraciones y Generar

Corto,

Negocio,

responsables, se debe mantener en el Project

Largo

Infraestructura

Formulario con los recursos que participaran de Generar

Corto,

Negocio,

las distintas dependencias, la disponibilidad y en

Largo

Infraestructura

Largo

Negocio,

Central Server. DANTI-10

Recursos del proyecto

la etapa en que participaran. DANTI-11

Matriz

de Matriz donde se detallen los entregables e Generar

comunicaciones

informes, con su responsable, a quién lo debe

Infraestructura

enviar y el medio. DANTI-12

DANTI-13

Lista de Riesgos

Informes

de

semanal DANTI-14

Informes mensual

Plantilla para listar, detallar, clasificar los riesgos Generar

Corto,

Negocio,

del proyecto.

Largo

Infraestructura

Largo

Negocio,

avance Plantilla

para

la

preparación

de

informes Generar

semanales. de

avance Plantilla

para

Infraestructura la

preparación

mensuales (consolidado).

de

informes Generar

Corto,

Negocio,

Largo

Infraestructura

74

Metodología para la Administración de Proyectos Informáticos

Código DANTI-15

DANTI-16

DANTI-17

DANTI-18

Nombre

Funcionalidad

Aceptación del producto

Nota de cierre

Recepción

Acción

Categoría

Tipo

Acta donde el cliente da por aceptado el producto Generar

Corto,

Negocio,

y con ello el cierre del proyecto.

Largo

Infraestructura

Acta con el resumen del resultado del proyecto y Generar

Corto,

Negocio,

la liberación de los recursos.

Largo

Infraestructura

Corto,

Negocio,

de Formulario para la recepción de los entregables Generar

entregables

del proyecto.

Largo

Infraestructura

Control de cambios

Formulario para documentar las solicitudes de Generar

Corto,

Negocio,

cambio, quedando evidencia de su aprobación o

Largo

Infraestructura

Largo

Negocio,

rechazo y el impacto en el proyecto. DANTI-19

Glosario

Formulario con los términos propios del negocio Generar o técnicos que deben ser del conocimiento del

Infraestructura

equipo del proyecto. DANTI-20

Lecciones aprendidas

Plantilla

para

documentar

aprendidas durante el proyecto

las

lecciones Generar

Corto,

Negocio,

Largo

Infraestructura

Metodología para la Administración de Proyectos Informáticos

75

En el siguiente cuadro se presentan los documentos que se deberán utilizar los ejecutivos de tecnología durante el desarrollo del proyecto. Cuadro 4. Documentos y/o plantillas a utilizar en proyectos de TI por fases

Administración Proyectos Sistemas '

Recepción

Conceptualización

Elaboración

Inicialización 1. Identificación del Proyecto 2. Visión y alcance 3. Lista de insumos 4. Acta de inicio 1. Visión técnica 2. Modelación del negocio

Planificación

Ejecución

1. Plan del proyecto 2. Cronograma 3. Matriz de comunicación 4. Lista de Riesgos 5. Lista de Recursos 6. Glosario 7. Lecciones aprendidas

1. Lista de Riesgos 2. Glosario 3. Lecciones aprendidas 4. Recepción de entregables

1. Modelo de casos de uso 2. Especificación suplementaria 3. Casos de uso 4. Lista de Riesgos

Seguimiento y Control

1. Minutas 2. Informes de avance semanal 3. Informes de avance mensual

Cierre

Metodología para la Administración de Proyectos Informáticos

Construcción

Transición

Cierre

76 5. Glosario 6. Lecciones aprendidas 7. Recepción de entregables 1. Lista de Riesgos 2. Glosario 3. Lecciones aprendidas 4. Recepción de entregables 1. Lista de Riesgos 2. Glosario 3. Lecciones aprendidas 4. Recepción de entregables 1. Lecciones aprendidas 4. Recepción de entregables

1. Minutas 2. Informes de avance semanal 3. Informes de avance mensual 1. Minutas 2. Informes de avance semanal 3. Informes de avance mensual 1. Minutas 2. Informes de avance semanal 3. Informes de avance mensual

1. Aceptación del producto 2. Nota de cierre

Metodología para la Administración de Proyectos Informáticos

77

Los siguientes son los documentos y/o plantillas implementadas con sus respectivas guías. La letra indicada con “cursiva” representa la información que debe ser completada (es la guía de la información requerida).

4.2.3.1 DANTI-01: Casos de uso Objetivo: Detallar los documentos funcionales del producto. Descripción: Este documento especifica los requerimientos paso a paso, tal como lo requiere el usuario. Sirve como lenguaje único entre el área de negocio y el área técnica. La plantilla a utilizar es la especificada en el “Anexo 9 Plantillas de TI” en la parte de “Especificación caso de uso”, de igual forma utilizar el formato definido en el “Anexo 8 Formato de los documentos” Responsable: Usuario, Ejecutivo de Tecnología. Fase del proyecto a utilizar: Elaboración del proyecto

4.2.3.2 DANTI-02: Especificación suplementaria Objetivo: Detallar los requerimientos no funcionales del producto. Descripción: Este documento especifica las necesidades que el usuario requiere del producto pero que no son funcionales, sino en aspectos de forma, rendimiento, etc. La plantilla a utilizar es la especificada en el “Anexo 9 Plantillas de TI” en la parte de “Especificaciones suplementarias”, de igual forma utilizar el formato definido en el “Anexo 8 Formato de los documentos” Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Elaboración del proyecto

Metodología para la Administración de Proyectos Informáticos

78

4.2.3.3 DANTI-03: Modelo de casos de uso Objetivo: Documentar el modelo de casos de uso. Descripción: Este documento se realiza anterior a la confección de casos de uso, con el fin de verificar que todas las necesidades funcionales y los afectados estén identificados. Utilizar el formato definido en el “Anexo 8 Formato de los documentos”. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Elaboración del proyecto Cuadro 5. DANTI-03 Modelo caso de uso

1

Definición de actores

[Detallar los actores involucrados con las necesidades funcionales, para cada actor se debe detallar.] [Nombre del actor] Nombre del actor Descripción del actor [Descripción del actor] Casos de uso [Mencionar los casos de uso relacionados al actor] relacionados 2

Definición de casos de uso

[Definir los casos de uso identificados, para cada uno detallar] [Nombre del caso de uso] Nombre del caso de uso Descripción del caso de uso [Descripción del caso de uso] [Identificar los actores que interactúan con Actores relacionados el caso de uso] [Identificar los casos de uso relacionados Casos de uso relacionados al caso de uso en mención] 3

Modelo de casos de uso

[Insertar el diagrama del modelo de casos de uso donde se identifican las relaciones entre los casos de uso - actores y casos de uso – casos de uso]

Metodología para la Administración de Proyectos Informáticos

79

4.2.3.4 DANTI-04: Lista de insumos Objetivo: Recolectar información que debe ser del conocimiento de la DCTIC para iniciar el proyecto. Descripción: Esta plantilla contiene la solicitud de información que la DCTIC requiere, para iniciar el proyecto y no se encuentra dentro de los documentos de Identificación y Visión del proyecto. Esta información siempre es solicitada al director de una u otra forma, por tanto se establece como requisito. Responsable: Director del Proyecto. Fase del proyecto a utilizar: Recepción del proyecto. Cuadro 6. DANTI-04 Lista de Insumos

DANTI – 04 Lista de Insumos Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Información general del proyecto Fecha: [Indicar la fecha de confección] Identificación Proyecto: [Identificación del Proyecto]

Nombre del Proyecto: [Nombre del proyecto] Nombre del Director de Proyecto: Nombre del Ejecutivo de Tecnología: [Nombre del director del proyecto] [Nombre del Ejecutivo asignado] Detalle del proyecto

Metodología para la Administración de Proyectos Informáticos

80

Definición del Grupo de trabajo [Para los siguientes roles Indicar el nombre de la persona y la dependencia a la que pertenece] Rol Patrocinador del Proyecto Director del Proyecto Dueño del Producto Ingeniero de Procesos

Nombre

Dependencia

[En el caso de los usuarios indicar el nombre de la persona que participará en cada una de las siguientes tareas. Indicar el nombre de la persona, la dependencia a la que pertenece y la dedicación de horas por semana] Etapa Nombre Dependencia Horas/semana Modelo de Negocio Casos de Uso Revisión del Prototipo Casos de Prueba Aplicación de Pruebas Criterios de aceptación [Listar los criterios que el Negocio utilizará para dar por aceptado el producto tecnológico] Presupuesto asignado para el producto tecnológico [Indicar el presupuesto asignado para el desarrollo, adquisición o modificación del producto tecnológico] Insumos del producto tecnológico Sistemas relacionados [Listar los sistemas identificados que tendrán relación con el nuevo producto tecnológico] Cantidad clientes [Estimar la cantidad de clientes o usuarios que utilizarán el producto, en el primer, tercer y quinto año] 1º Año 3º Año 5º Año Cantidad de transacciones [Estimar la cantidad de transacciones, procesos y/o reportes que esperan ejecutar por periodo] Diario Mensual Transacciones Procesos Reportes

Metodología para la Administración de Proyectos Informáticos

81

Disponibilidad de información histórica [Indicar el tiempo mínimo que se requiere almacenar la información histórica] Días pico del producto [Indicar los días que se espera mayor utilización del producto] Horario del servicio [Indicar el horario en que el producto es utilizado por los usuarios o clientes] Días Horas Disponibilidad del servicio [Indicar el horario en que el producto debe estar disponible para realizar todos sus procesos] Días Horas Tiempo de recuperación [Indicar la cantidad máxima de tiempo que el producto puede estar fuera ante una falla inesperada, considerado la criticidad del servicio]

4.2.3.5 DANTI-05: Acta de inicio Objetivo: Dar inicio al proyecto desde la perspectiva de la DCTIC y formalizar el ejecutivo asignado. Descripción: Plantilla donde se establece la fecha real en la cual la DCTIC iniciará sus labores, esto después de haber recibido los requisitos establecidos. Responsable: Jefe de DANTI. Fase del proyecto a utilizar: Recepción del proyecto. Cuadro 7. DANTI-05 Acta de Inicio

DANTI – 05 Acta de Inicio Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio DANTI-[Consecutivo]-[Año] Información general del proyecto Fecha: [Indicar la fecha del acta] Identificación Proyecto: [Identificación del Proyecto]

Nombre del Proyecto: [Nombre del proyecto]

82

Metodología para la Administración de Proyectos Informáticos

Fecha de inicio: Fecha de finalización: [fecha de inicio del proyecto] [fecha de finalización del proyecto] Nombre del Director de Proyecto: Nombre del Ejecutivo de Tecnología: [Nombre del director del proyecto] [Nombre del Ejecutivo asignado] Detalle del proyecto Objetivo General [Indicar el objetivo general del proyecto] Presupuesto asignado para el producto tecnológico [Monto presupuestado para adquisiciones de tecnología] Documentos recibidos Documento

Fecha de recepción

AP-01-2002: Identificación del Proyecto

[Fecha de aprobado] AP-02-2002: Visión y alcance [Fecha de aprobado] Solicitud de ejecutivo de tecnología [Fecha de aprobado] DANTI-04: Lista de insumos [Fecha de aprobado] Aprobaciones Nombre [Nombre del Jefe] Jefe, Análisis de Negocio TI [Nombre del director] Director de Proyecto [Nombre del ejecutivo] Dirección Análisis de Negocio TI

recepción

del

documento

recepción

del

documento

recepción

del

documento

recepción

del

documento

Firma

Fecha

4.2.3.6 DANTI-06: Visión técnica Objetivo: Servir de contrato entre la DCTIC y el área de Negocio. Descripción: Este documento sirve para documentar el entendimiento que el ejecutivo de tecnología está teniendo del proyecto a desarrollar. Debe utilizar el formato indicado en el “Anexo 8 Formato de los documentos”. Para este documento se detallan cinco sesiones. Responsable: Ejecutivo de Tecnología.

Metodología para la Administración de Proyectos Informáticos

83

Fase del proyecto a utilizar: Conceptualización del proyecto. Cuadro 8. DANTI-06 Visión técnica

1 1.1

Posicionamiento Oportunidad de Negocio

[Describir la oportunidad de negocio que se persigue con este proyecto.] 1.2

Definición del Problema

[Proveer una evaluación resumen del problema que esta siendo resuelto por este proyecto] [describir el problema] El problema de [el solicitante afectado por el problema] Afecta [cuál es el impacto del problema] El impacto es Una solución exitosa [listar algunos beneficios claves de una solución exitosa] es [cliente interno/externo al cual está Para orientado] 2

Descripciones de los Afectados y Usuarios

[Para proporcionar con eficacia productos y servicios que resuelvan las necesidades de los clientes, es necesario identificar e involucrar a los usuarios y afectados.] 2.1

Resumen de Afectados

[Presentar una lista resumen de todos los afectados identificados, estos pueden ser unidades, departamentos, direcciones, entidades externas, sistemas, etc.] Nombre Relación con el proyecto [Nombre el tipo de afectado] [Describa brevemente la relación que el afectado tendrá con el desarrollo del proyecto] 2.2

Resumen del Usuario

[Presentar una lista resumen de todos los usuarios identificados.]

Metodología para la Administración de Proyectos Informáticos

2.3

Nombre

Descripción

[Nombre el tipo de usuario]

[Describa brevemente lo que ellos representan con respecto al sistema.]

84

Principales Necesidades de Afectados o Usuarios

[Listar los principales problemas y sus soluciones, esto contestando las siguientes preguntas para cada problema percibido: ¿Cuál es el problema? ¿Cómo se resuelve actualmente? ¿Cuáles soluciones desea el afectado o usuario? 3

Descripción del Producto

[Esta sección proporciona una opinión de alto nivel de las capacidades del producto, de los interfaces con otras aplicaciones, y de las configuraciones de sistemas] 3.1

Visión del Producto

[Indicar la visión que se tiene del producto en relación con otros productos existentes y el ambiente del usuario. Cabe indicar si el producto va a ser independiente, si es parte de un sistema ya existente o bien si está relacionado con otros sistemas, es importante mencionar las posibles interconexiones e interfaces externa. La forma más fácil de entenderlo es con un diagrama.] 3.2

Suposiciones y dependencias

[Listar cada uno de los factores que afectan las características del proyecto y que pueden alterar la visión] 4

Criterios de aceptación

[Listar cuáles se consideran como criterios para que el proyecto sea cerrado con la aceptación del usuario] 5

Estándares relevantes

[Detallar los estándares que deberán ser utilizados dentro del desarrollo del producto]

Metodología para la Administración de Proyectos Informáticos

85

4.2.3.7 DANTI-07: Modelación del negocio Objetivo: Entender el posicionamiento del producto por desarrollar. Descripción: En este documento se describe el producto y la posición que tiene a nivel del negocio, no se detalla el producto a nivel tecnológico sino el entorno dentro de la organización del banco, esta enfocado en entender el producto desde la perspectiva de procesos del negocio. Utilizar el formato indicado en el “Anexo 8 Formato de los documentos”, aparte de las cinco secciones que se detallan. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Conceptualización del proyecto Cuadro 9. DANTI-07 Modelación del negocio

1

Descripción del Producto

[Describir brevemente el producto a ser desarrollado, con el propósito de darle al lector un contexto general. Incluir el nombre del sistema y las siglas con que se conocerá. Explicar qué problema resuelve y por qué tiene sentido el esfuerzo de desarrollarlo.] 2

Contexto de Negocio

[Definir el contexto de negocio del producto. ¿Quiénes son los usuarios? Indicar si el producto está siendo desarrollado para cumplir una normativa o es un producto comercial, además de indicar a que programa u objetivo estratégico responde] 3

Objetivos del Producto

[Indicar los objetivos que se persiguen con el desarrollo de este producto – las razones por las que tiene sentido de negocio. Definir los objetivos en forma clara y expresa] 4

Modelo de procesos del negocio

[Modelar los proceso del negocio en torno a las tareas que se ven afectadas con el producto a implementar, no ha nivel del producto sino a nivel operativo, esto incluye áreas funcionales, sistemas, entidades externas]

Metodología para la Administración de Proyectos Informáticos

5

86

Visualización del producto

[Ilustrar a nivel general como el usuario visualiza el producto, de ser necesario ilustrar pantallas de cómo el usuario percibe el nuevo producto.]

4.2.3.8 DANTI-08: Plan del proyecto Objetivo: Proveer una guía sobre los objetivos, alcance y la forma en que se implementará una solución tecnológica. Descripción: En este documento se detalla la planificación del proyecto en cuanto a alcance, tiempo, costo, recursos humanos, comunicaciones y riesgos. Utilizar el formato indicado en el “Anexo 8 Formato de los documentos”, a continuación se detallan las secciones que debe contener como mínimo. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Conceptualización del proyecto Cuadro 10. DANTI-08 Plan del proyecto

1 Generalidades del proyecto [Brindar una descripción resumida del proyecto, indicando la forma en que el producto que se genere durante el proyecto operará dentro de la organización.] 2 2.1

Plan de Gestión del Proyecto Alcance del Proyecto

2.1.1 Visión [Describir brevemente la visión del proyecto] 2.1.2 Objetivos 2.1.2.1 Objetivo General [Brindar una descripción clara del objetivo u objetivos generales del proyecto] 2.1.2.2 Objetivos Específicos [Describir claramente los objetivos específicos del proyecto]

87

Metodología para la Administración de Proyectos Informáticos

2.1.3 Beneficios esperados [Escribir los principales beneficios que la organización obtendrá con el desarrollo del proyecto] 2.1.4 Declaración del Alcance 2.1.4.1 Entregas [Incluir el EDT o WBS (Estructura Detallada de Trabajo) mediante la cual se detallen las macro tareas para lograr los objetivos del proyecto] 2.1.4.2 Supuestos [Especificar los supuestos que se dan como ciertos para la ejecución del proyecto] 2.1.4.3 Exclusiones [Especificar claramente aquellos aspectos que no forman parte del alcance del proyecto] 2.1.5 Criterios de Aceptación [Identificar cuales serán los criterios que se usarán para dar por aceptado el producto] 2.1.6 Ciclo de vida del proyecto [Incluir un detalle de las fases que desarrollaran durante el proyecto]

Conceptualización

Nombre del proyecto Elaboración

Construcción

Transición

Cierre

Mes 1

Mes 2

Mes 3

Mes 4

Mes 5

Mes 6

Mes 7

Mes n

2.2 Actividades y costos del proyecto [Brindar detalles en cuanto a la planificación de los tiempos y costos del proyecto y

88

Metodología para la Administración de Proyectos Informáticos

en que momento se realizará cada actividad, así como los mecanismos mediante los cuales se planifica llevar el control del mismo. Para ello se deberán explicar las principales entregas del proyecto a través de un WBS, cronograma de actividades, así como la ruta crítica del proyecto.] 2.2.1 Definición de las actividades [Detallar los principales entregables del proyecto, brindando una pequeña explicación del mismo, indicando las tareas que se realizarán para lograr el entregable] Entrega Descripción Tareas [Nombre del [Descripción del [Tareas para entregable] entregable] realizarlo] 2.2.2 Desarrollo del cronograma [Detallar el cronograma de actividades del proyecto, considerando la secuencia de las mismas, responsables, participantes, fechas estimadas de inicio y fin de cada actividad. Se recomienda desarrollarlo con la herramienta Microsoft Project] 2.2.3 Ruta Crítica del Proyecto [Brindar la ruta crítica del proyecto, mediante la cual se definen todas aquellas actividades en las cuales, cualquier retraso ocasionarán un atraso en la fecha de finalización del proyecto y que por consiguiente se debe mantener un control constante] 2.2.4 Curva “S” del trabajo acumulado [Elaborar una curva “S” del trabajo acumulado del proyecto, mediante la cual se brindará el seguimiento respectivo una vez el proyecto se encuentre en ejecución.] Trabajo acumulado 1400 1200

Horas

1000 800 Trabajo 600 400 200 0 Mes 1

Mes 2

Mes 3

Mes 4 Meses

Mes 5

Mes 6

Mes 7

Metodología para la Administración de Proyectos Informáticos

89

2.2.5 Presupuesto de actividades [Detallar el presupuesto del proyecto a partir de la definición de las actividades con su calendarización y su costo estimado desde el inicio hasta la finalización del proyecto.] Costo estimado [Identificac [Nombre de [Comienzo de [Fin de la [Costo ión de la la tarea] la tarea tarea estimado] tarea] establecido en establecido el en el cronograma] cronograma] Id

2.3

Nombre

Comienzo

Fin

Organización del proyecto

2.3.1 Diagrama funcional del Proyecto [Especificar la estructura funcional de los recursos, para ello desarrollar un organigrama con las relaciones funcionales de cada miembro del equipo de trabajo] 2.3.2 Roles necesarios [Especificar claramente los recursos requeridos, especificando el rol que cumplirá uno y sus funciones.] Rol [Rol en el proyecto]

Funciones [Especificar a nivel general las funciones del recurso]

2.3.3 Matriz de Responsabilidades [Se deben especificar quien es el responsable de cada una de las actividades identificadas en el proyecto] La nomenclatura utilizada en la tabla es la siguiente: Símbolo


Significado Responsable de toda la macro actividad, debe asegurarse de que todas las actividades se vayan ejecutando y que los recursos involucrados estén realizando su labor. Es un miembro del equipo que desarrollará labores específicas para alcanzar el objetivo de la macro actividad

90

Metodología para la Administración de Proyectos Informáticos

Miembro n

Miembro 4

Miembro 3

Tareas

Miembro 2

WBS 1.1 1.1.1 1.1.1.1 1.1.1.2 1.1.1.n 1.1.n 1.1.n.1 1.1.n.2 1.1.n.m

Miembro 1

Ejemplo:

Entrega 1 Actividad 1 Tarea 1 Tarea 2 Tarea n Actividad n Tarea 1 Tarea 2 Tarea n

2.3.4 Matriz de comunicación [Definir los principales insumos del proyecto que deben ser informados a los miembros del equipo o a otros miembros de la organización, se puede incorporar los elementos que se consideren necesarios. Para ello se debe especificar la frecuencia con la que se debe generar el documento, el responsable, la forma de realizar la distribución. Utilizar la plantilla DANTI-11] 2.3.5 Reuniones de seguimiento [Se debe especificar la frecuencia de las reuniones de seguimiento, quién realizará las convocatorias, metodología de la reunión, es decir, agenda, mecanismo de convocatoria, etc.] 2.3.6 Informe de Avance [Se debe especificar la forma en que serán generados los reportes de avance del proyecto, especificando la frecuencia, responsable de su ejecución, destinatarios, y contenido. Utilizar plantillas DANTI-13 y DANTI-14.] 2.3.7 Control de Cambios [Detallar la forma en que serán administrados los cambios durante la ejecución del proyecto, especificando el procedimiento desde su solicitud hasta la autorización o rechazo de los mismos. Para su control utilizar el formulario DANTI-18.]

91

Metodología para la Administración de Proyectos Informáticos

2.3.8 Aprobación de Entregables [Especificar la forma en que serán aprobadas las entregas del proyecto, utilizando la plantilla DANTI-17. También se debe indicar el procedimiento a seguir en caso de que alguna entrega no sea aprobada.] 2.3.9 Lecciones aprendidas [Especificar la forma en que serán documentadas las lecciones aprendidas que se produzcan durante la ejecución del proyecto, utilizando la plantilla DANTI-20] 2.4

Riesgos

[La definición de Riesgos se realiza de acuerdo a lo establecido en la Metodología de Administración de Proyectos del BNCR.] 2.4.1 Definición del impacto Impacto Definición de Categoría Critico Un evento, que si ocurre, causaría fallas en el proyecto (inhabilita el alcance de los requerimientos mínimos aceptables). Serio Un evento, que si ocurre, causaría incrementos severos en el costo y el tiempo. Requerimientos secundarios pueden no ser alcanzados. Moderado Un evento, que si ocurre, causaría incrementos moderados en el costo y el tiempo, pero los requerimientos importantes pueden aún lograrse. Menor Un evento, que si ocurre, causaría incrementos bajos en el costo y el tiempo. Los requerimientos pueden ser alcanzados. Despreciable Un evento, que si ocurre, no tendría efecto en el proyecto. 2.4.2 Categorías de Riesgos Impacto / Probabilidad

Despreciable

Menor

Moderado

Serio

Crítico

00-10% 11-40% 41-60% 61-90% 91-100%

Bajo Bajo Bajo Medio Medio

Bajo Bajo Medio Medio Alto

Bajo Medio Medio Medio Alto

Medio Medio Medio Medio Alto

Medio Alto Alto Alto Alto

2.4.3 Identificación de Riesgos [Especificar los riesgos asociados al proyecto para tal efecto se debe realizar una identificación de riesgos priorizados. La identificación de los riesgos debe contener

Metodología para la Administración de Proyectos Informáticos

92

al menos la siguiente información] ID Riesgo Probabilidad Impacto [ID del [Descripción [Probabilidad [Impacto, riesgo] del riesgo] de ocurrencia tabla 1] de 1 a 100%]

Categoría [Acuerdo a la probabilidad y al impacto, tabla 2]

2.4.4 Estrategias de respuesta Las estrategias a utilizar son: Código Descripción de la Estrategia Eliminar Eliminación del riesgo. Transferir Transferencia del riesgo (traslado de la responsabilidad a terceras partes). Mitigar Mitigación del riesgo. Aceptar Aceptación del riesgo. Debe utilizarse para los riesgos de categoría Baja. 2.4.5 Planificación de la respuesta a riesgos [Una vez que los riesgos han sido identificados y priorizados, desarrollar procedimientos y acciones para mejorar las oportunidades y minimizar las amenazas a los objetivos del proyecto. Se debe incluir recursos y actividades en el presupuesto, cronograma y plan de gestión del proyecto.] Riesgo

Estra-

Acción

Contin-

tegia

[ID del [Estra[Acción riesgo] tegia a a utilizar] realizar]

2.5

Presupuesto

gencia

[Medida [Presupuesto de contin- requerido gencia] para desarrollar la estrategia, en tiempo y costo]

Respon-

Disparador

sable

{Persona responsa ble de su administr ación}

{Evento que indica si el riesgo se va a materializar o ya se materializó}

Adquisiciones del proyecto

2.5.1 Matriz de Adquisiciones [Detallar todas las adquisiciones que se estiman para llevar a cabo el proyecto. Se debe indicar quien es el responsable de la gestión de las adquisiciones, quien autoriza el presupuesto, quien realiza las aprobaciones y quien da trámite a los pagos correspondientes.]

Metodología para la Administración de Proyectos Informáticos

Nombre de Contratación

Descripción de la contratación

Costo Estimado

[Identificador [Descripción [Costo para la de la estimado] contratación] contratación ]

93

Fecha límite Posibles Responsa contratación Proveedores ble

[Fecha máxima para realizar la contratación ]

[Lista de proveedores preseleccion ados]

[Responsa ble de realizar la contrataci ón]

4.2.3.9 DANTI-09: Cronograma Objetivo: Guiar en la construcción del cronograma. Descripción: Esta plantilla constituye las tareas de un proyecto de desarrollo de un producto. Los tiempos son estimados los cuales serán variados de acuerdo a los requerimientos. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Conceptualización del proyecto

Metodología para la Administración de Proyectos Informáticos

Cuadro 11. DANTI-09 Cronograma Id

Nombre de tarea

0

DANTI-09 Cronograma Base

1

Fas e de Conce ptualizació n

Dur ación

27 d ías?

Creación de sitio

30 mins?

3

Publicación de documentos

30 mins?

4

Vis ión Té cnica

5 d ías?

Rev isar documentación

6

Creación DANTI-06

7

Rev isión

8

Apr obación

Nombres de los recurs os

129,5 dí as?

2

5

Predeces oras

Ejec utivo de Tec nología 2

Ejec utivo de Tec nología

1 día?

3

3 días?

5

Ejec utivo de Tec nología;Direc tor del Proyecto;Usuario Ejec utivo de Tec nología

1 día?

6

Director del Proy ecto

0 días?

7

Director del Proy ecto

9

Mo delación de l Neg ocio

10

Analizar entorno

1 día?

6

Ejec utivo de Tec nología;Usuario

11

Creación DANTI-07

3 días?

10

Ejec utivo de Tec nología

12

Rev isión

2 días?

11

Usuario

13

Apr obación

0 días?

12

Usuario

14

Plan de Proyecto

6 d ías?

13,13 días?

15

Creación del DA NTI-08

5 días?

13

Ejec utivo de Tec nología

16

Confeccc ionar DANTI- 09 Cronograma preliminar

1 día?

15

Ejec utivo de Tec nología

17

Confeccionar DA NTI-11 Matr iz de Comunicación

1 hora?

16

Ejec utivo de Tec nología

18

Confeccc ionar DANTI- 12 Lis ta de Riesgos

2 días?

17

Ejec utivo de Tec nología

19

Rev isión

5 días?

18

Jefes TI

20

Apr obación

0 días?

19

Jefes TI

21

Lis ta de Recur sos

3 días?

20

Jefes TI

2 horas?

22

Ejec utivo de Tec nología

18

Ejec utivo de Tec nología

23

Ejec utivo de Tec nología

22

Def inir rec ursos para el proy ecto

23

Confeccionar DA NTI-10

24 25 26 27 28 29

Glo sario Inicial Confección DANTI-19 Leccione s apr endid as Confección DANTI-20 Fas e de Elabor ación Mo delar casos de u so

3,25 días ?

0,5 días? 0,5 días? 0,5 días? 0,5 días? 35 d ías? 4 d ías?

30

Analizar Necesidades

0,5 días?

20

Ejec utivo de Tec nología

31

Creación del diagrama

0,5 días?

30

Ejec utivo de Tec nología

32

Confeccionar DA NTI-03

1 día?

31

Ejec utivo de Tec nología

33

Rev isión

2 días?

32

Usuario

34

Apr obación

0 días?

33

Usuario

35

Det allar n eces idade s

36

Priorizar r equerimientos

37

DANTI -01 Confección de casos de uso

38

19 d ías? 1 día?

34

Usuario;Ejecutiv o de Tecnología

10 días?

36

Usuario

Rev isión

5 días?

37

Ejec utivo de Tec nología

39

Apr obación

0 días?

38

Usuario

40

Detallar necesidades no func ionales

2 días?

36

Usuario

41

DANTI-02 Espec ificaciones s uplementarias

2 días?

40

Ejec utivo de Tec nología

42

Confección de presentación a TI

1 día?

41;39

Ejec utivo de Tec nología

43

Presentac ión

1 día?

42

Ejec utivo de Tec nología

44

Entega de documentac ión

1 día?

43

Ejec utivo de Tec nología

35

Ejec utivo de Tec nología

45

Actualizar DANTI-19 Glosario

1 hora?

46

Arq uitectura

7 d ías?

47

Analisis de las necesidades

2 días?

44

Arquitecto

48

Doc umento de A rquitectura

5 días?

47

Arquitecto

49

Entr ega del documento de Ar quitec tura

0 días?

48

Arquitecto

3 días?

46;44

Ingeniero

50

Realizar estimac iones

51

Actualizac ión del cronograma

1 día?

50

Ejec utivo de Tec nología

52

Entr ega de tiempos para el director

1 día?

51

Ejec utivo de Tec nología

94

Metodología para la Administración de Proyectos Informáticos

Id 53

Nombre de tarea

Dur ación

Rie sgos

Predeces oras

Nombres de los recurs os

4 d ías?

54

Analizar posibles riesgos

2 días?

49

Arquitecto;Ingeniero

55

Entr egar r iesgos identificados

1 día?

54

Arquitecto;Ingeniero

56

Actualizar DANTI-12 Lista de Riesgos

1 día?

55

Ejec utivo de Tec nología

56

Ejec utivo de Tec nología

57 58 59 60

Leccione s apr endid as Confección DANTI-20 Fas e de Const rucción Análisis y dise ño

0,25 días ? 2 horas? 39,25 días? 8 d ías?

61

Analizar el producto

3 días?

55

Ingeniero

62

Confeccionar documento de Anális is y Diseño

5 días?

61

Ingeniero

63

Entr egar documento de Análisis y Diseño

0 días?

62

Ingeniero

20 días?

63

Ingeniero

3 días?

66

Ingeniero

20 días?

63

Ingeniero

3 días?

69

Ingeniero

20 días?

63

Ingeniero

3 días?

72

Ingeniero

64 65

Des arrollo de la solución I Ite ració n

66

Des arrollo

67

Pruebas internas

68

II It eració n

69

Des arrollo

70

Pruebas internas

71

III It eración

72

Des arrollo

73

Pruebas internas

31 d ías? 23 d ías?

23 d ías?

23 d ías?

74

Confeccionar lis ta de materiales

3 días?

65;68;71

Ingeniero

75

Entr egar lista de mater iales

0 días?

74

Ingeniero

76

Manual Técnico

5 días

75

Ingeniero

77

Leccione s apr endid as

64

Ejec utivo de Tec nología

78 79 80

95

Confección DANTI-20 Fas e de Trans ición Planificación d e las prueb as

81

Plan de Pr uebas

82

Cas os de prueba

83 84

0,25 días ? 2 horas? 76,25 días? 15 d ías? 5 días?

63

Implantador

10 días?

63

Usuario

Rev isión

5 días?

82

Implantador

Apr obación

0 días?

83

Usuario

5 días?

49

Implantador

85

Preparar ambientes de pruebas

86

Pru ebas de us uario

15 d ías?

87

Ejec utar pruebas I Iteración

5 días?

65;85

Usuario

88

Ejec utar pruebas II Iter ación

5 días?

68;85

Usuario

89

Ejec utar pruebas III Iter ación

5 días?

71;85

Usuario

90

Pruebas Integrales

10 días?

87;88;89

Usuario

5 días?

90

Usuario

3 días?

91

Usuario;Ejecutiv o de Tecnología

1 día?

93

Director del Proy ecto

5 días?

94

Usuario;Implantador;Ejecutivo de Tecnología

91

Manual de Usuario

92

Cap acitación

93

Elaboración Plan de Capacitación

94

Apr obación del Plan de Capacitación

95

Realizar Capacitación

96

Pas e a Producción

9 d ías?

27 d ías?

97

Planificar pase

5 días?

90

Implantador;Ejec utivo de Tec nología

98

Realizar pase a producción

5 días?

97

Implantador

99

Elaboración Plan Piloto

3 días?

90

Director del Proy ecto

100

Ejec utar Plan Piloto

15 días?

99;98

Usuario

101

Reporte de resultados Plan Piloto

2 días?

100

Usuario

102

Apr obación Plan Piloto

0 días?

101

Usuario

96

Ejec utivo de Tec nología

103 104

Leccione s apr endid as Confección DANTI-20

0,25 días ? 2 horas?

96

Metodología para la Administración de Proyectos Informáticos

Id 105

Nombre de tarea

Dur ación

Cie rre de l Pro yecto TI

106

Predeces oras

Nombres de los recurs os

17,13 días?

Ace ptación

0,13 días ?

107

DANTI-15 Nota de aceptación

1 hora?

102

Usuario

108

Entr ega de Nota

0 días?

107

Usuario

109

Pre sentación del pr oduct o

110

Preparar Presentación

1 día?

98

Ejec utivo de Tec nología

111

Presentac ión

1 día?

110

Ejec utivo de Tec nología

1 día?

111

Ejec utivo de Tec nología

2 días?

113

Jefes TI

114

Ejec utivo de Tec nología

112

Not a de cierre

3 d ías?

113

Confeccionar DA NTI-16

114

Apr obación del Cierre

115 116

4.2.3.10

2 d ías?

Leccione s apr endid as Confección DANTI-20

1 d ía? 1 día?

DANTI-10: Recursos del proyecto

Objetivo: Documentar los recursos humanos que participaran del proyecto. Descripción: Esta tabla contiene el detalle de los recursos que participaran del proyecto y sus datos. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Conceptualización del proyecto Cuadro 12. DANTI-10 Recursos del proyecto

DANTI – 10 Recursos del proyecto Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Nombre Dependencia

Rol

Correo Teléfono Fase electrónico [Nombre [Dependencia [Rol [Correo [Teléfono] [Fases del del a la cual dentro electrónico] proyecto recurso] pertenece] del en las que proyecto] participará]

Fecha estimada [Fecha estimada de inicio y finalización en que participará en el proyecto]

Horas/ semana [Cantidad de horas disponibles por semana para participar en el proyecto]

97

Metodología para la Administración de Proyectos Informáticos

4.2.3.11

DANTI-11: Matriz de comunicaciones

Objetivo: Mantener informados a los involucrados. Descripción: Esta plantilla identifica los principales documentos y plantillas, sus receptores y distribuidores, la periodicidad y el medio de distribución. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Conceptualización del proyecto

Involucrado [Nombre involucrado]

*

Sem.

Plan del Proyecto

Solicitudes de cambio

Minutas de reuniones internas Minutas de reuniones con proveedores

Rol en el Sem. Men. Sem. Proyecto del [Rol dentro del proyecto]

Término Sem. Men.

4.2.3.12

Informe Mensual

DANTI – 11 Matriz de Comunicación

Informe Semanal

Cuadro 13. DANTI-11 Matriz de comunicaciones

Otro. Otro

Significado Semanal Mensual Impreso Correo Electrónico Responsable

DANTI-12: Lista de Riesgos

Objetivo: Documentar los riesgos asociados al proyecto Descripción: Esta tabla es un resumen de los riesgos identificados durante el proyecto. Utilizar la definición de riesgos se realiza de acuerdo a lo establecido en la Metodología de Administración de Proyectos del BNCR.]

Metodología para la Administración de Proyectos Informáticos

98

Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Conceptualización del proyecto Cuadro 14. DANTI-12 Lista de Riesgos

DANTI – 12 Lista de Riesgos Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio ID Riesgo Probabilidad Impacto [ID del [Descripción [Probabilidad [Impacto, riesgo] del riesgo] de ocurrencia tabla 1] de 1 a 100%]

Categoría [Acuerdo a la probabilidad y al impacto, tabla 2]

Acción [Indicar si se mitiga, se elimina o se acepta]

Actividad [Actividad que se realizará para enfrentarlo]

Estado [Estado del riesgo: Activo o Inactivo]

Tabla 1. Definición de Impacto Impacto Critico Serio Moderado Menor Despreciable

Definición de Categoría Un evento, que si ocurre, causaría fallas en el proyecto (inhabilita el alcance de los requerimientos mínimos aceptables). Un evento, que si ocurre, causaría incrementos severos en el costo y el tiempo. Requerimientos secundarios pueden no ser alcanzados. Un evento, que si ocurre, causaría incrementos moderados en el costo y el tiempo, pero los requerimientos importantes pueden aún lograrse. Un evento, que si ocurre, causaría incrementos bajos en el costo y el tiempo. Los requerimientos pueden ser alcanzados. Un evento, que si ocurre, no tendría efecto en el proyecto.

Tabla 2. Definición de la categoría Impacto / Despreciable Probabilidad 00-10% Bajo 11-40% Bajo 41-60% Bajo 61-90% Medio 91-100% Medio

Menor

Moderado

Serio

Crítico

Bajo Bajo Medio Medio Alto

Bajo Medio Medio Medio Alto

Medio Medio Medio Medio Alto

Medio Alto Alto Alto Alto

Metodología para la Administración de Proyectos Informáticos

4.2.3.13

99

DANTI-13: Informes de avance semanal

Objetivo: Funcionar como herramienta de control semanal. Descripción: Esta plantilla contiene los elementos mínimos que se deben formular en la confección de un informe semanal. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Todas las fases. Cuadro 15. DANTI-13 Informe semanal

DANTI – 13 Informe semanal Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Información general Fecha: [Indicar la fecha de confección] Identificación Proyecto: Nombre del Proyecto: [Identificación del Proyecto] [Nombre del proyecto] Periodo que comprende: [Fecha inicio y fin que comprende el informe Responsable: [Nombre del Ejecutivo] Detalle del Informe Tareas del periodo [Identificar las tareas que se encuentran dentro del periodo] Tareas del periodo Inicio Final Progreso Real [Nombre de la tarea] [Fecha [Fecha [% de [% de inicio] final] avance] Esper ado]

Diferencia [Diferencia progreso y real]

Metodología para la Administración de Proyectos Informáticos

100

Amenazas [Identificar las actividades que son necesarias resolver para no provocar impactos en el proyecto] Amenazas [Actividad identificada]

Fecha [Fecha máxima a ejecutar]

Responsable [Responsable realizar actividad ]

Impacto Estatus de [Impacto [Estado de la para el la actividad] proyecto]

Prioridades para la próxima semana: [Identificar tareas prioritarias que se deben ejecutar la próxima semana.]

4.2.3.14

DANTI-14: Informes de avance mensual

Objetivo: Llevar el control mensual del avance del proyecto. Descripción: Esta plantilla especifica los elementos mínimos que debe contener un informe mensual. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Todas las fases. Cuadro 16. DANTI-14 Informe mensual

DANTI – 14 Informe mensual Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Información general Fecha: [Indicar la fecha de confección] Identificación Proyecto: Nombre del Proyecto: [Identificación del Proyecto] [Nombre del proyecto] Periodo que comprende: [Fecha inicio y fin que comprende el informe Responsable: [Nombre del Ejecutivo] Detalle del Informe

Metodología para la Administración de Proyectos Informáticos

101

Estado actual del proyecto: [Realizar una breve explicación del estado y un gráfico de curva S del trabajo con el avance real y el esperado acorde al cronograma.] Logros del proyecto: [Enumerar las actividades finalizadas durante el periodo] Atrasos sufridos: [Identificar las tareas que se encuentran atrasadas, con su porcentaje de avance real y la justificación del atraso.] Tareas del periodo % Avance Justificación [Nombre de la tarea] [% avance real] [Justificación del atraso]

Acciones correctivas: [Acciones realizadas durante el periodo para la buena marcha del proyecto] Metas para el próximo periodo: [Identificar las metas (no necesariamente actividades) que se realizaran en el próximo mes] 4.2.3.15

DANTI-15: Aceptación del producto

Objetivo: Documentar la aceptación del usuario Descripción: Esta carta especifica la aceptación del producto implementado por parte del usuario. Con esta carta se puede cerrar el proyecto. Responsable: Dueño del producto. Fase del proyecto a utilizar: Cierre del proyecto. Cuadro 17. DANTI-15 Aceptación del producto

Fecha: Fecha de la carta Señor: Nombre del Ejecutivo de tecnología Proyecto “Nombre del proyecto” Estimado señor: Por medio de la presente doy por aceptado el producto “Nombre del producto”, resultado del Proyecto denominado “Nombre del Proyecto“, dado que

Metodología para la Administración de Proyectos Informáticos

102

el mismo cumple con las necesidades planteadas. Al mismo tiempo hago constar, que se ha cumplido con los entregables planificados, realizando las pruebas correspondientes. Sin más por el momento, se despide atentamente, Nombre del Administrador del Producto o Servicio Dependencia a la cual pertenece

4.2.3.16

DANTI-16: Nota de cierre

Objetivo: Documentar el cierre del proyecto. Descripción: Esta plantilla constituye el acta de cierre del proyecto, mostrando un resumen del mismo, con esta acta se liberan los recursos asignados. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Cierre del proyecto Cuadro 18. DANTI-16 Nota de cierre

DANTI – 16 Nota de cierre Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio DANTI-[Consecutivo]-[Año] Información general Fecha: [Indicar la fecha de confección] Identificación Proyecto: [Identificación del Proyecto]

Nombre del Proyecto: [Nombre del proyecto] Fecha de inicio: Fecha de finalización: [Fecha de inicio real del proyecto] [Fecha de finalización del proyecto] Nombre del Director de Proyecto: Nombre del Ejecutivo de Tecnología: [Nombre del director del proyecto] [Nombre del Ejecutivo] Detalle de la nota

Metodología para la Administración de Proyectos Informáticos

103

Dueño del producto: [Indicar el nombre y al dependencia del dueño del producto implementado] Nombre del producto implementado: [Si se trata de un nuevo producto especificar el nombre o siglas con que se conocerá.] Descripción: [Descripción detallada del producto implementado] Objetivos alcanzados: [Detallar los objetivos alcanzados con el desarrollo del proyecto] Equipo de trabajo: [Especificar el nombre y la dependencia de las personas de la DCTIC que laboraron en el proyecto] Nombre Dependencia

Observaciones [Indicar cualquier observación que se considere dejar en evidencia] Responsables Entregado por Fecha y hora [Nombre y firma del ejecutivo de [Fecha y hora de la entrega] tecnología] Aprobado por Fecha y hora [Nombre y firma del director del [Fecha y hora de la aprobación] proyecto] Receptores Receptores Fecha y hora [Nombre y firma de de los receptores [Fecha y hora de la recepción] de la nota] 4.2.3.17

DANTI-17: Recepción de entregables

Objetivo: Documentar la recepción de entregables. Descripción: Esta plantilla sirve como registro para la recepción de los entregables desarrollados durante el proyecto. Responsable: Miembros del Equipo. Fase del proyecto a utilizar: Todas las fases del proyecto.

Metodología para la Administración de Proyectos Informáticos

104

Cuadro 19. DANTI-17 Recepción de entregables

DANTI – 17 Recepción de entregables Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Información general Fecha: [Indicar la fecha de confección] Identificación Proyecto: Nombre del Proyecto: [Número del Proyecto] [Nombre del proyecto] Información del entregable Responsable: [Nombre de la persona que responsable del entregable] Nombre: [Nombre del entregable] Descripción: [Descripción general del entregable] Tarea asociada: [Tarea asociada según cronograma] Resolución Resolución [Marcar con una “X” la solución seleccionada] Aceptado Rechazado Justificación [En el caso que el entregable es rechazado, indicar las razones por las cuales se realiza el rechazo y los ajustes requeridos para que el entregable sea aceptado.] Responsables Entregado por Fecha y hora [Nombre y firma de la persona que [Fecha y hora de la entrega] realiza la entrega] Recibido por Fecha y hora [Nombre y firma del receptor del [Fecha y hora de la resolución del entregable] entregable]

Metodología para la Administración de Proyectos Informáticos

4.2.3.18

105

DANTI-18: Control de cambios

Objetivo: Documentar la solicitud de cambio y su impacto. Descripción: Esta plantilla contiene los insumos generales del proyecto, la solicitud del cambio, su impacto y una vez valorado se documenta su aceptación o rechazo. Responsable: Miembros del equipo. Fase del proyecto a utilizar: Todas las fases. Cuadro 20. DANTI-18 Control de Cambios

DANTI – 18 Control de Cambios Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Información general Fecha: Número de Cambio: [Indicar la fecha de confección] [Consecutivo de cambio para el proyecto] Identificación Proyecto: Nombre del Proyecto: [Identificación del Proyecto] [Nombre del proyecto] Solicitante: Rol del solicitante: [Nombre de la persona que gestiona el [Rol de la persona dentro del proyecto cambio] que gestiona el cambio] Cambio propuesto Descripción del cambio: [Descripción detallada del cambio propuesto] Impacto de no realizar el cambio: [Justificación de la solicitud de cambio] Registro del impacto Responsable del análisis Fecha: [Nombre de la persona que realiza el [Fecha de realización del análisis] análisis] Impacto Técnico: Impacto en Presupuesto: [Indicar el impacto a nivel técnico que [Indicar el impacto en presupuesto de provoca el cambio] realizar el cambio propuesto] Impacto en Cronograma: Impacto en otros Proyectos: [Indicar si el cambio provoca [Indicar si el cambio impacta a otros modificaciones al cronograma proyectos] propuesto]

Metodología para la Administración de Proyectos Informáticos

106

Resolución Resolución [Marcar con una “X” la solución seleccionada] Aceptado Rechazado Justificación [Indicar las razones por las cuales procede el cambio] Responsables Implementar cambio Fecha y hora [Nombre y firma del ejecutivo de [Fecha y hora de la firma de la resolución] tecnología] Autorizar cambio Fecha y hora [Nombre y firma del director de [Fecha y hora de la firma de la resolución] proyecto] 4.2.3.19

DANTI-19: Glosario

Objetivo: Documentar términos o abreviaturas del proyecto. Descripción: En este documento se definen términos y abreviaturas que se utilizan desde el inicio hasta la finalización del proyecto. Estos conceptos pueden ser de índole técnico o del negocio. Utilizar el formato definido en el “Anexo 8 Formato de los documentos”. Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Todas las fases. Cuadro 21. DANTI-19 Glosario

1

Abreviaturas

[Especificar las abreviaturas utilizadas, indicar la abreviatura y su significado Abreviatura1 Abreviatura n] 2

Términos

[Especificar los términos o conceptos utilizados, indicar el concepto y su descripción Término 1 Término n]

Metodología para la Administración de Proyectos Informáticos

4.2.3.20

107

DANTI-20: Lecciones Aprendidas

Objetivo: Documentar aciertos y desaciertos ocurridos durante el proyecto Descripción: En esta plantilla se deben documentar los problemas y aciertos ocurridos en el proyecto con el fin de lograr un mejor desempeño en un próximo suceso. Responsable: Equipo de Proyecto. Fase del proyecto a utilizar: Todas las fases. Cuadro 22. DANTI-20 Lecciones aprendidas

DANTI – 20 Lecciones aprendidas Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Información general del proyecto Fecha: [Indicar la fecha de confección] Identificación Proyecto: Nombre del Proyecto: [Identificación del Proyecto] [Nombre del proyecto] Información de la lección Fase del proyecto: [Fase en la que se presenta la situación] Situación presentada: [Descripción de la situación presentada] Consecuencias: [Enumerar las consecuencias de la situación] Resolución de la situación: [Detallar la solución que se dio a la situación] Documentado por [Nombre de la persona que documentó la lección aprendida]

Metodología para la Administración de Proyectos Informáticos

4.2.3.21

108

AP-03-2002 Minuta

Objetivo: Documentar los puntos tratados, los acuerdos y los asistentes a la reunión. Descripción: Esta plantilla contiene los aspectos para documentar una reunión, en donde también se establecen los acuerdos, sus responsables y la fecha límite de realización. Esta plantilla es firmada por todos los asistentes a la reunión. La plantilla a utilizar es la de la Metodología de Administración de proyectos del BNCR, la cual se encuentra en el anexo 7 “Plantillas de la Metodología del BNCR” Responsable: Ejecutivo de Tecnología. Fase del proyecto a utilizar: Todas las fases (siempre que haya una reunión).

Metodología para la Administración de Proyectos Informáticos

4.3

109

Validación de la metodología

4.3.1 Proyecto seleccionado La aplicación de la metodología se realizó para la etapa de conceptualización para el proyecto “Aplicación de la Normativa Prudencial de la SUGEF” cuyas siglas es ANPS. El proyecto tiene como fin la creación de una nueva aplicación para la consolidación de la información crediticia que debe enviar el Banco Nacional a la Superintendencia General de Entidades Financieras (SUGEF), acorde con las normativas de crédito vigentes.

4.3.2 Plantillas aplicadas La aplicación de la metodología se hace con el fin de verificar que las plantillas y/o documentos propuestos, sean de fácil utilización. Se seleccionó aplicar las plantillas a la fase de conceptualización del proyecto. A continuación se especifican los documentos y/o plantillas que se aplicaron de acuerdo a cada grupo de procesos: Cuadro 23. Plantillas aplicadas

Inicialización Planificación 1. Visión técnica 1. Plan del proyecto 2. Modelación del negocio 2. Matriz de comunicación 3. Lista de Recursos 4. Glosario

Ejecución 1. Lecciones aprendidas

Metodología para la Administración de Proyectos Informáticos

110

4.3.2.1 DANTI-06: Visión técnica

DANTI-06 Visión Técnica 1

Introducción

1.1 Propósito Entendimiento del proyecto y servir de contrato entre la DCTIC y el Director del Proyecto 1.2 Definiciones, Siglas y Abreviaciones Ver documento de Glosario (DANTI-19 Glosario) 1.3

2 2.1

Referencias  AP-001-2006: Identificación del Proyecto (DCC-006-2006)  AP-002-2006 : Visión y Alcance del Proyecto (DCC-006-2006) Posicionamiento Oportunidad de Negocio

El proyecto no tiene la finalidad de generar ganancias a la entidad, sino de tener los insumos necesarios para poder cumplir con la entrega de la información crediticia estipulada en las normativas del ente regulador SUGEF y que esta información sea entregada de forma veraz y oportuna. 2.2

Definición del Problema El problema de

Afecta

El impacto es

Una solución exitosa es

El Banco Nacional debe cumplir con la entrega de información crediticia estipulada en las normativas de la SUGEF (1-05, 4-04 y 5-04.), sin embargo no posee una herramienta para la verificación y control de la dicha información consolidada. Dirección de Crédito Nacional Dirección de Coordinación de Entes Reguladores Al carecer de un sistema informático que permita administrar la información consolidada, puede provocar atrasos en la entrega de la información, lo cual provoca sanciones económicas para el banco. Un medio tecnológico que permita:  Administrar la información crediticia de forma consolidada  Corregir información inconsistente

Metodología para la Administración de Proyectos Informáticos

 Ajustarse a los requerimientos de validación definidos por la SUGEF Unidad de Seguimiento de crédito de la Dirección de Crédito Nacional Jefes de Crédito de las oficinas del BNCR Dirección de Coordinación de Entes Reguladores

Para

3 3.1

111

Descripciones de los Afectados y Usuarios Resumen de Afectados Nombre

Relación con el proyecto Proveer la información de los Créditos Recibir la información consolidada para generar los archivos que deben remitirse a la SUGEF MTVAL Brindar la información de operaciones contingentes que se administran en Finesse SIFCO Brindar los saldos de las cuentas contables asociadas a crédito. SFB Brindar la información de sobregiros de cuentas corrientes ORACARD Brindar la información de las tarjetas de crédito Dirección de Contabilidad Verificar que la información contable esté disponible y colaborar ante alguna diferencia contable entre las transacciones y lo contabilizado. Dirección de Medios de Revisar la información de Oracard antes de Pago Electrónico trasladarla al nuevo sistema. Jefes de Crédito Brindar la información de los clientes de crédito Grupo 1 Dirección de Crédito Definir los aspectos operativos para cumplir con la normativa. Dirección de Coordinación Identificar las validaciones realizadas por la de Entes Reguladores SUGEF SIACC SIEF

3.2

Resumen del Usuario Nombre

Descripción

Dirección de Coordinación de Administran el sistema, consolidan, validan Entes Reguladores y generan la información Jefes de crédito Modificación de información Unidad de Seguimiento de Generación de reportes Crédito 3.3

Principales Necesidades de Afectados o Usuarios

Metodología para la Administración de Proyectos Informáticos

Problema Cambio de esquema de envío de información crediticia Cambio en la normativa definida por la SUGEF

Reglas de validación para el envío de información Consolidar la información crediticia

4 4.1

112

Solución actual

Solución que desea el usuario Envió de archivos de texto, Envió de archivos en el los cuales se envían por el formato y seguridad sistema llamado estipulado por la SUGEF. Ingresador de la SUGEF No hay Tener una aplicación que permita aplicar las condiciones establecidas en la nueva normativas de SUGEF No hay Tener un sistema que permita aplicar las reglas establecidas por la SUGEF Consolidación en BUCRE Sustituir BUCRE por un sistema que cumpla con los aspectos considerados en la normativa y con mayor facilidad de administrar dicha información

Descripción del Producto Visión del Producto

El producto del proyecto se llamará COVIC el cual permitirá la consolidación de la información para que se ajuste a los requerimientos establecidos por la SUGEF, con una tecnología de vanguardia para la automatización de los procesos. El sistema COVIC sustituirá el sistema BUCRE. Por otro lado la SUGEF sustituirá el sistema Ingresador por SICVECA. COVIC, no es un sistema transaccional en si, sino se alimentará de los sistemas mostrados en el diagrama.

4.2

Suposiciones y dependencias

Metodología para la Administración de Proyectos Informáticos

113

 La información requerida por COVIC, está disponibles en los sistemas centrales: SIACC, SFB, ORACARD, MTVAL.  COVIC, no afectará la información de los sistemas transaccionales.  Como primera etapa está la implementación de los procesos básicos para el envió de información a la SUGEF, la segunda etapa es dotar de una herramienta amigable al usuario para que el tenga el control de la información. 5

Criterios de aceptación  Realizar envíos de prueba con la SUGEF y el producto se dará por aceptado cuando realizadas las validaciones y verificaciones la SUGEF aceptada la información remitida.  El sistema esté disponible en todas las oficinas del país.

6

Estándares relevantes  BNCR-21 Especificación de Requerimientos  BNCR-31 Diseño de Aplicaciones  BNCR-51 Pruebas  Normativa1 -05, 4-04 y 5-04 de la SUGEF

Metodología para la Administración de Proyectos Informáticos

114

4.3.2.2 DANTI-07: Modelación del negocio

DANTI-07 Modelación del negocio 1 1.1

Introducción Propósito

Entender el posicionamiento del producto por desarrollar a nivel del negocio, es decir el entorno del producto dentro de la organización del banco 1.2

Definiciones, Siglas y Abreviaciones

Ver documento de Glosario (DANTI-19 Glosario) 1.3

Referencias  AP-001-2006: Identificación del Proyecto (DCC-006-2006)  AP-002-2006 : Visión y Alcance del Proyecto (DCC-006-2006)  DANTI-06 Visión Técnica

2

Descripción del Producto

El producto por desarrollar es el Sistema para la Consolidación y verificación de Información Crediticia cuyas siglas es COVIC, el cual permitirá la consolidación de la información crediticia y realizar los procesos correspondientes para cumplir con las normativas 1-05, 4-04 y 5-04 establecida por la SUGEF, y definir las validaciones para el envío de información. Además de disponer de consultas y reportes sobre dicha información. 3

Contexto de Negocio

El producto será de uso de la Dirección de Crédito Nacional y la Dirección de Coordinación con Entes Reguladores. Este producto no proveerá un nuevo negocio o ganancias al banco sino el tener un producto para responder a la normativa de la SUGEF, por tanto el no disponer de una herramienta que permita responder de forma veraz y oportuna podrá traer multas para la institución. 4

Objetivos del Producto

4.1 Objetivo General Implementar una solución tecnológica que permita al Banco Nacional de Costa Rica cumplir con la nueva normativa SUGEF 1-05, 4-04, 5-04 para procesos básicos antes del 31 de diciembre 2006 y con un costo no mayor a $150,000.00.

Metodología para la Administración de Proyectos Informáticos

4.2

115

Objetivos Específicos  Implementar los procesos básicos para el envió de información a la SUGEF.  Poseer un solo punto para administrar la información crediticia que es remitida a la SUGEF.  Tener una herramienta tecnológica acorde a lo definido en las normativas 1-05, 404 y 5-04.  Permitir la validación de la información acorde a los reglas definidas por SUGEF.

5

Modelo de procesos del negocio

(Para efectos del caso se modelará el proceso de tarjetas)

6

Visualización del producto

El usuario requiere de una aplicación con las siguientes características:  Tipo Web  Pueda ser accedido en todas las oficinas del país  Permita generar reportes y los mismos puedan ser migrados a las herramientas Excel, Word, Archivo txt o archivo PDF.  Consulta de datos por cubos. Ejemplo de pantalla

Metodología para la Administración de Proyectos Informáticos

116

Ejemplo de reporte

4.3.2.3 DANTI-08: Plan del proyecto

DANTI-08 Plan del proyecto 1 1.1

Introducción Propósito

Proveer una guía una guía completa sobre los objetivos, alcance, y la forma en que el Banco Nacional de Costa Rica implementará una solución tecnológica para la Aplicación de la Normativa Prudencial SUGEF 1.2

Definiciones, Siglas y Abreviaciones

Ver documento de Glosario (DANTI-19 Glosario) 1.3

Referencias  AP-001-2006: Identificación del Proyecto (DCC-006-2006)  AP-002-2006 : Visión y Alcance del Proyecto (DCC-006-2006)

Metodología para la Administración de Proyectos Informáticos

117

 DANTI-06 Visión Técnica 2

Generalidades del proyecto

El proyecto Aplicación Normativa Prudencial de la SUGEF (ANPS) tiene como objetivo implementar una solución tecnológica que soporte los procesos para el cumplimiento de las normativas 1-05, 4-04 y 5-04 establecidas por la SUGEF. El principal inconveniente es que la información crediticia se encuentra en varios sistemas, lo cual dificulta su administración y la aplicación de las mismas reglas de negocio. Dado que está información debe ser entregada a la SUGEF de forma oportuna se deberán implementar los procesos que agilicen la operativa de preparación de esta información. El producto implementado se alimentará de los sistemas centrales SIACC, SFB, ORACARD, SIFCO, MTVAL; una vez que la información se encuentre consolidada se realizará la depuración de la misma aplicando las reglas de validación correspondientes además de las cuadraturas contables. Cuando la información se encuentre validada se procede al envió al sistema que integra la información que se remite a la SUGEF, para su envío. La Dirección de Coordinación de Entes Reguladores, será la encargada de administrar dicho producto y con ello la información.

Sistemas transaccionales

Procesos de Transformación

Información consolidada

3 3.1

Procesos de validación

Información validada

Plan de Gestión del Proyecto Alcance del Proyecto

3.1.1 Visión Implementar una solución tecnológica integrada y robusta que permita contar con una Metodología Automatizada para realizar la extracción, validación, administración y preparación de la información de crédito; según se estipula en la SUGEF 1-05, 4-04 y 5-04 para brindar información oportuna. 3.1.2 Objetivos 3.1.2.1 Objetivo General Implementar una solución tecnológica que permita al Banco Nacional de Costa Rica

Metodología para la Administración de Proyectos Informáticos

118

cumplir con la nueva normativa SUGEF 1-05, 4-04, 5-04 para procesos básicos antes del 31 de diciembre 2006 y con un costo no mayor a $150,000.00. 3.1.2.2 Objetivos Específicos  Implementar los procesos básicos para el envió de información a la SUGEF.  Poseer un solo punto para administrar la información crediticia que es remitida a la SUGEF.  Tener una herramienta tecnológica acorde a lo definido en las normativas 1-05, 404 y 5-04.  Permitir la validación de la información acorde a los reglas definidas por SUGEF 3.1.3   

Beneficios esperados Consolidación de la información crediticia, con ello un único punto de consulta. Poseer una herramienta adherida las normativas 1-05, 4-04 y 5-04 de la SUGEF Realizar entregas oportunas de la información crediticia a la SUGEF.

3.1.4

Declaración del Alcance

3.1.4.1 Entregas

3.1.4.2 Supuestos  Se cuenta con el presupuesto necesario para realizar la contratación para el desarrollo de la solución, así como para adquirir el equipo tecnológico que la soporte.  Los usuarios expertos conocen las nuevas normativas de la SUGEF 1-05, 4-05 y 505, y las implicaciones de las mimas para el Banco Nacional.  No se producirán cambios significativos durante la ejecución del proyecto por parte de la SUGEF.  Los requerimientos están claramente definidos por parte de los usuarios.

Metodología para la Administración de Proyectos Informáticos

119

3.1.4.3 Exclusiones  El proyecto no contempla la generación de los archivos que se remiten a la SUGEF.  El proyecto no realizará la migración de la herramienta para vista de cubos. 3.1.5 Criterios de Aceptación  Realizar envíos de prueba con la SUGEF y el producto se dará por aceptado cuando realizadas las validaciones y verificaciones la SUGEF aceptada la información remitida.  El sistema esté disponible en todas las oficinas del país. 3.1.6

3.2

Ciclo de vida del proyecto

Actividades y costos del proyecto

3.2.1

Definición de las actividades

Entrega Visión Técnica del proyecto

Modelación del Negocio

Plan de Proyecto

Descripción Documento para identificar la visión desde el punto de vista técnico de la solución

Tareas Revisar documentación Creación DANTI-06 Revisión Aprobación

Documento con la modelación de las funcionalidades desde la perspectiva del negocio.

Analizar entorno

Documento que sirve como guía para el desarrollo del plan de proyecto, formato y

Creación del DANTI-08 Confeccionar DANTI-09 Cronograma preliminar

Creación DANTI-07 Revisión Aprobación

Confeccionar DANTI-11 Matriz de

Metodología para la Administración de Proyectos Informáticos

considerar.

120

Comunicación Confeccionar DANTI-12 Lista de Riesgos Revisión del plan Aprobación del plan Definir recursos para el proyecto Confeccionar DANTI-10

Glosario

Lecciones aprendidas

Modelo de casos de uso

Documento en el que Formulario se documentan términos y abreviaciones del proyecto Plantillas donde se documentan las lecciones aprendidas del proyecto Documento con el diagrama de los requerimientos funcionales del producto

Confección DANTI-19 Publicación

Confección DANTI-20 Publicación Analizar Necesidades Creación del diagrama Confeccionar DANTI-03 Revisión Aprobación

Detalle de requerimientos

Documentos con las especificaciones funcionales como no funcionales del producto

Priorizar requerimientos Confección de requerimientos Revisión Aprobación Detallar necesidades no funcionales DANTI-02 Especificaciones suplementarias Confección de presentación a TI Presentación Entrega de documentación

Arquitectura

Diseño de la aplicación

Documento con la especificación arquitectónica del producto Documentar los riesgos asociados al proyecto para su seguimiento y control Documento con el diseño del producto

Solución Sw

Producto de software

Riesgos

Análisis de las necesidades Documento de Arquitectura Entrega del documento de Arquitectura Analizar posibles riesgos Entregar riesgos identificados Actualizar DANTI-12 Lista de Riesgos Analizar el producto Confeccionar documento de Análisis y Diseño Entregar documento de Análisis y Diseño Modificación DTS existentes DTS de extracción

Metodología para la Administración de Proyectos Informáticos

DTS de Transformación DTS de Control de Integridad Validaciones Carga de Información Validación cuadratura contable Validación por entregable Procesos Cubos Mantenimientos Catálogos Consultas y reportes Seguridad sistema Lista de materiales

Manuales Plan de pruebas

Pruebas internas Documento con la lista Confeccionar lista de materiales de materiales del producto a implementar Entregar lista de materiales Manuales técnicos y Confección del Manual Técnico del usuario Confección del Manual de Usuario Documento con la Confección de Plan de Pruebas planificación y el ambiente para realizar Confección de Casos de prueba las pruebas del Revisión de Casos de prueba producto Aprobación de casos de prueba Preparar ambientes de pruebas

Solución probada

Capacitación

Producto probado por el usuario

Ejecutar pruebas I Iteración Ejecutar pruebas II Iteración

Pruebas Integrales Capacitación técnica y Elaboración Plan de Capacitación operativa del producto Aprobación del Plan de Capacitación Realizar Capacitación

Solución en producción

Producto implementado en producción

Planificar pase Realizar pase a producción Elaboración Plan Piloto Ejecutar Plan Piloto Reporte de resultados Plan Piloto Aprobación Plan Piloto

Nota de aceptación de la solución Nota de cierre del proyecto

Documentar la DANTI-15 Nota de aceptación aceptación del usuario Entrega de Nota Documentar el cierre Confeccionar DANTI-16 del proyecto Aprobación del Cierre

121

122

Metodología para la Administración de Proyectos Informáticos

3.2.2 Desarrollo del cronograma Para detalles consultar el cronograma publicado en el Project Central Server. Id

Nombre de tarea

0

ANPS

1

Fas e de Conce ptualizació n

Dur ación

Comienzo

Fin

284,5 dí as

lun 09/01/06

vie 23/02/07

23 d ías

lun 09/01/06

mié 08/02/06

2

Creación de sitio

30 mins

lun 09/01/06

lun 09/01/06

3

Publicación de documentos

30 mins

lun 09/01/06

lun 09/01/06

4

Vis ión Té cnica

5 d ías

lun 09/01/06

lun 16/01/06 vie 20/01/06

9

Mo delación de l Neg ocio

5 d ías

vie 13/01/06

14

Plan de Proyecto

10,13 días

vie 20/01/06

vie 03/02/06

21

Lis ta de Recur sos

3,25 días

vie 03/02/06

mié 08/02/06

24

Glo sario Inicial

0,5 días

mié 01/02/06

mié 01/02/06

26

Leccione s apr endid as

0,5 días

mié 08/02/06

mié 08/02/06

93 d ías

vie 03/02/06

mié 14/06/06

28

Fas e de Elabor ación

Predeces oras Nombres de los recurs os

Ejec utivo de Tec nología 2

Ejec utivo de Tec nología

29

Mo delar casos de u so

4 d ías

vie 03/02/06

jue 09/02/06

35

Det allar n eces idade s

29 d ías

jue 09/02/06

mié 22/03/06

45

Actualizar DANTI-19 Glosario

1 hora

mié 22/03/06

mié 22/03/06

35

Ejec utivo de Tec nología

46

Contratac ión

60 días

mié 22/03/06

mié 14/06/06

35

Ingeniero

47

Arq uitectura

7 d ías

mié 22/03/06

vie 31/03/06

51

Realizar estimac iones

3 días

vie 31/03/06

mié 05/04/06

47;44

Ingeniero

52

Actualizac ión del cronograma

1 día

mié 05/04/06

jue 06/04/06

51

Ejec utivo de Tec nología

53

Entr ega de tiempos para el director

1 día

jue 06/04/06

vie 07/04/06

52

Ejec utivo de Tec nología

54

Rie sgos

4 d ías

vie 31/03/06

jue 06/04/06

68

Implantador

103

Usuario

58 60

Leccione s apr endid as Fas e de Const rucció n

0,25 días

jue 06/04/06

jue 06/04/06

153,25 días

mié 05/04/06

lun 06/11/06

8 d ías

mié 05/04/06

lun 17/04/06

61

Análisis y dise ño

65

Des arrollo de la solu ción

145 días

lun 17/04/06

lun 06/11/06

91

Leccione s apr endid as

0,25 días

lun 06/11/06

lun 06/11/06

214,25 días

lun 17/04/06

vie 23/02/07

15 d ías

lun 17/04/06

lun 08/05/06

93

Fas e de Trans ición

94

Planificación d e las prueb as

99

Preparar ambientes de pruebas

100

Pru ebas de us uario

104

Manual de Usuario

5 días

mié 17/01/07

mié 24/01/07

105

Cap acitación

9 d ías

mié 24/01/07

mar 06/02/07

109

Pas e a Producción

116

Leccione s apr endid as

118

Cie rre de l Pro yecto TI

5 días

mié 12/07/06

mié 19/07/06

95 d ías

mié 23/08/06

mié 17/01/07

27 d ías

mié 17/01/07

vie 23/02/07

0,25 días

vie 23/02/07

vie 23/02/07

17,13 días

mié 31/01/07

vie 23/02/07

0,13 días

vie 23/02/07

vie 23/02/07

119

Ace ptación

122

Pre sentación del pr oduct o

2 d ías

mié 31/01/07

vie 02/02/07

125

Not a de cierre

3 d ías

vie 02/02/07

mié 07/02/07

128

Leccione s apr endid as

1 d ía

mié 07/02/07

jue 08/02/07

3.2.3 Ruta Crítica del Proyecto A continuación se detallan las tareas que conforman la ruta crítica Id 0 1 2 3 4 5 6 9 10 11 12

EDT 0 1 1.1 1.2 1.3 1.3.1 1.3.2 1.4 1.4.1 1.4.2 1.4.3

Nombre ANPS Fase de Conceptualización Creación de sitio Publicación de documentos Visión Técnica Revisar documentación Creación DANTI-06 Modelación del Negocio Analizar entorno Creación DANTI-07 Revisión

Metodología para la Administración de Proyectos Informáticos

13 14 15 16 17 18 19 20 28 29 30 31 32 33 34 35 36 37 38 39 42 43 44 46 66 67 68 69 72 73 76 78 79 80 81 85 86 87 93 100 102 103 109 110 111

1.4.4 1.5 1.5.1 1.5.2 1.5.3 1.5.4 1.5.5 1.5.6 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.7 2.2.8 2.2.9 2.4 3.2.1 3.2.1.1 3.2.1.1.1 3.2.1.1.1.1 3.2.1.1.1.4 3.2.1.1.2 3.2.1.1.2.3 3.2.1.2 3.2.2 3.2.2.1 3.2.2.1.1 3.2.2.1.3 3.2.2.1.4 3.2.2.2 4 4.3 4.3.2 4.3.3 4.6 4.6.1 4.6.2

Aprobación Plan de Proyecto Creación del DANTI-08 Confeccionar DANTI-09 Cronograma preliminar Confeccionar DANTI-11 Matriz de Comunicación Confeccionar DANTI-12 Lista de Riesgos Revisión Aprobación Fase de Elaboración Modelar casos de uso Analizar Necesidades Creación del diagrama Confeccionar DANTI-03 Revisión Aprobación Detallar necesidades Priorizar requerimientos Confección de requerimientos Revisión Aprobación Confección de presentación a TI Presentación Entrega de documentación Contratación I Iteración Desarrollo DTS Modificación DTS existentes DTS de Control de Integridad Validación Validación por entregable Pruebas internas II Iteración Desarrollo Cubos Consultas y reportes Seguridad sistema Pruebas internas Fase de Transición Pruebas de usuario Ejecutar pruebas II Iteración Pruebas Integrales Pase a Producción Planificar pase Realizar pase a producción

123

124

Metodología para la Administración de Proyectos Informáticos

113 114 115 116 117

3.2.4

4.6.4 4.6.5 4.6.6 4.7 4.7.1

Ejecutar Plan Piloto Reporte de resultados Plan Piloto Aprobación Plan Piloto Lecciones aprendidas Confección DANTI-20

Curva “S” del trabajo acumulado Trabajo acumulado Trabajo

6.000

5.000

Horas

4.000

3.000

2.000

1.000

Ene-06 Feb-06 Mar-06 Abr-06 May-06 Jun-06 Jul-06 Ago-06 Sep-06 Oct-06 Nov-06 Dic-06 Ene-07 Feb-07

Meses

3.2.5

Presupuesto de actividades

Id 65

Nombre Desarrollo de la solución

Comienzo 17/04/2006

Fin

Costo estimado

17/01/2007

$140,000.00

Metodología para la Administración de Proyectos Informáticos

3.3 3.3.1

125

Organización del proyecto Diagrama funcional del Proyecto Patrocinador del proyecto Director del proyecto Usuarios Expertos

Ejecutivo de tecnología Arquitecto

Usuario de Crédito

Soportista Técnico

Usuario de Contabilidad

Implementador

Usuario de Entes

Ingeniero

Usuario de tarjetas

Desarrolladores

3.3.2

Roles necesarios Rol Arquitecto Soportista técnico Implementador Ingeniero Desarrollador

3.3.3

Jefes de Crédito

Funciones Realizar la definición del modelo de arquitectura a nivel de software y de hardware Implementar la infraestructura para el ambiente de producción Llevar el proceso de pruebas y coordinar con el soportista la puesta en producción de la solución Realizar el análisis y diseño de la aplicación y velar por el desarrollo del producto Realizar el desarrollo del producto

Matriz de Responsabilidades

La nomenclatura utilizada en la tabla es la siguiente: Símbolo




Significado Responsable de toda la macro actividad, debe asegurarse de que todas las actividades se vayan ejecutando y que los recursos involucrados estén realizando su labor. Es un miembro del equipo que desarrollará labores específicas para alcanzar el objetivo de la macro actividad

0

ANPS

1.1

Creación de sitio




1.2

Publicación de documentos




1.3.1

Revisar documentación


 

1.3.2

Creación DANTI-06




1.3.3

Revisión




1.3.4

Aprobación




1.4.1

Analizar entorno




1.4.2

Creación DANTI-07




1.4.3

Revisión




1.4.4

Aprobación




1.5.1 1.5.2 1.5.3

Creación del DANTI-08 Confeccionar DANTI-09 Cronograma preliminar Confeccionar DANTI-11 Matriz de Comunicación









1.5.4

Confeccionar DANTI-12 Lista de Riesgos

1.5.5

Revisión




1.5.6

Aprobación




1.6.1

Definir recursos para el proyecto




1.6.2

Confeccionar DANTI-10




1.7.1

Confección DANTI-19




1.8.1

Confección DANTI-20




2.1.1

Analizar Necesidades




2.1.2

Creación del diagrama




2.1.3

Confeccionar DANTI-03




2.1.4

Revisión




2.1.5

Aprobación




2.2.1

Priorizar requerimientos

2.2.2

Confección de requerimientos

2.2.3

Revisión

2.2.4

Aprobación




2.2.5

Detallar necesidades no funcionales




2.2.6

DANTI-02 Especificaciones suplementarias













Implementador

Ingeniero

Arquitecto

Jefes TI

Usuario

Director

Nombre

Ejecutivo

EDT

Desarrollador

126

Metodología para la Administración de Proyectos Informáticos

127

Metodología para la Administración de Proyectos Informáticos

2.2.7

Confección de presentación a TI




2.2.8

Presentación




2.2.9

Entrega de documentación




2.3

Actualizar DANTI-19 Glosario




2.4

Contratación




2.5.1

Análisis de las necesidades




2.5.2

Documento de Arquitectura




2.5.3

Entrega del documento de Arquitectura





2.6

Realizar estimaciones

2.7

Actualización del cronograma




2.8

Entrega de tiempos para el director




2.9.1

Analizar posibles riesgos




2.9.2

Entregar riesgos identificados




2.9.3

Actualizar DANTI-12 Lista de Riesgos




2.10.1

Confección DANTI-20




3.1.1 3.1.2 3.1.3




Analizar el producto Confeccionar documento de Análisis y Diseño





Entregar documento de Análisis y Diseño

3.2.1.1.1.1

Modificación DTS existentes




3.2.1.1.1.2

DTS de extracción




3.2.1.1.1.3

DTS de Transformación




3.2.1.1.1.4

DTS de Control de Integridad




3.2.1.1.2.1

Validaciones Carga de Información




3.2.1.1.2.2

Validación cuadratura contable




3.2.1.1.2.3

Validación por entregable




3.2.1.1.3 3.2.1.2 3.2.2.1.1




Procesos




Pruebas internas




Cubos

3.2.2.1.2.1

Mantenimientos




3.2.2.1.2.2

Catálogos




3.2.2.1.3

Consultas y reportes




3.2.2.1.4

Seguridad sistema




3.2.2.2




Pruebas internas

3.2.3

Confeccionar lista de materiales




3.2.4

Entregar lista de materiales




3.2.5

Manual Técnico




3.3.1

Confección DANTI-20

4.1.1

Plan de Pruebas





128

Metodología para la Administración de Proyectos Informáticos

4.1.2

Casos de prueba

4.1.3

Revisión

4.1.4





Aprobación




Preparar ambientes de pruebas

4.3.1

Ejecutar pruebas I Iteración




4.3.2

Ejecutar pruebas II Iteración




4.3.3

Pruebas Integrales





Manual de Usuario


4.5.1

Elaboración Plan de Capacitación

4.5.2

Aprobación del Plan de Capacitación




4.5.3

Realizar Capacitación




4.6.1

Planificar pase




4.6.2

Realizar pase a producción

4.6.3

Elaboración Plan Piloto

4.6.4

Ejecutar Plan Piloto




4.6.5

Reporte de resultados Plan Piloto




4.6.6

Aprobación Plan Piloto




4.7.1

Confección DANTI-20

5.1.1

DANTI-15 Nota de aceptación




5.1.2

Entrega de Nota




5.2.1

Preparar Presentación




5.2.2

Presentación




5.3.1

Confeccionar DANTI-16




5.3.2

Aprobación del Cierre

5.4.1

Confección DANTI-20

 












Involucrado Adrián Salazar Alejandra Mora Oscar Cambronero Harold Bustos

Rol en el Proyecto Director Proyecto Ejecutivo Jefe de TI Jefe de TI

Minutas de reuniones internas Minutas de reuniones con proveedores

DANTI – 11 Matriz de Comunicación

Informe Mensual

Matriz de comunicación

Informe Semanal

3.3.4



Sem. Men. Sem.

Sem.

Plan del Proyecto

4.4

Solicitudes de cambio

4.2




Otro. Otro

del

*

*

*

*

*

*

Metodología para la Administración de Proyectos Informáticos

Danilo Segura Gilberto Villalobos Oldemar Vargas William Romero Edwin León Mario Gamboa

129

Jefe de TI Jefe de TI Arquitecto Ingeniero Implementador Soportista Téc.

Impreso *

Correo Electrónico Responsable

3.3.5 Reuniones de seguimiento  Reuniones del Equipo de Proyecto: estas reuniones se realizarán semanalmente los martes, la convocatoria será enviada por el ejecutivo de tecnología mediante el Outlook. Para cada reunión cada miembro del proyecto deberá llevar un informe con los avances de las tareas asignadas. La minuta será redactada por el ejecutivo de tecnología y será enviada al siguiente día de la reunión para ser revisada, cualquier observación deberá ser enviada al menos dos días después de la recepción de la minuta. La firma de las mismas se realizará en la próxima reunión.  Reuniones con el director del Proyecto: estas reuniones se realizarán mensualmente o en el momento que el director lo considere necesario. La convocatoria será realizada por el director del proyecto. En esta reunión se revisará el informe mensual y cualquier otro aspecto por resolver. Para ambos casos se utilizará la plantilla de la Metodología de Administración de Proyectos del BNCR APP-03-2002 Minuta 3.3.6 Informe de Avance  Reportes de avance semanales: Cada jueves los miembros del equipo entregarán al ejecutivo de tecnología el reporte del avance de las tareas asignadas de acuerdo al cronograma definido. Con esto el ejecutivo realizará la confección del reporte de acuerdo al DANTI-13. Este informe será enviado por el ejecutivo de tecnología todos los viernes por medio electrónico.  Reportes de avance mensuales: Cada fin de mes el ejecutivo de tecnología confeccionará el reporte de avance de acuerdo a la plantilla DANTI-14. Este informe será enviado vía correo al equipo de trabajo de tecnología y a sus jefes correspondientes, además le entregará un reporte impreso al director del proyecto. 3.3.7

Control de Cambios

En la siguiente figura se detalla el proceso a ser ejecutado ante una solicitud de cambio. Una solicitud de cambio deberá ser gestionada ante el ejecutivo de tecnología y él mismo procederá con su revisión con el director del proyecto.

Metodología para la Administración de Proyectos Informáticos

130

3.3.8 Aprobación de Entregables Cuando se requiera dar un entregable al proyecto, el responsable de realizar la entrega deberá llenar el formulario DANTI-17. El responsable de la recepción del entregable lo revisará e indicará en el mismo formulario si se acepta o no el entregable. De no aceptarse se le devuelve al encargado del entregable para que realice los cambios solicitados. 3.3.9 Lecciones aprendidas Cada vez que ocurra una situación de éxito o error dentro del proyecto, se deberá completar el formulario DANTI-20, esto lo podrá completar cualquier miembro del equipo de proyecto. Sin embargo, al finalizar cada fase del proyecto el ejecutivo realizará una recapitulación y documentará cualquier situación que no se haya considerado. 3.4 3.4.1

Riesgos

Definición del impacto Impacto Definición de Categoría Critico Un evento, que si ocurre, causaría fallas en el proyecto (inhabilita el alcance de los requerimientos mínimos aceptables). Serio Un evento, que si ocurre, causaría incrementos severos en el costo y el tiempo. Requerimientos secundarios pueden no ser alcanzados.

131

Metodología para la Administración de Proyectos Informáticos

Moderado

Menor Despreciable

3.4.2

Un evento, que si ocurre, causaría incrementos moderados en el costo y el tiempo, pero los requerimientos importantes pueden aún lograrse. Un evento, que si ocurre, causaría incrementos bajos en el costo y el tiempo. Los requerimientos pueden ser alcanzados. Un evento, que si ocurre, no tendría efecto en el proyecto.

Categorías de Riesgos Impacto / Probabilidad 00-10% 11-40% 41-60% 61-90% 91-100%

Despreciable

Menor

Moderado

Serio

Crítico

Bajo Bajo Bajo Medio Medio

Bajo Bajo Medio Medio Alto

Bajo Medio Medio Medio Alto

Medio Medio Medio Medio Alto

Medio Alto Alto Alto Alto

3.4.3 Identificación de Riesgos (Para efectos de la aplicación se defines 5 riesgos) ID 1

2

3

4

5

Riesgo Si se dan controles de cambios que afecten el alcance porque los requerimientos no están bien definidos puede generar aumento en el costo del proyecto Si se da un atraso en el inicio del desarrollo del producto puede generar que el costo del proyecto supere lo aprobado Si se presentan problemas en la aprobación del presupuesto puede provocar atrasos en el inicio del proyecto. Si se dan retrasos en la contratación para el desarrollo del sistema puede generar atrasos en el cronograma Si el usuario no participa en el proceso de pruebas del sistema puede afectar la calidad del producto final.

Probabilidad 70%

Impacto Serio

Categoría Medio

80%

Serio

Medio

10%

Moderado

Bajo

50%

Moderado

Medio

10%

Crítico

Medio

Metodología para la Administración de Proyectos Informáticos 3.4.4

132

Estrategias de respuesta

Código Eliminar Transferir Mitigar Aceptar

Descripción de la Estrategia Eliminación del riesgo. Transferencia del riesgo (traslado de la responsabilidad a terceras partes). Mitigación del riesgo. Aceptación del riesgo. Debe utilizarse para los riesgos de categoría Baja.

3.4.5 Planificación de la respuesta a riesgos Riesgo

Estrategia

Acción

Contingencia

Presu-

Responsable

Disparador

puesto

1

Mitigar

2

Transferir

Realizar sesiones con los usuarios para la elaboración de casos de uso. Análisis de los casos de uso con el personal técnico. Realizar sesiones con el personal técnico y usuarios para aclaraciones de casos de uso. Aprobación de los casos de uso (Firma de los usuarios). En el contrato se debe incluir las cláusulas donde se especifiquen las multas por atraso en la entrega del producto.

Realizar controles de cambio solo para requerimientos críticos (que impidan la puesta en producción del producto)

Costo: $2,000.00 Tiempo: 80 hora

Director proyecto

Ingeniero

del Que se presenten dos solicitudes de cambio

En el seguimiento, existen atrasos en los porcentajes de trabajo finalizado

Metodología para la Administración de Proyectos Informáticos Riesgo

Estrategia

Acción

Contingencia

133 Presu-

Responsable

Disparador

puesto

4

Aceptar

5

Mitigar

3

Aceptar

Estimar 10 días adicionales para la contratación. Ajustar el tiempo de inicio de desarrollo cuando la proveeduría genere la orden de compra. Solicitar al proveedor la inclusión de recursos adicionales para finalizar a tiempo Definir un plan de pruebas con los usuarios. Realizar reunión con los usuarios y sus jefaturas para explicar el proceso de pruebas y obtener el compromiso

Implementador

Solicitar al patrocinador la incorporación del proyecto dentro del portafolio de proyectos o solicitar presupuesto de las áreas beneficiadas. Realizar estimaciones para el desarrollo con recurso interno. Ajustar los tiempos en el cronograma con los tiempos internos.

Director proyecto

Usuario no desea participar en las reuniones de seguimiento y no desea realizar el proceso de pruebas del Se recibe nota de la presupuesto acerca de la no aprobación del presupuesto

Metodología para la Administración de Proyectos Informáticos

3.5 3.5.1

134

Adquisiciones del proyecto Matriz de Adquisiciones

Nombre de Descripción de la contratación Costo Estimado Fecha límite Posibles Responsable Contratación contratación Proveedores Ingeniería-01 Desarrollo de la aplicación $ 140,000.00 14/06/2007 Grupo MAS William Romero

Metodología para la Administración de Proyectos Informáticos

135

4.3.2.4 DANTI-10: Recursos del proyecto A continuación se detalla los recursos del proyecto de la DCTIC.

DANTI – 10 Recursos del proyecto Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Nombre Dependencia

Correo Teléfono electrónico

Ejecutivo de Tecnología

Fase

Fecha estimada

Horas/ semana

Conceptualización, Elaboración, Constricción, Transición, Cierre Elaboración

09/01/2006 al 23/02/2007

8 horas

03/02/06 al 14/06/06

6 horas

03/02/2006 al 06/11/2006 17/04/2006 al 23/02/2007 17/01/2007 al 23/01/2007

8 horas

Alejandra Mora

Análisis Negocio

Oldemar Vargas

Arquitectura de Servicios de TI

Arquitecto

William Romero

Ingeniería de Servicios de TI

Ingeniero

Elaboración, Constricción

Edwin León

Implantación de Servicios de TI Servicios en Producción

Implementador

Transición

Soportista Téc.

Transición

Mario Gamboa

de

Rol

4.3.2.5 DANTI-19: Glosario

DANTI-19 Glosario 1 1.1

Introducción Propósito

Documentar las abreviaturas y términos utilizados dentro del Proyecto. 2 2.1 2.2 2.3 2.4

Abreviaturas ANPS: Aplicación Normativa Prudencial SUGEF COVIC: Sistema para la Consolidación y verificación de Información Crediticia SIACC: Sistema Integrado de la Administración de la Cartera de Crédito BUCRE: Base Única de Crédito

8 horas

6 horas

Metodología para la Administración de Proyectos Informáticos

2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12

136

SIEF: Sistema Integrador para Entidades Financieras SICVECA: Sistema de Verificación y Carga de datos - SUGEF SICICC: Sistema Conciliación Información Crediticia MTVAL: Módulo de Transferencia de Valores FINESSE: Sistema de Cajas SIFCO: Sistema Financiero Contable Oracard: Sistema de Administración de Tarjetas de Crédito SFB: Sistema Financiero Bancario

4.3.2.6 DANTI-20: Lecciones Aprendidas

DANTI – 20 Lecciones aprendidas Dirección Corporativa de Tecnología de Información y Comunicaciones Dirección Análisis de Negocio Información general del proyecto Fecha: 02/11/2007 Identificación Proyecto: ANPS

Nombre del Proyecto: Aplicación Normativa Prudencial SUGEF Información de la lección

Fase del proyecto: Elaboración Situación presentada: Definición tardía, en algunos casos ambigua y contradictoria; de las validaciones y reglas del negocio, por parte de la Superintendencia General de Entidades Financieras. Consecuencias: Atrasos en el desarrollo de algunos procesos por contradicción de las validaciones. El desarrollo no se podía detener porque las fechas de envío con la SUGEF no eran modificadas. Resolución de la situación: Basándose en la normativa aprobada, se procedió a definir los requerimientos base sobre los cuales se debería desarrollar el producto. Los requerimientos fueron ajustándose gradualmente durante la construcción, al tiempo que la SUGEF publicaba correcciones a lo normado inicialmente. Documentado por Alejandra Mora Rodríguez

Metodología para la Administración de Proyectos Informáticos

4.4

137

Plan de divulgación

Con el fin de no dejar la metodología solo sobre papel se realizará un plan de divulgación a la Dirección de Análisis de Negocio, el cual se presenta a continuación. Dentro del alcance de este trabajo se realizará únicamente su definición, no conlleva su aplicación.

4.4.1 Objetivo Dar a conocer al personal de la Dirección de Análisis de Negocio la Metodología para estandarizar la administración de proyectos informáticos.

4.4.2 Personal a quien va dirigido La divulgación se realizará al personal de la Dirección de Análisis de Negocio, sin embargo es esencial la participación de todos los ejecutivos de tecnología.

4.4.3 Temario propuesto 1. Objetivos: Objetivos por los cuales se realizó el desarrollo de la metodología. 2. Hallazgos identificados por el personal de DANTI: Mostrar los principales hallazgos producto de las entrevistas y cuestionarios desarrollados con el personal de DANTI. 3. Procesos para la administración de proyectos informáticos: Para cada una de las fases del proyecto conceptualizarlas, mostrar el flujo de procesos y exponer y explicar las plantillas a utilizar. a. Recepción b. Conceptualización

138

Metodología para la Administración de Proyectos Informáticos

c. Elaboración d. Construcción e. Transición f. Cierre

4.4.4 Definición de recursos Para el desarrollo de este plan se requieren los siguientes recursos: 1. Sala de sesiones 2. Proyector 3. Computadora portátil 4. Material impreso para la capacitación

4.4.5 Tareas a realizar En el siguiente cronograma se definen las tareas a realizar. Cuadro 24. Tareas por realizar Id

Nombre de tarea

Dur ación

Comienzo

0

Pla n de divulgación

Fin

Predeces oras

20, 5 día s

lun 21/01/08

lun 18/02/08

1

Des arrollo del contenido

5 días

lun 21/01/08

vie 25/01/08

2

Confección de un manual

5 días

lun 28/01/08

vie 01/02/08 1

3

Confección de la presentación

2 días

lun 04/02/08

mar 05/02/08 2

4

Impresión del material

0,5 días

mié 06/02/08

mié 06/02/08 3

5

Def inición de un caso práctic o

1 día

mié 06/02/08

jue 07/02/08 4

6

Impartir capacitación

1 día

jue 07/02/08

vie 08/02/08 5

7

Entr ega del caso a res olver

1 día

vie 08/02/08

lun 11/02/08 6

8

Valoración del resultados

5 días

lun 11/02/08

lun 18/02/08 7

Metodología para la Administración de Proyectos Informáticos

139

CAPITULO 5 CONCLUSIONES Y RECOMENDACIONES

Metodología para la Administración de Proyectos Informáticos

5.1

140

Conclusiones

El Banco Nacional de Costa Rica, es una entidad que se ha preocupado por promover el tema de la administración de proyectos. Por tal razón, se evidencia que el personal que labora en la Dirección de Análisis de Negocio posee experiencia en el tema y ha recibido capacitaciones. La Dirección de Análisis de Negocio se ha convertido en una oficina administradora de proyectos tecnológicos, con el fin de mejorar la gestión que realiza está oficina, se crea la metodología, la cual se convierte en un complemento de la Metodología de Administración de Proyectos del Banco Nacional de Costa Rica. Dentro de los proyectos, la generación de un producto tecnológico es solo un producto del macro proyecto, por eso la generación de ese producto se convierte para tecnología en todo un proyecto, en donde la cabeza para tecnología es el ejecutivo de tecnología. Cada ejecutivo tiene su criterio y su forma de trabajar en la administración de proyectos, por tanto esta metodología se considera una guía para la administración de proyectos informáticos, estandarizando el proceso y con esto dando un paso más en el proceso de maduración. Dentro de los hallazgos de las entrevistas y cuestionarios se evidencias los siguientes puntos: En la documentación que se le entrega a tecnología, se dan casos donde el alcance del proyecto no está claramente definido. Este punto se convierte en un aspecto crítico, dado que si no existe un alcance claro, el producto implementado probablemente no cumplirá las expectativas del usuario.

Metodología para la Administración de Proyectos Informáticos

141

Falta de comunicación. Dentro de los proyectos la comunicación es un elemento que debe calar a todos los niveles, esto por cuanto el conocimiento genera mayor confianza y podría colaborar en el incremento del compromiso que cada miembro del equipo de trabajo pueda implementar a lo largo del desarrollo del proyecto. Existe resistencia a la documentación porque algunas de las plantillas y documentos son difíciles de utilizar y poco claros. Por esta razón la metodología implementada considera las plantillas y/o documentos con una guía que le permita a la persona, identificar la información que debe ser completada en cada apartado. Poco tiempo para planificar. Algunos ejecutivos se saltan la planificación del proyecto a desarrollar, sin embargo esta es una etapa en la cual hay que dedicar tiempo y recursos, porque del nivel de planificación depende en gran porcentaje el éxito del proyecto. Dedicar tiempo a la planificación, en vez de un gasto se verá reflejado como una inversión al final del proyecto. Poca documentación. La documentación no es un aspecto de cumplimiento, sino debe convertirse dentro de la cultura como una herramienta para resguardar la experiencia y así colaborar en el éxito de próximos proyectos. Planificar requiere un esfuerzo importante, y si no se realiza desde el inicio, se convierte en una pérdida del momento propicio para identificar el entorno y aspectos que se deberán considerar para desarrollar el proyecto con éxito.

142

Metodología para la Administración de Proyectos Informáticos

5.2

Recomendaciones

Con el fin de mejorar el proceso de administración de los proyectos informáticos y que la metodología propuesta tenga éxito dentro, se realizan las siguientes recomendaciones: Documentar: Concienciar en el personal de la Dirección Corporativa de Tecnología

de

Información

y

Comunicaciones,

la

importancia

de

documentar dado que la misma se convierte en las bases de datos de conocimiento en cada uno de los procesos, además de ser una herramienta que les colabora en el éxito del producto y del proyecto, provee un punto de referencia para toma de decisiones y reutilización de información. Cuando un proyecto ingresa a la Dirección Corporativa de Tecnología de Información y Comunicaciones, es importante que el mismo cumpla con los insumos necesarios para iniciar el proyecto, el no contar con toda la información provoca atrasos en los proyectos y muchas veces al fracaso de los mismos. Dado el proceso actual de reestructuración de la Dirección Corporativa de Tecnología de Información y Comunicaciones, existen personas que no tienen claro su rol dentro de los procesos. Por tanto, se recomienda: o Realizar una sesión con cada dirección donde se explique la razón de ser de cada dirección, los roles definidos con sus respectivas funciones. o Entregar a cada persona su perfil de puesto (especificación de las tareas a realizar).

Metodología para la Administración de Proyectos Informáticos

143

o Definir que a pesar que cada recurso tiene su jefe de línea, ellos deben responder ante sus responsabilidades dentro del proyecto al ejecutivo de tecnología. En los proyectos definir claramente los roles de cada persona e identificar las responsabilidades de cada persona. Con el fin de mantener un proceso estandarizado se recomienda: o Realizar sesiones mensuales dentro de la Dirección de Análisis de Negocio donde participe todo el personal y se identifiquen dificultades en los procesos, mejora a las plantillas. o Realizar revisiones periódicas a proyectos de forma aleatoria, con el fin de verificar que el personal este utilizando la metodología. o Actualizar la metodología de acuerdo a las mejoras que se aprueben. Verificar periódicamente resultados, para ello se recomienda establecer algunas métricas antes de aplicar la metodología y actualizarlas en cada revisión, esto con el fin de tener unidades de medida que permitan contabilizar los resultados. Realizar un análisis de la capacidad de atención de proyectos para cada recurso dentro de cada dirección de la Dirección Corporativa de Tecnología de Información y Comunicaciones, dado que uno de los problemas identificados por los ejecutivos de tecnología, es que el personal asignado a los proyectos no responde de forma oportuna dado la sobrecarga de trabajo. De acuerdo a la revisión realizada, la Metodología de Administración de Proyectos del Banco Nacional, no ha sufrido revisión ni actualización desde el 2002, por tanto se recomienda su actualización de acuerdo a la

Metodología para la Administración de Proyectos Informáticos

144

estructura actual del banco, la experiencia obtenida en estos años y analizar mejoras de acuerdo a estándares internacionales.

Metodología para la Administración de Proyectos Informáticos

145

BIBLIOGRAFIA BNCR (Banco Nacional de Costa Rica). Sitio informativo del Banco Nacional de Costa Rica. Disponible en: http://www.bncr.fi.cr. Consultado 26 de julio 2007. BNCR (Banco Nacional de Costa Rica). Sitio intranet. Disponible en: http://bnintranet/Principal. Consulado 26 de julio 2007. BNCR (Banco Nacional de Costa Rica). Sitio de documentación de la Dirección de Análisis de Negocio. Disponible en: http://equipos/tecnologia/Analisis_del_negocio. Consultado 26 de julio 2007. Chamoun, Yamal. Administración Profesional de Proyectos. La Guía. Primera edición. McGraw-Hill Interamerica, 2002. Fowler, Martín; Scout, Kendall. UML gota a gota. Addison Wesley Longman, 1997. Gallardo, Helio. Elementos de Investigación Académica. Vigésimo novena Reimpresión. Editorial Universidad Estatal a Distancia, 2005. Gido, Jack; Clements, James. Administración Exitosa de Proyectos. Segunda edición. Internacional Thomson Editores, S.A. de C.V., 2003. OGC (Office of Government Commerce). Prince2. Disponible en: http://www.prince2.com. Consultado 11 de agosto 2007. Ortiz, Frida; García, María del Pilar. Metodología de la investigación. Segunda Reimpresión. Editorial Limusa, S.A. de C.V., 2002 PMI (Project Management Institute). Guía de los fundamentos de administración de proyectos (Guía del PMBOK). Tercera edición. PMI Publications, 2004.

Metodología para la Administración de Proyectos Informáticos

146

Rational Corporation Software. History Rational Software. Disponible en http://investor.rational.com. Consultado 05 agosto 2007. Real Academia Española. Diccionario de la Real Academia Española. Disponible en: http://www.rae.es. Consultado 01 de agosto 2007. Software “Rational” Unified Process, Versión 2003.06.15. Rational Software Corporation, 2005

Metodología para la Administración de Proyectos Informáticos

147

ANEXOS

Metodología para la Administración de Proyectos Informáticos

148

Anexo 1 Acta del proyecto ACTA DEL PROYECTO Información general del proyecto Fecha: Nombre de Proyecto: 18 de julio 2007 Metodología para estandarización de la Administración de Proyectos Informáticos dentro de la Dirección de Tecnología de Información y Comunicaciones del Banco Nacional Áreas de conocimiento / procesos Área de aplicación (sector / actividad): Conceptualización, Planificación, Dirección de Análisis de Negocio / Seguimiento y Control, Cierre Dirección Corporativa de Tecnología de Información y Comunicaciones / Banco Nacional de Costa Rica Fecha de inicio del proyecto: Fecha tentativa de finalización del 18 de julio del 2007 proyecto: 05 de febrero del 2008 Detalle del proyecto Objetivo General: Elaborar una Metodología para la Administración de Proyectos Informáticos dentro de la Dirección de Análisis de Negocio de la DCTIC, considerando las mejores prácticas propuestas por el PMI en el PMBOK 2004. Objetivos específicos: a. Analizar el proceso de administración de proyectos de TI que realiza la Dirección de Análisis de Negocio. b. Realizar un análisis comparativo entre las disciplinas de PMI y los procesos de proyectos de TI. c. Definir el flujo de procesos para la administración de proyectos de TI. d. Confeccionar las plantillas para el apoyo a utilizar en la administración de proyectos de TI. e. Validar parcialmente la metodología propuesta. f. Desarrollar un plan preliminar de divulgación de la metodología. Descripción del producto: Documento mediante el cual se realice una propuesta de Metodología para la administración de proyectos informáticos, controlados por la Dirección de Análisis de Negocio de la Dirección Corporativa de Tecnología de Información y Comunicaciones del Banco Nacional de Costa Rica.

Metodología para la Administración de Proyectos Informáticos

149

Necesidad del proyecto: La Dirección Corporativa de Tecnología de Información y Comunicaciones (DCTIC), inició un proceso de reestructuración a principios del 2007, dentro de está estructura se realizó la creación de una dirección llamada Análisis de Negocio, quien tendrá la función de administrar los proyectos informáticos que ingresen a la DCTIC. Sin embargo, no se ha establecido una metodología que indique la forma en que los ejecutivos de tecnología deben administrar sus proyectos. Con el fin de facilitar la administración de proyectos informáticos y asegurar el éxito de los mismos, se desarrollará la metodología. Justificación del impacto: a. Contar con una metodología que facilite la administración de proyectos de TI. b. Uniformar el proceso de administración de proyectos informáticos con los estándares de PMI. c. Alinear los proyectos de TI para que utilicen la metodología definida. Restricciones/ Limitantes/ Factores críticos de éxito: a. Apoyo de la Dirección de Análisis de Negocio. b. La Metodología es considerada solo para la administración de proyectos informáticos administrados por la Dirección de Análisis de Negocio. c. El tiempo de cuatro meses para llevar a cabo el trabajo Identificación de grupos de interés (stakeholders): Cliente(s) directo(s):  Ejecutivos de Tecnología  Jefaturas de la Dirección de Análisis de Negocio. Clientes indirecto(s):  Directora de la DCTIC.  Directores de Proyecto por parte del Negocio.  Miembros de los equipos de proyectos. Aprobaciones Nombre Licda. Alejandra Mora Sustentante Msc. Miguel Ángel Vallejo Instructor

Firma

Fecha

Metodología para la Administración de Proyectos Informáticos

150

Anexo 2 Declaración del alcance DECLARACIÓN DEL ALCANCE DEL PROYECTO Fecha: 18 de julio 2007

Nombre de Proyecto: Metodología para estandarización de la Administración de Proyectos Informáticos dentro de la Dirección de Tecnología de Información y Comunicaciones del Banco Nacional Planteamiento del problema y justificación del proyecto: La Dirección Corporativa de Tecnología de Información y Comunicaciones (DCTIC), inició un proceso de reestructuración a principios del 2007. Dentro de está estructura se realizó la creación de una dirección llamada Análisis de Negocio, quien tendrá la función de administrar los proyectos informáticos que ingresen a la DCTIC. Esta dirección no posee una metodología que indique la forma en que se deben administrar los proyectos de tecnología acordes a sus procesos. El Banco Nacional tiene una metodología para la administración de proyectos, la cual tiene como objetivo definir los estándares y fases para la Administración de Proyectos La primera versión aprobada fue el 30 de mayo de 1999, y la última actualización registrada es el 20 de septiembre del 2002. Con lo anterior se contempla, crear una metodología para la administración de proyectos de TI, considerando la metodología del banco, los procesos de TI y las mejores prácticas consideradas en el PMBOK 2004. Objetivos del proyecto: Objetivo General: Elaborar una Metodología para la Administración de Proyectos Informáticos dentro de la Dirección de Análisis de Negocio de la DCTIC, considerando las mejores prácticas propuestas por el PMI en el PMBOK 2004. Objetivos Específicos: a. Analizar el proceso de administración de proyectos de TI que realiza la Dirección de Análisis de Negocio. b. Realizar un análisis comparativo entre las disciplinas de PMI y los procesos de proyectos de TI. c. Definir el flujo de procesos para la administración de proyectos de TI. d. Confeccionar las plantillas para el apoyo a utilizar en la administración de proyectos de TI. e. Validar parcialmente la metodología propuesta. f. Desarrollar un plan preliminar de divulgación de la metodología para hacerla del conocimiento de la Dirección de Análisis de Negocio. Producto principal del proyecto: Documento mediante el cual se realice una propuesta de Metodología para administrar un proyecto informático dentro de la Dirección de de Análisis de

Metodología para la Administración de Proyectos Informáticos

151

Negocio de la DCTIC. Entregables del proyecto: a. Análisis del proceso actual de administración de proyectos de TI y la identificación de áreas de mejora. b. Análisis de las disciplinas de PMI y los procesos de desarrollo de TI. c. Procesos para la administración de proyectos de TI. d. Plantillas a utilizar en la administración de proyectos de TI. e. Validación de la metodología propuesta aplicada parcialmente a un proyecto. f. Plan de preliminar para la divulgación de la metodología propuesta.

Metodología para la Administración de Proyectos Informáticos

Anexo 3 WBS

152

153

Metodología para la Administración de Proyectos Informáticos

Anexo 4 Cronograma Id

Nombre de tarea

Dur ación

Comienzo

Fin

0

Cronograma

204 día s

mi é 18/ 07/07

mi é 06/ 02/08

1

Sem inar io

41 días

m ié 18/07/07

lun 27/08/07

15 días

m ié 18/07/07

m ié 01/08/07

2

Ent regab le 1

Predeces orasNombres de los rec ursos

3

Preparación del Charter del proyec to

3 días

mié 18/07/07

vie 20/07/07

4

Preparación de la Dec laración del Proyec to

3 días

sáb 21/07/07

lun 23/07/07

3

Alejandra Mora

5

Def inición del WBS

1 día

mar 24/07/07

mar 24/07/07

4

Alejandra Mora

6

Des arrollo del Cronogr ama

1 día

mar 24/07/07

mar 24/07/07

4

Alejandra Mora

7

Presentac ión del char ter

0 días

lun 23/07/07

lun 23/07/07

3

Alejandra Mora

8

Entrega del charter, declarac ión, WBS y cronograma

0 días

mié 25/07/07

mié 25/07/07

6

Alejandra Mora

9

Rev isión del charter, declaración, WBS y cronograma

7 días

jue 26/07/07

mié 01/08/07

8

Instructor Miguel

20 días

m ié 25/07/07

lun 13/08/07

10

Ent regab le 2

Alejandra Mora

11

Preparación de la introducción

5 días

mié 25/07/07

dom 29/07/07

6

Alejandra Mora

12

Entrega de la introduc ción

0 días

lun 06/08/07

lun 06/08/07

11

Alejandra Mora

13

Rev isión de la introduc ción

7 días

mar 07/08/07

lun 13/08/07

12

Instructor Miguel

14

17 días

lun 30/07/07

m ié 15/08/07

15

Preparación del marco teóric o

6 días

lun 30/07/07

sáb 04/08/07

11

Alejandra Mora

16

Entrega del mar co teórico

0 días

mié 08/08/07

mié 08/08/07

15

Alejandra Mora

17

Rev isión del marco teórico

7 días

jue 09/08/07

mié 15/08/07

16

Instructor Miguel

16 días

dom 05/08/07

lun 20/08/07

dom 05/08/07

dom 12/08/07

15

Alejandra Mora

18

Ent regab le 3

Ent regab le 4

19

Preparación del marco metodológic o

8 días

20

Entrega del mar co metodológico

0 días

lun 13/08/07

lun 13/08/07

19

Alejandra Mora

21

Rev isión del marco metodológico

7 días

mar 14/08/07

lun 20/08/07

20

Instructor Miguel

14 días

lun 13/08/07

dom 26/08/07

22

Ent regab le 5

23

Preparación del esquema de contenidos, bibliografía y resumen

4 días

lun 13/08/07

jue 16/08/07

19

Alejandra Mora

24

Entrega del esquema de contenidos, bibilografía y res umen

0 días

mié 22/08/07

mié 22/08/07

23

Alejandra Mora

25

Rev isión del esquema de contenidos, bibilograf ía y resumen

4 días

jue 23/08/07

dom 26/08/07

24

Instructor Miguel

26

11 días

vie 17/08/07

lun 27/08/07

27

Docum e nto fin al Preparación del documento f inal

10 días

vie 17/08/07

dom 26/08/07

23

Alejandra Mora

28

Presentac ión del borrador PFG

0 días

lun 27/08/07

lun 27/08/07

27

Alejandra Mora

154

Metodología para la Administración de Proyectos Informáticos Id 29

Nombre de tarea Des arrollo del PFG

30

Coordinac ión tutorial

31

An álisis y reco m en dacio nes d el pro ceso

Dur ación

Comienzo

Fin

93 días

m ar 28/08/07

m ié 28/11/07

7 días

mar 28/08/07

lun 03/09/07

28 días

m ar 28/08/07

lun 24/09/07

Predeces orasNombres de los rec ursos 28

32

Confeccionar cuestionarios

3 días

mar 28/08/07

jue 30/08/07

28

Alejandra Mora

33

Aplicar cuestionarios

5 días

vie 31/08/07

jue 06/09/07

32

Enc uestados

34

Realizar entrevistas

3 días

vie 07/09/07

dom 09/09/07

33

35

Análisis de resultados

5 días

lun 10/09/07

vie 14/09/07

34

Alejandra Mora

36

Análisis de áreas que se utilizan actualmente

5 días

sáb 15/09/07

mié 19/09/07

35

Alejandra Mora

37

Rec omendaciones sobre áreas a desarr ollar

5 días

jue 20/09/07

lun 24/09/07

36

Alejandra Mora

38

An álisis discip linas de PM I y lo s pro cesos de T I

lun 08/10/07

14 días

m ar 25/09/07

39

Análisis de proc esos de TI

3 días

mar 25/09/07

jue 27/09/07

37

Alejandra Mora

40

Análisis disciplinas PMI

3 días

vie 28/09/07

dom 30/09/07

39

Alejandra Mora

41

Realizar entrevistas

3 días

lun 01/10/07

mié 03/10/07

40 41

Alejandra Mora

42 43

Comparac ión de PMI y procesos de desarrollo Pro ceso s

5 días

jue 04/10/07

lun 08/10/07

10 días

m ar 09/10/07

jue 18/10/07

mar 09/10/07

mié 10/10/07

42

Alejandra Mora

44

Análisis de la informac ión

2 días

45

Análisis de documentación

3 días

jue 11/10/07

sáb 13/10/07

44

Alejandra Mora

46

Realizar entrevistas

3 días

dom 14/10/07

mar 16/10/07

45

Alejandra Mora

47

Diagramación de los procesos

2 días

mié 17/10/07

jue 18/10/07

46

Alejandra Mora

10 días

vie 19/10/07

dom 28/10/07

48

Plantillas

49

Analizar plantillas de Metodología del BNCR

2 días

vie 19/10/07

sáb 20/10/07

47

Alejandra Mora

50

Analizar plantillas de TI

3 días

dom 21/10/07

mar 23/10/07

49

Alejandra Mora

51

Confección de nuevas plantillas

3 días

mié 24/10/07

vie 26/10/07

50

Alejandra Mora

52

Realizar entrevistas para validación

2 días

sáb 27/10/07

dom 28/10/07

51

Alejandra Mora

6 d ías

lun 29/10/07

sáb 03/11/07

53

Validació n de la m e todolo gía

54

Seleccionar proyecto

1 día

lun 29/10/07

lun 29/10/07

52

Alejandra Mora

55

Aplicar metodología

5 días

mar 30/10/07

sáb 03/11/07

54

Alejandra Mora

155

Metodología para la Administración de Proyectos Informáticos Id 56

Nombre de tarea Plan de d ivulg ación

Dur ación

Comienzo

Fin

Predeces orasNombres de los rec ursos

5 d ías

dom 04/11/07

jue 08/11/07

57

Def inición de inv olucrados

1 día

dom 04/11/07

dom 04/11/07

53

Alejandra Mora

58

Def inición de tar eas a realizar

2 días

lun 05/11/07

mar 06/11/07

57

Alejandra Mora

59

Calendarización de ac tividades

1 día

mié 07/11/07

mié 07/11/07

58

Alejandra Mora

60

Def inición de recursos necesarios

1 día

jue 08/11/07

jue 08/11/07

59

Alejandra Mora

61

Redacción de c onclus iones

5 días

vie 09/11/07

mar 13/11/07

56

Alejandra Mora

62

Redacción de recomendaciones

5 días

mié 14/11/07

dom 18/11/07

61

Alejandra Mora

63

Me todología f inal

10 días

lun 19/11/07

m ié 28/11/07

Rev isión general

5 días

lun 19/11/07

vie 23/11/07

62

Tutor

65

Cor recciones generales

5 días

sáb 24/11/07

mié 28/11/07

64

Alejandra Mora

66

Apr obación del PFG

0 días

mié 28/11/07

mié 28/11/07

65

Tutor

70 días

jue 29/11/07

m ié 06/02/08 sáb 22/12/07

64

67 68

Cie rre

24 días

jue 29/11/07

69

Coordinac ión revisión

5 días

jue 29/11/07

lun 03/12/07

66

Alejandra Mora

70

Entrega del PFG

1 día

mar 04/12/07

mar 04/12/07

69

Alejandra Mora

71

Revisión

18 días

mié 05/12/07

sáb 22/12/07

70

Lec tores

72

Cor recciones al PFG

Rev isión

30 días

dom 23/12/07

lun 21/01/08

68

Alejandra Mora

73

Sus tentación

m ié 06/02/08

16 días

m ar 22/01/08

74

Coordinac ión

10 días

mar 22/01/08

jue 31/01/08

72

Alejandra Mora

75

Confeccionar pr esentación

15 días

mar 22/01/08

mar 05/02/08

72

Alejandra Mora

76

Presentac ión

1 día

mié 06/02/08

mié 06/02/08

75

Alejandra Mora

Metodología para la Administración de Proyectos Informáticos

156

Anexo 5 Resultado de las entrevistas

Pareto de los problemas a los que se enfrenta DANTI Personal responde al jefe de línea Disponibilidad de los recursos

12,0% 10,0%

Estandarización

8,0%

Definición del alcance

6,0%

Personal sobre cargado Recursos no comprometidos

4,0%

Poca Planificación

2,0%

Recursos sin experiencia

0,0%

Responsabilidad de cada miembro Madurez en el tema

Problemas

Metodología para la Administración de Proyectos Informáticos

Anexo 6 Resultado de los cuestionarios

157

Metodología para la Administración de Proyectos Informáticos

158

Metodología para la Administración de Proyectos Informáticos

159

Metodología para la Administración de Proyectos Informáticos

160

Metodología para la Administración de Proyectos Informáticos

161

Metodología para la Administración de Proyectos Informáticos

162

Metodología para la Administración de Proyectos Informáticos

163

Metodología para la Administración de Proyectos Informáticos

164

Metodología para la Administración de Proyectos Informáticos

165

Metodología para la Administración de Proyectos Informáticos

166

Metodología para la Administración de Proyectos Informáticos

167

168

Metodología para la Administración de Proyectos Informáticos

Anexo 7 Plantillas Metodología BNCR Las siguientes plantillas son tomadas de la Metodología de Administración de Proyectos del Banco Nacional, la cual se encuentra publicada en la Intranet.

AP-001-2002 “IDENTIFICACION DEL PROYECTO” Número y Nombre del Proyecto: Descripción de la situación actual: Tipo de Problema o Necesidad por Justificación: resolver: 1. 2. 3. 4. Otros... Descripción general de la Solución propuesta: Definición de Objetivos Unidad de Medida 1. 2. 3. 4. Otros... Objetivo Institucional Relacionado con el Proyecto Impacto en el Banco Nacional Oficinas Relacionadas Servicios o relacionados

Estimación preliminar de los Recursos: Presupuesto Inversiones: Recursos humanos: Unidad Organizativa y nombre del solicitante: Nombre: Director Corporativo, Regional o Gerente de Sociedad Anónima

Sistemas Documentos relacionados

Tiempo: Firma: Firma: VB. Director Corporativo, Regional o Gerente de Sociedad Anónima

169

Metodología para la Administración de Proyectos Informáticos

AP-002-2002: VISIÓN Y ALCANCE DEL PROYECTO Número y Nombre del Proyecto: Visión del Proyecto: Alcances del Proyecto: Requerimientos a nivel macro: Requerimientos de Software

Ver

Estándar

BNCR-21

Especificación

de

Factibilidad: Técnica: Operacional: Económica Valor Actual (V.A.N.):

Neto

Tasa Interna de Rend. % (T.I.R.):

¢

Factores Críticos de Éxito: Recursos Técnicos Recursos Financieros

Recursos Recursos Humanos Administrativos

1. 1. 1. 2. 2. 2. 3. 3. 3. Identificación de Roles y Responsabilidades: Rol

1. 2. 3.

Otros 1. 2. 3.

Nombre Dedicación Localización del Semanal recurso

Administrador del Producto: Director del Proyecto Equipo Desarrollador Equipo Capacitador Equipo de pruebas: Equipo de Logística: Perfiles de los Usuarios: Usuario Descripción de Dedicación Funciones Semanal

Localización

Análisis Preliminar de Riesgos: Metodología para la Administración de Riesgos No. Clase Actividad Riesgo Impacto Probabilidad Categoría 1.

Metodología para la Administración de Proyectos Informáticos

170

2. Otros Consideraciones y Recomendaciones: Cronograma Preliminar (Agregar en anexo Project 2000): Nombre y Firma de los responsables de la elaboración de la Justificación: Nombre del Director del Nombre: Proyecto: Firma: Firma del Director del Proyecto: Nombre: Nombre: Firma: Firma: Nombre: Nombre: Firma: Firma: Aprobación del Documento de Justificación: Nombre: Firma: Director Corporativo, Regional, Director Corporativo, Regional, Gerente Gerente de Sociedad Anónima Sociedad Anónima Es designado como Patrocinador del Proyecto

de

Metodología para la Administración de Proyectos Informáticos

171

AP-003-2002 “MINUTAS” MINUTA No.XX Nombre del Proyecto: Fecha:

Lugar:

PRESENTES: Nombres y apellidos

nombre de la dependencia a la cual pertenece cada participante

AUSENTES: Nombres y apellidos

nombre de la dependencia a la cual pertenece cada participante

TEMAS TRATADOS: NOMBRE DEL TEMA En este espacio se debe indicar los puntos tratados en la sesión de trabajo

RESPONSABLE Especificar el nombre de la persona quien expuso la idea o comentario

ACUERDOS TOMADOS: ACUERDO: En este espacio se debe especificar el acuerdo tomado con su respectiva numeración

RESPONSABLE: FECHA: Se refiere a la persona Se especifica la fecha o unidad encargada de límite para lograr la realizar la tarea o actividad o tarea acordada. actividades para cumplir con el acuerdo tomado. APROBACIÓN DE ACUERDOS: Como resultado de la sesión de trabajo realizada el o los acuerdos tomados en el presente documento son avalados en su totalidad e integridad por los abajo firmantes (personas participantes de la sesión de trabajo): Nombre: Nombre: Nombre: Nombre: Nombre: Nombre: Firma: Firma: Firma: Firma: Firma: Firma:

172

Metodología para la Administración de Proyectos Informáticos

AP-004-2002 “INFORME DE AVANCE DEL PROYECTO” Nombre del Proyecto: Fecha:

Unidad organizativa:

PERIODO QUE CUBRE: LISTA DE TAREAS CONCLUIDAS EN EL PERIODO REPORTADO LISTA DE TAREAS EN PROCESO (RESPONSABLE Y % AVANCE)

AL

MOMENTO

DEL

INFORME

LISTA DE TAREAS RETRASADAS Y SUS JUSTIFICACIONES LISTA DE TAREAS ELIMINADAS O SUSPENDIDAS Y SU JUSTIFICACIÓN LISTA DE TAREAS A INICIAR EN EL PRÓXIMO PERIODO DETALLE DE SITUACIONES PRESENTADAS FIRMA DEL DIRECTOR DEL PROYECTO

Metodología para la Administración de Proyectos Informáticos

173

AP-005-2002 “SOLICITUD CONTROL DE CAMBIOS” Nombre del Proyecto: Fecha:

Nombre del Solicitante:

NOMBRE DE LA ACTIVIDAD / TAREA / OTRO: DESCRIPCIÓN DE LA SOLICITUD: ANÁLISIS DE IMPACTO: Se debe realizar un estudio de impacto sobre los siguientes aspectos CRONOGRAMA / TIEMPO: PRODUCTOS O SERVICIOS: RECURSOS: PRESUPUESTO: DE NO REALIZARSE EL CAMBIO RECOMENDACIÓN: APROBACIÓN DE LA SOLICITUD: SESIÓN NUMERO: FECHA:

NOMBRE Y FIRMA:

Metodología para la Administración de Proyectos Informáticos

174

AP-009-2002 “LECCIONES APRENDIDAS” Nombre del proyecto: Fecha: Nombre del Director: ACCIÓN ADMINISTRATIVA SITUACIÓN PRESENTADA REALIZADA

Metodología para la Administración de Proyectos Informáticos

175

AP-007-2002 “INFORME DE FINALIZACIÓN POR CANCELACIÓN” Fecha del informe Fecha Logros Alcanzados

Problemas Enfrentados

Justificación de la Cancelación

Nombre y Firma del Director del Proyecto

Metodología para la Administración de Proyectos Informáticos

176

Anexo 8 Formato de los documentos



Versión <1.0>

177

Metodología para la Administración de Proyectos Informáticos

Bitácora de acciones sobre el documento Registro de generación y revisión

Fecha

Versión

<x.x>

Revisión <detalles>

Responsable <nombre>

Registro de aprobación

Fecha

Versión

<x.x>

Revisión <detalles>

Responsable

Responsables de acciones sobre el documento

Unidad/Dirección

Funcionario

Acción

Firma

Generar Revisar Aprobar Custodiar Control de cambios Cancelar Distribuir

Nota: Versión (X.y): la versión de un documento cambia si existe ya una aprobación previa de un documento anterior. Release (x.Y): el release cambia (aumenta de forma secuencial empezando en cero) conforme una revisión obligue a realizar cambios al documento.

Metodología para la Administración de Proyectos Informáticos

Tabla de Contenidos

178

Metodología para la Administración de Proyectos Informáticos

179

1. Introducción 1.1 Propósito [Detallar el propósito del documento]

1.2 Definiciones, Siglas y Abreviaciones [Definición de todos los términos, siglas y abreviaciones requeridas para interpretar en forma correcta el documento. Esta información puede ser proveída haciendo referencia al Glosario del proyecto.]

1.3 Referencias [Esta subsección provee una lista completa de todos los documentos referenciados o consulados para desarrollar el documento. Identifique cada documento por título, versión (si aplica), fecha, nombre de quién lo crea o publica.]

2. Sección 1 3. Sección 2 n. Sección n

Metodología para la Administración de Proyectos Informáticos

180

Anexo 9 Plantillas de TI Las siguientes plantillas son tomadas del sitio de documentación de la Dirección de Análisis de Negocio.

Especificación de Caso de Uso: Descripción breve [La descripción brevemente transmite el rol y el objetivo del caso de uso. Un solo párrafo bastará para esta descripción.]

Pre-condiciones [Una pre-condición de un caso de uso es el estado del sistema que debe estar presente antes de que un caso de uso sea realizado.]

< Una Pre-condición >

Flujo de Eventos Flujo Básico [Este caso de uso comienza cuando el actor hace algo. Un actor siempre inicia casos de uso. El caso de uso describe lo que el actor hace y lo que el sistema hace en respuesta. Esto es descrito en forma de un diálogo entre el actor y el sistema. El caso de uso describe lo que pasa dentro del sistema, pero no cómo o por qué. Si la información es cambiada, se específica lo que ha pasado hacia adelante y hacia atrás. Por ejemplo, esto no es muy ilustrativo para decir que el actor ingresa información del cliente. Es mejor decir que el actor ingresa el nombre y dirección del cliente. Un Glosario de Términos es a menudo útil para mantener la complejidad del caso de uso manejable – se puede querer definir cosas como la información del cliente allí para impedir al caso de uso ahogarse en detalles. Alternativas simples pueden ser presentadas dentro del texto del caso de uso. Si esto sólo toma unas pocas sentencias para describir que pasa cuando hay una alternativa, hágalo directamente dentro de la sección de Flujo de Eventos. Si el flujo alternativo es más complejo, use una sección separada para describirlo. Por ejemplo, una subdivisión de Flujo Alternativo explica como describir alternativas más complejas. Una imagen a veces dice mil palabras. Si esto mejora la claridad, el sentido libre de pegar las imágenes gráficas de interfaces de usuario, flujos de proceso u otras figuras en el caso de uso. Si un diagrama de flujo es útil para presentar un proceso de decisión complejo, cueste lo que cueste, úselo. Un diagrama de transición de estados a menudo clarifica el comportamiento de un sistema mejor que páginas sobre las páginas de texto. Recuerde que su objetivo es de clarificar, no obstaculizarlo.]

Metodología para la Administración de Proyectos Informáticos

181

Flujos Alternos < Primer Flujo Alterno > [Alternativas más complejas son descritas en una sección separada, referenciada en la subdivisión de Flujo Básico de la sección Flujo de Eventos. Piense en subdivisiones de Flujos Alternos como el comportamiento alternativo -- cada flujo alternativo representa el comportamiento alternativo por lo general debido a las excepciones que ocurren en el flujo principal. Ellos pueden ser necesario para describir los eventos asociados con el comportamiento alternativo. Cuando un flujo alternativo termina, los eventos del flujo principal de eventos son resumidos a no ser que no sea declarado.]

[Los flujos alternativos pueden, ser dividiso en subdivisiones si mejoran la claridad.]

< Segundo Flujo Alterno > [Puede haber, y muy probablemente habrá, un número de flujos alternativos en un caso de uso. Mantenga cada flujo alternativo separado para mejorar la claridad. La utilización de flujos alternativos mejora la legibilidad del caso de uso, así como impide que los casos de uso sean descompuestos en jerarquías de casos de uso. Tenga presente que los casos de uso son solo descripciones textuales, y su objetivo principal es de documentar el comportamiento de un sistema de un modo claro, conciso, y comprensible.]

Requerimientos Especiales [Un requerimiento especial es típicamente un requerimiento no funcional que es específico a un caso de uso, pero no es fácilmente o naturalmente especificado en el texto del flujo de eventos del caso de uso. Los ejemplos de requerimientos especiales incluyen requerimientos legales y regulatorios, normas de aplicación, y los atributos de calidad del sistema para ser construído incluyendo la utilidad, la confiabilidad, el funcionamiento o requerimientos de soporte. Además, otros requirimientos – tales como sistemas operativos y ambientales, requerimientos de compatibilidad, y restricciones de diseño .. deben ser capturados en esta sección.]

< Primer Requerimiento Especial >

Post-condiciones [Una post-condición de un caso de uso es una lista de posibles estados en los que el sistema puede estar inmediatamente después de que un caso de uso ha finalizado.]



Puntos de Extensión [Puntos de extensión del caso de uso.]

[Definición de la localización del punto de extensión en el flujo de eventos.]

Metodología para la Administración de Proyectos Informáticos

182

Especificaciones Suplementarias Introducción [La introducción de las Especificaciones Suplementarias provee una descripción del documento completo. Este incluye el propósito, alcance, definiones, acrónimos, abreviaciones, referencias y un vistaso de estas Especificaciones Suplementarias. Las Especificaciones Suplementarias captura los Requerimientos del sistema que no capturados en los casos de uso del modelo de casos de uso. Tales requerimientos incluyen: Requerimientos legales y regulatorios, incluyendo la aplicaciónde estándares. Atributos de calidad del sistema a ser construido, incluyendo requerimientos de usabilidad, confibilidad, ejecución y soporte. Otros requerimientos tales como ambientes y sistema operatives, Requerimientos de compatibilidad y restricciones de diseño.]

Propósito u objetivos [Se describen los objetivos de las Especificaciones Suplementarias y se definen claramente sus lectores, es decir, los usuarios del mismo.]

Alcance [En este punto se deben identificar los productos de software a desarrollar con un nombre, así como el alcance de los mismos en términos de funcionalidad general. Para ello, se deben describir los objetivos generales del software y los beneficios que se obtendrán de su implementación..]

Definiciones, acrónimos, y abreviaciones [Se deben definir todos los términos, acrónimos, y abreviaciones que se utilicen en el resto del documento. Esta información puede ser proporcionada por referencias al Glosario del proyecto.]

Referencias [Se deben enumerar las referencias completas (e.g., título, autor, fecha, editorial, etc.) de todos los documentos mencionados en las Especificaciones Suplementarias, así como cualquier otra documentación complementaria que esté relacionada con el mismo.]

Organización del documento [Se describe el contenido del resto de las Especificaciones Suplementarias y se explica cómo está organizado el resto del documento.]

Usabilidad [Esta sección debe incluir todos aquellos Requerimientos que afectan la usabilidad. Por ejemplo: especiicar el tiempo de capacitación requerido para que un usuario normal y un usuario experto lleguen a ser productivos en una operación particular especificar tiempos requeridos para tareas típicas]



Metodología para la Administración de Proyectos Informáticos

183

La descripción del requirimiento.

Confiabilidad [Requerimientos para confiabilidad del sistema deben ser especificados aquí. Considerando aspectos como los que siguen: Disponibilidad – especificar el porcentaje de tiempo disponible ( xx.xx%), horas de uso, operaciones en modo degradado, etc. (MTBF) Cantidad de Tiempo entre Fallas – esto es usualmente especificado en horas, pero también puede ser especificado en términos de días, meses o años. (MTTR) Cantidad de Tiempo para Reparar – cuanto tiempo puede el sistema estar fuera de operación después de la falla? Exactitud – especificar precision (resolución) y exactitud (por medio de algún estándar conocido). Máximo de errors o tasa de defectos – usualmente expresado en terminos de errores/KLOC (miles de líneas de código), ó errores/puntos de función. Errors o tasa de defectos – categorizzdos en terminus de error menor, significante, y crítico: los Requerimientos deben definer que se entiende por error ‘crítico’; por ejemplo, pérdida de datos completa ó incapacidad de usar ciertas partes de la funcionalidad del sistema.]

[La descripción del requerimiento.]

Rendimiento [Se deben especificar los requerimientos cuantitativos relacionados con el funcionamiento del software. Éstos pueden ser de dos tipos: Estáticos (o de capacidad): aspectos como número de terminales o usuarios, número de transacciones por unidad de tiempo, número de usuarios simultáneos que debe soportar, y número de archivos y registros a ser manejados. Dinámicos: se refiere a aspectos dinámicos del funcionamiento del software. Por ejemplo, el número de transacciones a ser procesadas en cierto período de tiempo en condiciones normales o situaciones de sobrecarga del software. Estos requerimientos deben ser dados en términos medibles, por ejemplo, “el 98% del tiempo las transacciones de X tipo deberán ser procesadas en menos de 0,5 segundos”.]

[La descripción del requerimiento.]

Soporte [Esta sección indica cualquier requerimiento que permita el soporte o mantenimiento del sistema a ser construido, incluyendo estándares de codificación convenciones de nombres, librería de clases, utilidades de mantenimiento.]

Metodología para la Administración de Proyectos Informáticos

184

[La descripción del requerimiento.]

Restricciones de Diseño [Se debe especificar cualquier tipo de restricción de diseño. Este tipo de restricciones generalmente se presentan por el uso de estándares o limitaciones de hardware. Cumplimiento de estándares Se deben especificar los estándares que se deben utilizar en el desarrollo del proyecto (e.g., estándares de diseño de bases de datos, estándares de interfaces de usuario, etc.) Limitaciones de hardware Se deben especificar si existe algún tipo de restricción o requerimiento sobre la plataforma de hardware en la que debe funcionar el software.]

[La descripción del requerimiento.]

Documentación del Usuario en línea y Requerimientos de Ayuda del Sistema [Describe los Requerimientos para documentación del usuario en-línea, sistemas de ayuda, notas acerca de la ayuda, entre otras.]

Interfaces [Esta sección define las interfaces que deben ser soportadas por la aplicación. ]

Interfaces de Usuario [Debe especificar puntos como características de soporte para cada interfaz humana (e.g., estándares de formatos de pantalla, estándares de formatos de reportes y menúes, tiempos relativos de entradas y salidas, formatos de los mensajes de error, etc.), y cualquier optimización de interfaces con las personas que deben utilizar el software. Un ejemplo puede ser qué tan largos deben ser tales mensajes.]

Interfaces de Hardware [Especificación de características de las interfaces de hardware que se van a tener. Cubre por ejemplo, qué dispositivos serán soportados, cómo, y los protocolos a utilizar.]

Metodología para la Administración de Proyectos Informáticos

185

Interfaces de Software [El uso de otros productos de software requeridos e interfaces con el software a desarrollar. Para cada producto de software requerido se debe especificar el nombre, número de versión, y origen. Cada interfaz que se defina deberá tener especificado el propósito del enlace y la interfaz en términos de mensajes, y formatos. No es necesario documentar detallado pero sí se deberá dar una referencia al documento que lo hace, si fuera necesario hacerlo.]

Interfaces de Comunicación [Describe cualquier interfaz de Comunicación hacia otros sistemas o dispositivos tales como Redes de Area Local, dispositivos remotos, y demás.]

Estándares Aplicables [Esta sección describe por referencias cualquier estándar applicable y las secciones específicas de cualquier estándar que appliqué al sistema que está siendo descrito. Por ejemplo, esto podría incluir estándares legales, de calidad y regulatorios, estándares de la industria para usabilidad, interoperabilidad, internacionalización, sistemas operativos y demás.]