Metodología para la administración de proyectos ...

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

i

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

ii

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.

iii

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.

iv

“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

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

v

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 MARCO TEORICO ........................................................................ 5

2.1 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 MARCO METODOLOGICO......................................................... 30

3.1 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


vi

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 DESARROLLO............................................................................ 38

4.1 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


vii

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


viii

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


ix

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


x

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

DCTIC Dirección 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

OOSE Siglas en inglés de Software para Ingeniería Orientada a Objetos

(Software Object- Oriented Software Engineering)

PMBOK Guía de los Fundamentos de la Dirección de Proyectos del PMI


xi

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)


xii

RESUMEN EJECUTIVO


xiii

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


xiv

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.

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

CAPITULO 1 INTRODUCCION


1.1 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.


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.


1.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.


CAPITULO 2 MARCO TEORICO


2.1 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


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)


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)


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)


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


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.


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)


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).


2.2 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


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)


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.


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.


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.


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


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.


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.


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


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.


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


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.


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.


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


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.


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.


CAPITULO 3 MARCO

METODOLOGICO


3.1 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.


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


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.


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


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.


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.


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.


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


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.


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.


CAPITULO 4 DESARROLLO


4.1 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


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.


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


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, pruebas internas de la aplicación y

documentación técnica.


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.


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.


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.


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


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


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)


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.


4.1.5 Comparación de PMI y procesos de desarrollo

Cuadro 2. Documentos utilizados en DCTIC

Administración Proyectos

Sistemas ' Inicialización Planificación Ejecución

Seguimiento y Control

Cierre

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

Conceptualización 1. Aceptación del proyecto

1.Plan del proyecto 2. Lista de Riesgos

Elaboración

1. Modelo de casos de uso 2. Especificación suplementaria 3. Casos de uso 4. Documento de arquitectura 5. Documento de diseño

1. Minutas 2. Informes de avance

Construcción 1. Plan de pruebas 1. Casos de uso

funcionales 1. Minutas 2. Informes de avance

Transición 1. Casos de

prueba 1. Minutas 2. Informes de avance

Cierre 1.Nota de

cierre


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.


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


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 semanal y localización para los roles:

administrador del producto, director del proyecto, equipo

desarrollador, equipo capacitador, equipo de pruebas y equipo de

logística, perfil de los usuarios, análisis preliminar de riesgos,


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


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.


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.


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


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).


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


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.


Figura 17. Diagrama proceso de recepción


Figura 18. Diagrama del proceso de Conceptualización


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


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


Figura 21. Diagrama del proceso de Elaboración


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


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


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


Figura 25. Diagrama de cierre


Figura 26. Diagrama de control de cambios


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.


Cuadro 3. Herramientas y su funcionalidad

Código Nombre Funcionalidad Acción Categoría Tipo

AP-01-2002 Identificación del

Proyecto

Generado por el solicitante de la necesidad

donde se define la idea del proyecto para su

aprobación.

Recibir Corto,

Largo

Negocio,

Infraestructura

AP-02-2002 Visión y alcance Generado por el director, presenta una visión

inicial del proyecto y el alcance definido.

Recibir Corto,

Largo

Negocio,

Infraestructura

AP-03-2002 Minutas Formulario para documentar acuerdos y

pendientes de las reuniones.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-01 Casos de uso Documento de especificación de los

requerimientos funcionales del sistema.

Generar Corto,

Largo

Negocio

DANTI-02 Especificación

suplementaria

Documento de especificación de requerimientos

no funcionales (rendimiento, tiempos de

respuesta, presentación) del sistema.

Generar Largo Negocio

DANTI-03 Modelo de casos de uso Diagrama de los requerimientos funcionales del

producto.

Generar Largo Negocio

DANTI-04 Lista de insumos Aspectos que deben ser presentados por el

director del proyecto, para la DCTIC son de suma

importancia.

Recibir,

Generar

Corto,

Largo

Negocio,

Infraestructura

DANTI-05 Acta de inicio Aprueba el proyecto dentro de la DCTIC y asigna

un ejecutivo.

Generar Corto,

Largo

Negocio,

Infraestructura



DANTI-06 Visión técnica Guía para identificar la visión desde el punto de

vista técnico de la solución.

Generar Largo Negocio,

Infraestructura

DANTI-07 Modelación del negocio Guía para modelar las funcionalidades desde la

perspectiva del negocio.


Infraestructura

DANTI-08 Plan del proyecto Guía para el desarrollo del plan de proyecto,

formato y aspectos mínimos a considerar.


Infraestructura

DANTI-09 Cronograma Archivo para el control de tareas, duraciones y

responsables, se debe mantener en el Project

Central Server.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-10 Recursos del proyecto Formulario con los recursos que participaran de

las distintas dependencias, la disponibilidad y en

la etapa en que participaran.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-11 Matriz de

comunicaciones

Matriz donde se detallen los entregables e

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

enviar y el medio.


Infraestructura

DANTI-12 Lista de Riesgos Plantilla para listar, detallar, clasificar los riesgos

del proyecto.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-13 Informes de avance

semanal

Plantilla para la preparación de informes

semanales.


Infraestructura

DANTI-14 Informes de avance

mensual

Plantilla para la preparación de informes

mensuales (consolidado).

Generar Corto,

Largo

Negocio,

Infraestructura



DANTI-15 Aceptación del producto Acta donde el cliente da por aceptado el producto

y con ello el cierre del proyecto.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-16 Nota de cierre Acta con el resumen del resultado del proyecto y

la liberación de los recursos.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-17 Recepción de

entregables

Formulario para la recepción de los entregables

del proyecto.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-18 Control de cambios Formulario para documentar las solicitudes de

cambio, quedando evidencia de su aprobación o

rechazo y el impacto en el proyecto.

Generar Corto,

Largo

Negocio,

Infraestructura

DANTI-19 Glosario Formulario con los términos propios del negocio

o técnicos que deben ser del conocimiento del

equipo del proyecto.


Infraestructura

DANTI-20 Lecciones aprendidas Plantilla para documentar las lecciones

aprendidas durante el proyecto

Generar Corto,

Largo

Negocio,

Infraestructura


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 ' Inicialización Planificación Ejecución

Seguimiento y Control

Cierre

Recepción

1. Identificación del Proyecto 2. Visión y alcance 3. Lista de insumos 4. Acta de inicio

Conceptualización

1. Visión técnica 2. Modelación del negocio

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

Elaboración

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

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


5. Glosario 6. Lecciones aprendidas 7. Recepción de entregables

Construcción



Transición



Cierre

1. Lecciones aprendidas 4. Recepción de entregables


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


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.



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”.



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 relacionados

[Mencionar los casos de uso relacionados al actor]

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] Actores relacionados [Identificar los actores que interactúan con

el caso de uso] Casos de uso relacionados [Identificar los 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]


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 director del proyecto]

Nombre del Ejecutivo de Tecnología:

[Nombre del Ejecutivo asignado] Detalle del proyecto


Definición del Grupo de trabajo [Para los siguientes roles Indicar el nombre de la persona y la dependencia a la que pertenece]

Rol Nombre Dependencia Patrocinador del Proyecto Director del Proyecto Dueño del Producto Ingeniero de Procesos

[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


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]



Fecha de inicio: [fecha de inicio del proyecto]

Fecha de finalización: [fecha de finalización del proyecto]

Nombre del Director de Proyecto: [Nombre del director del proyecto]

Nombre del Ejecutivo de Tecnología: [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 recepción del documento aprobado]

AP-02-2002: Visión y alcance [Fecha de recepción del documento aprobado]

Solicitud de ejecutivo de tecnología [Fecha de recepción del documento aprobado]

DANTI-04: Lista de insumos [Fecha de recepción del documento aprobado]

Aprobaciones

Nombre Firma Fecha [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

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.



Fase del proyecto a utilizar: Conceptualización del proyecto.

Cuadro 8. DANTI-06 Visión técnica

1 Posicionamiento

1.1 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]

El problema de [describir el problema]

Afecta [el solicitante afectado por el problema]

El impacto es [cuál es el impacto del problema]

Una solución exitosa es

[listar algunos beneficios claves de una solución exitosa]

Para [cliente interno/externo al cual está 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.]


Nombre Descripción

[Nombre el tipo de usuario] [Describa brevemente lo que ellos representan con respecto al sistema.]

2.3 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]


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.


Fase del proyecto a utilizar: Conceptualización del proyecto

Cuadro 9. DANTI-07 Modelación del negocio


[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]


5 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.



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 Plan de Gestión del Proyecto 2.1 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]


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]

Nombre del proyecto

Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes n

Conceptualización

Elaboración

Construcción

Transición

Cierre

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


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 entregable]

[Descripción del entregable]

[Tareas para 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

0

200

400

600

800

1000

1200

1400

Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7Meses

Horas

Trabajo


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.]

Id Nombre Comienzo Fin Costo

estimado

[Identificación de la tarea]

[Nombre de la tarea]

[Comienzo de la tarea establecido en el cronograma]

[Fin de la tarea establecido en el cronograma]

[Costo estimado]

2.3 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 Funciones [Rol en el proyecto] [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


Ejemplo:

WBS Tareas Mie

mb

ro 1

Mie

mb

ro 2

Mie

mb

ro 3

Mie

mb

ro 4

Mie

mb

ro n

1.1 Entrega 1 1.1.1 Actividad 1 1.1.1.1 Tarea 1 1.1.1.2 Tarea 2 1.1.1.n Tarea n 1.1.n Actividad n 1.1.n.1 Tarea 1 1.1.n.2 Tarea 2 1.1.n.m 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.]


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% Bajo Bajo Bajo Medio Medio 11-40% Bajo Bajo Medio Medio Alto 41-60% Bajo Medio Medio Medio Alto 61-90% Medio Medio Medio Medio Alto 91-100% 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


al menos la siguiente información]

ID Riesgo Probabilidad Impacto Categoría [ID del riesgo]

[Descripción del riesgo]

[Probabilidad de ocurrencia de 1 a 100%]

[Impacto, tabla 1]

[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.]

2.5 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.]

Riesgo Estra-

tegia

Acción Contin-

gencia

Presupuesto Respon-

sable

Disparador

[ID del riesgo]

[Estra-tegia a utilizar]

[Acción a realizar]

[Medida de contin-gencia]

[Presupuesto requerido para desarrollar la estrategia, en tiempo y costo]

{Persona responsable de su administración}

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


Nombre de Contratación

Descripción de la

contratación

Costo Estimado

Fecha límite contratación

Posibles Proveedores

Responsable

[Identificador para la contratación]

[Descripción de la contratación]

[Costo estimado]

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

[Lista de proveedores preseleccionados]

[Responsable 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.




Cuadro 11. DANTI-09 Cronograma Id Nombre de tarea Duración Predecesoras Nombres de los recursos

0 DANTI-09 Cronograma Base 129,5 días?1 Fase de Conce ptualización 27 d ías?

2 Creación de sitio 30 mins? Ejecutivo de Tecnología

3 Publicación de documentos 30 mins? 2 Ejecutivo de Tecnología

4 Vis ión Té cnica 5 d ías?

5 Rev isar documentación 1 día? 3 Ejecutivo de Tecnología;Direc tor delProyecto;Usuario

6 Creación DANTI-06 3 días? 5 Ejecutivo de Tecnología

7 Rev isión 1 día? 6 Director del Proyecto

8 Aprobación 0 días? 7 Director del Proyecto

9 Modelación de l Negocio 6 d ías?

10 Analizar entorno 1 día? 6 Ejecutivo de Tecnología;Usuario

11 Creación DANTI-07 3 días? 10 Ejecutivo de Tecnología

12 Rev isión 2 días? 11 Usuario

13 Aprobación 0 días? 12 Usuario

14 Plan de Proyecto 13,13 días?

15 Creación del DA NTI-08 5 días? 13 Ejecutivo de Tecnología

16 Confeccc ionar DANTI-09 Cronograma preliminar 1 día? 15 Ejecutivo de Tecnología

17 Confeccionar DA NTI-11 Matr iz de Comunicación 1 hora? 16 Ejecutivo de Tecnología

18 Confeccc ionar DANTI-12 Lis ta de Riesgos 2 días? 17 Ejecutivo de Tecnología

19 Rev isión 5 días? 18 Jefes TI

20 Aprobación 0 días? 19 Jefes TI

21 Lis ta de Recursos 3,25 días ?

22 Def inir recursos para el proyecto 3 días? 20 Jefes TI

23 Confeccionar DA NTI-10 2 horas? 22 Ejecutivo de Tecnología

24 Glosario Inicial 0,5 días?

25 Confección DANTI-19 0,5 días? 18 Ejecutivo de Tecnología

26 Lecciones aprendidas 0,5 días?

27 Confección DANTI-20 0,5 días? 23 Ejecutivo de Tecnología

28 Fase de Elaboración 35 d ías?

29 Modelar casos de uso 4 d ías?

30 Analizar Necesidades 0,5 días? 20 Ejecutivo de Tecnología

31 Creación del diagrama 0,5 días? 30 Ejecutivo de Tecnología

32 Confeccionar DA NTI-03 1 día? 31 Ejecutivo de Tecnología

33 Rev isión 2 días? 32 Usuario


35 Detallar neces idade s 19 d ías?

36 Priorizar requerimientos 1 día? 34 Usuario;Ejecutivo de Tecnología

37 DANTI -01 Confección de casos de uso 10 días? 36 Usuario

38 Rev isión 5 días? 37 Ejecutivo de Tecnología


40 Detallar necesidades no func ionales 2 días? 36 Usuario

41 DANTI-02 Espec ificaciones suplementarias 2 días? 40 Ejecutivo de Tecnología

42 Confección de presentación a TI 1 día? 41;39 Ejecutivo de Tecnología

43 Presentac ión 1 día? 42 Ejecutivo de Tecnología

44 Entega de documentac ión 1 día? 43 Ejecutivo de Tecnología

45 Actualizar DANTI-19 Glosario 1 hora? 35 Ejecutivo de Tecnología

46 Arquitectura 7 d ías?

47 Analisis de las necesidades 2 días? 44 Arquitecto

48 Documento de A rquitectura 5 días? 47 Arquitecto

49 Entrega del documento de Arquitec tura 0 días? 48 Arquitecto

50 Realizar estimac iones 3 días? 46;44 Ingeniero

51 Actualizac ión del cronograma 1 día? 50 Ejecutivo de Tecnología

52 Entrega de tiempos para el director 1 día? 51 Ejecutivo de Tecnología


Id Nombre de tarea Duración Predecesoras Nombres de los recursos

53 Riesgos 4 d ías?

54 Analizar posibles riesgos 2 días? 49 Arquitecto;Ingeniero

55 Entregar r iesgos identif icados 1 día? 54 Arquitecto;Ingeniero

56 Actualizar DANTI-12 Lista de Riesgos 1 día? 55 Ejecutivo de Tecnología

57 Lecciones aprendidas 0,25 días ?

58 Confección DANTI-20 2 horas? 56 Ejecutivo de Tecnología

59 Fase de Construcción 39,25 días?

60 Análisis y diseño 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 Entregar documento de Análisis y Diseño 0 días? 62 Ingeniero

64 Des arrollo de la solución 31 d ías?

65 I Ite ración 23 d ías?

66 Desarrollo 20 días? 63 Ingeniero

67 Pruebas internas 3 días? 66 Ingeniero

68 II It eración 23 d ías?



71 III Iteración 23 d ías?



74 Confeccionar lis ta de materiales 3 días? 65;68;71 Ingeniero

75 Entregar lista de mater iales 0 días? 74 Ingeniero

76 Manual Técnico 5 días 75 Ingeniero



79 Fase de Trans ición 76,25 días?

80 Planificación de las pruebas 15 d ías?

81 Plan de Pruebas 5 días? 63 Implantador

82 Casos de prueba 10 días? 63 Usuario

83 Rev isión 5 días? 82 Implantador


85 Preparar ambientes de pruebas 5 días? 49 Implantador

86 Pruebas de usuario 15 d ías?

87 Ejecutar pruebas I Iteración 5 días? 65;85 Usuario

88 Ejecutar pruebas II Iteración 5 días? 68;85 Usuario

89 Ejecutar pruebas III Iteración 5 días? 71;85 Usuario

90 Pruebas Integrales 10 días? 87;88;89 Usuario

91 Manual de Usuario 5 días? 90 Usuario

92 Capacitación 9 d ías?

93 Elaboración Plan de Capacitación 3 días? 91 Usuario;Ejecutivo de Tecnología

94 Aprobación del Plan de Capacitación 1 día? 93 Director del Proyecto

95 Realizar Capacitación 5 días? 94 Usuario;Implantador;Ejecutivo de Tecnología

96 Pase a Producción 27 d ías?

97 Planif icar pase 5 días? 90 Implantador;Ejecutivo de Tecnología

98 Realizar pase a producción 5 días? 97 Implantador

99 Elaboración Plan Piloto 3 días? 90 Director del Proyecto

100 Ejecutar Plan Piloto 15 días? 99;98 Usuario

101 Reporte de resultados Plan Piloto 2 días? 100 Usuario

102 Aprobación Plan Piloto 0 días? 101 Usuario




Id Nombre de tarea Duración Predecesoras Nombres de los recursos

105 Cie rre de l Proyecto TI 17,13 días?

106 Aceptación 0,13 días ?

107 DANTI-15 Nota de aceptación 1 hora? 102 Usuario

108 Entrega de Nota 0 días? 107 Usuario

109 Pre sentación del producto 2 d ías?

110 Preparar Presentación 1 día? 98 Ejecutivo de Tecnología

111 Presentac ión 1 día? 110 Ejecutivo de Tecnología

112 Nota de cierre 3 d ías?

113 Confeccionar DA NTI-16 1 día? 111 Ejecutivo de Tecnología

114 Aprobación del Cierre 2 días? 113 Jefes TI

115 Lecciones aprendidas 1 d ía?

116 Confección DANTI-20 1 día? 114 Ejecutivo de Tecnología

4.2.3.10 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.



Cuadro 12. DANTI-10 Recursos del proyecto

DANTI – 10 Recursos del proyecto Dirección Corporativa de Tecnología de Información y Comunicaciones


Nombre Dependencia Rol Correo electrónico

Teléfono Fase Fecha estimada

Horas/ semana

[Nombre del recurso]

[Dependencia a la cual pertenece]

[Rol dentro del proyecto]

[Correo electrónico]

[Teléfono] [Fases del proyecto en las que participará]

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

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


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.



Cuadro 13. DANTI-11 Matriz de comunicaciones

DANTI – 11 Matriz de Comunicación In

form

e

Sem

anal

Info

rme

M

ensu

al

Min

uta

s de

reunio

nes

in

tern

as

Min

uta

s de

reunio

nes

con

pro

veedore

s

Solic

itudes

de

cam

bio

Pla

n d

el

Pro

yect

o

Involucrado Rol en el Proyecto

Sem. Men. Sem. Sem. Otro. Otro

[Nombre del involucrado]

[Rol dentro del proyecto]

Término Significado Sem. Semanal Men. Mensual

Impreso

Correo Electrónico * Responsable

4.2.3.12 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.]




Cuadro 14. DANTI-12 Lista de Riesgos

DANTI – 12 Lista de Riesgos Dirección Corporativa de Tecnología de Información y Comunicaciones


ID Riesgo Probabilidad Impacto Categoría Acción Actividad Estado [ID del riesgo]

[Descripción del riesgo]

[Probabilidad de ocurrencia de 1 a 100%]

[Impacto, tabla 1]

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

[Indicar si se mitiga, se elimina o se acepta]

[Actividad que se realizará para enfrentarlo]

[Estado del riesgo: Activo o Inactivo]

Tabla 1. Definición de 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.

Tabla 2. Definición de la categoría





4.2.3.13 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.


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


Información general Fecha: [Indicar la fecha de confección] Identificación Proyecto: [Identificación 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 Diferencia [Nombre de la tarea] [Fecha

de inicio] [Fecha final]

[% de avance]

[% Esperado]

[Diferencia progreso y real]


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

[Fecha máxima a ejecutar]

[Responsable de realizar la actividad ]

[Impacto para el proyecto]

[Estado de la actividad]

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.



Cuadro 16. DANTI-14 Informe mensual

DANTI – 14 Informe mensual Dirección Corporativa de Tecnología de Información y Comunicaciones




Periodo que comprende: [Fecha inicio y fin que comprende el informe

Responsable: [Nombre del Ejecutivo]

Detalle del Informe


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


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.


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]



Fecha de inicio: [Fecha de inicio real del proyecto]

Fecha de finalización: [Fecha de finalización del proyecto]

Nombre del Director de Proyecto: [Nombre del director del proyecto]

Nombre del Ejecutivo de Tecnología: [Nombre del Ejecutivo]

Detalle de la nota


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 [Nombre y firma del ejecutivo de tecnología]

Fecha y hora [Fecha y hora de la entrega]

Aprobado por [Nombre y firma del director del proyecto]

Fecha y hora [Fecha y hora de la aprobación]

Receptores Receptores [Nombre y firma de de los receptores de la nota]

Fecha y hora [Fecha y hora de la recepción]

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.


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


Información general Fecha: [Indicar la fecha de confección] Identificación Proyecto: [Número 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 [Nombre y firma de la persona que realiza la entrega]

Fecha y hora [Fecha y hora de la entrega]

Recibido por [Nombre y firma del receptor del entregable]

Fecha y hora [Fecha y hora de la resolución del entregable]


4.2.3.18 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.


Cuadro 20. DANTI-18 Control de Cambios

DANTI – 18 Control de Cambios Dirección Corporativa de Tecnología de Información y Comunicaciones


Información general Fecha: [Indicar la fecha de confección]

Número de Cambio: [Consecutivo de cambio para el proyecto]

Identificación Proyecto: [Identificación del Proyecto]


Solicitante: [Nombre de la persona que gestiona el cambio]

Rol del solicitante: [Rol de la persona dentro del proyecto 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 [Nombre de la persona que realiza el análisis]

Fecha: [Fecha de realización del análisis]

Impacto Técnico: [Indicar el impacto a nivel técnico que provoca el cambio]

Impacto en Presupuesto: [Indicar el impacto en presupuesto de realizar el cambio propuesto]

Impacto en Cronograma: [Indicar si el cambio provoca modificaciones al cronograma propuesto]

Impacto en otros Proyectos: [Indicar si el cambio impacta a otros proyectos]


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 [Nombre y firma del ejecutivo de tecnología]

Fecha y hora [Fecha y hora de la firma de la resolución]

Autorizar cambio [Nombre y firma del director de proyecto]

Fecha y hora [Fecha y hora de la firma de la resolución]

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”.



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]


4.2.3.20 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.


Cuadro 22. DANTI-20 Lecciones aprendidas

DANTI – 20 Lecciones aprendidas Dirección Corporativa de Tecnología de Información y Comunicaciones


Información general del proyecto Fecha: [Indicar la fecha de confección] Identificación Proyecto: [Identificación 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]


4.2.3.21 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”


Fase del proyecto a utilizar: Todas las fases (siempre que haya una reunión).


4.3 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 Ejecución 1. Visión técnica 2. Modelación del negocio

1. Plan del proyecto 2. Matriz de comunicación 3. Lista de Recursos 4. Glosario

1. Lecciones aprendidas


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 Referencias

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

2 Posicionamiento

2.1 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 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.

Afecta Dirección de Crédito Nacional Dirección de Coordinación de Entes Reguladores

El impacto es 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.

Una solución exitosa es Un medio tecnológico que permita: � Administrar la información crediticia de

forma consolidada � Corregir información inconsistente


� Ajustarse a los requerimientos de validación definidos por la SUGEF

Para 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

3 Descripciones de los Afectados y Usuarios

3.1 Resumen de Afectados

Nombre Relación con el proyecto SIACC Proveer la información de los Créditos SIEF 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 Pago Electrónico

Revisar la información de Oracard antes de 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 de Entes Reguladores

Identificar las validaciones realizadas por la SUGEF

3.2 Resumen del Usuario

Nombre Descripción

Dirección de Coordinación de Entes Reguladores

Administran el sistema, consolidan, validan y generan la información

Jefes de crédito Modificación de información Unidad de Seguimiento de Crédito

Generación de reportes

3.3 Principales Necesidades de Afectados o Usuarios


Problema Solución actual Solución que desea el usuario

Cambio de esquema de envío de información crediticia

Envió de archivos de texto, los cuales se envían por el sistema llamado Ingresador de la SUGEF

Envió de archivos en el formato y seguridad estipulado por la SUGEF.

Cambio en la normativa definida por la SUGEF

No hay Tener una aplicación que permita aplicar las condiciones establecidas en la nueva normativas de SUGEF

Reglas de validación para el envío de información

No hay Tener un sistema que permita aplicar las reglas establecidas por la SUGEF

Consolidar la información crediticia

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


4.1 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


� 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


4.3.2.2 DANTI-07: Modelación del negocio

DANTI-07 Modelación del negocio

1 Introducción

1.1 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


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.


4.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, 4-

04 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


Ejemplo de reporte

4.3.2.3 DANTI-08: Plan del proyecto

DANTI-08 Plan del proyecto

1 Introducción

1.1 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)


� 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.

3 Plan de Gestión del Proyecto 3.1 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

Sistemas transaccionales

Información consolidada

Procesos de Transformación

Información validada Procesos de

validación


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, 4-

04 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 5-05, 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.


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 Ciclo de vida del proyecto

3.2 Actividades y costos del proyecto 3.2.1 Definición de las actividades

Entrega Descripción Tareas

Revisar documentación

Creación DANTI-06

Revisión

Visión Técnica del proyecto

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

Analizar entorno

Creación DANTI-07

Revisión

Modelación del Negocio

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

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

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

Confeccionar DANTI-11 Matriz de


Comunicación

Confeccionar DANTI-12 Lista de Riesgos

Revisión del plan

Aprobación del plan

Definir recursos para el proyecto

considerar.

Confeccionar DANTI-10

Confección DANTI-19 Glosario Documento en el que Formulario se documentan términos y abreviaciones del proyecto

Publicación

Confección DANTI-20 Lecciones aprendidas

Plantillas donde se documentan las lecciones aprendidas del proyecto Publicación

Analizar Necesidades

Creación del diagrama

Confeccionar DANTI-03

Revisión

Modelo de casos de uso

Documento con el diagrama de los requerimientos funcionales del producto

Aprobación

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

Detalle de requerimientos

Documentos con las especificaciones funcionales como no funcionales del producto

Entrega de documentación

Análisis de las necesidades

Documento de Arquitectura

Arquitectura Documento con la especificación arquitectónica del producto Entrega del documento de Arquitectura

Analizar posibles riesgos

Entregar riesgos identificados

Riesgos Documentar los riesgos asociados al proyecto para su seguimiento y control Actualizar DANTI-12 Lista de Riesgos

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

Diseño de la aplicación

Documento con el diseño del producto

Entregar documento de Análisis y Diseño

Modificación DTS existentes Solución Sw Producto de software

DTS de extracción


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

Pruebas internas

Confeccionar lista de materiales Lista de materiales Documento con la lista de materiales del producto a implementar Entregar lista de materiales

Confección del Manual Técnico Manuales Manuales técnicos y del usuario

Confección del Manual de Usuario

Confección de Plan de Pruebas

Confección de Casos de prueba

Revisión de Casos de prueba

Aprobación de casos de prueba

Plan de pruebas Documento con la planificación y el ambiente para realizar las pruebas del producto

Preparar ambientes de pruebas

Ejecutar pruebas I Iteración

Ejecutar pruebas II Iteración

Solución probada Producto probado por el usuario

Pruebas Integrales

Elaboración Plan de Capacitación

Aprobación del Plan de Capacitación

Capacitación Capacitación técnica y operativa del producto

Realizar Capacitación

Planificar pase

Realizar pase a producción

Elaboración Plan Piloto

Ejecutar Plan Piloto

Reporte de resultados Plan Piloto

Solución en producción

Producto implementado en producción

Aprobación Plan Piloto

DANTI-15 Nota de aceptación Nota de aceptación de la solución

Documentar la aceptación del usuario

Entrega de Nota

Confeccionar DANTI-16 Nota de cierre del proyecto

Documentar el cierre del proyecto

Aprobación del Cierre


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

Id Nombre de tarea Duración Comienzo Fin Predeces orasNombres de los recurs os

0 ANPS 284,5 días lun 09/01/06 vie 23/02/071 Fas e de Conceptualización 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 Ejec utivo de Tec nología

3 Publicación de documentos 30 mins lun 09/01/06 lun 09/01/06 2 Ejec utivo de Tec nología

4 Vis ión Té cnica 5 días lun 09/01/06 lun 16/01/06

9 Modelación de l Negocio 5 días vie 13/01/06 vie 20/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 Glosario Inicial 0,5 días mié 01/02/06 mié 01/02/06

26 Leccione s apr endidas 0,5 días mié 08/02/06 mié 08/02/06

28 Fas e de Elaboración 93 días vie 03/02/06 mié 14/06/06

29 Modelar casos de uso 4 días vie 03/02/06 jue 09/02/06

35 Detallar neces 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 Arquitectura 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 Entrega 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

58 Leccione s apr endidas 0,25 días jue 06/04/06 jue 06/04/06

60 Fas e de Construcción 153,25 días mié 05/04/06 lun 06/11/06

61 Análisis y dise ño 8 días mié 05/04/06 lun 17/04/06

65 Desarrollo de la solución 145 días lun 17/04/06 lun 06/11/06

91 Leccione s apr endidas 0,25 días lun 06/11/06 lun 06/11/06

93 Fas e de Trans ición 214,25 días lun 17/04/06 vie 23/02/07

94 Planificación de las pruebas 15 días lun 17/04/06 lun 08/05/06

99 Preparar ambientes de pruebas 5 días mié 12/07/06 mié 19/07/06 68 Implantador

100 Pruebas de us uario 95 días mié 23/08/06 mié 17/01/07

104 Manual de Usuario 5 días mié 17/01/07 mié 24/01/07 103 Usuario

105 Capacitación 9 días mié 24/01/07 mar 06/02/07

109 Pas e a Producción 27 días mié 17/01/07 vie 23/02/07

116 Leccione s apr endidas 0,25 días vie 23/02/07 vie 23/02/07

118 Cie rre de l Proyecto TI 17,13 días mié 31/01/07 vie 23/02/07

119 Aceptación 0,13 días vie 23/02/07 vie 23/02/07

122 Pre sentación del producto 2 días mié 31/01/07 vie 02/02/07

125 Nota de cierre 3 días vie 02/02/07 mié 07/02/07

128 Leccione s apr endidas 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 EDT Nombre

0 0 ANPS 1 1 Fase de Conceptualización 2 1.1 Creación de sitio 3 1.2 Publicación de documentos 4 1.3 Visión Técnica 5 1.3.1 Revisar documentación 6 1.3.2 Creación DANTI-06 9 1.4 Modelación del Negocio 10 1.4.1 Analizar entorno 11 1.4.2 Creación DANTI-07 12 1.4.3 Revisión


13 1.4.4 Aprobación 14 1.5 Plan de Proyecto 15 1.5.1 Creación del DANTI-08 16 1.5.2 Confeccionar DANTI-09 Cronograma preliminar 17 1.5.3 Confeccionar DANTI-11 Matriz de Comunicación 18 1.5.4 Confeccionar DANTI-12 Lista de Riesgos 19 1.5.5 Revisión 20 1.5.6 Aprobación 28 2 Fase de Elaboración 29 2.1 Modelar casos de uso 30 2.1.1 Analizar Necesidades 31 2.1.2 Creación del diagrama 32 2.1.3 Confeccionar DANTI-03 33 2.1.4 Revisión 34 2.1.5 Aprobación 35 2.2 Detallar necesidades 36 2.2.1 Priorizar requerimientos 37 2.2.2 Confección de requerimientos 38 2.2.3 Revisión 39 2.2.4 Aprobación 42 2.2.7 Confección de presentación a TI 43 2.2.8 Presentación 44 2.2.9 Entrega de documentación 46 2.4 Contratación 66 3.2.1 I Iteración 67 3.2.1.1 Desarrollo 68 3.2.1.1.1 DTS 69 3.2.1.1.1.1 Modificación DTS existentes 72 3.2.1.1.1.4 DTS de Control de Integridad 73 3.2.1.1.2 Validación 76 3.2.1.1.2.3 Validación por entregable 78 3.2.1.2 Pruebas internas 79 3.2.2 II Iteración 80 3.2.2.1 Desarrollo 81 3.2.2.1.1 Cubos 85 3.2.2.1.3 Consultas y reportes 86 3.2.2.1.4 Seguridad sistema 87 3.2.2.2 Pruebas internas 93 4 Fase de Transición 100 4.3 Pruebas de usuario 102 4.3.2 Ejecutar pruebas II Iteración 103 4.3.3 Pruebas Integrales 109 4.6 Pase a Producción 110 4.6.1 Planificar pase 111 4.6.2 Realizar pase a producción


113 4.6.4 Ejecutar Plan Piloto 114 4.6.5 Reporte de resultados Plan Piloto 115 4.6.6 Aprobación Plan Piloto 116 4.7 Lecciones aprendidas 117 4.7.1 Confección DANTI-20

3.2.4 Curva “S” del trabajo acumulado

Trabajo acumulado

-

1.000

2.000

3.000

4.000

5.000

6.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

Horas

Trabajo

3.2.5 Presupuesto de actividades

Id Nombre Comienzo Fin Costo

estimado

65 Desarrollo de la solución 17/04/2006 17/01/2007 $140,000.00


3.3 Organización del proyecto 3.3.1 Diagrama funcional del Proyecto

3.3.2 Roles necesarios

Rol Funciones Arquitecto Realizar la definición del modelo de arquitectura a

nivel de software y de hardware Soportista técnico Implementar la infraestructura para el ambiente de

producción Implementador Llevar el proceso de pruebas y coordinar con el

soportista la puesta en producción de la solución Ingeniero Realizar el análisis y diseño de la aplicación y velar

por el desarrollo del producto Desarrollador Realizar el desarrollo del producto

3.3.3 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

Patrocinador del proyecto

Director del proyecto

Ejecutivo de tecnología Usuarios Expertos

Arquitecto

Soportista Técnico

Implementador

Ingeniero

Usuario de Crédito

Usuario de Contabilidad

Usuario de Entes

Usuario de tarjetas

Jefes de Crédito Desarrolladores


EDT Nombre

Ejecu

tivo

Director

Usu

ario

Jefes TI

Arquitecto

Ingen

iero

Desarrollad

or

Implemen

tador

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.5.1 Creación del DANTI-08 �

1.5.2 Confeccionar DANTI-09 Cronograma

preliminar

�

1.5.3 Confeccionar DANTI-11 Matriz de

Comunicación

�

1.5.4 Confeccionar DANTI-12 Lista de Riesgos �

1.5.5 Revisión �


1.6.1 Definir recursos para el proyecto �

1.6.2 Confeccionar DANTI-10 �

1.7.1 Confección DANTI-19 �


2.1.1 Analizar Necesidades �

2.1.2 Creación del diagrama �


2.1.4 Revisión �


2.2.1 Priorizar requerimientos � �

2.2.2 Confección de requerimientos �

2.2.3 Revisión �


2.2.5 Detallar necesidades no funcionales �

2.2.6 DANTI-02 Especificaciones suplementarias �


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 �


3.1.1 Analizar el producto �

3.1.2 Confeccionar documento de Análisis y

Diseño �

3.1.3 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 Procesos �

3.2.1.2 Pruebas internas �

3.2.2.1.1 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 �


4.1.1 Plan de Pruebas �


4.1.2 Casos de prueba �

4.1.3 Revisión �


4.2 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 �

4.4 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 �


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.2 Aprobación del Cierre �

5.4.1 Confección DANTI-20 � 3.3.4 Matriz de comunicación

DANTI – 11 Matriz de Comunicación

Info

rme

S

em

anal

Info

rme

M

ensu

al

Min

uta

s de

reunio

nes

in

tern

as

Min

uta

s de

reunio

nes

con

pro

veedore

s

Solic

itudes

de

cam

bio

Pla

n d

el

Pro

yect

o

Involucrado Rol en el Proyecto

Sem. Men. Sem. Sem. Otro. Otro

Adrián Salazar Director del Proyecto

Alejandra Mora Ejecutivo * * * * * * Oscar Cambronero Jefe de TI Harold Bustos Jefe de TI


Danilo Segura Jefe de TI Gilberto Villalobos Jefe de TI Oldemar Vargas Arquitecto William Romero Ingeniero Edwin León Implementador Mario Gamboa 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.


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 Riesgos 3.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. 3.4.2 Categorías de Riesgos




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

ID Riesgo Probabilidad Impacto Categoría 1 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

70% Serio Medio

2 Si se da un atraso en el inicio del desarrollo del producto puede generar que el costo del proyecto supere lo aprobado

80% Serio Medio

3 Si se presentan problemas en la aprobación del presupuesto puede provocar atrasos en el inicio del proyecto.

10% Moderado Bajo

4 Si se dan retrasos en la contratación para el desarrollo del sistema puede generar atrasos en el cronograma

50% Moderado Medio

5 Si el usuario no participa en el proceso de pruebas del sistema puede afectar la calidad del producto final.

10% Crítico Medio


3.4.4 Estrategias de respuesta

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.

3.4.5 Planificación de la respuesta a riesgos Riesgo Estrategia Acción Contingencia Presu-

puesto

Responsable Disparador

1 Mitigar 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).

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


Que se presenten dos solicitudes de cambio

2 Transferir En el contrato se debe incluir las cláusulas donde se especifiquen las multas por atraso en la entrega del producto.

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


Riesgo Estrategia Acción Contingencia Presu-

puesto

Responsable Disparador

4 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

5 Mitigar 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 Usuario no desea participar en las reuniones de seguimiento y no desea realizar el proceso de pruebas

3 Aceptar 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.


Se recibe nota de la presupuesto acerca de la no aprobación del presupuesto


3.5 Adquisiciones del proyecto 3.5.1 Matriz de Adquisiciones

Nombre de Contratación

Descripción de la contratación Costo Estimado Fecha límite contratación

Posibles Proveedores

Responsable

Ingeniería-01 Desarrollo de la aplicación $ 140,000.00 14/06/2007 Grupo MAS William Romero


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


Nombre Dependencia Rol Correo electrónico

Teléfono Fase Fecha estimada

Horas/ semana

Alejandra Mora

Análisis de Negocio

Ejecutivo de Tecnología

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

09/01/2006 al 23/02/2007

8 horas

Oldemar Vargas

Arquitectura de Servicios de TI

Arquitecto Elaboración 03/02/06 al 14/06/06

6 horas

William Romero

Ingeniería de Servicios de TI

Ingeniero Elaboración, Constricción

03/02/2006 al 06/11/2006

8 horas

Edwin León

Implantación de Servicios de TI

Implementador Transición 17/04/2006 al 23/02/2007

8 horas

Mario Gamboa

Servicios en Producción

Soportista Téc.

Transición 17/01/2007 al 23/01/2007

6 horas

4.3.2.5 DANTI-19: Glosario

DANTI-19 Glosario

1 Introducción

1.1 Propósito

Documentar las abreviaturas y términos utilizados dentro del Proyecto.

2 Abreviaturas

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


2.5 SIEF: Sistema Integrador para Entidades Financieras 2.6 SICVECA: Sistema de Verificación y Carga de datos - SUGEF 2.7 SICICC: Sistema Conciliación Información Crediticia 2.8 MTVAL: Módulo de Transferencia de Valores 2.9 FINESSE: Sistema de Cajas 2.10 SIFCO: Sistema Financiero Contable 2.11 Oracard: Sistema de Administración de Tarjetas de Crédito 2.12 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


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


4.4 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


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 Duración Comienzo Fin Predecesoras

0 Plan de divulgación 20,5 días lun 21/01/08 lun 18/02/081 Desarrollo 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áctico 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 Entrega del caso a resolver 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


CAPITULO 5 CONCLUSIONES Y

RECOMENDACIONES


5.1 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.


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.


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).


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


estructura actual del banco, la experiencia obtenida en estos años y

analizar mejoras de acuerdo a estándares internacionales.


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.


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


ANEXOS


Anexo 1 Acta del proyecto

ACTA DEL PROYECTO Información general 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

Áreas de conocimiento / procesos Conceptualización, Planificación, Seguimiento y Control, Cierre

Área de aplicación (sector / actividad): Dirección de Análisis de Negocio / Dirección Corporativa de Tecnología de Información y Comunicaciones / Banco Nacional de Costa Rica

Fecha de inicio del proyecto: 18 de julio del 2007

Fecha tentativa de finalización del 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.


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 Firma Fecha

Licda. Alejandra Mora Sustentante

Msc. Miguel Ángel Vallejo Instructor


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


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.


Anexo 3 WBS


Anexo 4 Cronograma Id Nombre de tarea Duración Comienzo Fin PredecesorasNombres de los

recursos

0 Cronograma 204 días mié 18/07/07 mié 06/02/081 Sem inar io 41 días mié 18/07/07 lun 27/08/07

2 Ent regable 1 15 días mié 18/07/07 mié 01/08/07

3 Preparación del Charter del proyec to 3 días mié 18/07/07 vie 20/07/07 Alejandra Mora

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 Desarrollo del Cronograma 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

10 Ent regable 2 20 días mié 25/07/07 lun 13/08/07

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 introducción 0 días lun 06/08/07 lun 06/08/07 11 Alejandra Mora

13 Rev isión de la introducción 7 días mar 07/08/07 lun 13/08/07 12 Instructor Miguel

14 Ent regable 3 17 días lun 30/07/07 mié 15/08/07

15 Preparación del marco teórico 6 días lun 30/07/07 sáb 04/08/07 11 Alejandra Mora

16 Entrega del marco 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

18 Ent regable 4 16 días dom 05/08/07 lun 20/08/07

19 Preparación del marco metodológico 8 días dom 05/08/07 dom 12/08/07 15 Alejandra Mora

20 Entrega del marco 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

22 Ent regable 5 14 días lun 13/08/07 dom 26/08/07

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 resumen 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 Documento final 11 días vie 17/08/07 lun 27/08/07

27 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


Id Nombre de tarea Duración Comienzo Fin PredecesorasNombres de losrecursos

29 Desarrollo del PFG 93 días mar 28/08/07 mié 28/11/07

30 Coordinac ión tutorial 7 días mar 28/08/07 lun 03/09/07 28

31 Análisis y recomendaciones del proceso 28 días mar 28/08/07 lun 24/09/07

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 Encuestados

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 Recomendaciones sobre áreas a desarrollar 5 días jue 20/09/07 lun 24/09/07 36 Alejandra Mora

38 Análisis discip linas de PM I y los procesos de T I 14 días mar 25/09/07 lun 08/10/07

39 Análisis de procesos 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

42 Comparac ión de PMI y procesos de desarrollo 5 días jue 04/10/07 lun 08/10/07 41 Alejandra Mora

43 Procesos 10 días mar 09/10/07 jue 18/10/07

44 Análisis de la informac ión 2 días mar 09/10/07 mié 10/10/07 42 Alejandra Mora

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

48 Plantillas 10 días vie 19/10/07 dom 28/10/07

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

53 Validación de la me todología 6 d ías lun 29/10/07 sáb 03/11/07

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


Id Nombre de tarea Duración Comienzo Fin PredecesorasNombres de losrecursos

56 Plan de d ivulgación 5 días dom 04/11/07 jue 08/11/07

57 Def inición de involucrados 1 día dom 04/11/07 dom 04/11/07 53 Alejandra Mora

58 Def inición de tareas 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 conclus 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 mié 28/11/07

64 Rev isión general 5 días lun 19/11/07 vie 23/11/07 62 Tutor

65 Correcciones generales 5 días sáb 24/11/07 mié 28/11/07 64 Alejandra Mora

66 Aprobación del PFG 0 días mié 28/11/07 mié 28/11/07 65 Tutor

67 Cie rre 70 días jue 29/11/07 mié 06/02/08

68 Revisión 24 días jue 29/11/07 sáb 22/12/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 Rev isión 18 días mié 05/12/07 sáb 22/12/07 70 Lec tores

72 Cor recciones al PFG 30 días dom 23/12/07 lun 21/01/08 68 Alejandra Mora

73 Sus tentación 16 días mar 22/01/08 mié 06/02/08

74 Coordinac ión 10 días mar 22/01/08 jue 31/01/08 72 Alejandra Mora

75 Confeccionar presentació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


Anexo 5 Resultado de las entrevistas

0,0%

2,0%

4,0%

6,0%

8,0%

10,0%

12,0%

Problemas

Pareto de los problemas a los que se enfrenta DANTI

Personal responde al jefe delíneaDisponibilidad de los recursos

Estandarización

Definición del alcance

Personal sobre cargado

Recursos no comprometidos

Poca Planificación

Recursos sin experiencia

Responsabilidad de cadamiembroMadurez en el tema


Anexo 6 Resultado de los cuestionarios


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 resolver:

Justificación:

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 Sistemas relacionados

Documentos relacionados

Estimación preliminar de los Recursos: Presupuesto Inversiones: Recursos humanos: Tiempo: Unidad Organizativa y nombre del solicitante:

Firma:

Nombre: Director Corporativo, Regional o Gerente de Sociedad Anónima

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


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: Ver Estándar BNCR-21 Especificación de Requerimientos de Software

Factibilidad: Técnica:

Operacional: Económica

Valor Actual Neto (V.A.N.):

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

%

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

Recursos Financieros

Recursos Administrativos

Recursos Humanos

Otros

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

del recurso

Dedicación Semanal

Localización

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

Funciones Dedicación 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.


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 Proyecto: Firma del Director del Proyecto:

Nombre: Firma:

Nombre: Firma:

Nombre: Firma:

Nombre: Firma:

Nombre: Firma:

Aprobación del Documento de Justificación: Nombre: Director Corporativo, Regional, Gerente de Sociedad Anónima Es designado como Patrocinador del Proyecto

Firma: Director Corporativo, Regional, Gerente de Sociedad Anónima


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: Se refiere a la persona o unidad encargada de realizar la tarea o actividades para cumplir con el acuerdo tomado.

FECHA: Se especifica la fecha límite para lograr la actividad o tarea acordada.

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: Firma:

Nombre: Firma:

Nombre: Firma:

Nombre: Firma:

Nombre: Firma:

Nombre: Firma:


AP-004-2002 “INFORME DE AVANCE DEL PROYECTO”


Fecha:

Unidad organizativa:

PERIODO QUE CUBRE:

LISTA DE TAREAS CONCLUIDAS EN EL PERIODO REPORTADO

LISTA DE TAREAS EN PROCESO AL MOMENTO DEL INFORME (RESPONSABLE Y % AVANCE)

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


AP-005-2002 “SOLICITUD CONTROL DE CAMBIOS”


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:


AP-009-2002 “LECCIONES APRENDIDAS”

Nombre del proyecto: Fecha:

Nombre del Director:

SITUACIÓN PRESENTADA ACCIÓN ADMINISTRATIVA

REALIZADA


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


Anexo 8 Formato de los documentos

<Nombre Proyecto>

<Nombre del documento>

Versión <1.0>


Bitácora de acciones sobre el documento

Registro de generación y revisión

Fecha Versión Revisión Responsable

<dd/mm/yy> <x.x> <detalles> <nombre>

Registro de aprobación

Fecha Versión Revisión Responsable

<dd/mm/yy> <x.x> <detalles> <Director de Proyecto>

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.


Tabla de Contenidos


<Nombre del documento>

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


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: <Nombre del 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.]


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.]

<Un Subflujo Alterno >

[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.]

<Primera Post-condición >

Puntos de Extensión

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

<Nombre del Punto de Extensión >

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


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]

<Requerimiento de Usabilidad Uno>


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.]

<Requerimiento de Confiabilidad Uno >

[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”.]

<Requerimiento de Rendimiento Uno >


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.]


<Requerimiento de Soporte Uno>


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.]

<Restricción de Diseño Uno >


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.]


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.]

Metodología para la administración de proyectos ...

Documents

Transcript of Metodología para la administración de proyectos ...