Proyecto++informatico Desbloqueado PDF

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
METODOLOGIA PARA ESTANDARIZACION DE LA

ADMINISTRACION DE PROYECTOS INFORMATICOS DENTRO DE
LA DIRECCION DE TECNOLOGIA DE INFORMACION Y
COMUNICACIONES DEL BANCO NACIONAL
MARIA ALEJANDRA MORA RODRIGUEZ
PROYECTO FINAL DE GRADUCIACION PRESENTADO COMO

REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER
EN ADMINISTRACION DE PROYECTOS
San José, Costa Rica

FEBRERO 2008
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)
Este Proyecto Final de graduación fue aprobado por la Universidad como

Requisito parcial para optar al grado de Master en Administración de Proyectos
___________________________
Juan Carlos Navarro
PROFESOR TUTOR
__________________________
Fausto Fernández Martínez
LECTOR Nº 1
___________________________
Víctor Noguera Durán
LECTOR Nº 2
___________________________
María Alejandra Mora Rodríguez
SUSTENTANTE
i
AGRADECIMIENTO
A Dios por darme el don del entendimiento. Sin las maravillas que me
regalas día a día, no podría conseguir el éxito que hasta el día de hoy
he alcanzado.
A Juan Carlos, por su colaboración y apoyo en este proceso.
ii
DEDICATORIA
A mi mamá, porque gracias a su esfuerzo he logrado llegar hasta aquí.
A mi papá que a la distancia siempre recibo su apoyo.
Y a mi abuela Rosa,
aunque ya no estas aquí, siempre estarás en mi corazón,
con tus oraciones llenaste mi vida de bendiciones.
iii
“Dichoso el que adquiere sabiduría y consigue prudencia.
Tener sabiduría vale más que tener dinero;
conseguir prudencia es mejor que conseguir oro.
Ser sabio es más valioso que tener perlas y esmeraldas.
No hay tesoro que iguale al tener sabiduría.”
Proverbios 3,13
iv
Metodología para la Administración de Proyectos Informáticos
INDICE DE CONTENIDO
CAPITULO 1 INTRODUCCION ........................................................................... 1
1.1 Antecedentes .................................................................................................... 2
1.2 Problemática ..................................................................................................... 2
1.3 Justificación del proyecto................................................................................ 3
1.4 Objetivos ........................................................................................................... 4

1.4.1 Objetivo General............................................................................................................ 4
1.4.2 Objetivos específicos..................................................................................................... 4
CAPITULO 2 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
v
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
vi
Anexo 2 Declaración del alcance ............................................................................ 150
Anexo 3 WBS ............................................................................................................ 152
Anexo 4 Cronograma ............................................................................................... 153
Anexo 5 Resultado de las entrevistas..................................................................... 156
Anexo 7 Plantillas Metodología BNCR.................................................................... 168
Anexo 8 Formato de los documentos ..................................................................... 176
Anexo 9 Plantillas de TI ........................................................................................... 180
vii
INDICE DE ILUSTRACIONES
Figura 1. Organigrama BNCR (BNCR, 2007)_____________________________ 8

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

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

COVIC
Crediticia
DANTI Dirección de Análisis de Negocio de Tecnología de Información
Dirección Corporativa de Tecnología de Información y

DCTIC
Comunicaciones
DEP Dirección de Estrategia y Proyectos
DTS Data Transformation Services
FINESSE Sistema de Cajas
IBM International Business Machines
MTVAL Módulo de Transferencia de Valores
OGC Office of Government Commerce
Oracard Sistema de Administración de Tarjetas de Crédito
Siglas en inglés de Software para Ingeniería Orientada a Objetos

OOSE
(Software Object- Oriented Software Engineering)
PMBOK Guía de los Fundamentos de la Dirección de Proyectos del PMI
x
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
Siglas en inglés de Lenguaje de Modelamiento Unificado (Unified

UML
Modeling Language)
VAN Valor Actual Neto
Siglas en inglés de Estructura de Desglose del Trabajo (Work

WBS- EDT
Breakdown Structure)
xi
RESUMEN EJECUTIVO
xii
Las organizaciones han recurrido a la utilización de la tecnología de información

para lograr una ventaja competitiva, como base para la toma de decisiones. Estas
tecnologías deben brindar información oportuna, veraz y exacta, que les permita
colaborar en el planeamiento de las estrategias de negocio y robustecer sus
fortalezas internas.
En su afán de cumplir las necesidades del negocio, mejorar los servicios y los
tiempos de respuesta que la Dirección Corporativa de Tecnología de Información y
Comunicaciones (DCTIC) brinda a las unidades de negocio, se crea la Dirección
de Análisis de Negocio, cuya función es administrar los proyectos informáticos.
Dada la importancia de esta dirección, el siguiente documento tiene como objetivo

elaborar una Metodología para la Administración de Proyectos Informáticos dentro
de la Dirección de Análisis de Negocio de la DCTIC, considerando las mejores
prácticas propuestas por el PMI en el PMBOK 2004.
Dentro de los objetivos específicos que se plantean en el desarrollo de este

documento se encuentran: analizar el proceso de administración de proyectos de
TI que realiza la Dirección de Análisis de Negocio para identificar debilidades;
realizar un análisis comparativo entre las disciplinas de PMI y los procesos de
proyectos de TI para relacionar ambos procesos; definir el flujo de procesos para
la administración de proyectos de TI para guiar al personal; confeccionar las
plantillas para el apoyo a utilizar en la administración de proyectos de TI; aplicar
parcialmente la metodología propuesta para validarla; desarrollar un plan
preliminar de divulgación de la metodología para hacerla del conocimiento de la
Dirección de Análisis de Negocio.
Para el desarrollo del documento se realizará una investigación exploratoria, con

el fin de obtener los conocimientos sobre el tema y una investigación descriptiva,
con lo cual se estará describiendo las características del objetivo. Además se
recurrirá a los siguientes instrumentos: cuestionarios (identificar procesos y
conocimiento del personal), entrevistas (analizar el proceso, retroalimentación del
personal, validación de información), revisión de documentación (verificación de
información) y confección de documentación.
Además se consideró como estándar la Guía de los fundamentos de

administración de proyectos (Guía del PMBOK) en las áreas de: alcance, tiempo,
costo, recursos humanos, riesgos, comunicación e integración. La metodología
desarrollada está acorde con la Metodología de Administración de Proyectos del
BNCR y los procesos de la DCTIC.
Como primer punto se analiza la situación actual, entorno a la administración de

proyectos informáticos dentro de la DCTIC y la Metodología de Administración de
Proyectos del BNCR, esto con el fin de encontrar los puntos de mejora y
xiii
estandarizar el proceso. Considerando este análisis se realiza el planteamiento de

la propuesta donde el primer punto es la definición de los procesos que se
desarrollan durante un proyecto de tecnología, considerando a nivel general la
participación de las direcciones pertenecientes a la DCTIC.
Uno de los hallazgos es que los ejecutivos de tecnología, quienes administran los
proyectos informáticos, no tienen un estándar para administrar los proyectos, cada
quien considera su método de trabajo. Por tanto se desarrolla la diagramación de
los procesos involucrados en la administración, estos diagramas contiene el flujo
de las actividades que se deben desarrollar, indicando los documentos y/o
plantillas que se deben completar, además de los responsables de realizar cada
actividad y los insumos necesarios. Cabe destacar, que dentro de la metodología
no se hace obligatoria la utilización de todos los documentos y/o plantillas, sino va
a depender del tipo de proyecto y la duración del mismo. Otro punto importante es
que la identificación de los documentos a utilizar en el desarrollo del proyecto,
encajado con cada uno de los procesos de la DCTIC y la concordancia con las
fases del proyecto acorde a la Metodología de Administración de Proyectos del
BNCR. Estos documentos y/o plantillas contienen una guía con la información que
requiere para ser desarrollada, esto para dar una guía a los ejecutivos y facilitar su
desarrollo.
Para evaluar la metodología propuesta se seleccionó un proyecto y se aplicaron

las plantillas propuestas de la fase de conceptualización, con esto se logra
analizar lo planteado y realizar las mejoras correspondientes, para facilitar su uso
y desarrollo.
Con el fin de dar a conocer la metodología, se desarrolló un plan de divulgación

con el objetivo que los ejecutivos de tecnología conozcan la misma y la apliquen
dentro de sus labores y así estandarizar el proceso actual.
Para ir madurando en la administración de proyectos, es necesario mantener una

forma estandarizada de realizar las tareas, por tanto, esta metodología se
convierte en una guía práctica para los ejecutivos de tecnología, unificando los
procesos y la documentación que se debe generar.
Dado que cada proyecto es diferente, durante su desarrollo el personal va

adquiriendo la experiencia. Es importante que esta experiencia se mantenga
dentro de la institución, porque servirá como referencia para otros proyectos en la
toma de decisiones.
xiv
Metodología para la Administración de Proyectos Informáticos 1
CAPITULO 1
INTRODUCCION
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

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
Seguimiento y
Proyectos Inicialización Planificación Ejecución Cierre
Control
Sistemas '
1. Identificación del
Recepción Proyecto
2. Visión y alcance
1. Aceptación del 1.Plan del proyecto
Conceptualización
proyecto 2. Lista de Riesgos
1. Modelo de 1. Minutas
casos de uso 2. Informes de
2. Especificación avance
suplementaria
Elaboración 3. Casos de uso
4. Documento de
arquitectura
5. Documento de
diseño
1. Plan de pruebas 1. Casos de uso 1. Minutas
Construcción funcionales 2. Informes de
avance
1. Casos de 1. Minutas
Transición prueba 2. Informes de
avance
1.Nota de
Cierre
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 Generado por el solicitante de la necesidad Recibir Corto, Negocio,
Proyecto donde se define la idea del proyecto para su Largo Infraestructura
aprobación.
AP-02-2002 Visión y alcance Generado por el director, presenta una visión Recibir Corto, Negocio,
inicial del proyecto y el alcance definido. Largo Infraestructura
AP-03-2002 Minutas Formulario para documentar acuerdos y Generar Corto, Negocio,
pendientes de las reuniones. Largo Infraestructura
DANTI-01 Casos de uso Documento de especificación de los Generar Corto, Negocio
requerimientos funcionales del sistema. Largo
DANTI-02 Especificación Documento de especificación de requerimientos Generar Largo Negocio
suplementaria no funcionales (rendimiento, tiempos de
respuesta, presentación) del sistema.
DANTI-03 Modelo de casos de uso Diagrama de los requerimientos funcionales del Generar Largo Negocio
producto.
DANTI-04 Lista de insumos Aspectos que deben ser presentados por el Recibir, Corto, Negocio,
director del proyecto, para la DCTIC son de suma Generar Largo Infraestructura
importancia.
DANTI-05 Acta de inicio Aprueba el proyecto dentro de la DCTIC y asigna Generar Corto, Negocio,
un ejecutivo. Largo Infraestructura

DANTI-06 Visión técnica Guía para identificar la visión desde el punto de Generar Largo Negocio,
vista técnico de la solución. Infraestructura
DANTI-07 Modelación del negocio Guía para modelar las funcionalidades desde la Generar Largo Negocio,
perspectiva del negocio. Infraestructura
DANTI-08 Plan del proyecto Guía para el desarrollo del plan de proyecto, Generar Largo Negocio,
formato y aspectos mínimos a considerar. Infraestructura
DANTI-09 Cronograma Archivo para el control de tareas, duraciones y Generar Corto, Negocio,
responsables, se debe mantener en el Project Largo Infraestructura
Central Server.
DANTI-10 Recursos del proyecto Formulario con los recursos que participaran de Generar Corto, Negocio,
las distintas dependencias, la disponibilidad y en Largo Infraestructura
la etapa en que participaran.
DANTI-11 Matriz de Matriz donde se detallen los entregables e Generar Largo Negocio,
comunicaciones informes, con su responsable, a quién lo debe Infraestructura
enviar y el medio.
DANTI-12 Lista de Riesgos Plantilla para listar, detallar, clasificar los riesgos Generar Corto, Negocio,
del proyecto. Largo Infraestructura
DANTI-13 Informes de avance Plantilla para la preparación de informes Generar Largo Negocio,
semanal semanales. Infraestructura
DANTI-14 Informes de avance Plantilla para la preparación de informes Generar Corto, Negocio,
mensual mensuales (consolidado). Largo Infraestructura

DANTI-15 Aceptación del producto Acta donde el cliente da por aceptado el producto Generar Corto, Negocio,
y con ello el cierre del proyecto. Largo Infraestructura
DANTI-16 Nota de cierre Acta con el resumen del resultado del proyecto y Generar Corto, Negocio,
la liberación de los recursos. Largo Infraestructura
DANTI-17 Recepción de Formulario para la recepción de los entregables Generar Corto, Negocio,
entregables del proyecto. Largo Infraestructura
DANTI-18 Control de cambios Formulario para documentar las solicitudes de Generar Corto, Negocio,
cambio, quedando evidencia de su aprobación o Largo Infraestructura
rechazo y el impacto en el proyecto.
DANTI-19 Glosario Formulario con los términos propios del negocio Generar Largo Negocio,
o técnicos que deben ser del conocimiento del Infraestructura
equipo del proyecto.
DANTI-20 Lecciones aprendidas Plantilla para documentar las lecciones Generar Corto, Negocio,
aprendidas durante el proyecto Largo 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
Seguimiento y
Proyectos Inicialización Planificación Ejecución Cierre
Control
Sistemas '
1. Identificación del
Proyecto
Recepción 2. Visión y alcance
3. Lista de insumos
4. Acta de inicio
1. Visión técnica 1. Plan del 1. Lista de Riesgos
2. Modelación del proyecto 2. Glosario
negocio 2. Cronograma 3. Lecciones
3. Matriz de aprendidas
comunicación 4. Recepción de
Conceptualización 4. Lista de Riesgos entregables
5. Lista de
Recursos
6. Glosario
7. Lecciones
aprendidas
1. Modelo de casos 1. Minutas
de uso 2. Informes de
2. Especificación avance semanal
Elaboración
suplementaria 3. Informes de
3. Casos de uso avance mensual
4. Lista de Riesgos
5. Glosario
6. Lecciones
aprendidas
7. Recepción de
entregables
1. Lista de Riesgos 1. Minutas
2. Glosario 2. Informes de
3. Lecciones avance semanal
Construcción
aprendidas 3. Informes de
4. Recepción de avance mensual
entregables
1. Lista de Riesgos 1. Minutas
2. Glosario 2. Informes de
3. Lecciones avance semanal
Transición
aprendidas 3. Informes de
4. Recepción de avance mensual
entregables
1. Lecciones 1. Minutas 1. Aceptación
aprendidas 2. Informes de del producto
Cierre 4. Recepción de avance semanal 2. Nota de
entregables 3. Informes de cierre
avance mensual
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 [Mencionar los casos de uso relacionados al
relacionados 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: Nombre del Proyecto:
[Identificación del Proyecto] [Nombre del proyecto]
Nombre del Director de Proyecto: Nombre del Ejecutivo de Tecnología:
[Nombre del director del proyecto] [Nombre del Ejecutivo asignado]
Detalle del proyecto
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

DANTI-[Consecutivo]-[Año]
Fecha:
[Indicar la fecha del acta]
Fecha de inicio: Fecha de finalización:

[fecha de inicio del proyecto] [fecha de finalización del proyecto]
[Nombre del director del proyecto] [Nombre del Ejecutivo asignado]
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 [listar algunos beneficios claves de una
es 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]
Conceptualización
Nombre del
proyecto
Elaboración
Construcción
Transición
Cierre
Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes n
2.2 Actividades y costos del proyecto

[Brindar detalles en cuanto a la planificación de los tiempos y costos del proyecto y
en que momento se realizará cada actividad, así como los mecanismos mediante
los cuales se planifica llevar el control del mismo. Para ello se deberán explicar las
principales entregas del proyecto a través de un WBS, cronograma de actividades,
así como la ruta crítica del proyecto.]
2.2.1 Definición de las actividades

[Detallar los principales entregables del proyecto, brindando una pequeña
explicación del mismo, indicando las tareas que se realizarán para lograr el
entregable]
Entrega Descripción Tareas
[Nombre del [Descripción del [Tareas para
entregable] entregable] realizarlo]
2.2.2 Desarrollo del cronograma

[Detallar el cronograma de actividades del proyecto, considerando la secuencia de
las mismas, responsables, participantes, fechas estimadas de inicio y fin de cada
actividad. Se recomienda desarrollarlo con la herramienta Microsoft Project]
2.2.3 Ruta Crítica del Proyecto

[Brindar la ruta crítica del proyecto, mediante la cual se definen todas aquellas
actividades en las cuales, cualquier retraso ocasionarán un atraso en la fecha de
finalización del proyecto y que por consiguiente se debe mantener un control
constante]
2.2.4 Curva “S” del trabajo acumulado

[Elaborar una curva “S” del trabajo acumulado del proyecto, mediante la cual se
brindará el seguimiento respectivo una vez el proyecto se encuentre en ejecución.]
Trabajo acumulado
1400
1200
1000
800
Horas
Trabajo
600
400
200
0
Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7
Meses
2.2.5 Presupuesto de actividades

[Detallar el presupuesto del proyecto a partir de la definición de las actividades con
su calendarización y su costo estimado desde el inicio hasta la finalización del
proyecto.]
Costo
Id Nombre Comienzo Fin
estimado
[Identificac [Nombre de [Comienzo de [Fin de la [Costo
ión de la la tarea] la tarea tarea estimado]
tarea] establecido en establecido
el en el
cronograma] cronograma]
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:
Miembro 1
Miembro 2
Miembro 3
Miembro 4
Miembro n
WBS Tareas
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 /
Despreciable Menor Moderado Serio Crítico
Probabilidad
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 [Descripción [Probabilidad [Impacto, [Acuerdo a la
riesgo] del riesgo] de ocurrencia tabla 1] probabilidad y al
de 1 a 100%] impacto, tabla 2]
2.4.4 Estrategias de respuesta

Las estrategias a utilizar son:
Código Descripción de la Estrategia

Eliminar Eliminación del riesgo.
Transferir Transferencia del riesgo (traslado de la responsabilidad a
terceras partes).
Mitigar Mitigación del riesgo.
Aceptar Aceptación del riesgo. Debe utilizarse para los riesgos de
categoría Baja.
2.4.5 Planificación de la respuesta a riesgos

[Una vez que los riesgos han sido identificados y priorizados, desarrollar
procedimientos y acciones para mejorar las oportunidades y minimizar las
amenazas a los objetivos del proyecto. Se debe incluir recursos y actividades en el
presupuesto, cronograma y plan de gestión del proyecto.]
Riesgo Estra- Acción Contin- Presupuesto Respon- Disparador

tegia gencia sable
[ID del [Estra- [Acción [Medida [Presupuesto {Persona {Evento
riesgo] tegia a a de contin- requerido responsa que indica
utilizar] realizar] gencia] para ble de su si el riesgo
desarrollar la administr se va a
estrategia, en ación} materializar
tiempo y o ya se
costo] materializó}
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.]
Nombre de Descripción Costo Fecha límite Posibles Responsa

Contratación de la Estimado contratación Proveedores ble
contratación
[Identificador [Descripción [Costo [Fecha [Lista de [Responsa
para la de la estimado] máxima proveedores ble de
contratación] contratación para realizar preseleccion realizar la
] la ados] contrataci
contratación ó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 Dur ación Predeces oras Nombres de los recurs os
0 DANTI-09 Cronograma Base 129,5 dí as?

1 Fas e de Conce ptualizació n 27 d ías?
2 Creación de sitio 30 mins? Ejec utivo de Tec nología
3 Publicación de documentos 30 mins? 2 Ejec utivo de Tec nología
4 Vis ión Té cnica 5 d ías?
5 Rev isar documentación 1 día? 3 Ejec utivo de Tec nología;Direc tor del
Proyecto;Usuario
6 Creación DANTI-06 3 días? 5 Ejec utivo de Tec nología
7 Rev isión 1 día? 6 Director del Proy ecto
8 Apr obación 0 días? 7 Director del Proy ecto
9 Mo delación de l Neg ocio 6 d ías?
10 Analizar entorno 1 día? 6 Ejec utivo de Tec nología;Usuario
11 Creación DANTI-07 3 días? 10 Ejec utivo de Tec nología
12 Rev isión 2 días? 11 Usuario
13 Apr obación 0 días? 12 Usuario
14 Plan de Proyecto 13,13 días?
15 Creación del DA NTI-08 5 días? 13 Ejec utivo de Tec nología
16 Confeccc ionar DANTI- 09 Cronograma preliminar 1 día? 15 Ejec utivo de Tec nología
17 Confeccionar DA NTI-11 Matr iz de Comunicación 1 hora? 16 Ejec utivo de Tec nología
18 Confeccc ionar DANTI- 12 Lis ta de Riesgos 2 días? 17 Ejec utivo de Tec nología
19 Rev isión 5 días? 18 Jefes TI
20 Apr obación 0 días? 19 Jefes TI
21 Lis ta de Recur sos 3,25 días ?
22 Def inir rec ursos para el proy ecto 3 días? 20 Jefes TI
23 Confeccionar DA NTI-10 2 horas? 22 Ejec utivo de Tec nología
24 Glo sario Inicial 0,5 días?
25 Confección DANTI-19 0,5 días? 18 Ejec utivo de Tec nología
26 Leccione s apr endid as 0,5 días?
27 Confección DANTI-20 0,5 días? 23 Ejec utivo de Tec nología
28 Fas e de Elabor ación 35 d ías?
29 Mo delar casos de u so 4 d ías?
30 Analizar Necesidades 0,5 días? 20 Ejec utivo de Tec nología
31 Creación del diagrama 0,5 días? 30 Ejec utivo de Tec nología
32 Confeccionar DA NTI-03 1 día? 31 Ejec utivo de Tec nología
33 Rev isión 2 días? 32 Usuario
35 Det allar n eces idade s 19 d ías?
36 Priorizar r equerimientos 1 día? 34 Usuario;Ejecutiv o 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 Ejec utivo de Tec nología
40 Detallar necesidades no func ionales 2 días? 36 Usuario
41 DANTI-02 Espec ificaciones s uplementarias 2 días? 40 Ejec utivo de Tec nología
42 Confección de presentación a TI 1 día? 41;39 Ejec utivo de Tec nología
43 Presentac ión 1 día? 42 Ejec utivo de Tec nología
44 Entega de documentac ión 1 día? 43 Ejec utivo de Tec nología
45 Actualizar DANTI-19 Glosario 1 hora? 35 Ejec utivo de Tec nología
46 Arq uitectura 7 d ías?
47 Analisis de las necesidades 2 días? 44 Arquitecto
48 Doc umento de A rquitectura 5 días? 47 Arquitecto
49 Entr ega del documento de Ar quitec tura 0 días? 48 Arquitecto
50 Realizar estimac iones 3 días? 46;44 Ingeniero
51 Actualizac ión del cronograma 1 día? 50 Ejec utivo de Tec nología
52 Entr ega de tiempos para el director 1 día? 51 Ejec utivo de Tec nología
53 Rie sgos 4 d ías?

54 Analizar posibles riesgos 2 días? 49 Arquitecto;Ingeniero
55 Entr egar r iesgos identificados 1 día? 54 Arquitecto;Ingeniero
56 Actualizar DANTI-12 Lista de Riesgos 1 día? 55 Ejec utivo de Tec nología
57 Leccione s apr endid as 0,25 días ?
58 Confección DANTI-20 2 horas? 56 Ejec utivo de Tec nología
59 Fas e de Const rucció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 Entr egar 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 Des arrollo 20 días? 63 Ingeniero
67 Pruebas internas 3 días? 66 Ingeniero
68 II It eració n 23 d ías?
71 III It eración 23 d ías?
74 Confeccionar lis ta de materiales 3 días? 65;68;71 Ingeniero
75 Entr egar lista de mater iales 0 días? 74 Ingeniero
76 Manual Técnico 5 días 75 Ingeniero
79 Fas e de Trans ición 76,25 días?
80 Planificación d e las prueb as 15 d ías?
81 Plan de Pr uebas 5 días? 63 Implantador
82 Cas os 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 Pru ebas de us uario 15 d ías?
87 Ejec utar pruebas I Iteración 5 días? 65;85 Usuario
88 Ejec utar pruebas II Iter ación 5 días? 68;85 Usuario
89 Ejec utar pruebas III Iter ación 5 días? 71;85 Usuario
90 Pruebas Integrales 10 días? 87;88;89 Usuario
91 Manual de Usuario 5 días? 90 Usuario
92 Cap acitación 9 d ías?
93 Elaboración Plan de Capacitación 3 días? 91 Usuario;Ejecutiv o de Tecnología
94 Apr obación del Plan de Capacitación 1 día? 93 Director del Proy ecto
95 Realizar Capacitación 5 días? 94 Usuario;Implantador;Ejecutivo de Tecnología
96 Pas e a Producción 27 d ías?
97 Planificar pase 5 días? 90 Implantador;Ejec utivo de Tec nología
98 Realizar pase a producción 5 días? 97 Implantador
99 Elaboración Plan Piloto 3 días? 90 Director del Proy ecto
100 Ejec utar Plan Piloto 15 días? 99;98 Usuario
101 Reporte de resultados Plan Piloto 2 días? 100 Usuario
102 Apr obación Plan Piloto 0 días? 101 Usuario
105 Cie rre de l Pro yecto TI 17,13 días?

106 Ace ptación 0,13 días ?
107 DANTI-15 Nota de aceptación 1 hora? 102 Usuario
108 Entr ega de Nota 0 días? 107 Usuario
109 Pre sentación del pr oduct o 2 d ías?
110 Preparar Presentación 1 día? 98 Ejec utivo de Tec nología
111 Presentac ión 1 día? 110 Ejec utivo de Tec nología
112 Not a de cierre 3 d ías?
113 Confeccionar DA NTI-16 1 día? 111 Ejec utivo de Tec nología
114 Apr obación del Cierre 2 días? 113 Jefes TI
115 Leccione s apr endid as 1 d ía?
116 Confección DANTI-20 1 día? 114 Ejec utivo de Tec nologí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

Nombre Dependencia Correo Rol

Teléfono Fase Fecha Horas/
electrónico estimada semana
[Nombre [Dependencia [Rol [Correo [Teléfono] [Fases del [Fecha [Cantidad
del a la cual dentro electrónico] proyecto estimada de horas
recurso] pertenece] del en las que de inicio y disponibles
proyecto] participará] finalización por
en que semana
participará para
en el participar
proyecto] 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
reuniones con
Solicitudes de
proveedores
Minutas de
Minutas de
reuniones
Proyecto
Semanal
Mensual
Plan del
internas
Informe
Informe
cambio
DANTI – 11 Matriz de Comunicación
Involucrado Rol en el Sem. Men. Sem. Sem. Otro. Otro

Proyecto
[Nombre del [Rol dentro
involucrado] 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

ID Riesgo Probabilidad Impacto Categoría Acción Actividad Estado

[ID del [Descripción [Probabilidad [Impacto, [Acuerdo a [Indicar [Actividad [Estado
riesgo] del riesgo] de ocurrencia tabla 1] la si se que se del
de 1 a 100%] probabilidad mitiga, realizará riesgo:
y al se para Activo o
impacto, elimina enfrentarlo] Inactivo]
tabla 2] o se
acepta]
Tabla 1. Definición de Impacto

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.
Tabla 2. Definición de la categoría

Impacto /
Probabilidad
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

Información general
Fecha:
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 [Fecha [% de [% [Diferencia
de inicio] final] avance] Esper progreso y
ado] real]
Amenazas
[Identificar las actividades que son necesarias resolver para no provocar impactos
en el proyecto]
Amenazas Fecha Responsable Impacto Estatus

[Actividad [Fecha [Responsable de [Impacto [Estado de
identificada] máxima a realizar la para el la actividad]
ejecutar] actividad ] proyecto]
Prioridades para la próxima semana:

[Identificar tareas prioritarias que se deben ejecutar la próxima semana.]
4.2.3.14 DANTI-14: Informes de avance mensual
Objetivo: Llevar el control mensual del avance del proyecto.

Descripción: Esta plantilla especifica los elementos mínimos que debe contener
un informe mensual.
Cuadro 16. DANTI-14 Informe mensual
DANTI – 14 Informe mensual

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

DANTI-[Consecutivo]-[Año]
Fecha:
Fecha de inicio: Fecha de finalización:
[Fecha de inicio real del proyecto] [Fecha de finalización del proyecto]
[Nombre del director del proyecto] [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 Fecha y hora
[Nombre y firma del ejecutivo de [Fecha y hora de la entrega]
tecnología]
Aprobado por Fecha y hora
[Nombre y firma del director del [Fecha y hora de la aprobación]
proyecto]
Receptores
Receptores Fecha y hora
[Nombre y firma de de los receptores [Fecha y hora de la recepción]
de la nota]
4.2.3.17 DANTI-17: Recepción de entregables
Objetivo: Documentar la recepción de entregables.

Descripción: Esta plantilla sirve como registro para la recepción de los
entregables desarrollados durante el proyecto.
Responsable: Miembros del Equipo.
Fase del proyecto a utilizar: Todas las fases del proyecto.
Cuadro 19. DANTI-17 Recepción de entregables
DANTI – 17 Recepción de entregables

Fecha:
[Número del Proyecto] [Nombre del proyecto]
Información del entregable
Responsable:
[Nombre de la persona que responsable del entregable]
Nombre:
[Nombre del entregable]
Descripción:
[Descripción general del entregable]
Tarea asociada:
[Tarea asociada según cronograma]
Resolución
Resolución
[Marcar con una “X” la solución seleccionada]
Aceptado Rechazado
Justificación
[En el caso que el entregable es rechazado, indicar las razones por las cuales se
realiza el rechazo y los ajustes requeridos para que el entregable sea aceptado.]
Responsables
Entregado por Fecha y hora
[Nombre y firma de la persona que [Fecha y hora de la entrega]
realiza la entrega]
Recibido por Fecha y hora
[Nombre y firma del receptor del [Fecha y hora de la resolución del
entregable] entregable]
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

Fecha: Número de Cambio:
[Indicar la fecha de confección] [Consecutivo de cambio para el proyecto]
Solicitante: Rol del solicitante:
[Nombre de la persona que gestiona el [Rol de la persona dentro del proyecto
cambio] que gestiona el cambio]
Cambio propuesto
Descripción del cambio:
[Descripción detallada del cambio propuesto]
Impacto de no realizar el cambio:
[Justificación de la solicitud de cambio]
Registro del impacto
Responsable del análisis Fecha:
[Nombre de la persona que realiza el [Fecha de realización del análisis]
análisis]
Impacto Técnico: Impacto en Presupuesto:
[Indicar el impacto a nivel técnico que [Indicar el impacto en presupuesto de
provoca el cambio] realizar el cambio propuesto]
Impacto en Cronograma: Impacto en otros Proyectos:
[Indicar si el cambio provoca [Indicar si el cambio impacta a otros
modificaciones al cronograma proyectos]
propuesto]
Resolución
Resolución
[Marcar con una “X” la solución seleccionada]
Aceptado Rechazado
Justificación
[Indicar las razones por las cuales procede el cambio]
Responsables
Implementar cambio Fecha y hora
[Nombre y firma del ejecutivo de [Fecha y hora de la firma de la resolución]
tecnología]
Autorizar cambio Fecha y hora
[Nombre y firma del director de [Fecha y hora de la firma de la resolución]
proyecto]
4.2.3.19 DANTI-19: Glosario
Objetivo: Documentar términos o abreviaturas del proyecto.

Descripción: En este documento se definen términos y abreviaturas que se
utilizan desde el inicio hasta la finalización del proyecto. Estos conceptos pueden
ser de índole técnico o del negocio. Utilizar el formato definido en el “Anexo 8
Formato de los documentos”.
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


Fecha:
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 1. Plan del proyecto 1. Lecciones aprendidas
2. Modelación del negocio 2. Matriz de
comunicación
3. Lista de Recursos
4. Glosario
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 Revisar la información de Oracard antes de
Pago Electrónico trasladarla al nuevo sistema.
Jefes de Crédito Brindar la información de los clientes de crédito
Grupo 1
Dirección de Crédito Definir los aspectos operativos para cumplir con la
normativa.
Dirección de Coordinación Identificar las validaciones realizadas por la
de Entes Reguladores SUGEF
3.2 Resumen del Usuario

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

Problema Solución actual Solución que desea el

usuario
Cambio de esquema de Envió de archivos de texto, Envió de archivos en el
envío de información los cuales se envían por el formato y seguridad
crediticia sistema llamado estipulado por la SUGEF.
Ingresador de la SUGEF
Cambio en la normativa No hay Tener una aplicación que
definida por la SUGEF permita aplicar las
condiciones establecidas
en la nueva normativas de
SUGEF
Reglas de validación para No hay Tener un sistema que
el envío de información permita aplicar las reglas
establecidas por la SUGEF
Consolidar la información Consolidación en BUCRE Sustituir BUCRE por un
crediticia 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.3 Referencias

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.3 Referencias
2 Generalidades del proyecto
El proyecto Aplicación Normativa Prudencial de la SUGEF (ANPS) tiene como objetivo

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

Visión Técnica del Documento para Revisar documentación
proyecto identificar la visión
desde el punto de Creación DANTI-06
vista técnico de la Revisión
solución Aprobación
Modelación del Documento con la Analizar entorno
Negocio modelación de las
funcionalidades desde Creación DANTI-07
la perspectiva del Revisión
negocio. Aprobación
Plan de Proyecto Documento que sirve Creación del DANTI-08
como guía para el Confeccionar DANTI-09 Cronograma
desarrollo del plan de preliminar
proyecto, formato y
Confeccionar DANTI-11 Matriz de
considerar. Comunicación
Confeccionar DANTI-12 Lista de Riesgos
Revisión del plan
Aprobación del plan
Definir recursos para el proyecto
Confeccionar DANTI-10
Glosario Documento en el que Confección DANTI-19
Formulario se Publicación
documentan términos
y abreviaciones del
proyecto
Lecciones Plantillas donde se Confección DANTI-20
aprendidas documentan las
lecciones aprendidas
del proyecto Publicación
Modelo de casos de Documento con el Analizar Necesidades
uso diagrama de los
requerimientos Creación del diagrama
funcionales del Confeccionar DANTI-03
producto Revisión
Aprobación
Detalle de Documentos con las Priorizar requerimientos
requerimientos especificaciones
funcionales como no Confección de requerimientos
funcionales del Revisión
producto Aprobación
Detallar necesidades no funcionales
DANTI-02 Especificaciones suplementarias
Confección de presentación a TI
Presentación
Entrega de documentación
Arquitectura Documento con la Análisis de las necesidades
especificación
arquitectónica del Documento de Arquitectura
producto Entrega del documento de Arquitectura
Riesgos Documentar los Analizar posibles riesgos
riesgos asociados al
proyecto para su Entregar riesgos identificados
seguimiento y control Actualizar DANTI-12 Lista de Riesgos
Diseño de la Documento con el Analizar el producto
aplicación diseño del producto Confeccionar documento de Análisis y
Diseño
Entregar documento de Análisis y Diseño
Solución Sw Producto de software Modificación DTS existentes
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
Lista de materiales Documento con la lista Confeccionar lista de materiales
de materiales del
producto a
implementar Entregar lista de materiales
Manuales Manuales técnicos y Confección del Manual Técnico
del usuario
Confección del Manual de Usuario
Plan de pruebas Documento con la Confección de Plan de Pruebas
planificación y el
ambiente para realizar Confección de Casos de prueba
las pruebas del Revisión de Casos de prueba
producto Aprobación de casos de prueba
Preparar ambientes de pruebas
Solución probada Producto probado por Ejecutar pruebas I Iteración
el usuario
Ejecutar pruebas II Iteración
Pruebas Integrales
Capacitación Capacitación técnica y Elaboración Plan de Capacitación
operativa del producto
Aprobación del Plan de Capacitación
Realizar Capacitación
Solución en Producto Planificar pase
producción implementado en
producción Realizar pase a producción
Elaboración Plan Piloto
Ejecutar Plan Piloto
Reporte de resultados Plan Piloto
Aprobación Plan Piloto
Nota de aceptación Documentar la DANTI-15 Nota de aceptación
de la solución aceptación del usuario
Entrega de Nota
Nota de cierre del Documentar el cierre Confeccionar DANTI-16
proyecto 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 Dur ación Comienzo Fin Predeces oras
Nombres de los recurs os
0 ANPS 284,5 dí as lun 09/01/06 vie 23/02/07

1 Fas e de Conce ptualizació 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 Mo delación de l Neg ocio 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 Glo sario Inicial 0,5 días mié 01/02/06 mié 01/02/06
26 Leccione s apr endid as 0,5 días mié 08/02/06 mié 08/02/06
28 Fas e de Elabor ación 93 d ías vie 03/02/06 mié 14/06/06
29 Mo delar casos de u so 4 d ías vie 03/02/06 jue 09/02/06
35 Det allar n eces idade s 29 d ías jue 09/02/06 mié 22/03/06
45 Actualizar DANTI-19 Glosario 1 hora mié 22/03/06 mié 22/03/06 35 Ejec utivo de Tec nología
46 Contratac ión 60 días mié 22/03/06 mié 14/06/06 35 Ingeniero
47 Arq uitectura 7 d ías mié 22/03/06 vie 31/03/06
51 Realizar estimac iones 3 días vie 31/03/06 mié 05/04/06 47;44 Ingeniero
52 Actualizac ión del cronograma 1 día mié 05/04/06 jue 06/04/06 51 Ejec utivo de Tec nología
53 Entr ega de tiempos para el director 1 día jue 06/04/06 vie 07/04/06 52 Ejec utivo de Tec nología
54 Rie sgos 4 d ías vie 31/03/06 jue 06/04/06
58 Leccione s apr endid as 0,25 días jue 06/04/06 jue 06/04/06
60 Fas e de Const rucció 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 Des arrollo de la solu ción 145 días lun 17/04/06 lun 06/11/06
91 Leccione s apr endid as 0,25 días lun 06/11/06 lun 06/11/06
93 Fas e de Trans ición 214,25 días lun 17/04/06 vie 23/02/07
94 Planificación d e las prueb as 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 Pru ebas 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 Cap acitació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 endid as 0,25 días vie 23/02/07 vie 23/02/07
118 Cie rre de l Pro yecto TI 17,13 días mié 31/01/07 vie 23/02/07
119 Ace ptación 0,13 días vie 23/02/07 vie 23/02/07
122 Pre sentación del pr oduct o 2 d ías mié 31/01/07 vie 02/02/07
125 Not a de cierre 3 d ías vie 02/02/07 mié 07/02/07
128 Leccione s apr endid as 1 d ía mié 07/02/07 jue 08/02/07
3.2.3 Ruta Crítica del Proyecto

A continuación se detallan las tareas que conforman la ruta crítica
Id 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
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
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
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
Trabajo
6.000
5.000
4.000
Horas
3.000
2.000
1.000
-
Ene-06 Feb-06 Mar-06 Abr-06 May-06 Jun-06 Jul-06 Ago-06 Sep-06 Oct-06 Nov-06 Dic-06 Ene-07 Feb-07
Meses
3.2.5 Presupuesto de actividades
Costo
Id Nombre Comienzo Fin
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

Patrocinador del proyecto
Director del proyecto
Ejecutivo de tecnología Usuarios Expertos
Arquitecto Usuario de Crédito
Soportista Técnico Usuario de Contabilidad
Implementador Usuario de Entes
Ingeniero Usuario de tarjetas
Desarrolladores Jefes de Crédito
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
Implementador
Desarrollador
Arquitecto
Ingeniero
Ejecutivo
Director
Jefes TI
Usuario
EDT Nombre
0 ANPS
1.1 Creación de sitio
1.2 Publicación de documentos
1.3.1 Revisar documentación
1.3.2 Creación DANTI-06
1.3.3 Revisión
1.3.4 Aprobación
1.4.1 Analizar entorno
1.4.2 Creación DANTI-07
1.4.3 Revisión
1.4.4 Aprobación
1.5.1 Creación del DANTI-08
Confeccionar DANTI-09 Cronograma
1.5.2 preliminar
Confeccionar DANTI-11 Matriz de
1.5.3 Comunicación
1.5.4 Confeccionar DANTI-12 Lista de Riesgos
1.5.5 Revisión
1.5.6 Aprobación
1.6.1 Definir recursos para el proyecto
1.6.2 Confeccionar DANTI-10
1.7.1 Confección DANTI-19
2.1.1 Analizar Necesidades
2.1.2 Creación del diagrama
2.1.4 Revisión
2.1.5 Aprobación
2.2.1 Priorizar requerimientos
2.2.2 Confección de requerimientos
2.2.3 Revisión
2.2.4 Aprobación
2.2.5 Detallar necesidades no funcionales
2.2.6 DANTI-02 Especificaciones suplementarias
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
Confeccionar documento de Análisis y
3.1.2 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.1.4 Aprobació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
3.3.4 Matriz de comunicación

reuniones con
Solicitudes de
proveedores
Minutas de
Minutas de
reuniones
Proyecto
Semanal
Mensual
Plan del
internas
Informe
Informe
cambio
DANTI – 11 Matriz de
Comunicación
Involucrado Rol en el Sem. Men. Sem. Sem. Otro. Otro

Proyecto
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

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.
3.4.2 Categorías de Riesgos
Impacto /
Probabilidad
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 70% Serio Medio
que afecten el alcance porque
los requerimientos no están
bien definidos puede generar
aumento en el costo del
proyecto
2 Si se da un atraso en el inicio 80% Serio Medio
del desarrollo del producto
puede generar que el costo del
proyecto supere lo aprobado
3 Si se presentan problemas en 10% Moderado Bajo
la aprobación del presupuesto
puede provocar atrasos en el
inicio del proyecto.
4 Si se dan retrasos en la 50% Moderado Medio
contratación para el desarrollo
del sistema puede generar
atrasos en el cronograma
5 Si el usuario no participa en el 10% Crítico Medio
proceso de pruebas del sistema
puede afectar la calidad del
producto final.
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- Responsable Disparador

puesto
1 Mitigar Realizar sesiones con los Realizar controles de Costo: Director del Que se presenten
usuarios para la cambio solo para $2,000.00 proyecto dos solicitudes de
elaboración de casos de requerimientos críticos Tiempo: cambio
uso. (que impidan la puesta 80 hora
Análisis de los casos de en producción del
uso con el personal producto)
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).
2 Transferir En el contrato se debe Ingeniero En el
incluir las cláusulas seguimiento,
donde se especifiquen existen atrasos en
las multas por atraso en los porcentajes de
la entrega del producto. trabajo finalizado
Riesgo Estrategia Acción Contingencia Presu- Responsable Disparador

puesto
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 Implementador Usuario no desea
pruebas con los usuarios. participar en las
Realizar reunión con los reuniones de
usuarios y sus jefaturas seguimiento y no
para explicar el proceso desea realizar el
de pruebas y obtener el proceso de
compromiso pruebas
3 Aceptar Solicitar al patrocinador Director del Se recibe nota de
la incorporación del proyecto la presupuesto
proyecto dentro del acerca de la no
portafolio de proyectos o aprobación del
solicitar presupuesto de presupuesto
las áreas beneficiadas.
Realizar estimaciones
para el desarrollo con
recurso interno.
Ajustar los tiempos en el
cronograma con los
tiempos internos.
3.5 Adquisiciones del proyecto
3.5.1 Matriz de Adquisiciones
Nombre de Descripción de la contratación Costo Estimado Fecha límite Posibles Responsable

Contratación contratación Proveedores
Ingeniería-01 Desarrollo de la aplicación $ 140,000.00 14/06/2007 Grupo MAS William Romero
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

Nombre Dependencia Rol Correo Teléfono Fase Fecha Horas/

electrónico estimada semana
Alejandra Análisis de Ejecutivo de Conceptualización, 09/01/2006 8 horas
Mora Negocio Tecnología Elaboración, al
Constricción, 23/02/2007
Transición, Cierre
Oldemar Arquitectura de Arquitecto Elaboración 03/02/06 6 horas
Vargas Servicios de TI al
14/06/06
William Ingeniería de Ingeniero Elaboración, 03/02/2006 8 horas

Romero Servicios de TI Constricción al
06/11/2006
Edwin Implantación Implementador Transición 17/04/2006 8 horas
León de Servicios de al
TI 23/02/2007
Mario Servicios en Soportista Transición 17/01/2007 6 horas
Gamboa Producción Téc. al
23/01/2007
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


Fecha:
02/11/2007
ANPS 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 Dur ación Comienzo Fin Predeces oras
0 Pla n de divulgación 20, 5 día s lun 21/01/08 lun 18/02/08

1 Des arrollo del contenido 5 días lun 21/01/08 vie 25/01/08
2 Confección de un manual 5 días lun 28/01/08 vie 01/02/08 1
3 Confección de la presentación 2 días lun 04/02/08 mar 05/02/08 2
4 Impresión del material 0,5 días mié 06/02/08 mié 06/02/08 3
5 Def inición de un caso práctic o 1 día mié 06/02/08 jue 07/02/08 4
6 Impartir capacitación 1 día jue 07/02/08 vie 08/02/08 5
7 Entr ega del caso a res olver 1 día vie 08/02/08 lun 11/02/08 6
8 Valoración del resultados 5 días lun 11/02/08 lun 18/02/08 7
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

Fecha: Nombre de Proyecto:
18 de julio 2007 Metodología para estandarización de la Administración de
Proyectos Informáticos dentro de la Dirección de Tecnología de
Información y Comunicaciones del Banco Nacional
Áreas de conocimiento / procesos Área de aplicación (sector / actividad):
Conceptualización, Planificación, Dirección de Análisis de Negocio /
Seguimiento y Control, Cierre Dirección Corporativa de Tecnología de
Información y Comunicaciones / Banco
Nacional de Costa Rica
Fecha de inicio del proyecto: Fecha tentativa de finalización del
18 de julio del 2007 proyecto:
05 de febrero del 2008
Objetivo General:
Elaborar una Metodología para la Administración de Proyectos Informáticos dentro
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
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: Nombre de Proyecto:
18 de julio 2007 Metodología para estandarización de la Administración de
Proyectos Informáticos dentro de la Dirección de Tecnología
de Información y Comunicaciones del Banco Nacional
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
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 Dur ación Comienzo Fin Predeces orasNombres de los
rec ursos
0 Cronograma 204 día s mi é 18/ 07/07 mi é 06/ 02/08
1 Sem inar io 41 días m ié 18/07/07 lun 27/08/07
2 Ent regab le 1 15 días m ié 18/07/07 m ié 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 Des arrollo del Cronogr ama 1 día mar 24/07/07 mar 24/07/07 4 Alejandra Mora
7 Presentac ión del char ter 0 días lun 23/07/07 lun 23/07/07 3 Alejandra Mora
8 Entrega del charter, declarac ión, WBS y cronograma 0 días mié 25/07/07 mié 25/07/07 6 Alejandra Mora
9 Rev isión del charter, declaración, WBS y cronograma 7 días jue 26/07/07 mié 01/08/07 8 Instructor Miguel
10 Ent regab le 2 20 días m ié 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 introduc ción 0 días lun 06/08/07 lun 06/08/07 11 Alejandra Mora
13 Rev isión de la introduc ción 7 días mar 07/08/07 lun 13/08/07 12 Instructor Miguel
14 Ent regab le 3 17 días lun 30/07/07 m ié 15/08/07
15 Preparación del marco teóric o 6 días lun 30/07/07 sáb 04/08/07 11 Alejandra Mora
16 Entrega del mar co teórico 0 días mié 08/08/07 mié 08/08/07 15 Alejandra Mora
17 Rev isión del marco teórico 7 días jue 09/08/07 mié 15/08/07 16 Instructor Miguel
18 Ent regab le 4 16 días dom 05/08/07 lun 20/08/07
19 Preparación del marco metodológic o 8 días dom 05/08/07 dom 12/08/07 15 Alejandra Mora
20 Entrega del mar co metodológico 0 días lun 13/08/07 lun 13/08/07 19 Alejandra Mora
21 Rev isión del marco metodológico 7 días mar 14/08/07 lun 20/08/07 20 Instructor Miguel
22 Ent regab le 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 res umen 0 días mié 22/08/07 mié 22/08/07 23 Alejandra Mora
25 Rev isión del esquema de contenidos, bibilograf ía y resumen 4 días jue 23/08/07 dom 26/08/07 24 Instructor Miguel
26 Docum e nto fin al 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

rec ursos
29 Des arrollo del PFG 93 días m ar 28/08/07 m ié 28/11/07
30 Coordinac ión tutorial 7 días mar 28/08/07 lun 03/09/07 28
31 An álisis y reco m en dacio nes d el pro ceso 28 días m ar 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 Enc uestados
34 Realizar entrevistas 3 días vie 07/09/07 dom 09/09/07 33
35 Análisis de resultados 5 días lun 10/09/07 vie 14/09/07 34 Alejandra Mora
36 Análisis de áreas que se utilizan actualmente 5 días sáb 15/09/07 mié 19/09/07 35 Alejandra Mora
37 Rec omendaciones sobre áreas a desarr ollar 5 días jue 20/09/07 lun 24/09/07 36 Alejandra Mora
38 An álisis discip linas de PM I y lo s pro cesos de T I 14 días m ar 25/09/07 lun 08/10/07
39 Análisis de proc esos de TI 3 días mar 25/09/07 jue 27/09/07 37 Alejandra Mora
40 Análisis disciplinas PMI 3 días vie 28/09/07 dom 30/09/07 39 Alejandra Mora
41 Realizar entrevistas 3 días lun 01/10/07 mié 03/10/07 40
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 Pro ceso s 10 días m ar 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 m e todolo gí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

rec ursos
56 Plan de d ivulg ación 5 d ías dom 04/11/07 jue 08/11/07
57 Def inición de inv olucrados 1 día dom 04/11/07 dom 04/11/07 53 Alejandra Mora
58 Def inición de tar eas a realizar 2 días lun 05/11/07 mar 06/11/07 57 Alejandra Mora
59 Calendarización de ac tividades 1 día mié 07/11/07 mié 07/11/07 58 Alejandra Mora
60 Def inición de recursos necesarios 1 día jue 08/11/07 jue 08/11/07 59 Alejandra Mora
61 Redacción de c onclus iones 5 días vie 09/11/07 mar 13/11/07 56 Alejandra Mora
62 Redacción de recomendaciones 5 días mié 14/11/07 dom 18/11/07 61 Alejandra Mora
63 Me todología f inal 10 días lun 19/11/07 m ié 28/11/07
64 Rev isión general 5 días lun 19/11/07 vie 23/11/07 62 Tutor
65 Cor recciones generales 5 días sáb 24/11/07 mié 28/11/07 64 Alejandra Mora
66 Apr obación del PFG 0 días mié 28/11/07 mié 28/11/07 65 Tutor
67 Cie rre 70 días jue 29/11/07 m ié 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 m ar 22/01/08 m ié 06/02/08
74 Coordinac ión 10 días mar 22/01/08 jue 31/01/08 72 Alejandra Mora
75 Confeccionar pr esentación 15 días mar 22/01/08 mar 05/02/08 72 Alejandra Mora
76 Presentac ión 1 día mié 06/02/08 mié 06/02/08 75 Alejandra Mora
Anexo 5 Resultado de las entrevistas
Pareto de los problemas a los que se enfrenta DANTI
Personal responde al jefe de

12,0% línea
Disponibilidad de los recursos
10,0%
Estandarización
8,0% Definición del alcance
Personal sobre cargado

6,0%
Recursos no comprometidos
4,0%
Poca Planificación
2,0% Recursos sin experiencia
0,0% Responsabilidad de cada

Problemas miembro
Madurez 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 Justificación:

resolver:
1.
2.
3.
4. Otros...
Descripción general de la Solución propuesta:
Definición de Objetivos Unidad de Medida

1.
2.
3.
4. Otros...
Objetivo Institucional Relacionado con el Proyecto
Impacto en el Banco Nacional

Oficinas Relacionadas Servicios o Sistemas Documentos relacionados
relacionados
Estimación preliminar de los Recursos:

Presupuesto Inversiones:
Recursos humanos: Tiempo:
Unidad Organizativa y nombre del Firma:
solicitante:
Nombre: Firma:
Director Corporativo, Regional o VB. Director Corporativo, Regional o
Gerente de Sociedad Anónima 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
Tasa Interna
Valor Actual Neto
¢ de Rend. %
(V.A.N.):
(T.I.R.):
Factores Críticos de Éxito:
Recursos Técnicos Recursos Recursos Recursos Humanos Otros
Financieros Administrativos
1. 1. 1. 1. 1.
2. 2. 2. 2. 2.
3. 3. 3. 3. 3.
Identificación de Roles y Responsabilidades:
Rol Nombre Dedicación Localización
del Semanal
recurso
Administrador del Producto:
Director del Proyecto
Equipo Desarrollador
Equipo Capacitador
Equipo de pruebas:
Equipo de Logística:
Perfiles de los Usuarios:
Usuario Descripción de Dedicación Localización
Funciones Semanal
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 Nombre:
Proyecto: Firma:
Firma del Director del Proyecto:
Nombre: Nombre:
Firma: Firma:
Nombre: Nombre:
Firma: Firma:
Aprobación del Documento de Justificación:
Nombre: Firma:
Director Corporativo, Regional, Director Corporativo, Regional, Gerente de
Gerente de Sociedad Anónima Sociedad Anónima
Es designado como Patrocinador
del Proyecto
AP-003-2002 “MINUTAS”
MINUTA No.XX
Nombre del Proyecto:
Fecha: Lugar:
PRESENTES: nombre de la dependencia a la cual

Nombres y apellidos pertenece cada participante
AUSENTES: nombre de la dependencia a la cual

Nombres y apellidos pertenece cada participante
TEMAS TRATADOS:
NOMBRE DEL TEMA RESPONSABLE

En este espacio se debe indicar los Especificar el nombre de la persona
puntos tratados en la sesión de trabajo quien expuso la idea o comentario
ACUERDOS TOMADOS:
ACUERDO: RESPONSABLE: FECHA:

En este espacio se debe Se refiere a la persona Se especifica la fecha
especificar el acuerdo o unidad encargada de límite para lograr la
tomado con su respectiva realizar la tarea o actividad o tarea acordada.
numeración actividades para
cumplir con el acuerdo
tomado.
APROBACIÓN DE ACUERDOS:
Como resultado de la sesión de trabajo realizada el o los acuerdos tomados en el
presente documento son avalados en su totalidad e integridad por los abajo
firmantes (personas participantes de la sesión de trabajo):
Nombre: Nombre: Nombre: Nombre: Nombre: Nombre:
Firma: Firma: Firma: Firma: Firma: Firma:
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:
ACCIÓN ADMINISTRATIVA
SITUACIÓN PRESENTADA
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]

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

Proyecto++informatico Desbloqueado PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Proyecto++informatico Desbloqueado PDF

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL

METODOLOGIA PARA ESTANDARIZACION DE LA

MARIA ALEJANDRA MORA RODRIGUEZ

PROYECTO FINAL DE GRADUCIACION PRESENTADO COMO

San José, Costa Rica

Este Proyecto Final de graduación fue aprobado por la Universidad como

A Juan Carlos, por su colaboración y apoyo en este proceso.

A mi mamá, porque gracias a su esfuerzo he logrado llegar hasta aquí.

A mi papá que a la distancia siempre recibo su apoyo.

CAPITULO 1 INTRODUCCION ........................................................................... 1

1.1 Antecedentes .................................................................................................... 2

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

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

1.4 Objetivos ........................................................................................................... 4

CAPITULO 2 MARCO TEORICO ........................................................................ 5

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

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

CAPITULO 3 MARCO METODOLOGICO......................................................... 30

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

3.2 Entregables ..................................................................................................... 33

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

CAPITULO 4 DESARROLLO ............................................................................ 38

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

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

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

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

CAPITULO 5 CONCLUSIONES Y RECOMENDACIONES............................. 139

5.1 Conclusiones ................................................................................................ 140

5.2 Recomendaciones ........................................................................................ 142

BIBLIOGRAFIA .................................................................................................. 145

ANEXOS ............................................................................................................. 147

Anexo 1 Acta del proyecto....................................................................................... 148

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

Figura 1. Organigrama BNCR (BNCR, 2007)_____________________________ 8

Cuadro 1. Cuestionarios análisis del proceso actual............................................. 33

ANPS Aplicación Normativa Prudencial SUGEF

BNCR Banco Nacional de Costa Rica

BUCRE Base Única de Crédito

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

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

Dirección Corporativa de Tecnología de Información y

DEP Dirección de Estrategia y Proyectos

DTS Data Transformation Services

FINESSE Sistema de Cajas

IBM International Business Machines

MTVAL Módulo de Transferencia de Valores

OGC Office of Government Commerce

Oracard Sistema de Administración de Tarjetas de Crédito

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

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

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